There's a particular kind of call I dread. A company reaches out, and within the first two minutes it becomes clear they've already tried this. Someone internally built a prototype. Or they hired another agency. Or they ran a three-month "AI pilot." And it didn't work. Now they're sceptical, their team is tired of the topic, and leadership has already asked once whether this AI stuff is actually real or if it's all hype.
They're still calling because the problem hasn't gone away. The invoices still take three days to process. The customer queries still pile up on Monday morning. The operation is still fragile in exactly the same ways it was before.
After enough of these calls, patterns emerge. It's almost never one dramatic failure — it's one of the same five things, over and over. I'm writing this to help you see them before you spend six months finding them yourself.
The five reasons it failed
They automated the easy thing, not the expensive thing
The first automation target at most companies is whatever the team mentions most often — "oh, it'd be so amazing if we could automate that." The problem is that the things people notice most are rarely the things that cost the most. People notice context-switching. They notice annoying manual copy-paste tasks. They notice having to chase colleagues for information. These feel like friction, but they're not necessarily where the hours or the risk or the money is.
The logistics company I worked with last year had already run one automation project before we arrived. They'd automated their purchase order confirmation emails — saving about 40 minutes a week across the team. Felt like a win. Meanwhile, their invoice processing was costing them 180 staff-hours a month and an error rate that was triggering supplier disputes every two weeks. Nobody had automated that because it seemed harder and messier. It was harder and messier. It was also where €155,000 a year was sitting on the table.
Start your automation roadmap with a cost audit, not a convenience audit. What are the five most expensive manual bottlenecks in the business? That's your list.
They started with the AI instead of the data pipeline
Most failed automation projects I've seen were built top-down: pick the AI model first, build the cool interface, then figure out how data gets in and out. This feels natural because the AI is the exciting part. It's also exactly backwards. The AI is the last mile. Data ingestion, normalization, validation, and routing is the actual system. If that's unreliable, the AI is just generating confident-looking answers from corrupted inputs.
No error handling meant production failure on day three
A common prototype-to-production gap. In testing, you run the happy path — clean inputs, expected formats, no edge cases. Everything works. You demonstrate it to stakeholders. It looks great. Then it goes live, and on day three, a supplier sends an invoice with a different date format, or a customer writes their query entirely in uppercase, or someone uploads a scanned PDF that's slightly rotated, and the system crashes. Not gracefully. Just crashes. And nobody thought to build a fallback.
Production systems need to handle not just what you expected, but everything you didn't expect. They need to log failures. They need to route edge cases to humans when confidence is low. They need to degrade gracefully rather than halt. Building this properly adds 30–50% to development time vs. a prototype. Every time someone tries to skip it, they learn the hard way why it exists.
The team who uses it wasn't involved in building it
This one sounds obvious in retrospect but it keeps happening. A decision is made at the management level to automate something, an IT team or external partner builds it, and the people who actually do the process every day find out about it at launch. They weren't consulted on what actually matters. They weren't asked about the edge cases they handle routinely. And now they're being asked to trust a system that was built without them, that handles their job differently than they do, and that occasionally gets things wrong in ways that are hard to spot. The adoption rate is predictably low.
The prototype-to-production gap was wildly underestimated
A prototype that handles 80% of cases can be built in a week. A production system that handles 99% of cases reliably, with monitoring, error handling, logging, and the ability to be updated without breaking, takes much longer. The difference isn't linear — it's not "a bit more work." The last 19% of edge cases often takes as long as the first 80%. Companies that budget three weeks for "the build" and assume they're done when the demo works are almost universally six months late and over budget.
The pattern behind the pattern
Look at all five failure modes and you'll notice something. None of them are about AI. They're not about choosing the wrong model, or having the wrong architecture, or using the wrong prompting technique. They're all either strategy failures (wrong problem, wrong team involvement) or engineering failures (bypassing the boring, necessary infrastructure work).
This is counterintuitive because when an AI project fails, the blame usually lands on the AI. It's not smart enough. It hallucinated. The model wasn't good enough for this use case. Sometimes that's true. But after dozens of production deployments, I'd estimate that fewer than 20% of failures are primarily model failures. The rest are process and infrastructure failures that would have sunk any technical project, AI or otherwise.
The question isn't "was the AI good enough?" It's "was the whole system — data pipeline, error handling, team alignment, realistic scope — built well enough?" Usually not.
What to do differently the third time
If you're reading this after already running into one of the above walls, here's the framework we use when we take on these projects:
Six decisions to make before writing a line of code
What this looks like in practice
The logistics company I mentioned earlier — the one where invoice processing was costing €155K a year. When we came in, two automation attempts had already failed. The first was an internal project that got orphaned when the developer who built it left the company. The second was an agency project that produced a working prototype but crashed on non-standard invoice formats in week two and was quietly shelved.
We spent the first three weeks not building anything. We mapped every invoice format currently in use (23 of them). We interviewed the accounts payable team to understand how they handle ambiguous cases. We traced exactly where the previous solutions had broken and why. We defined the acceptance criteria: process 95% of invoices without human intervention, flag the remaining 5% to a review queue, reduce processing time from 72 hours to under 4.
Then we built. The full pipeline took eight weeks, not three. It's been running for fourteen months. The only time it's been manually intervened since launch was when one supplier switched to a format we hadn't seen before — the system flagged it, it was handled, and we updated the parser in a day.
That's what production-grade automation actually looks like. Not a clever demo. A system that still works fourteen months later when you've mostly forgotten it exists.
The difference between that outcome and the two previous failures wasn't AI capability. The models used in both previous attempts were perfectly capable. The difference was the six steps above: start with the right problem, build the infrastructure properly, and bring the actual users into the process.
If you're on attempt one or two and it's not going well, you haven't failed at AI. You've just found out which parts of the system need more attention. That's genuinely useful information — if you use it.
Ready for the version that actually works?
Tell us what you've already tried and where it broke down. We'll figure out what's missing and whether we can fix it.
Talk it through