AI

Which enquiries should never reach a machine first

Every deployment I have reviewed has a plan for what the assistant does when it fails. Almost none has a plan for what should never have reached it.

That is the wrong way round. The fallback matters, but it is a repair. The routing decision at the front door is the design, and it is made once, cheaply, before any of the technology exists. Get it right and a mediocre assistant is safe. Get it wrong and an excellent one will eventually cost you a customer you cannot afford to lose.

The axis everybody sorts on is the wrong one

The instinct is to sort enquiries by difficulty. Simple questions to the machine, hard ones to a person. It is intuitive and it does not work, because difficulty is a property of the answer and the risk lives in the question.

“Where is my order” is trivially easy to answer and catastrophic to answer coldly when the order is nine days late and the customer has already called twice. “What are your opening hours in Ramadan” is harder to get right and carries no risk at all if it is slightly wrong.

Sort on consequence instead. Not how hard is this to answer, but what happens if the first reply is wrong, generic, or merely late. That single change reorders the whole queue, and it usually shrinks the set that needs a person to something a small company can actually staff.

Two columns showing four customer messages routed one way when sorted by difficulty and the opposite way when sorted by consequence
Same messages, same staffing. Only the sorting rule changed.

Four kinds that should never meet a machine first

One: the customer has already lost something. Money has left their account, an order has not arrived, a service they paid for did not happen. Whatever the machine says, however correct, the first reply reads as the company avoiding them. The content of the message is not the problem; the fact of it is.

Two: the clock belongs to the customer, not to you. A deadline they will miss, a document they need before a bank cut-off, an appointment tomorrow. Here the cost of a wrong routing is not annoyance, it is a real loss they will attribute entirely to you, and correctly.

Three: it is about a person, or about a previous exchange. A complaint naming an employee, or a message that begins “as I explained last time”. A machine cannot see the history that makes the message make sense, so it answers the words rather than the situation, which is precisely the experience the customer was already complaining about.

Four: it is from an account you cannot lose. The enterprise client, the government contract, the distributor who is a fifth of your revenue. There is nothing technical about this category. It is commercial, the list is short, and it should be written down by name.

And a fifth that overrides the other four: anything expressed in distress. If somebody is frightened or furious, the correct first response is a human being, in any language, regardless of what the message is actually about.

How to detect them without a clever classifier

Here is the part that saves people a year. You do not need the machine to recognise these categories, and you should not rely on it to.

Route on the entry point instead of on the content. A separate form for anything order-related. A number that goes straight to a person. A distinct WhatsApp entry for existing customers, separate from the one on the marketing page. Each of these is a routing decision the customer makes for you, before a single word is classified, and it is close to free.

Add a short keyword list on top of that — the words for late, wrong, refund, complaint, lawyer, and their equivalents in Arabic and in the dialect people actually type. Not to answer, only to divert. A crude list that over-diverts is the correct kind of wrong here: sending a few ordinary questions to a person costs you minutes, and the opposite error costs you the customer.

Then let the assistant handle the rest, which in most businesses is still the large majority. That is how automation is supposed to be scoped in the first place: not by what it can do, but by what it is allowed to touch.

Three cards describing routing on the entry point, diverting on a crude keyword list, and acknowledging rather than answering
Three layers, none of which needs a model to work.

What the machine should do when it is unsure

It should say so and hand over, and this is a design decision rather than a model capability.

Google’s People and AI guidance treats low confidence as a distinct class of failure with its own correct response, which is to explain the limitation rather than produce an answer anyway, and it makes the wider point that how failures are handled is what calibrates a user’s trust in the system. A confident wrong answer does more damage than a visible handover, because it teaches the customer that nothing the system says can be relied on.

What it must not do is bury the exit. I have written before about what an Arabic assistant has to get right, and the route to a person being visible immediately is the part that survives every other disagreement about design.

Borrow the discipline from incident response

The best model for this is not a customer service handbook. It is how engineering teams handle outages.

Google’s incident management practice rests on a recursive separation of responsibilities: everyone involved knows their role and does not stray into someone else’s. The failure modes it names are worth reading with an inbox in mind — a responder so absorbed in the immediate task that nobody is watching the whole picture, communication nobody has time for, and people freelancing changes that make things worse.

