When AI Is the Wrong Answer: Seven Situations to Walk Away From

We turn work down for these reasons, which is a strange thing for a consultancy to publish and a useful thing for a business owner to read before signing anything. Each of the seven below is a pattern, not a hunch, and each has a better alternative that costs less.

1. The process is not documented anywhere

If nobody can describe the steps without saying “it depends” four times, the process is not ready. Automating an undocumented workflow means encoding whatever one person happened to describe on one afternoon, including the mistakes and the workarounds they have stopped noticing.

Do instead: document it. Watch it run three times, write down what actually happens rather than what is supposed to happen, and note every decision point. Businesses that do this frequently fix the problem during the documentation and no longer need the automation.

2. It changes shape every time it runs

Some work looks repetitive but is actually a series of unique judgments wearing a uniform. If the steps genuinely differ each time, based on context a person holds in their head, automation produces something brittle that quietly stops matching reality.

The tell is when a walkthrough keeps branching and no branch is typical. Rule-bound exceptions are fine, automation handles branching well when the branches are known. Improvisation is not.

Do instead: automate the stable parts around the judgment. Preparation, data gathering and follow-through are usually consistent even when the decision is not.

3. The volume does not justify the build

A task done twice a month, taking twenty minutes, costs about eight hours a year. Nothing built by a professional pays that back inside a decade. This is the most common reason we decline work, and it is the one owners most often argue with, because the task is annoying, and annoyance feels like cost.

Do instead: use a template, a checklist, or a saved prompt in a tool you already pay for. Reserve building for the work that happens daily.

4. The real problem is the process, not the speed

If three people re-enter the same customer details, the problem is not data entry speed. It is that three systems do not share a record. Automating the re-entry makes a broken design permanent and adds a maintenance burden on top.

Do instead: fix the design. Sometimes that is an integration; sometimes it is retiring a system or reassigning a step. Both beat automating the symptom, and both are usually cheaper.

5. Being wrong is expensive and nobody would notice

The dangerous combination is not high stakes alone. It is high stakes plus low detectability. An automation that produces visibly wrong output gets caught. One that produces plausible wrong output, in a process nobody audits, compounds silently.

Financial reconciliation, regulatory filings, safety-related records, anything a customer relies on and will not check: these need a verification step, and if you cannot design one that people will genuinely perform, the honest answer is not to automate the decision at all.

Do instead: automate the preparation and keep approval human, with a log. If approval becomes rubber-stamping — and it does when volume is high — you have not solved it.

6. The data does not exist in usable form

A system that answers from your documentation needs documentation. A system that routes by customer history needs customer history in a system rather than in a filing cabinet or someone’s memory.

This is not a permanent disqualification, but it does reorder the project: the data work comes first, it is the larger share of the effort, and it is worth doing on its own terms even if the AI never gets built.

Do instead: treat the data cleanup as the project. Scope the automation afterwards, when you can see what is actually possible.

7. The motivation is that a competitor announced something

This produces worse outcomes than any technical problem on the list, because it inverts the process: it starts with a solution and searches for a justification. Projects born this way get scoped to be visible rather than useful, and they get evaluated on whether they shipped rather than whether anything improved.

Also worth knowing: a competitor’s announcement is not evidence their implementation works. Announcements are marketing artifacts. Plenty describe pilots that were quietly shut down.

Do instead: start from your own constraint. What is the bottleneck that costs you the most right now? If the answer is not something AI addresses, the competitive response is to fix the bottleneck, not to match the press release.

How to use this list

Before committing to any AI project, walk the seven. One clear match is worth pausing over. Two or more means the project as scoped will probably disappoint, and the money is better spent on whatever the list surfaced instead: documentation, an integration, a process change, or a cheaper tool you already own.

If you are talking to someone about a build and none of these ever come up in the conversation, that absence is itself informative. Every real implementation has a boundary. A proposal without one has not been thought through, or has been thought through and is not being shared.