The first conversation with a new client almost always opens the same way: where could we use AI in this business?
It is the wrong question. Not because it is naive, but because it has no bottom. Ask it in any company of any size and you will generate forty candidates in an hour, all of them technically true, none of them ranked. The list is worse than useless, because it feels like progress.
The question we ask instead is narrower and much harder to answer: where does this business lose time, money or information today, and which of those losses is largest?
That reframing is the entire content of the first two stages of our method. Discover maps how work actually moves. Diagnose puts numbers against the places it stalls. Only after both do we let anyone draw an architecture.
Discover: map the work, not the org chart
Every company has two structures. There is the one on the org chart, and there is the one that actually carries the work: the WhatsApp group that routes urgent enquiries, the spreadsheet a single coordinator maintains, the person everybody calls when the system says no.
The second structure is the one that matters, and it is never written down anywhere.
So Discover is not a workshop. It is closer to observation. We sit with the people doing the work and trace a single record end to end. One enquiry, from the moment it arrives to the moment it is either closed or lost. One invoice. One onboarding. We follow that record across every tool and every human it touches, and we count three things:
- Handoffs. Every time the record changes hands, including handoffs between a person and a system.
- Re-entry. Every time the same information is typed a second time.
- Waiting. Every point where the record sits because it is queued behind a human decision.
The output is a map, and the map is almost always a surprise to the person who commissioned it. Founders know their process as designed. Very few know it as run. In one recent engagement the documented sales process had six steps; the traced one had nineteen, eleven of which existed only to move information between two systems nobody wanted to replace.
That gap is where the work is.
Diagnose: three numbers per candidate
A map produces candidates. Numbers rank them.
For each candidate we insist on three figures, and we insist on getting them from the business rather than estimating them ourselves:
Volume. How many times does this happen in a month? A painful task that runs four times a month is a bad first target no matter how much everyone hates it.
Unit cost in time. How long does one instance take, measured end to end including the waiting? The waiting is usually the larger number and is almost always omitted when people estimate this from memory.
Leak rate. What fraction of instances go wrong, get lost, or arrive too late to matter? This is the figure that turns an efficiency argument into a revenue argument, and it is the one most businesses have never measured.
Volume multiplied by unit cost gives you the size of the operational prize. Volume multiplied by leak rate, priced at whatever one lost instance is worth, gives you the size of the commercial prize. In our experience the second number is larger about two-thirds of the time, and it is the one that gets a project approved.
The four tests
Having ranked the candidates, we apply four tests before committing to one. A candidate that fails any of them goes back on the list, however attractive its numbers.
Is it decidable? Can the correct outcome be stated as a rule, or at minimum can two experienced people in the business look at the same case and agree on the right answer? If they disagree, the process is not ready to be automated. It needs to be decided first. This is a business problem, and we say so.
Is the data underneath it trustworthy? An agent acting on bad records produces bad actions faster. If the underlying data is incomplete or contested, fixing that is the project, and the automation comes after.
Does it have an owner? Someone inside the business has to want this to work, be measured on it, and have the authority to change how their team operates. Without that person the system is deployed and then quietly routed around.
Can we measure it before we build? If we cannot establish a baseline today, we cannot prove an impact later. A project with no baseline is one that will be argued about forever.
Why the first build should be boring
There is a pull, always, toward making the first project the most ambitious one. Resist it.
The first build's real job is not to deliver the largest number on the list. It is to prove that the business can absorb a system like this at all: that the team will use it, that the data holds, that the measurement is honest, that the sign-off rhythm works. A modest system that survives contact with real usage earns the right to build the ambitious one. An ambitious system that stalls in month one poisons the well for years.
So we bias the first engagement toward high volume, low ambiguity, and a clear owner, even when a larger prize sits one row above it on the ranked list. The larger prize is still there afterwards, and by then we know considerably more about the business.
Design, and what you own either way
Discover and Diagnose end in a business case: the ranked candidates, the numbers behind each one, the baseline we would measure against, and a recommendation. Design turns the chosen one into a blueprint, which is signed off before a line of it is built.
One thing worth stating plainly, because it surprises people. That business case is yours whether or not you build it with us. It is a document about your own operations, produced from your own data. We have had clients take it away and implement internally, and that is a legitimate outcome. The alternative, where a studio holds the diagnosis hostage to the build, produces exactly the vendor relationship we would not want to be on the other side of.
We solve the bottleneck before we build the technology. Business outcome first, technology second. Everything else in the method follows from getting these two stages right.