Discovery
How an AI discovery actually works, step by step
What an FDE does during the two to four weeks of discovery, who they talk to, what they pull from your systems, and exactly what you get at the end.
If someone offers you an “AI audit”, it’s fair to ask what that actually means. So here is what we do during those two to four weeks.
0. Before we arrive
We ask for two things up front: an org chart for the department, and read access to the systems the process runs in. Not so we can pre-decide the answer, but so the first day isn’t spent discovering how many systems there are.
We ask you to name an internal point of contact. Not a project manager: one person who knows the department and can introduce us in a way that doesn’t feel like an inspection.
That last part matters more than it sounds. If the team believes we’re there to count who can be let go, we will learn nothing.
Week 1 — observation
The first day is mostly quiet. Your colleague works, we sit beside them and watch. Not an interview, not a questionnaire: observation.
Why? Because if you ask someone how their work happens, you get an abstract summary. If you watch, you also see the moment they interrupt themselves, turn to the next desk, ask something, and carry on. That turn is documented nowhere — and it’s often the most important step in the process.
When something unusual happens, that’s when we ask. The memory is fresh and we’re talking about a concrete case rather than a rule.
What we record:
- What they do, in what order, on which screen.
- How long it takes, and how often per day.
- Where they wait on someone else, and for how long.
- What they copy by hand from one system into another.
- When and why they deviate from the usual path.
Week 2 — exception log and system logs
Two things run in parallel.
The exception log. We ask something simple of the team: when something doesn’t go the usual way, write one line. Over two weeks that produces 40–120 entries. It becomes half the specification later.
System logs. The ERP audit log, the CRM export, filenames in the shared folder, email metadata. These tell you what nobody says: that a “rare” exception is actually 18% of cases, or that a step averages 40 minutes rather than five.
This is where the surprises show up. At one customer, discovery revealed that at one point in the process two teams were entering the same data in parallel — for years, neither aware of the other.
Week 3 — the operating map
The document comes together. For every step:
| Field | What it holds |
|---|---|
| Input / output | What comes in, what goes out, in what form |
| Owner and time | Who does it, how long, how often |
| Systems touched | Where the data lives, whether there’s an API |
| Exceptions | What deviations occur, at what rate |
| Failure handling | What happens when it breaks, who notices |
| Judgement | Whether a real decision is needed, or it can be ruled |
The last row is the point. It produces the decision about whether a step stays deterministic code, becomes an agent, or keeps a human in the loop.
Week 4 — ROI matrix and plan
The map becomes a priority order, sorted on two axes: volume and recoverable time, against risk and implementation difficulty.
Three groups fall out:
- Now. High volume, low risk, existing API. This is where we start.
- Later. Worth doing, but something’s missing — data, an integration, a decision.
- No. Too little benefit, too much risk, or already automated.
We describe the third group in the same detail as the other two. Saving someone a dead end is worth something.
Alongside it goes an architecture and an estimate: how long, how much, with which risks.
What you get at the end
- An operating map, step by step, with exception branches
- Quantified time spent per process
- An ROI matrix with the three groups
- An architecture for the proposed solution
- An estimate of time and cost
- A 30-minute presentation for leadership
That package is yours even if you don’t do the build with us. We don’t obscure it, and we don’t build dependency into it.
If you’re curious what this would surface at your company, get in touch.
Questions on this topic
How much of our team's time does it take?
Less than you'd think. Observation happens alongside the normal work, not instead of it. Interviews take 4-6 hours per function in total, spread out.
What if discovery concludes it isn't worth doing?
Then we write that down. That's a result too: you'll know exactly why not, and what would have to change for the answer to flip.
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.