AI projects fail in companies that have already bought the tools, and the reason is usually adoption rather than the model. I had a call last week that made that concrete in a way no case study has.
The person on the other side runs teams inside a global group, the kind of company where IT policy is set once and applies in every country. I came in ready to talk about automation systems.
He stopped me early: their policy blocks external automation tools. Zapier, Make, custom integrations, all of it.
The short version
- A global group blocks every external automation platform by policy, which rules out building the usual integrations.
- The same group already pays for approved AI tools that sit at roughly 1% of their plausible usage.
- What he asked for was not a system. It was someone embedded with the teams for a week or two, teaching daily workflows on the tools they are already allowed to use.
- The target he named was 1% to 10%. The technology was never the constraint.
Why AI projects fail in companies that already bought the tools
His teams have sanctioned AI available today: a Copilot-style assistant and an internal sandbox wired to the large models. Nothing needed procurement, nothing needed a security review, nothing needed me.
Usage sits at something like 1%. People take meeting notes with it. That is roughly where it stops.
Not because the tools are bad. Because the one workflow a person discovers unprompted is the obvious one, and there is no path from there to the rest without someone showing them.
Insight
What 1% actually looks like from the inside
The gap between 1% and 10% is not made of exotic use cases. It is made of the tasks people already do badly and slowly.
The examples he named on the call were analysing a full inbox and scheduling meetings. The ones I would add from every other company I have worked inside: drafting the reply that follows a long thread, and turning a rough brief into a first-pass deck.
Each one is unglamorous and each one recurs every single day. None of it requires a new system. It requires a person to sit next to the team, take a real piece of their week, and do it with them in the tool their employer already permits.
That is also, I suspect, why the gap persists. Nobody's job description includes teaching a colleague a workflow, so whatever one person works out stays with that person.
| Build a system | Raise adoption | |
|---|---|---|
| Precondition | You are allowed to connect tools | Tools already exist and are approved |
| Where the gain sits | In a process nobody has to touch | In the hours people spend on their own work |
| What ships | A workflow that runs on its own | A team that works differently on Monday |
| How it fails | Nobody uses the output | It decays once you leave |
Why the constraint changed my answer, not my opinion
A blocked integration policy is not an obstacle to argue with. In a group that size it was set globally, for reasons that predate the conversation, and no single department gets to reverse it for one project.
So the question becomes: given what is permitted, where is the largest unclaimed gain? In his case it was sitting inside licences already on the invoice.
That reframing is the part worth stealing. Most companies I walk into assume the next gain requires the next purchase. Often the next gain requires using the last purchase.
Measuring the starting point is harder than it sounds. Licence dashboards report seats assigned and monthly active users, and both numbers look healthy the moment somebody opens the app once a month to take notes.
A useful baseline is a fraction: of the work a team does that the approved tools could plausibly take a share of, how much currently goes through them. That number is not in any dashboard. You get it by sitting with four or five people for an hour each and asking what their week is made of.
It is a soft number, and he named 1% and 10% as soft numbers. The value is not the precision, it is that both sides agree what would count as the project having worked.
Inventory what is already sanctioned
The approved AI tools, the sandbox, the assistant bundled with the office suite nobody opened.
Measure current usage honestly
Not seats assigned. What fraction of the work people could plausibly do with it is actually done with it.
Take one real week of one real team
Their inbox, their reports, their meeting load. Not a demo dataset.
Teach the workflows in place, then leave
The test is whether the habit survives the month after you stop showing up.
The honest limit: this work leaves no artifact
I am genuinely undecided about whether to take this kind of engagement, and the reason is worth saying out loud.
When we build a system, something exists afterwards. It runs at 3am, it does not resign, and it can be pointed at a second team next quarter.
Adoption work leaves habits instead of artifacts, and a habit is the kind of thing that erodes as soon as nobody is checking on it. I have no measured decay curve to offer here, which is itself part of the problem.
There is also no honest way to price it against a savings number, which is how we normally work. You cannot measure the hours a habit saves the way you can measure a queue that used to take three days and now takes twenty minutes.
Both of those are arguments about my business model rather than about his problem, and I want to be clear which is which.
“Most companies assume the next gain requires the next purchase. Often it requires using the last one.”
What I cannot say is that he is wrong about the problem. A team at 1% usage is a larger unrealised gain than most automation projects I have scoped, and it needs no integration, no vendor, and no security review.
What to do with this at your own company
Before approving the next AI budget line, find out what fraction of the last one is actually being used, and by whom.
If the answer is "meeting notes", you do not have a tooling gap. You have a week of somebody's time standing between your teams and the thing you already bought.
Key takeaways
- Approved and unused is the most common state of enterprise AI, and it shows up as a budget line rather than as a visible failure.
- Measure adoption as a fraction of plausible usage, not as seats assigned, or the number will always look healthy.
- When policy blocks external automation platforms, the remaining gain is usually inside the licences already approved.
- Adoption work targets the daily unglamorous tasks: triaging an inbox, drafting a reply, turning a brief into a deck.
- The honest weakness of training over building is that habits decay and systems do not, so the test is whether the change survives the month after the trainer leaves.
Related reading: what an AI recommendation is worth without its denominator covers the other half of this problem, the teams who do use the tools and trust the output too readily, and 60,128 email rows, 3,921 actual inboxes is what that looks like when the output is a data file rather than a recommendation. If you want a view of where the automatable work actually sits in your operations, that mapping is the first thing we do when we work inside a company.
Common questions
Why do AI projects fail in companies that already bought the tools?
Because the tools get used for the one workflow people discovered on their own, usually meeting notes, and nothing else. The gap is not model capability, it is that nobody has shown the team what their own daily work looks like when the tool does part of it.
What do you do when corporate IT blocks external automation tools?
Work inside what is already approved. If Zapier, Make and custom integrations are blocked but an internal AI assistant and a sandbox are sanctioned, the available gain is in raising usage of the sanctioned tools, not in smuggling in a new platform.
How do you measure AI adoption inside a team?
Pick a usage baseline and a target before starting. The executive I spoke to framed it as moving from roughly 1% to 10% of the work his teams could plausibly be doing with the tools they already have.