The short answer: nine reasons to stop before you start
Most companies that come to us already have a specific workflow in mind. Before scoping any of them, we run each one against this list. If a workflow matches more than one item here, the honest recommendation is not to build — not later, not smaller, not at all:
- A deterministic script or a database query already does the job.
- The volume is too low to justify any build, custom or bought.
- The process itself is broken or undocumented.
- The real problem is organisational, not technical.
- Being wrong is unacceptable, and no human reliably checks the output.
- The data the system would need doesn't exist yet.
- A good off-the-shelf tool already does this well.
- Nobody in the business will own the system after launch.
- The actual motivation is a board asking for "an AI initiative," not a named problem.
Each gets its own section below, with what it actually looks like in a real business rather than the theoretical version.
When a deterministic script or a database query already does the job
Take a request like "what's the status of order 4471." The answer already lives in one place — a database row joined to a shipping API, with a fixed, complete set of possible states: ordered, shipped, delivered, delayed. There's no ambiguity to resolve and no judgment to apply. A script that reads the row and formats a reply answers it instantly, the same way every time, and fails only when the database itself is down.
Putting an AI agent in front of that same lookup adds a model call's latency and cost to a question that was never uncertain, and introduces a failure mode that didn't exist before — a model confidently returning the wrong tracking number. If the rules are fixed and complete, AI doesn't make the answer better. It makes the same answer slower, more expensive, and occasionally wrong in a way a plain query never was.
When the volume doesn't justify any build
A task that happens twice a month rarely earns back the cost of any build, custom or off-the-shelf. Picture a finance team reconciling one vendor invoice, by hand, because the format doesn't match the accounting system — call it twenty minutes, a couple of times a month. That's a small, occasional cost, cheap enough that the fastest, lowest-risk fix is a person doing it directly, not a project sized around it.
Volume is one of the first things a real AI strategy conversation tests, because it's easy to get wrong in either direction. Teams underestimate how often a task actually happens, or they assume high volume alone justifies a build when the task is still too simple to need one. Low, occasional volume is a reason to leave a process alone, not a reason to automate it quickly.
When the process is broken or undocumented
If a workflow doesn't have one agreed version of how it actually works, automating it doesn't fix that. It runs whichever version got captured, faster and with more authority behind it. A common case: a lead-qualification process where every sales rep applies slightly different criteria, and nobody has written down which one is correct. Feed that into an AI system and it inherits the inconsistency, then executes it at a pace nobody can review.
The fix isn't a smarter model. It's agreeing on the process first, on paper, with the people who actually run it in the room, and only then deciding whether the agreed version is worth a workflow automation build. Automating a broken process is one of the fastest ways to turn a slow, occasionally-wrong workflow into a fast, consistently-wrong one.
When the real problem is organisational, not technical
Some of the workflows people bring to us aren't broken because of missing software. They're broken because two teams don't share a reliable update cadence, because a decision — who approves a refund above a certain amount, say — has no named owner, or because a policy exists on paper but nobody enforces it day to day.
An AI system sitting between warehouse operations and customer service won't make those two teams share a cadence they've never agreed on. Wrapping an approval step in AI doesn't create an owner for the decision if one didn't exist before — it just automates the ambiguity, faster. These are real problems, worth fixing. They get fixed with a conversation, a named owner, and an enforced policy, not a model.
When being wrong is unacceptable and there's no viable human check
Some decisions carry a cost of being wrong that no accuracy figure makes acceptable — a clinical recommendation, an eligibility decision that denies someone access to something they're owed, anything where a wrong output causes harm that can't be undone. If a system like that has no human reviewing its output before it takes effect, that's not a scoping problem a better model solves. It's a category of decision that shouldn't run unsupervised at all.
That doesn't rule AI out of those workflows entirely — it rules out AI making the call unsupervised. A system that drafts a recommendation for a qualified person to approve is a different, much safer thing than a system that acts on its own. If a business can't build in that check, the honest answer is not to automate the decision itself, whatever else gets built around it.
When the data needed simply doesn't exist
A team wants AI to predict which customers are about to churn, but the only thing they've ever recorded is who's currently a customer — nobody logged who left, when, or why. There's nothing for a model to learn a pattern from. Building the system before the data exists doesn't produce a working prediction. It produces a guess wearing the confidence of a real one.
This is a different problem from a broken process, and a common one — plenty of businesses run well without a strong habit of recording what they'd need later. If the data a use case depends on genuinely doesn't exist yet, the right first move is building the habit of capturing it, not the model that assumes it's already there. The AI readiness checklist covers what else needs to be in place before a project starts.
When a good off-the-shelf tool already fits
Sometimes the honest answer, after actually looking, is that a mature product already does the job well — scheduling, standard helpdesk ticketing, basic bookkeeping, generic email marketing. Building a custom system to replace a tool that already fits isn't a case for or against AI at all. It's a build-versus-buy question, and buying wins it more often than most build-first advice admits.
The tell is simple: if nobody can name what the custom version would do that the existing tool doesn't, there's no case to build. Spending a project's budget re-creating something you could subscribe to this afternoon is money that should have gone toward the one workflow in the business that's actually differentiated enough to be worth the build.
When nobody in the business will own it after launch
An AI system doesn't run itself once it's live. Something will need adjusting as the business changes, an edge case will show up that nobody anticipated, and someone has to notice when the output has quietly started drifting wrong. If there's no one on the client's side who will own that — watch it, make small calls about it, flag when it needs a bigger change — the project doesn't fail at launch. It fails months later, silently, when the thing nobody's watching starts getting things wrong and nobody notices.
We ask directly, on the first call, who that person will be. "We'll figure that out later" is a real answer, and it usually means the project needs to wait until there's a name attached to it, not a reason to skip the question and build anyway.
When the actual motivation is a board mandate, not a problem
Occasionally the honest starting point isn't a workflow at all. It's a board that wants to say the company is "doing something with AI," or a leadership team that saw a competitor announce an initiative and doesn't want to be the one without one. There's no workflow attached, no outcome anyone expects to move, and no one who can say what gets better if the project ships.
That's a fundamentally different conversation from everything else on this list, because there's no process to fix and no volume to weigh — there's no problem yet, just a mandate looking for one. The honest move is to say so, and either help find a real candidate problem worth solving or recommend waiting until one exists, rather than build something cosmetic to satisfy a slide.
A checklist before you greenlight an AI project
Run a candidate project against these questions before it gets scoped:
- Could a script or a database query already answer this, reliably, every time?
- Does this happen often enough that a build pays for itself?
- Is there one agreed version of how this process works today?
- Is the blocker actually two teams, an unowned decision, or an unenforced policy?
- If the system gets this wrong, is that cost acceptable, and does a human check it before it acts?
- Does the data this depends on already exist, in a form you could hand over?
- Have you actually compared this to the best off-the-shelf tool, not just assumed one doesn't exist?
- Is there a named person who will own this system after it ships?
- Can you name the specific outcome this is meant to move?
A single "no" isn't automatically disqualifying — some of these are matters of degree. Several "no"s in a row is a project that isn't ready, whatever the pitch looked like in the meeting that started it.