Discovery
The documented process and the real one
Every company has two processes: the one written down, and the one that runs. AI deployments build on the first — here's how to capture the second.
Ask anyone in the company how their work happens. You’ll get a clean, linear answer in five or six steps. That’s the documented process.
Sit next to them for a full working day. You’ll get something else.
An example: accounts payable
Take a process that runs at every mid-sized company and that everyone thinks is simple. The documented version:
- An invoice arrives by email.
- It’s copied into a spreadsheet.
- It’s keyed into the ERP.
- It’s approved.
Four steps. A developer can start building from that immediately. Which is exactly why the project will fail.
What step one actually is
“An invoice arrives by email” sounds like a clean trigger. In reality:
- It arrives from forty senders and no two are formatted alike.
- The data is sometimes in a PDF, sometimes in Excel, sometimes in a screenshot, sometimes in the third message of a forwarded thread.
- There’s no consistent subject line, so you can’t route on it — you have to open the message.
- A few senders attach two files, and the second one must always be ignored, because it’s a copy of the delivery note.
What step two actually is
“Copied into a spreadsheet” — which spreadsheet? It turns out there are three. One is live, two are stale, and somebody still updates one of the stale ones. The data is retyped by hand, because pasting breaks the formatting. The columns occasionally drift, and there’s a Monday-morning routine where someone realigns them.
What step four actually is
“It’s approved” — usually. But there’s a category where it isn’t needed, because there’s a framework agreement with that supplier and one colleague knows this from memory. And another where the approver already signed off on a different channel, so the system must not ask again.
The point isn’t the number of steps
The point is that the exceptions are written down nowhere. Not out of malice or sloppiness. Simply because to the person doing it, these aren’t exceptions. They’re the job.
Try it on yourself: write down every case where you deviate from the usual routine in your own work. You won’t manage it. Not because you don’t know, but because that isn’t how you store it.
Which is why you can’t capture this with a questionnaire or a one-hour interview. You have to go and look.
How we capture the real process
Observation, not interview. The first day is mostly quiet. Your colleague works, we watch. When something unusual happens, we ask — but only then, because the memory is fresh and we’re discussing a concrete case rather than an abstract rule.
Several people on the same process. At a company of five thousand, ten people do the same job in ten different ways. The differences are information in themselves: where they diverge, there is no real rule, only habit.
The systems talk too. The ERP audit log, the CRM export, the filenames in the shared folder. These reveal what happens even when nobody says it.
An exception log. For two weeks we write down every deviation. That list ends up being half the specification.
What we hand over
The output of discovery is an operating map covering, for every step:
| What we record | Why it matters |
|---|---|
| The step’s real input and output | This is what can be tied to a system |
| Who does it, and for how long | This is the baseline for savings |
| Which systems it touches | This defines the integration surface |
| What exceptions occur, how often | This is half the specification |
| What happens when it breaks | Without this you’ve only built the happy path |
| Whether it needs real judgement | This decides whether a model belongs there |
That last row is the important one. It’s what produces the decision about which step stays deterministic code, which becomes an agent, and where a human stays in the loop.
Why this is worth something on its own
We’ve had customers tell us the discovery alone was worth more than they paid for it — and then nothing got built for months afterwards.
That’s fine. Companies rarely have a document describing how the work actually happens inside a department. Once it exists, a lot of other things start to resolve: handovers, onboarding, audit preparation, capacity planning.
AI is only one of the things you can use it for.
If you’re curious how wide the gap is between your written and real process, let’s start with discovery.
Questions on this topic
How long does capturing a process take?
A moderately complex back-office process takes 3–5 working days of observation, plus 2–3 days to assemble the map. Anything faster only captures the documented version, which is precisely the one you don't need.
Can screen recordings replace being there?
They help, but they aren't enough. A recording doesn't show the moment your colleague turned to the next desk to ask something — and that is often the single most important, least documented step in the process.
What does this look like at your company?
If this problem sounds familiar, let's start with one process. Tell us which department burns the most manual hours — we'll come back with a concrete proposal.