An inbox behaves identically. The value is not that someone is answering, it is that the right person owns it and everyone else knows they do not. Declare the class on arrival, name the owner, and the freelancing stops. This is the same reasoning as response times defined against severity in a maintenance agreement, and it is not a coincidence.

The one thing a machine may safely send

An acknowledgement is not an answer, and it is the most useful message in the whole system.

Three elements: confirmation that a person has it, the name of that person, and when they will reply expressed as a time rather than as soon as possible. That message can be sent instantly by a machine to every one of the four categories, and it buys the hours that the person actually needs. It is also the message most companies skip, because it feels like doing nothing.

On WhatsApp this has a technical edge worth knowing. Meta’s messaging rules put free-form replies inside a service window that opens when the customer writes. If your person picks it up after that window has closed, you are into templates and charges rather than a normal conversation, so the acknowledgement is not merely good manners — it shapes what you are able to say later, and at what cost.

Measure the thing you actually care about

First response time is the standard metric and it becomes a lie the moment a machine is answering, because the machine always wins it.

The number worth watching is time to a person who can decide, measured only across the four categories. Everything else can be measured on volume and deflection as usual. Google Cloud’s reliability guidance makes the same argument in a different domain: define the target from what the user experiences, not from what the system reports about itself.

Two supporting numbers are enough. How often the machine handled something from a protected category, which should be near zero and is your routing defect rate. And how often a person overrode the machine, which is your evaluation set arriving for free.

What I would do in the first week

Before any tooling. Pull the last two hundred real inbound messages and mark each one against the four categories. Most companies find the protected set is between eight and fifteen per cent, which is far smaller than the fear in the room and entirely staffable.

Write the list of named accounts. Split one entry point. Put the keyword divert in. Write the acknowledgement message and have a person approve its wording. That is a week of work, it costs nothing, and it holds whatever you buy afterwards.

It is also the sort of thing worth settling before the readiness questions are answered and long before anything is designed or built. The routing policy is not a feature of the assistant. It is the boundary you hire it inside.

Frequently asked questions

We are five people. Is a routing policy not overkill?

It is shorter at five people, not absent. The whole thing fits on one page: four categories, a list of named accounts, one keyword list, one acknowledgement message. Small companies actually need it more, because there is no second line to catch the mistake and the owner is usually the person the angry customer eventually reaches. Writing it down takes an afternoon and it survives the one person who currently holds it all in their head going on leave.

Will diverting so much to people defeat the point of automating?

Only if the protected set is large, and when measured it rarely is. Marking up two hundred real messages usually puts it between eight and fifteen per cent, which means the assistant still handles the great majority and does so without the failure mode that would have got it switched off. The economics of these systems have never depended on the last ten per cent. They depend on the routine volume, which is untouched by any of this.

Can the assistant not learn to spot these categories itself?

Increasingly yes, and it should still not be the only line of defence. Content classification fails on exactly the messages that matter most: the terse ones, the ones in dialect, the ones where the customer is being polite about something serious. Entry-point routing and a keyword divert cost almost nothing and fail in a safe direction. Use the model as a second layer that catches what the crude rules missed, never as the first.

What about after hours, when there is no person to route to?

Then the acknowledgement is the whole product, and it has to be honest. Confirm receipt, say a named person will reply, and give the actual hour rather than implying someone is looking now. The damage is done by messages that pretend to be handling it. A customer who is told plainly that the office opens at eight and that Fatima will reply first thing will usually wait; one who receives three cheerful automated replies overnight will not.

How do we handle this across Arabic and English at once?

The four categories are language-independent, which is the useful part. What is language-specific is only the keyword list, and it has to be written from your own inbox rather than from Modern Standard Arabic, because customers write in dialect and mix English words in. Take the actual words from the last two hundred messages. Expect the list to look wrong on paper and work in practice, and revisit it once a quarter.

Have a project, problem or idea?

Let's discuss what you're trying to build, improve or grow — and whether I can help.

Discuss Your Project