When the answer is not a chatbot

A chat assistant is a channel, not a strategy, and for a large share of what arrives in a support queue it is the most expensive way to solve the problem. If the answer is a status, send it before they ask. If it is a policy, fix the page. If it is a form field, shorten the form. Build the assistant for what is left, which is usually smaller and more interesting than the original brief.

The best possible answer to “where is my order” is an email that arrived yesterday saying where it is.

Key takeaways

• Deflection removes a contact from the queue. Prevention removes it from existing. The second is cheaper and nobody sells it.
• Four alternatives routinely beat a chatbot on the same budget: proactive notification, five rewritten help pages, a shorter form, better routing.
• If the content is not written down, chat will invent it. That is a documentation project wearing a technology costume.
• Chat earns its place on the long tail, out of hours, and before a purchase, where the alternatives do not reach.
• The comparison usually leaves out content maintenance, escalation design and the refusal rate.

Who this applies to

Somebody has proposed a chat assistant and you are deciding whether to fund it. This is the argument for spending the money elsewhere, and the conditions under which that argument stops applying.

If you have already decided to build one, the question of which intents to start with is ecommerce support: what to automate first, and whether to build or buy it is build or buy AI customer support.

Deflection and prevention are different products

Every proposal for a support assistant is measured on deflection: contacts the system handled instead of a person. It is a real saving and it is the second-best outcome.

The best outcome is that the contact never happens. A customer who receives a dispatch notification with a working tracking link, and a delay notification when the carrier stalls, does not write to ask where the order is. There is no conversation to deflect, no answer to get wrong, and no queue entry to pay for.

This distinction decides where the money should go, and it is invisible in the way these projects are usually scoped, because a prevented contact never appears in the ticket data the business case was built from. The scoping exercise measures the queue and proposes something to sit in front of the queue.

Ask a different question first: of the top five contact reasons, how many are the customer asking for information you already had and did not send?

Four things that usually beat it on the same budget

Proactive notification. Order dispatched, order delayed, payment failed, subscription renewing, document expiring. Each of these is a contact reason that can be turned into a notification, and the engineering is a fraction of an assistant.

Rewriting the five pages people actually land on. Support content is usually written once, by whoever launched the product, and never revised against the questions that arrived afterwards. A day spent rewriting the top five help pages against the last quarter’s tickets moves self-service more than most assistants do, and it also improves the assistant later, because retrieval can only work with what exists.

Shortening the form. A meaningful share of support contacts are people who could not complete something. Every required field is a place to fail, and the contact it generates is more expensive than the field was worth.

Routing to the right person the first time. For anything that will reach a human anyway, classification and routing capture a large part of the available saving with none of the customer-facing risk. This is the same argument as draft replies in a shared inbox, and it applies to any queue.

None of these is a satisfying answer to “what is our AI strategy”. All four are cheaper, faster and more certain than a chat assistant, and doing them first makes the assistant better if you build it afterwards.

When the content does not exist

This is the failure that a chatbot cannot solve and reliably makes worse.

If the answers to your customers’ questions live in the heads of three experienced people and not in any document, an assistant has nothing to retrieve. It will answer anyway, from the model’s general knowledge of businesses like yours, and it will sound plausible. That is the worst outcome available: confident, wrong, and at scale.

The tell is in the scoping conversation. Ask where the answer to a specific awkward question is written down. If the response is that somebody knows, you have a documentation project, and the honest sequence is to do that project first. It is also the cheaper half, and it delivers value with or without the assistant.

Where chat genuinely wins

Four places, and they are real.

The long tail of policy questions. Hundreds of low-frequency questions, each too rare to justify a page, all answerable from documents you already maintain. This is retrieval’s home ground and no amount of page rewriting substitutes.

Out of hours. An answer at 11pm from a system beats an answer at 9am from a person, for anything a customer wants to resolve before sleeping.

Before the purchase. Pre-sales questions convert rather than deflect, which makes the economics completely different and usually better. The related design question is in qualifying inbound enquiries.

Languages you cannot staff. With the caveat that you must be able to support the escalation in that language too, or you are generating tickets nobody can action.

If your situation is one of these, the case for chat is strong and the rest of this article does not apply to you.

What the comparison usually leaves out

Three costs that appear after the decision.

Content maintenance. The assistant is only as current as the documents behind it, and somebody has to own that permanently. This is a standing cost in a business case that usually shows a one-off build.

Escalation design. A handover that restarts the conversation is worse than no assistant. Doing it properly is real work, described in confidence thresholds and escalation design.

The refusal rate. Every assistant declines or misroutes some legitimate requests, and unless you measure it, that number is running unobserved on real customers. The argument is the same one as for any guardrail, in guardrails: what to check going in and coming out.

What we actually recommend, and how often

On roughly a third of the support enquiries we get, our first recommendation is not an assistant. It is notifications, content, or routing, in that order, and a review afterwards to see what is left.

That is a smaller engagement than the one being discussed, and we lose some of them, usually to a vendor who will build what was asked for. The reason we keep saying it is that a chat assistant deployed on top of an unfixed queue inherits every problem the queue had, and adds a new one: a confident voice in front of the customer.

Where we have been wrong: we have under-recommended chat for pre-purchase questions. We were reasoning from support economics, where deflection is the frame, and pre-sales does not work that way at all - the same answer that saves four minutes in support can convert an order. The rule we use now is that any assistant proposal gets assessed on both sides of the purchase, not just the one that generated the request.

When a chatbot is right after all

When the four cheaper things are already done. If notifications are in place, the content is current, the forms are short and routing works, the remaining queue is genuinely the long tail, and that is what an assistant is for.

When volume makes the arithmetic obvious. Above a few thousand contacts a month, the long tail alone justifies the build.

When the constraint is hours rather than headcount. If most of your queue arrives outside working hours, a person is not the alternative.

Frequently asked questions

Is this an argument against AI in support?

No. It is an argument about sequence. Most of these systems are built on top of a queue that was never cleaned up, and the cleanup is cheaper, faster and improves the assistant if you build it later.

Our competitors all have one. Does that matter?

Only if their customers use it. A chat widget is a visible signal of modernity and a poor one, and buyers judge support by whether their problem got solved, not by which interface it was solved in.

What if leadership has already decided?

Then build it, and build the notifications in the same project. They are cheap next to the assistant, they reduce its load, and the combined result is better than either alone. That is a compromise worth proposing rather than a battle worth having.

How do we know which contacts are preventable?

Classify ninety days of tickets and mark the ones where the customer was asking for information you already held at the time they wrote. In most operations that fraction is larger than anyone expects.

Does a knowledge base not solve this on its own?

For the top questions, yes, and that is the point of the second recommendation. It stops solving it at the long tail, where a page per question is not maintainable and retrieval is.

Next step

If you are weighing a support assistant, the useful first exercise is classifying ninety days of contacts and asking how many were preventable. AI support agents starts there, and it sometimes ends with a recommendation to send better emails instead.

Related: Build or buy AI customer support · Ecommerce support: what to automate first · Confidence thresholds and escalation design · Measuring cost per resolved task · AI support agents