The problem
three things that go wrong, and why a pilot is not one of them
Three things that actually go wrong
Not predictions. Each one is something most operations of this size have already been through.
Nobody in an industrial operation wakes up wanting AI. They want month-end to close on time, the auditor to find the permit, and the new engineer to stop asking three colleagues which revision of a procedure is current. The three sections below are what stands between those things and the tools that were supposed to deliver them.
In the reader’s own words
Three things an operations director has already lived through, in the words they would use.
The pilot worked and then nothing happened
Somebody built a document classifier on a laptop. It was demonstrated, it worked on the twenty documents it was demonstrated with, and everyone in the room agreed it was impressive. That was fourteen months ago. It is still on the laptop.
Pilots do not stall because the model was wrong. They stall because nobody established what the process cost before it started, so there is no number to justify the next phase with; because the twenty documents were the clean ones; because the person who would have to change how they work was never in the conversation; and because no owner was named for the thing after it worked.
This is precisely what a diagnostic answers, and it is why the first thing we sell is not a build. A pilot that cannot be scaled is not a small success. It is an expensive way to learn what a two-week audit would have told you.
The data was never going to work
No model repairs a figure that was already wrong when it arrived. And a definition that changed in a reorganisation three years ago is still wrong today, in every report built on top of it, because nobody went back and restated the history.
This is the most commonly sold first project in practice, and it is almost never the one the client came in asking for. On a demand-forecasting engagement the finding that mattered was not the model. It was that promotions and returns had been corrupting the demand history for years, so every forecast built on it was forecasting the promotion calendar. Repairing the definitions moved forecast error from roughly 42% to 19%. The model was the easy half.
Telling a client their data is not ready is an unpopular sentence and it is usually the accurate one. It is also a finding rather than a failure: it is specific, it is fixable, and it has an owner and a date attached by the time we hand it over.
The manual work is quietly costing you
Four thousand supplier invoices a month, and three people typing them into SAP. Month-end waits for them. Nobody has ever put that on a report, because it is not a project overrun or a line item - it is just how invoices get into the system, and it has been that way long enough to stop being visible.
The permit to work is signed on paper, photographed, emailed, filed twice, and found by nobody when the auditor asks. The variation order sits in a mailbox until somebody remembers it. The material submittal is approved in a thread. None of these has a cost centre.
The word for this cost is not inefficiency. It is that the expense has never appeared anywhere it could be argued with. That is what makes it survive budget rounds, and it is also what makes it the easiest thing on this page to measure: volumes, minutes per document, people, loaded cost. Four numbers, and most operations already know three of them.
Four shapes, whatever the industry
The same four problems keep arriving wearing different uniforms. Recognising which one you have is most of the work.
Across 85+ documented engagements, in government, telecoms, banking, healthcare, media and manufacturing, the problems reduce to four. That is why proof from one industry transfers to another: the telecom invoice case is the industrial invoice case, because the problem has the same structure.
A human reads it and types it in again
Invoices, contracts, scanned paper, submittals
6 documented deliveries
The answer exists and nobody can find it
Procedures, standards, specifications
13 documented deliveries
Too much arrives to check it all, so you sample
Inspections, calls, feedback, camera hours
7 documented deliveries
The same judgment, made differently every time
Risk scoring, prioritisation, approvals
9 documented deliveries
What the diagnostic is for
The point of this page is that the cost is unmeasured. The audit is what measures it.
A two-to-four week diagnostic interviews the people who actually run the process, looks at real data samples and real systems as they operate rather than as they are documented, establishes a baseline where none exists, and comes back with two or three opportunities ranked by impact, effort and data readiness - including any that turn out to be a broken-process problem rather than an AI problem.
It can conclude that no AI work is warranted. That is a complete piece of work, correctly delivered, and it is far cheaper than reaching the same conclusion eighteen months into a build.
You get a reply within one working day, from the engineer who would do the work - not a sales sequence.
Start here
If any of that reads like a memory rather than a warning, write to us.
Describe the documents, the systems they sit in, and roughly how much arrives each month. That is enough for a useful reply, and the reply comes from the engineer who would do the work.
You get a reply within one working day, from the engineer who would do the work - not a sales sequence.