What a diagnostic actually looks like
Two weeks, a map of how the work really moves, and a costed shortlist. What we look at, who we speak to, and what you are holding at the end of it.
Almost every engagement that goes wrong went wrong before anyone wrote any code. A business decides it needs AI, picks the process that is most annoying, builds something around it, and finds out eighteen months later that the annoying process was not the expensive one. The diagnostic exists to stop that, and it is deliberately the cheapest part of the work: it is the only stage whose output can reasonably be that you should not build anything at all.
This is what the two weeks actually contain. Not the sales version. The version we would want to read if we were buying it.
Week one: how work actually moves
The first job is to establish how the business runs, which is almost never how the business believes it runs. Process documentation describes the intended path. The interesting material is in the exceptions: the spreadsheet somebody maintains privately because the system cannot hold the thing they need, the approval that is technically required and is in practice granted in the corridor, the report that takes a person two days a month and is read by nobody.
We do this by sitting with the people who do the work, not with the people who own the org chart. Usually five to eight conversations, forty-five minutes each, structured around one question asked repeatedly: what did you do yesterday, and how long did each part take. Nobody can accurately describe their job in the abstract. Everybody can describe yesterday.
- Where work enters the business, in every form it enters in, including the ones nobody counts.
- What happens to it at each hop, who touches it, and what they are deciding.
- Where it waits. Queue time is almost always larger than handling time and almost never measured.
- What is already instrumented, so we know which claims we can check and which are anecdote.
The gap this is looking for
There is a specific shape we are looking for, and it is the shape the published research keeps finding at national scale. Personal use of these tools has run far ahead of organisational use. Staff have adopted them, quietly, on their own accounts, without anything changing about how the business is structured.
That is adoption. It is not transformation, and the difference between the two is exactly what a diagnostic is trying to locate. Somebody using a chat window to draft an email faster has changed their afternoon. Nothing about the business has changed. The value sits in the processes where a person is currently the connective tissue between two systems that were never designed to talk, and those processes are rarely the ones anyone complains about, because complaining about them would mean admitting how long they take.
Week two: cost, and what a fix is worth
By the second week the map exists and the question becomes arithmetic. For each candidate: how often does this happen, how long does it take, what does an hour of that person's time cost, and what does it cost when it goes wrong. That last one is usually the largest number and the one nobody has ever written down.
Three things fall out of that, and they are the reason the diagnostic is worth buying on its own.
- A shortlist, ranked by annual cost rather than by irritation. The order surprises people roughly half the time.
- A build estimate against each item, so the return is a subtraction rather than a feeling.
- An explicit list of what we would not build, and why. This is the most useful page in the document.
The output of a diagnostic can be that there is nothing here worth building. That has happened, and it is a good outcome for everyone except the invoice.
What you are holding at the end
A map of how work moves through the business, the costed shortlist, and the estimates. It is yours. There is no clause that stops you taking it to somebody else, and if we have priced ourselves out of the build we would rather you did. The diagnostic is a fixed fee, it is small relative to a build, and it is deliberately separable, because a diagnostic that can only conclude in favour of the firm that ran it is not a diagnostic. It is a proposal with a longer preamble.
The reason to do it first is visible in what happens without it. Adoption is close to universal and production is not, and the gap is not a technology problem.
Pilots do not stall because the models are not good enough. They stall because the thing being piloted was chosen before anybody had established what it was worth, and a pilot with no number attached has no argument for surviving contact with next year's budget.