What a good automation discovery phase should uncover

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

A thorough discovery phase starts by watching how a task actually gets done, rather than reading how a manual says it gets done. SAP Signavio notes that many organizations start process discovery with workshops and manual mapping, and points out that this approach can be slow and based on assumptions because processes behave differently once you look at how they actually run. A small business does not have enterprise event logs to check against, yet the same gap between theory and reality shows up at a smaller scale: the intake form nobody fills out first, or the client text message that skips the booking system entirely. A discovery phase that only reviews your existing process documentation misses the unrecorded workarounds that keep operations moving and skips the observation step that matters most.

It checks whether the process is actually ready for automation

After observing the workflow, discovery must test whether your systems can support automation. Forvis Mazars includes a feasibility assessment as one of its core discovery activities, noting that teams must revisit the complexity of the process, the existing IT infrastructure, and the costs involved once stakeholder interviews turn up new information. For a small business, running that readiness check means looking at what other software the process touches, verifying who logs into which accounts, and confirming whether the weekly volume of 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 operational problem through the same tool. A discovery phase that skips infrastructure checks and jumps straight to a proposal has not tested whether your process is ready.

It surfaces the exceptions, not just the clean path

Most operational work has a clean path alongside a set of exceptions that consume the actual time. SAP Signavio is careful to state 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 must include real time with you and the people handling daily edge cases, rather than a brief chat 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 review explicitly names what stays with a person, such as the customer call that requires human judgment or the decision that carries legal weight. We map the manual work first, and then state plainly what a system can own and what it cannot own before any building starts. If a vendor cannot point to at least one task in your business that should remain manual, they have not looked closely enough at your operation. That same boundary-setting question comes up again once a system is live: 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 approach a given task actually needs, not which option sounds more advanced.

It ends in a scope you could hand to a stranger

Forvis Mazars lists a clear project scope among the primary benefits of a well-run discovery phase, explaining that a well-defined scope helps prevent scope creep and keeps a project within budget. For an owner-operator, that written scope should be detailed enough to survive a change of vendor: which steps get automated, which stay manual, how exceptions route back to a person, and what counts as done. If the output of discovery is a general pitch instead of a specification clear enough for another builder to follow, ask for the detailed 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 is built. Our answers library breaks down what that written scope tends to look like across a range of operationally heavy industries.

Ask about timing before you ask about price

Before agreeing to a discovery phase, pin down how long it takes to get your first useful finding. 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 timeline 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 cannot tell you, in writing, what happens to that exact exception, it has not uncovered anything useful yet.