What a good automation discovery phase should uncover

It starts with the work as it actually happens, not the process document

Discovery should start by watching how a task actually gets done, not by reading how someone says it gets done. SAP Signavio notes that many organizations start process discovery with workshops and manual mapping, and that this approach can be slow and based on assumptions, since processes often behave differently once you look at how they actually run. A small business doesn't have enterprise event logs to check against, but the same gap shows up at a smaller scale: the intake form nobody fills out first, and the text message that skips the booking system entirely. A discovery phase that only reviews your process document has skipped the step that matters most.

It checks whether the process is actually ready for automation

Forvis Mazars includes a feasibility assessment as one of the core discovery activities: it revisits the complexity of the process, the existing IT infrastructure and the costs involved, once stakeholder interviews turn up new information. For a small business that often means checking what other software the process touches, who logs into what, and whether the volume of the work justifies the build. Forvis Mazars also names tool selection as part of discovery: matching the process to the right automation approach, rather than forcing every problem through the same tool. A discovery phase that skips this and jumps straight to a proposal hasn't actually tested whether the process is ready.

It surfaces the exceptions, not just the clean path

Most operational work has a clean path and a set of exceptions that eat the actual time. SAP Signavio is careful to say that automated discovery does not replace manual methods: workshops and expert input are still needed to understand business context, decisions and exceptions, because software can see what happened without always explaining why. Forvis Mazars describes stakeholder interviews as essential for identifying pain points and desired outcomes, for the same reason: the person doing the work daily knows which exceptions happen every week and which ones are hypothetical. In a small business that person is often the owner, so a discovery phase worth paying for should include real time with you, not just with whoever answers the phone.

It says plainly what a system can't own yet

A discovery phase that only lists what automation can do is a sales pitch with extra steps. A useful one also names what stays with a person, like the call that needs judgment or the decision that carries legal weight. We map the manual work first, then say plainly what a system can own and what it can't, before any building starts. If a vendor can't point to at least one task in your business that should stay manual, they haven't looked closely enough. That same boundary-setting question comes up again once a system is running: how to set limits on what an AI agent can do alone is worth reading before you sign anything, not after.

The distinction between a fixed script and a system that decides on its own matters here too: how workflow automation differs from agentic AI covers that difference in full, but the short version is that a discovery phase should tell you which one a given task actually needs, not which one sounds more advanced.

It ends in a scope you could hand to a stranger

Forvis Mazars lists a clear project scope among the benefits of a well-run discovery phase: a well-defined scope helps prevent scope creep and keeps a project within budget. For an owner-operator, that scope should survive a change of vendor: which steps get automated and which stay manual, and what counts as done. If the output of discovery is a general pitch instead of a list specific enough for someone else to build from, ask for the list before you sign anything. How to evaluate an AI automation vendor covers the rest of that evaluation, including who owns the code once it's built. Our answers library breaks down what that scope tends to look like across a range of operationally heavy industries.

Ask about timing before you ask about price

Timing is worth pinning down early too. KYP.ai cites Deloitte research finding that 63 percent of organizations reported process intelligence software accelerated discovery and helped identify automation use cases, and separately notes that deployment speed across the category ranges from one to two weeks on the fast end to eight to twenty four weeks on the slow end. That gap is the real negotiation: ask every vendor for time to first actionable insight, not time to go live, since a go-live date alone can slip for months without producing anything you can check along the way. A small business rarely has months to spend waiting on a finding it could have had in the first two weeks.

Before you take a call with any automation vendor, write down one process in your business exactly as it happened this week, including the exception that came up yesterday. If a discovery phase can't tell you, in writing, what happens to that exact exception, it hasn't found anything yet.