An automation discovery phase should deliver five things: the current process mapped with real volumes and timings, the exceptions and how often they occur, a costed shortlist of candidate improvements, a recommended first scope, and an honest list of what is still unknown. If it delivers only a proposal, it was a sales exercise.
Two to six weeks is normal for a single process. Longer usually means the scope was never bounded. Shorter usually means the exceptions were not found, and exceptions are what determine the real cost.
Key takeaways
- Exceptions are the deliverable: The happy path is easy to map and rarely where the cost lives.
- Real numbers, not estimates: Volumes and timings should come from observation or system data, not from interviews alone.
- You should own the output: A discovery you can take to any supplier is worth paying for; a free one exists to justify a proposal.
- "We don't know yet" is a valid finding: A discovery with no open questions has not looked hard enough.
Map the process as it actually runs
Interviewing managers produces the intended process. Following real cases produces the actual one, and the gap between them is where automation projects fail.
Discovery should include sitting with the people doing the work and tracing individual cases end to end: every step, who performs it, how long it waits between steps, and what happens when something is missing. It should capture the spreadsheets, the messages, the side notes and the informal escalations, because those workarounds encode rules that no process document contains.
Ask to see the output as a map anyone in the business can read. If it requires the consultant to explain it, it will not be used after they leave.
Produce evidence, not impressions
Evidence means numbers: cases per month, time per case, wait time between steps, error and rework rate, and the cost of each. Where systems can supply this, it should come from systems. Where they cannot, a fortnight of manual sampling produces a defensible baseline.
Workflow means the documented rules, including the conditional ones and who holds authority at each decision.
Boundaries mean what is in and out of the first scope, stated explicitly, with the reasoning. This is the section that prevents the project expanding indefinitely.
Pilot means a recommended first implementation small enough to prove the approach and large enough to produce a measurable result.
Insist on the exception catalogue
The routine 80% of a process is straightforward to automate. The remaining 20% determines whether the system is adopted or quietly bypassed.
A discovery should list the exceptions, how frequently each occurs, and what currently happens. It should then recommend which ones the software handles, which route to a person, and which the business should stop allowing. That third category is often the most valuable output, because some exceptions exist only because nobody has ever been asked to justify them.
If the exception list is short and tidy, it is probably incomplete. Real processes accumulate awkward cases, and a discovery that found none has been talking to the wrong people.
Get a costed shortlist, not a single recommendation
A useful discovery presents options with numbers attached: what each would cost to implement, what it would save annually, how long it would take, and what could go wrong. Including the option of changing the process without software at all, which is sometimes the correct answer.
A discovery that arrives at exactly one recommendation, which happens to be a large build by the firm that ran the discovery, has told you about the supplier rather than about your process.
For how to turn the shortlist into an approvable case, see how to build a business case for custom software.
Pay for it, and own the output
Free discovery is priced into a proposal you have not yet agreed to, and it is designed to lead somewhere. Paid discovery, with a contract stating the output is yours to use with any supplier, costs a fraction of a build and changes the incentives completely.
It also gives you a low-risk way to evaluate a partner. How a firm behaves during a paid discovery — whether they ask about your exceptions, whether they tell you something you did not want to hear — predicts how they will behave during delivery far better than a reference call.
Expect open questions in the output
A discovery that answers everything is either unusually simple or not being honest. Some things are genuinely unknowable until you build: how staff will respond to a changed workflow, whether an undocumented legacy integration behaves as described, what volume looks like at peak.
The right output names these, states what would resolve each, and recommends how the first phase can reduce the uncertainty cheaply. That is what distinguishes a discovery from a proposal wearing a discovery's clothes.
Related guides
Related reading:
- How to Build a Business Case for Custom Software
- Approval Workflow: Steps, Rules, and Software Requirements
- Spreadsheet Workflow Problems: Costs, Risks, and Alternatives
If the work prompted by What an Automation Discovery Phase Should Deliver leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Operations Platform.
Ali Boran Gazel