How we run discovery for automation projects

Discovery is the step between "we think this should be automated" and a build plan you can trust. For automation projects, it means mapping how the process really runs, counting the volumes and exceptions, finding where the data lives, agreeing how success will be measured, and turning all of that into a written scope and estimate.

Most automation projects that disappoint do not fail in the code. They fail because the team automated the process as described in a meeting, not the process as it actually runs, with its exceptions, workarounds and missing data. This article explains how we recommend running discovery, what you should have in hand at the end, a checklist you can use with any vendor, and the red flags to watch for.

Where discovery fits

Our way of working with a new client follows the same order every time:

1. A short call about the process, the people involved and what you want to change.
2. A written scope and estimate, so you know what discovery covers and what a likely build looks like.
3. Discovery, before any development starts.
4. Build, test and go live, based on what discovery found.

Discovery is sized to the problem. A single reconciliation between two systems needs far less of it than a new platform. For an early-stage PropTech startup, we started with a 2-week discovery and architecture sprint that produced a full technical specification and infrastructure diagram before the MVP was built. For a narrow process automation, discovery can be much lighter. The point is not the length. It is that the decisions are made on evidence.

The six parts of automation discovery

1. Map the process as it really runs

Start with the official version: the steps, the systems and who does what. Then find the real version. We ask the people doing the work to walk through recent examples, step by step, and we draw the process from those examples rather than from a procedure document.

The map should show every hand-off between people and systems, every place data is copied or re-typed, and every decision point. Decision points are where automation either saves the most time or breaks.

2. Shadow the people doing the work

Watching someone do the task for real reveals what nobody mentions in a meeting: the spreadsheet they keep on the side, the colleague they message to check a value, the step they skip on busy days. We sit with users, with their permission, through enough repetitions to see normal cases and awkward ones.

Shadowing is also where we measure the baseline: how long each step takes, how often it is repeated and where errors happen. Without a baseline, you cannot show later that the automation worked.

3. Build a volume and exception inventory

For each type of record or case, write down:

• how many arrive per day, week or month,
• how many are clean and follow the standard path,
• what the exceptions are and how often each one occurs,
• what a person currently does to resolve each exception.

This inventory decides the design. If most records are clean, automating the standard path and routing exceptions to a person in a triage view pays off quickly. If exceptions dominate, the first job may be fixing upstream data, not automating.

4. Find the data sources and access routes

List every system the process touches, who owns it and how data can be read or written: an API, a database, file exports, email or a scheduled report. Check access early. Waiting for API credentials or a firewall change is one of the most common causes of delay.

When a system has no API, there is usually another reliable route, such as file exports or email parsing. Discovery should identify it and note its limits, for example how often the export runs.

5. Agree success metrics

Agree up front how you will judge the result. Typical metrics are hours spent per week, error rate, time from event to action, and the share of cases handled without a person. Each metric needs a baseline from step 2 and a way to measure it after launch.

Example, with clearly hypothetical numbers: a team of 5 spends 6 hours a week each on a manual check, so 30 hours a week in total. If discovery shows 80% of cases are clean and can be cleared automatically, a realistic target is to remove most of those 30 hours, while the remaining exceptions still need a person. Our article on calculating automation ROI shows how to turn those numbers into a business case.

6. Prioritise

Not everything found in discovery should be automated, and not all at once. We score each candidate step on volume, time saved, error risk, technical difficulty and dependence on other teams. High volume, rule-based, low difficulty steps go first. Rare, judgement-heavy steps usually stay with people, supported by better information.

What you should receive at the end

A discovery phase should leave you with documents you own and could hand to any team:

• A current-state process map, including the real exceptions and workarounds.
• A baseline: measured time, volumes and error rates for the steps in scope.
• A volume and exception inventory with how each exception is handled today.
• A data source inventory: systems, owners, access routes and known data quality issues.
• A target design: which steps are automated, which stay human, and how exceptions are routed.
• Agreed success metrics and how they will be measured after launch.
• A prioritised backlog and a recommended first release.
• A written scope and estimate for the build, with assumptions and open risks stated.

If discovery shows automation is not worth it yet, that is a useful result too. It is cheaper to learn it before building.

A discovery checklist you can use

Use these questions whether you work with us, another vendor or an internal team:

1. Has someone watched the process being done, not only heard it described?
2. Do you have measured volumes per day or week, not estimates from memory?
3. Is every exception listed, with how often it happens and who resolves it?
4. Is every system listed with an owner and a confirmed way to access its data?
5. Have credentials or access requests been raised already?
6. Are success metrics agreed, with a baseline for each?
7. Is it written down which steps stay human, and why?
8. Does the scope state its assumptions and what is out of scope?
9. Is there a plan to test against real historical data before go-live?
10. Does the first release deliver value on its own, without waiting for later phases?

If you answer "no" to several of these, the project is not ready to build yet.

Red flags

Watch for these signs, in a vendor's proposal or in your own planning:

• A fixed price before anyone has seen the process. Without discovery, the estimate is a guess, and the gap shows up later as change requests.
• No time with the people who do the work. Interviews with managers alone miss most exceptions.
• "We will handle exceptions later." Exceptions are where the cost and the risk are. They belong in the design.
• A tool chosen before the problem is understood. Whether the answer is a no-code tool, n8n or custom code should follow from volumes and complexity. See n8n vs Zapier vs custom code.
• No baseline. If nobody measured the current process, nobody can prove the improvement.
• Discovery outputs that only the vendor can read. You should own clear documents, not a slide deck.

How this looks in a real project

For a medical and home supplies distributor, the operations team of 8 people spent the first two hours of every morning cross-checking purchase orders against carrier shipping confirmations, then reconciling invoices in SAP. The automation followed the shape of that work: matching logic clears clean records automatically, and discrepancies go to a triage dashboard. The result was about 20 hours a week of manual reconciliation removed, with discrepancies detected in real time instead of the next morning.

Frequently asked questions

How long does discovery take?

It depends on the number of systems, teams and exceptions involved. We size discovery in the written scope after the first call, so you know its length and cost before it starts.

Can we skip discovery if we already know what we want?

You can shorten it, not skip it. Even with clear requirements, someone needs to confirm data access, volumes and exceptions, because those decide the design and the estimate.

Who needs to be involved from our side?

The people who do the work today, the owner of the process, and someone with access to each system involved. Their time is usually the deciding factor for how quickly discovery moves.

Do we own the discovery documents?

Yes. The process map, inventories, metrics and scope are yours, and you can use them with any team.

To see how we approach automation end to end, visit our business process automation service. When you are ready, book a call to talk through your process, or request a quote.