Start with one workflow that costs the most manual time. Prove value there before expanding.
Step 1: Pick a slice small enough to fail safely
Run a pilot that produces a go/no-go decision in four weeks.
Choose one team, one product line, or one region to run the pilot, something contained enough that if something goes wrong, the impact is limited and recoverable. A pilot that is too large to fail safely is really just a full launch with a different name.
A useful test: if the pilot failed completely tomorrow, would it be a minor inconvenience or a real problem for the business? If the honest answer is a real problem, the scope is too big for a first pilot. Scale down until the honest answer is a minor inconvenience, then start there. You can always expand the pilot later once you have real evidence that it is worth expanding.
Include a rough sense of what an acceptable range looks like, not just a single perfect number.
Step 2: Define what pass and fail actually look like before you start
Agree on specific numbers before the pilot begins: acceptable error rate, response time, or cost per transaction. Deciding what success means after seeing the results invites everyone to interpret the data in whatever way supports the conclusion they already wanted.
Write these numbers down and share them with everyone involved before the pilot starts. This single step prevents most of the arguments that otherwise happen once the results actually come in, and it keeps everyone evaluating the same pilot against the same standard.
Include a rough sense of what an acceptable range looks like, not just a single perfect number. Real pilots rarely land on an exact target, and having a range agreed in advance avoids a pointless debate over whether a near-miss counts as a pass.
Working on something similar?
Let's talk →Step 3: Run it alongside the current process, not instead of it
Working on something similar?
Let's talk →Where possible, run the automated version in parallel with the existing manual process for at least part of the pilot, comparing results side by side. This gives you a direct comparison instead of relying on memory of how things used to work before the change.
This parallel run also gives you a safety net. If the new process has a serious flaw, the manual version is still there, running, and nothing falls through the cracks while you investigate. It costs some extra effort during the pilot period, and it is almost always worth it for the peace of mind alone.
Where a true parallel run is not practical, at minimum keep a clear record of how the old process performed recently, so you still have something concrete to compare the pilot’s results against rather than a vague memory of how things used to go.
Step 4: Decide who reviews the results and when
Set a specific date to review the pilot’s results against the criteria you defined at the start, with a named person responsible for making the go or no-go call. Without this, pilots have a way of running indefinitely without ever becoming a real decision.
Put this date on the calendar the same day the pilot launches, not weeks later once someone remembers to schedule it. A pilot without a scheduled review date tends to quietly become the new permanent process by default, without anyone ever formally deciding that it should. Treat the review meeting itself as a required step of the pilot, not an optional wrap-up that happens only if there is time for it.
Share the outcome of that review with everyone who was involved in the pilot, not just the people who made the final call. Whether the decision is to expand, adjust, or stop, closing the loop clearly keeps trust in the process for the next pilot you run.
Your pre-deployment checklist
Before you move forward, confirm:
- You have chosen a pilot scope small enough to fail safely if needed, with a clear owner assigned.
- Success and failure criteria are defined with specific numbers before starting.
- The pilot runs long enough to cover a full normal cycle of the process.
- Where possible, results are compared against the existing manual process.
- The team involved knows it is a pilot and feels able to report problems honestly.
- A specific date and owner are set for the go or no-go decision.
If you want a clear next step after reading this, start with an AI readiness assessment to map where automation fits your operations.
