Why do AI projects stall in growing businesses?

The pilot went well. The demo was shown to the board, a few people used it for a month, and then the invoices quietly went back to being typed in by hand. Nobody decided to stop. It just stopped. Now there's a line in last year's budget with nothing to show for it, and the next conversation about AI starts from there.

Projects like this rarely fail because the technology didn't work. They stall for six ordinary reasons, and each one can be seen coming.

It started with a tool, not a process

Someone saw a product, bought a licence, and then looked for somewhere to use it. The tool got pointed at whichever process was nearest, usually one that wasn't costing much time, and so the result wasn't worth much either. Six months later the licence is still being paid for.

The fix is to start the other way round. Pick the process that costs the most time and has a number attached, then choose what to build for it. What should you automate first gives you a way to choose.

Nobody owned the exceptions

The system handled the routine cases, and then an invoice arrived with a different total, or a lead came in from a company already in the CRM under another name. The system did something, or stopped, and nobody was watching. The first time that reached a customer, the team stopped trusting it, and from then on they checked everything, which was slower than the old way.

Before the build, name the person who sees exceptions and decide what they see. The routine runs on its own; the exceptions arrive with everything attached. That design is most of the work and it is where the trust comes from. How to keep a person in charge goes into it.

The old way kept running alongside

Nobody switched the spreadsheet off. The system created the record in the CRM, and the person who used to do it created it as well, just in case. Two versions of the truth, twice the work, and a system that could never prove itself because the old way was always there to fall back on.

Set a date on which the old way stops, after the testing is done. Tell the team the system is now how this work is done, and that the exception path is how they catch what it gets wrong. Running both for a week or two during testing is fine. Running both for months is a stall.

The real inputs were messier than the demo

The demo used ten clean invoices. The real inbox has photographs of invoices, invoices in the body of an email, two attached to one message, and one from a supplier that spells the company name three ways. The system was built for the demo, and the first week of real work broke it.

Test on your own history before launch: a few months of real cases, including the ones the team groans about, run through the system side by side with what the team did. Every difference is either a fix or an exception rule. If a partner tests on their own sample data, ask for yours to be used instead. What to ask an AI automation partner has that question and eight more.

Nobody took the reading before

When budget got tight, someone asked what the project had delivered. The honest answer was "it seems quicker", because nobody had measured how long the work took before. A project defended with adjectives loses to a project defended with a number, and it was cut.

Pick one measure, take its reading before anything changes, and report it on a rhythm afterwards. It's the cheapest step in the whole project and the one most often skipped. How to measure whether it paid for itself sets it out.

One champion held all the knowledge

One person pushed for the project, understood how it worked, and fixed it when it hiccupped. Then they went on holiday, or left, and the system stopped the first week they weren't there. Nobody else knew where the exceptions went or what to do when the supplier changed their form.

Write the system down as it's built: what it does, where the exceptions go, who to call when something upstream changes. Make sure at least two people in the business can read that document and act on it. And decide, in the proposal, who is responsible for the system after launch, so support isn't a favour from whoever built it.

The signs in the first month

A stall is visible long before the system stops being used. In the first month after launch, three things tell you which way it's going. Count how many exceptions reached a person and how long each waited. If the number is zero, either the system is handling everything, which is unlikely, or exceptions are going nowhere. Ask the team whether they're still doing the old step as well. If they are, ask what they'd need to see to stop. And look at who touched the system's settings or fixed a problem. If it's one name every time, the knowledge is in one head.

Each of those is a conversation to have in month one, when the fix is a small change. Left until month six, the same conversations are about whether to keep the system at all.

A short written handover is enough: one page that says what the system does, which systems it touches, where exceptions arrive and who clears them, what to do when something upstream changes, and who to call. The champion writes it with whoever built the system. The second person reads it and runs the exception path for a week while the champion watches. After that the system belongs to the business rather than to a person, which is the point.

The pattern underneath

Every one of these is a decision that wasn't made before the build: which process, who owns exceptions, when the old way stops, which cases to test, what to measure, who looks after it. The technology is rarely the problem. The project stalls because it was treated as a tool to install rather than a change to how a piece of the business works.

What to do this week

1. If you have a stalled project, go through the six reasons and mark which apply. Usually it's two or three, and they're fixable.
2. If you're about to start one, write down the process, the measure and its current reading, the exception owner, and the date the old way stops.
3. Ask whoever is building it how they'll test on your real cases and who looks after the system after launch.
4. Make sure two people, not one, will understand the system once it's live.

If you'd like a second opinion on a project that stalled, or one you're about to start, that's what the first call with us is for. Bring what you have and we'll tell you where we'd expect it to stick.