The call I almost took
Last quarter, a mid-sized logistics company reached out about an AI project. They wanted to automate their customer update emails — the kind that go out when a shipment changes status. Hundreds per day. Manual process. Took one person about two hours each morning.
On paper, this is an obvious automation candidate. I almost said yes before the discovery call.
Twenty minutes into that call, I asked one question: "What does the person who writes these emails actually do in those two hours?"
The answer changed everything. She wasn't just filling in templates. She was reading the notes from drivers, cross-referencing with customer history, deciding which delays warranted a proactive call instead of an email, and flagging accounts at risk of churning. The email was the output of a judgment-heavy triage process, not the process itself.
Automating the email would have saved the two hours. It would also have removed the human judgment that was silently catching churn risk and preventing escalations.
The problem didn't need AI. It needed a better-documented decision framework so that judgment could be delegated or eventually encoded properly. That was a three-week process improvement engagement, not a six-month AI project.
Why clients consistently buy the wrong solution
The pattern isn't unique to that company. I see it in a majority of inbound AI consulting enquiries.
A business has a visible inefficiency. Someone in leadership has read about AI. The connection gets made: "this looks automatable." The enquiry arrives framed as an AI project because AI is the current vocabulary for "I want this to be more efficient."
The problem is that efficiency and automation are different things. Efficiency can come from process redesign, better tooling, clearer role definitions, or eliminating work that shouldn't exist at all. Automation is one specific solution to one specific class of problem.
When the wrong solution is selected first, one of two things happens. Either the project fails partway through, when the complexity of automating something fundamentally judgment-dependent becomes obvious. Or the project succeeds technically but the business outcome is poor — the automated system handles the easy cases, the hard cases fall through, and the original problem is still there in a new form.
Both outcomes are expensive. Neither is good for the client.
What I actually do in the first call now
I stopped treating the first call as a discovery call for the AI solution. I treat it as a diagnosis call for the underlying problem.
The questions that matter:
**What specifically is slow, expensive, or error-prone?** Not "our customer communication is inefficient" — what specifically goes wrong, how often, what does it cost?
**Who does this work today, and what do they actually do?** The job title and the role description rarely match what the person spends time on. The actual work is usually more judgment-intensive than the description suggests.
**What would "fixed" look like?** This one surfaces misalignments fast. If the answer is "I wouldn't need someone doing this anymore," that's a different problem than "the person doing this would spend less time on it." The first is a headcount reduction goal with AI as the method. The second is a leverage goal. They require different solutions.
**What have you tried already?** This tells me whether the business has engaged with the problem seriously before deciding on AI, or whether AI is the first solution being considered because it's the current trend.
Eighty percent of the time, this conversation surface a problem that is partially or fully solvable without AI. Sometimes the full solution is AI. Sometimes it's a combination. Rarely is the original framing — "we want to automate this with AI" — the right brief.
The three categories most enquiries fall into
**Category 1: Process problem, not an AI problem.** The work is inefficient because the process is unclear, inconsistently executed, or doing things it doesn't need to do. Fixing the process produces the efficiency gain. Adding AI to an unclear process produces an automated unclear process.
**Category 2: Data problem, not an AI problem.** The business wants AI to draw insights from or act on their data. The data is inconsistent, incomplete, or not structured in a way that supports the task. AI won't fix data quality problems — it will reflect them more loudly. The work is data governance first, AI second.
**Category 3: Genuine AI problem.** The task involves volume, pattern recognition, or synthesis that genuinely exceeds what a human process can scale. The data is reasonably clean. The decision criteria are explicable. The output can be evaluated. This is the category AI is actually built for.
Most inbound enquiries are Category 1 or 2. A meaningful minority are Category 3. The fee structure for diagnosing which category you're in is the most honest thing I can offer early in an engagement.
Why this is commercially counterintuitive
Telling a client "you don't need an AI project" is a short-term revenue decision that looks like leaving money on the table.
It isn't.
A client who runs a Category 1 engagement and gets a process improvement outcome — not an AI system — has a clear win, a contained scope, and a shorter timeline to results. That client comes back when there is a genuine AI problem. That client refers other businesses. That relationship is worth more over three years than the one AI project that underdelivered.
A client who runs an AI project on a Category 1 problem spends more money, takes longer to reach any benefit, and often ends up with a result that doesn't solve the underlying issue. That client doesn't come back. And they have a story about AI consulting that doesn't help anyone.
The businesses in our portfolio that use AutoChat's WhatsApp automation at [autochat.in](https://autochat.in) see this pattern clearly: the ones who got results quickly were the ones who had their message routing and response criteria clear before they automated. The ones who struggled tried to automate the judgment first. Same technology, very different outcomes.
The question worth asking before the next AI project
Is the problem you're trying to automate actually a process that someone has thought through carefully and documented?
If the answer is no — if the current approach is "Sarah does it and she just knows how" — the first investment is making Sarah's knowledge explicit. Document the criteria. Map the edge cases. Build the decision framework. That work alone often produces efficiency gains that reduce or eliminate the AI need.
And if, after that documentation exercise, there is still a volume or pattern-matching problem that scales beyond human capacity, the AI project has a foundation. The result will be dramatically better.
The trap is not AI. The trap is reaching for AI before the problem is understood well enough to evaluate what it actually needs.
*Image suggestion: a decision tree diagram showing the three categories of business problems — process problem, data problem, genuine AI problem — with diagnostic questions leading to each branch.*
25+ years building web technology, SaaS, hosting, and AI automation. Founder of Hostao, AutoChat, RatingE, and BestEmail. I help businesses build stronger digital presence and real operating systems.
Want to implement this for your business?
I help business owners build digital systems that actually work. Let's talk about your specific situation.