Why your pilot never shipped
The test worked, the demo got applause, and nothing made it into the day-to-day of the company. That is almost never a technology problem. It is five decisions nobody made.
Run any test in your company through a list of five checks and say, with an argument, what is missing for it to become routine — or why it should be shut down.
Sign up once to unlock this course
Course 01 is open. For courses 02 to 05 we ask for six fields. It is a single signup: done once, valid for the whole track. It is not a free diagnosis and it does not trigger automatic sales contact.
A demo and the day-to-day are different things
A demo has to work once, with hand-picked data, in front of people who already want to see it work. The day-to-day has to work every day, with the data that actually shows up — and when it fails, it has to fail in a way that was already planned for.
Most tests die because they were built for the first case and later judged by the second. The team presents an example that worked, someone asks what happens when the document arrives illegible, and the meeting ends in a promise to adjust.
There is no owner, only an enthusiast
Every test has a sponsor who shows up in the photos and an enthusiast who makes the thing move. Neither of them is the owner. The owner is whoever has to explain when the number does not show up, holds budget to keep it running, and has authority to change the process around it.
The test is simple: if this stops working on a Tuesday, who gets the call? If the answer is “the IT people” or “it depends”, there is no owner.
Nobody wrote down when the task is done
To work day to day you need to know when a case is finished: the document was checked, the customer was qualified, the proposal is ready to send. Without that criterion written down, you cannot count how many cases were done, you cannot measure error, and you cannot pay for outcome.
A test survives without it because the assessment is by eye: someone looks at the output and says it looks good. The day-to-day does not survive that way.
The exception has nowhere to go
Every real process produces cases outside the standard. In the test, the exception goes back to the enthusiast, who handles it by hand and records it nowhere. Day to day, the exception needs an address: who receives it, within what time, with what information, and what happens if nobody answers.
Ask what percentage of cases needed someone to step in last month. If nobody can answer, it was never measured — and if it was never measured, it was never designed.
Nobody worked out what each case costs
The test runs at small volume, and the cost looks irrelevant. Day to day, that same per-case cost multiplied by the real volume can turn the arithmetic upside down. When the invoice arrives before anyone did that sum, the order to stop comes from finance, not from technology.
Three numbers: what a simple case costs, what a case that had to be redone costs, and what a case that ended up in a person's hands costs.
Connecting it to the system was left for later
If someone has to download a spreadsheet and paste the result into another system, that did not become routine: it became manual work with an extra step in the middle. Until the output lands automatically in the system where the decision is made, the gain stays trapped in the demo.
Shutting it down can be the right decision
Not every test deserves to become routine. If the volume is small, if the required data does not exist, if the surrounding process is about to change, closing it preserves budget and credibility. The mistake is not closing it. It is leaving it forever almost ready.
Basis
The five points are not management theory. They are the questions that actually show up when something with AI starts running day to day and someone has to answer for it in a results meeting.
When the checklist becomes an investment decision
If the test already has an owner, a criterion and volume, and all that is left is building it and connecting it to the systems, the problem is execution. If it lacks an owner and a criterion, the problem comes before the technology. Prumo Discovery separates the two before anything gets built.