A leadership team agrees AI should be doing more of the work. Someone builds a prototype in a fortnight. It demos well. People are impressed. A budget appears.
Six months later, nobody can say exactly what it replaced, who owns it or whether anything measurable changed.
That scenario is increasingly familiar. S&P Global Market Intelligence's 2025 research, surveying just over 1,000 senior technology and business professionals across North America and Europe, found organisations scrapping an average of 46% of AI projects between proof of concept and production. 42% said they abandoned the majority of their AI initiatives before production, up from 17% the previous year.
This doesn't mean AI isn't delivering value. It means getting from an impressive prototype to something that works reliably inside a business is hard, and the problem is rarely the technology. It is what happened before the technology was introduced.
Too many businesses start by asking "where can we use AI?" when they should be asking "which piece of work are we trying to make materially better?"
Before anyone writes a brief, answer seven questions.
1. Which process are we actually improving?
Start with a process, not an AI use case.
Lead to opportunity. Brief to campaign. Discovery to proposal. Quote to cash. Monthly reporting.
Map the steps, systems, handovers, decisions and rework. Then compare two things: how long the process takes end to end, and how much actual working time it contains.
If a five-day process contains six hours of hands-on work, making those six hours faster may barely affect the outcome. The real constraint could be approvals, missing information or handovers.
AI can accelerate a task without improving the process around it. So find the constraint before you automate it.
2. If we removed the AI, would we still want to do this?
This is one of the quickest ways to distinguish a genuine business improvement from an AI experiment.
Imagine you want an AI assistant to create campaign briefs. Take the AI away. Would you still want to standardise what a good brief contains, identify the information required and make that information easier to access?
If yes, that is the project. AI may make the new process faster and easier, but it isn't the reason the work has value.
If removing AI leaves nothing anybody particularly wanted, you are primarily experimenting with the technology. That can still be worthwhile. But call it an experiment, give it an experimental budget and judge it on what you learn, rather than on a business case that doesn't yet exist.
3. Do we know what "good" looks like?
AI can reproduce a standard remarkably quickly. It cannot compensate for a standard nobody has defined.
If a great proposal, report or pitch exists mainly in the heads of two experienced employees, don't start by building an AI tool. Start by extracting what those people know.
A simple test: put three examples of the output on the table. Can your team agree which is best, and explain precisely why?
If not, define the standard first. The technology can automate a standard. It cannot create one.
4. What should AI do, and what should a person own?
The useful question is no longer simply human or AI. It is what the right division of labour looks like.
AI is well suited to work that is repetitive, information-heavy, relatively structured and easy to verify: summarising, formatting, retrieval, first-pass analysis, drafting from an agreed structure, triaging enquiries.
People remain critical where work requires judgement, accountability, relationships, negotiation or consequential decisions.
Then there is the category businesses frequently underestimate: AI output that requires so much checking that the saving disappears. If somebody has to scrutinise every output closely enough to identify a convincing error, you may simply have moved the effort from creating to checking.
So define the review model alongside the AI model. What can AI do autonomously? What gets checked? Who checks it? Against what standard? What happens when it is wrong?
That becomes more important as businesses move from AI that creates content to agents that can take action.
5. What number should move?
"Improve efficiency" is not a business case. Pick a number:
- Time from brief to first usable draft: four days
- Manual reporting effort: 30 hours a month
- Deals using genuinely buyer-specific materials: 33%
- Average first response to an inbound enquiry: 11 hours
Then decide what improvement would justify the investment.
The baseline matters as much as the target. Without it you cannot prove the tool worked, and twelve months later you will have usage statistics and anecdotes rather than evidence of value. Start with the decision, not the dashboard covers how to choose that number properly.
If nobody can name the number that should improve, you don't yet have a business case. You have an interesting demo.
6. Who owns it when the excitement has gone?
Building version one is increasingly easy. Owning version seventeen is harder.
Someone needs responsibility for the source information, instructions, accuracy, access, feedback and eventual retirement of the tool. Before launch, decide:
- Who updates it when products, pricing or positioning change?
- Where do users report poor outputs?
- What happens when an underlying model changes?
- What is the fallback when the tool is unavailable?
- Who is accountable if incorrect output reaches a customer?
Governance isn't bureaucracy bolted onto the end of an AI project. It is part of the product. No owner means no reliable route to maintain quality once the people who built the prototype have moved on.
7. What is the smallest version that could prove, or kill, the idea?
Don't design the first version to become a platform. Design it to produce a decision.
One process. One team. One measurable outcome. One owner. One defined test period.
And, importantly, stopping criteria. "We'll give this to four salespeople for eight weeks. If it doesn't reduce preparation time by 30%, or fewer than half are still using it without prompting at the end of the trial, we stop."
That is a test. "We'll pilot AI and see what happens" isn't.
The objective isn't to get every pilot into production. It is to find out quickly which ones deserve to get there.
What these questions usually uncover
Work through the seven properly and the apparent AI problem often turns into something else.
A data problem. The tool needs customer or operational information that is fragmented, duplicated, inaccessible or unreliable. Putting AI over the top of that produces confident answers from unreliable inputs, which is worse than no answer. The groundwork is CRM and revenue operations work: a single architecture, cleansed legacy data, and pipeline structures the business can actually rely on. Your CRM isn't your RevOps strategy covers what to settle first.
A knowledge problem. The organisation knows how to produce excellent work, but the standard sits inside individual people's heads. Codifying that knowledge may create significant value before a line of AI development happens.
A workflow problem. The work itself isn't particularly slow. Waiting, searching, handing over and approving are. Making one task dramatically faster won't necessarily make the process faster.
An ownership problem. The business case works, but nobody has responsibility or capacity to keep the system useful.
All four are worth discovering before development starts.
Don't build yet. Run the process first.
None of this is an argument for moving slowly on AI. It is an argument for finding out what works before you industrialise it.
There is a simple way to do that. Run the proposed process for two weeks using existing AI tools rather than commissioning a build.
Record every prompt, intervention, correction, missing piece of information and point where a person has to take over. Those corrections become your specification. They tell you what context the AI needs, where your data fails, which decisions require human judgement, how expensive verification really is, whether people actually use it, and whether the claimed saving survives contact with the real work.
You can then make a much better decision about whether to build, buy, integrate or stop. Your prototype becomes your specification rather than your investment.
Ask a better question
"Where could we use AI?" produces a long list of possibilities. Lists produce pilots, and a significant proportion of pilots never become operational tools.
A better question is: which piece of work would we most want to make consistently excellent, regardless of who or what is doing it?
Then ask whether you know the process, standard, number and owner. If you do, AI may be exactly the right tool.
If you don't, working those things out isn't the obstacle standing between you and the AI project. It is the project.
More on how we approach AI and engineering, or how it fits into growing through digital.
Find out whether you have an AI project or a process project.
We will run the seven questions against the thing you were about to build, and tell you which of the four problems you actually have. Three of them are cheaper to fix than a development budget.
