Last spring you ran a pilot.
Somebody on the team — probably your sharpest young person, probably unprompted — put together a proof of concept. It summarized something, or drafted something, or answered questions about a set of documents. You saw a demo. It was genuinely impressive. Everybody said "wow." Somebody said "we should roll this out."
It is now nine months later and nothing has been rolled out. The pilot still technically exists. Two people use it occasionally. When someone asks about your AI strategy, you mention it, and the sentence dies a little in your mouth.
This happens constantly, and it has almost nothing to do with the technology.
Three things a pilot needs and yours had none of them
An owner. Not a sponsor, not an enthusiast — an owner. A named person whose job it is to make the decision at the end. "The team is playing with it" is not ownership; it's a hobby with a budget. When nobody owns the decision, the pilot doesn't fail, which sounds good but is actually the problem. It just never concludes. It drifts into the furniture.
A metric agreed in advance. Before the pilot starts, somebody has to write down the sentence: this is a success if ____. Not "if people like it." If the invoice coding time drops from five minutes to ninety seconds. If we respond to inbound leads in under four minutes instead of four hours. If the abstract that takes six hours takes one. A number, chosen before you have any emotional investment in the answer, so that you can't retrofit the definition of success to whatever happened.
A decision date. Pick the day. Put it on the calendar. On March 14th we will look at the number and either kill this or fund it. Both are acceptable outcomes. Drifting is not.
Almost every pilot that dies in purgatory is missing all three, and they're missing them for a sympathetic reason: the pilot started as curiosity, not as a project. Curiosity is a great way to start. It's a terrible way to finish.
The second failure mode: you piloted the wrong thing
The other pattern we see is that the pilot was chosen for how well it demos, not for how much it's worth.
Summarization demos beautifully. Everyone claps. Then you discover that summarizing your meeting notes saves each person about eleven minutes a week and nobody was going to read the notes anyway, and the value is real but it's tiny, and it will never be worth the change-management cost of getting forty people to alter a habit.
Meanwhile the thing that would actually move your business — the six-hour weekly reconciliation, the intake routing, the invoice coding — doesn't demo at all. It's ugly. It touches three systems. It has exceptions. It is boring in exactly the way that real money is boring.
So the pilot succeeded and the company gained nothing, and everyone quietly concluded that AI is overhyped, when what actually happened is that you tested the technology on a workflow you'd already priced at approximately zero.
The third failure mode: nobody built the boring half
The demo was 20% of the work. The pilot proved the interesting part — yes, the machine can read the lease, yes, it can code the invoice. Then rollout required the unglamorous 80%: what happens when it's uncertain, who reviews the exceptions, how does it write back to the system of record, what does the audit trail look like, who gets paged when it breaks at 6 a.m. on a Saturday.
Nobody scoped that, because the demo made it feel like the work was done.
This is where most small-company AI efforts actually stall, and it's why "we'll just have the team build it internally in their spare time" so rarely lands. Not because your team isn't capable — they usually are. Because spare time reliably produces the interesting 20% and never produces the boring 80%, and the boring 80% is the part that makes it a system instead of a trick.
How to get out
If you have a pilot sitting in limbo right now, here's the way out, and it takes about an hour.
Price the workflow it touches. Hours, loaded rate, frequency, consequence of failure. Get an annual number. If the number is small — under twenty grand, say — kill the pilot today, thank the person who built it publicly, and go find a workflow that's worth something. Killing it is not an admission of failure. It's the diligence you skipped in month one, performed late.
If the number is big, then stop calling it a pilot. Name an owner. Write the success metric. Set the decision date. Scope the boring 80% honestly, including what happens when it's wrong. And decide whether you're funding it properly or not at all, because half-funded is the one option guaranteed to waste money.
The technology is not the bottleneck anymore. It hasn't been for a while. The bottleneck is that most companies never asked what the thing was worth, so they had no way to justify finishing it — and a project that can't be justified doesn't get killed.
It just sits there. Costing you nothing, and returning nothing, forever.