Only 7% of CFOs report high ROI from their AI investments. Seven percent. That number - from Forrester's 2024 research - should make you put your coffee down. Not because AI doesn't work, but because the gap between what got sold and what got delivered has become the defining experience of enterprise AI so far.
If you're reading this, there's a decent chance you're in the 93%. You backed an initiative. You made the internal case. You put your name behind it. And what came back was somewhere between underwhelming and mortifying.
We invested real money and real political capital into this. The vendor sold us something that didn't exist at the scale they promised. I'm not doing that again.
That instinct is partly right. You've made an accurate call about a specific vendor. The mistake would be extending that call to the entire technology. And I've watched firms make exactly that mistake - quietly shelving their AI ambitions after one bad experience, while their competitors quietly pull ahead.
I've been in enough of these post-mortems to recognise the pattern. I've also been in enough vendor demos to know how the trick works. So let me walk you through what actually happened, what you need to do about it, and how to approach a second attempt without repeating the first one.
I sat in a demo last year - a well-known AI workflow platform, confident presenter, slick interface. Everything worked beautifully. The use case was obvious. I left the room thinking, "Why haven't we recommended this to clients already?" Then I started asking questions. Turns out the demo environment had been running against a dataset a tenth the size of a typical client's. The data was immaculate because someone had spent a week cleaning it. The workflow was smooth because every edge case had been quietly excluded.
That's Act One. You've probably been there.
Act Two is the ambitious timeline. Twelve weeks, maybe sixteen. Presented with the casual confidence of someone who's done this dozens of times. What they don't mention is that the timeline assumes your data is well-structured, your team is available, your integrations are straightforward, and nobody changes the requirements mid-stream. All of which, in my experience, is almost never true simultaneously.
Then comes the bit that really winds people up. As the gap between promise and reality starts to show, the vendor's communication shifts. Fewer proactive updates. More milestone reports. Less talk about outcomes, more talk about "blockers" - and somehow, most of those blockers seem to be on your side of the fence. I've seen this so many times I've started mentally timing it. Usually kicks in around week eight.
By month four or five, you're looking at adoption numbers that don't match the projections, accuracy that doesn't match the demo, and integrations that are more complex than anyone acknowledged during the sales process. The tool works, sort of, in a narrow set of conditions that don't quite match your actual operating environment.
And then comes the mutual blame. The vendor points to your data quality, your implementation decisions, your change management. You point to their capability, their overcommitment, their sales team's creative interpretation of "production-ready."
Here's the bit that's genuinely difficult to hear: both sides are usually partially right.
This pattern tends to be worst in specific categories - AI writing assistants, "no-code AI" platforms, workflow automation tools marketed at non-technical buyers. Not because the underlying technology is bad, but because the sales process is optimised for excitement rather than accuracy. The demo is a performance. The contract is where reality begins.
This is the section that matters most, and it's the one most firms skip. Because it's much easier to tell a clean story - "the vendor let us down" - than to do the uncomfortable work of asking what you could have done differently.
I'm not saying the vendor didn't let you down. They probably did. But if you attribute all the failure to them without examining your own contribution, you'll make the same mistakes with the next vendor. Just with a different logo on the invoice.
So, four questions. Answer them honestly.
Was the use case fundamentally achievable with the technology as it actually existed on the day you signed the contract? Not the demo version. Not the roadmap version. The production version. If the answer is no - if the vendor sold you capability that didn't exist yet - that's a vendor failure, full stop. But if the technology could do what was promised under the right conditions, the next three questions matter a lot.
Did you provide the data quality and integration conditions the vendor needed? I've seen this go both ways. Sometimes the vendor never properly assessed data readiness before committing to a timeline - that's on them. But sometimes the firm assured the vendor that data was "in good shape" without anyone actually checking. The CTO I mentioned earlier - the one whose document management system had seventeen different naming conventions across four offices - was genuinely frustrated with his vendor. And the vendor had failed to flag the problem early enough. But the firm had also told them the data was fine. Nobody had looked.
Were the expectations set during the sales process realistic, and did you have anyone in the room who could challenge them? When a vendor tells you their tool will reduce proposal turnaround by 60%, do you have someone who can ask: "60% compared to what baseline? Under what conditions? With what data quality requirements?" Deloitte's 2026 State of AI report found that 42% of leaders believe their AI strategy is prepared, but only one in five has mature AI governance to evaluate vendor claims. That gap is where overpromise lives.
And finally: did your governance structure include enough technical review to catch the gap between promise and reality early enough to do something about it? If the first time leadership heard things weren't on track was month five of a six-month implementation, that's a governance failure. The warning signs were almost certainly there earlier. Someone saw them. The question is whether the structure existed for that information to reach the people who could act on it.
If you can answer those four questions with specificity - not "there were mistakes on both sides" but "the vendor overstated production readiness on feature X, and we failed to validate data quality in system Y before committing to timeline Z" - you have something you can actually work with.
Right. So you've done the diagnosis. You know what went wrong and who was responsible for what. Now comes the harder part: convincing the people around you that a second attempt is worth the risk.
And I want to be straight with you here. If you're the managing partner or CTO who backed this investment, this isn't just an analytical problem. You spent credibility on it. You told the board it would work. Maybe you fought for the budget against competing priorities. The failure isn't just commercial - it's personal. Any framework that ignores that dimension isn't being honest about what recovery actually requires.
We've already had this conversation once. Why would the outcome be any different?
The board conversation that works is not "we're going to try again." Nobody wants to hear that. What works is specificity. Something like:
"Here's our diagnosis of what went wrong. The vendor overstated production readiness on the document classification capability - it worked in demo conditions but couldn't handle our naming conventions across four offices. On our side, we didn't validate data quality before committing to the timeline, and we didn't have anyone with enough technical depth to challenge the vendor's claims during the sales process. Here's what we'd do differently: start with a single, bounded use case - automated proposal generation for repeat client briefs. Define three measurable outcomes before selecting a vendor. Ensure at least one person on the evaluation team has enough AI literacy to interrogate vendor claims independently."
That's a fundamentally different conversation from "we've learned our lesson." The specificity is what makes it credible. People can evaluate specific claims. They can't evaluate vague reassurance.
Smaller scope. One specific, bounded use case rather than a platform-level commitment. Not "let's implement AI across the firm" but "let's automate the first draft of compliance reports for recurring audit clients." The scope should be small enough that failure is survivable and success is measurable. McKinsey's 2025 research found that structured pilot methodology with internal capability building shows 3.2x higher success rates than pure vendor dependency. Starting small isn't timidity - it's what actually works.
Clearer metrics, defined before the vendor is selected. Three observable, measurable outcomes. "Reduce proposal turnaround from five days to two." "Achieve 85% accuracy on document classification within the first 90 days." "Reduce manual data entry by 40% for the pilot team." If you can't define what success looks like in concrete terms before you start, you're not ready to start.
Internal capability. This is the one most firms skip, and it makes the biggest difference. You need at least one person - ideally more - who has enough AI literacy to evaluate vendor claims independently, ask the right questions during implementation, and recognise when the gap between promise and reality is opening up. That person doesn't need to be a data scientist. They need to understand enough about how these tools actually work to know when a vendor is hand-waving.
And design the use case around your problem, not around a particular vendor's capability. If you start with "we want to use [Vendor X's] tool," you've already anchored the conversation around their strengths. Start with "we need to reduce the time senior consultants spend on proposal drafts" and you can evaluate multiple approaches - including ones that don't require an external vendor at all.
Not all vendors are the same. The overpromise pattern is real, but so are the partners who do this properly.
A serious AI partner will assess your specific context before making promises - not just hear about it in a sales call, but actually look at your data, your systems, your team's readiness. They'll propose a phased approach with measurable outcomes at each stage rather than a full implementation commitment up front. They'll be able to explain the failure modes of their technology in your environment - not just the success cases. And they'll support the development of your internal AI literacy rather than creating dependency on themselves.
If a vendor can't tell you how their tool might fail in your specific situation, they either haven't thought about it, or they don't want you to know. Neither is acceptable.
But how do I know which category a new vendor falls into before I've already committed?
Honestly? You ask them to walk you through a project that went wrong. Not a case study - a failure. What happened, what they missed, what they'd do differently. The vendors who can answer that question clearly and without defensiveness are the ones worth talking to. The ones who pivot immediately to another success story are telling you something important.
Look, I know this piece asks a lot. It asks you to revisit something that was painful, do an honest diagnosis that might reveal uncomfortable things about your own organisation, and then make the case - again - for investing in a technology that let you down.
But the firms that wrote off AI entirely after a bad vendor experience are now watching their competitors pull ahead. Not because those competitors got lucky with a better vendor first time around. Because they did the work of understanding what went wrong and approached the second attempt differently.
The vendor overpromise pattern is real, it's consistent, and it's survivable. What's harder to survive - in the medium term - is deciding that one bad experience means the technology itself isn't for you. That's the right call about the wrong thing.
If you want to understand what your firm's actual starting conditions for a second attempt look like, our AI Readiness Assessment gives you a clear picture of which dimensions are genuinely in place and where the gaps are. It's worth the twenty minutes before you start any vendor conversations.