Home / Articles / AI pilots

95% of AI pilots never touch the bottom line. It is not the tools

Most AI pilots are built to impress in a demo, not to pay in the accounts. The fix is not a better model. It is a harder pilot design, with a baseline, an owner and a decision date.

The short answer

MIT research puts 95% of generative AI pilots at zero measurable bottom-line impact. The pilots fail on design, not capability: no baseline, no single owner, no written process and no kill criteria. A pilot that pays starts with one job tied to revenue or cost, gets baselined first, and ends with a clear keep, fix or kill decision on a set date.

"Their sales department overpromise, and underdeliver- selling you a fairytale of how its going to change your business." That line, from a Reddit post by a buyer of AI marketing tools, sums up the mood around agentic ai right now. The promise was large. The result, in most brands, was a pilot that looked clever in a meeting and changed nothing in the accounts.

That gap now has a number on it. MIT research puts 95% of generative AI pilots at zero measurable impact on the bottom line. Not small impact. Zero. The tools were bought, the logins were shared, the demo was applauded, and the revenue line and the cost line stayed exactly where they were.

It is tempting to blame the models. Resist it. The earlier piece on this site, agentic AI minus the hype, set out the layers that sit under a working setup. This piece goes deeper on the part most brands skip: how the pilot itself is designed, and how the decision at the end gets made.

Why do pilots look good in the demo and flat in the accounts?

A demo is judged on output. A pilot should be judged on outcome. That one difference explains most of the 95%.

In a demo, the vendor picks the example, cleans the data first, and shows the best run. Nobody asks what the task costs today, who owns it when it breaks, or what number would prove it worked. The room sees a fluent answer and mistakes fluency for value.

Inside a real brand, the same tool meets messy product data, a process that lives in one person's head, and a team that is already busy. The output is still fluent. The work around it, checking, correcting, chasing, quietly eats the time the tool was meant to save. By month two, usage fades. By month three, the pilot is a line in a deck and nothing more.

The pattern is familiar from earlier waves of software, and the AI theatre problem is the same pattern in a new costume: activity that signals progress while the commercial result stays flat.

What agentic ai needs before it can pay

A pilot that touches the bottom line starts smaller and stricter than most vendors want. It treats the pilot as a commercial test, not a product trial.

Pick one job with a revenue or cost line. Not "improve marketing" and not "explore AI". One job, stated in a sentence, with a line it should move. Chasing overdue invoices. Rewriting underperforming email flows. Triaging support tickets to resolution. If nobody can name the line, the pilot has nothing to prove and no way to fail honestly.

Baseline it before anything is switched on. Record how the job performs today: time taken, cost per task, error rate, conversion, resolution rate, revenue attached. Take the measure over at least two normal weeks, not one good day. Without that starting number, every later claim is opinion, and opinion is what the fairytale runs on.

Name one owner, not a committee. One person owns the number, the process and the decision. That person uses the output in real work, logs where it fails, and has the authority to say stop. Pilots with shared ownership die quietly, because everyone assumes someone else is watching.

Write the process down before automating it. The steps, the inputs, the checks, the exceptions. If the process cannot be written on one page, it is not ready to hand over. Writing it often exposes the real problem, which is usually a broken or inconsistent process that no tool could have fixed.

Set kill criteria and a decision date on day one. Decide in advance what result means stop. For example: if resolution rate does not beat the baseline by the agreed date, the pilot ends. If cost per task has not fallen, the pilot ends. A pilot with no kill criteria never ends. It drifts, and drift is how budgets leak without anyone making a bad decision on purpose.

How should the decision at the end actually work?

This is the part almost nobody designs, and it is the part that decides whether a pilot becomes a system or a story.

Hold the review on the date set at the start, with the baseline and the pilot numbers side by side. Same measure, same period length, same definitions. If the measure changed mid pilot, say so and discount the result. Moving the goalposts is how failed pilots get renewed.

Ready to run a pilot that has to pay?

The Growth Audit asks five questions about your brand, your numbers and the job AI should take first. It maps the one pilot worth running properly.

Start the Growth Audit

Then make one of three calls, in writing.

Keep and scale. The number moved, the owner trusts the output, and the checks are holding. Scale means handing the job over properly, with monitoring and a named owner staying in place, not quietly expanding into five new jobs at once.

Fix and retest once. The number moved a little, and the failure points are clear and specific. Allow one short retest with those points fixed and a new decision date. One retest, not a rolling extension.

Kill it. The number did not move, or the hidden work cancelled the gain. Stop, record what was learned, and release the budget. A clean kill is a good outcome from a pilot. It cost a few weeks and saved a large contract.

Notice what is not on that list: "keep it running and see". That is the default in most brands, and it is the most expensive option of all.

What does a well designed pilot feel like from the inside?

It feels less exciting than the fairytale, and that is a good sign. The job is narrow. The number is visible to the team. The owner can show, on one screen, the baseline, the current result and the exceptions from the last week.

It also feels honest about the human work that remains. A good setup resolves the routine cases and escalates the hard ones fast, with context attached. It does not pretend the hard cases do not exist. Trust builds because the limits are plain, not because the demo was smooth.

There is a founder version of this lesson. I built Liquiproof from zero to 3,000+ retail doors, including Adidas, IKEA, Selfridges and Burberry, with a profitable exit in under six years. Nothing in that run scaled because it demoed well. Things scaled because the unit numbers worked store by store, and the things that did not work got killed early, while they were still cheap to kill.

That discipline is the whole difference between a pilot and a purchase. One tests a claim against a number. The other buys the claim and hopes.

Where does the proof sit when it works?

When the design is right, the results show up in the same place the pilot was aimed: the line. The playbook behind the specialist bot team approach recorded 518% average revenue growth across clients who completed the 90-day Growth Sprint. Treat any figure like that the way a pilot should be treated: ask what the baseline was, over what period, and for whom. Proof that cannot answer those questions is marketing. Proof that can is a baseline for the next decision.

If your brand has a shelf of AI tools that changed nothing, the tools are probably fine. The pilots were built to impress, and they did exactly that, once, in a meeting. Run the next one to pay: one job, one baseline, one owner, one decision date, judged on one number. Start with the Growth Audit and map the first job worth testing properly.

Start with the Growth Audit.

5 short questions. The SIBT team replies with your next step.

  • 5 short questions
  • Runs 24/7
  • You pick approval or auto mode