A few months ago, a logistics company came to us wanting to automate their customer complaint handling. Volume was high, the team was stretched, and someone had seen a competitor demo a chatbot at a trade show.
We recommended against it.
Not because the technology could not do it. It could. But when we mapped where the complaints were actually coming from, about 80% traced back to one recurring problem in their dispatch scheduling. Fix the scheduling, and most of the complaint volume goes away on its own. Automate the complaints instead, and you have spent real money building a very efficient system for dealing with a problem you did not have to have.
They fixed the scheduling. The complaints dropped. The chatbot was never built.
This is not an unusual outcome for us. It happens often enough that we treat it as a genuine possibility in every audit, not a surprise.
The assumption most businesses bring in
When a company comes to us for an AI audit, the assumption is usually that AI is the answer and the only question is where to point it. That thinking is understandable. The gap between what AI can do and what most businesses have actually built is enormous. The temptation to close that gap quickly is real.
But "AI can help here" and "AI is the right move here now" are two different things. A lot of our work lives in that distinction.
There are three situations where we consistently recommend not building anything.
The problem is upstream of where it looks
This is the logistics case. The most visible problem in a business is rarely the source of the problem. It is usually a symptom of something that happened earlier in the process. When you automate a symptom, you spend budget handling something that could have been prevented at its root.
Part of what an audit has to do is go back far enough to find where a problem actually starts. That sometimes means what looks like a good AI use case turns out to be a process problem that predates any technology decision.
The volume does not justify a build
AI implementations cost something to build, cost something to run, and need someone to maintain them when things change. For a task that happens 20 times a month or involves one person spending two hours a week, the economics usually do not work. The time to manage, update, and monitor the system will cost more than the time it saves.
We see this with smaller teams especially. A well-designed template or a short checklist often handles the job for free. That is worth saying plainly, even when it means there is nothing for us to build.
The judgment involved should stay with a person
There are decisions where the accountability matters as much as the outcome. Legal sign-offs. Client communications where a single wrong response can undo a relationship that took years to build. Situations where being wrong has consequences that go beyond fixing the error.
We build AI systems for consequential work. But we are specific about what we take on and what stays in human hands, and we are direct about the line when a client wants to cross it.
What this costs us
Some clients find this frustrating. They came expecting to build something and we are telling them not to. A couple have gone to other vendors and built it anyway.
One came back about six months later. The build worked technically. The ROI did not, because the underlying problem had not changed.
The audit is a separate engagement from the build for a reason. We are not in a position where recommending more work is in our financial interest if we do not believe the build is right. That separation is deliberate. If the honest answer after an audit is "sort your data collection first" or "run this as a manual process for another year until you have enough volume to actually train on," that is what we say.
In practice, that honest answer is often the most useful thing a client takes from the whole engagement.
Three questions to pressure-test your own AI ideas
You do not need to commission anything to start thinking clearly about this. If you are weighing an AI project right now, these three questions are worth sitting with before any money changes hands.
Is the problem caused by something further upstream? If you fixed the source, how much of the visible problem disappears? If the answer is "most of it," fixing the source first is almost always the right move.
What does the realistic maintenance cost look like? Not just the build invoice. The ongoing time to manage, update, and check the system month to month after it goes live. Does that number still make sense given the volume you are dealing with?
Who is accountable if this goes wrong? If the answer is unclear, that discomfort is information. Systems without clear accountability become nobody's problem when they fail, and they do fail eventually.
If your answers to all three point clearly forward, that is a real signal to move. If any of them feel uncertain, that uncertainty is far cheaper to resolve before a build than after one.
Where this leaves us
Grapine builds AI systems that have a clear, provable reason to exist. That specificity means we take on fewer projects than we could. The ones we take on tend to hold up.
If you want to understand whether AI is genuinely the right move for a specific part of your business before anyone commits any budget, that is what the AI Opportunity Audit is designed to do.
It will tell you where AI will help. It will also tell you where it will not.
Both are worth knowing.