An AI chatbot for customer support, and what to trust it with

Support is the first place most businesses try to put a language model, and it is a reasonable instinct. The volume is high, the questions repeat, and the cost of answering them is a person's afternoon. The projects that go badly are not the ones with a weaker model. They are the ones that never decided which questions the bot was allowed to answer.

This note is about drawing that line, what grounding actually buys you, the legal disclosure that now applies, and how to tell within a month whether the thing is working.

Sort your questions into three tiers first

Before choosing anything technical, take a month of real support conversations and sort them. Almost every support inbox falls into three groups, and the groups have completely different risk profiles.

The first tier is where the value is, and in most inboxes it is a larger share of the volume than people expect. The third tier is where the damage is, and the whole design problem is making sure a tier three conversation never gets a confident tier one answer.

Grounding matters more than which model you pick

A support bot that answers from the model's own training will be fluent, occasionally wrong, and wrong in a way that reads exactly like being right. That is the failure mode that costs you a customer, because the answer was specific and confident and about your refund policy, which the model has never seen.

The fix is not a better model. It is retrieval: the bot searches your actual documentation, quotes what it found, and is instructed to say it does not know when the search returns nothing relevant. The engineering work is mostly in the documents rather than the model, which is why the projects that succeed tend to start with somebody rewriting the help pages.

• If the answer is not in a document, the bot should not be answering the question.
• Show the source. A link to the page the answer came from converts a claim into something the customer can check.
• Test with the questions your customers actually asked, not the ones you imagine they ask.
• Measure the refusals. A bot that never says it does not know is not being careful, it is guessing.

You have to say it is a bot

This stopped being a matter of taste. Article 50 of the EU AI Act requires that systems which interact directly with people inform them that they are interacting with an AI, unless that is obvious to a reasonably well-informed and observant person. The information has to be given clearly and distinguishably, and the article's text is explicit that it must arrive at the latest at the time of the first interaction, in an accessible form. Those transparency obligations came into force on 2 August 2026.

If you serve customers in the EU this applies to you regardless of where you are based. If you do not, disclose anyway. The commercial case is the same as the legal one: a customer who discovers halfway through that they have been explaining a problem to software is angrier than one who knew from the start, and the disclosure costs a single line.

Design the handover before the answers

The handover to a person is the part that gets built last and matters most. A bot that cannot hand over is a wall, and customers experience a wall as a company that does not want to hear from them.

Three rules hold up. Make the escape route visible on every turn rather than hidden behind a phrase the customer has to guess. Trigger it automatically on frustration signals and on any tier three subject, without waiting to be asked. And pass the whole conversation across, because making somebody repeat what they just typed undoes any goodwill the speed earned.

The same discipline applies to any operational use of these models, and the broader version of that argument is in how to use AI in operations without breaking the business.

What to measure

Deflection rate is the number everybody reports and the easiest to fake, because a conversation the customer abandoned in frustration counts as deflected. Measure it alongside the share of bot conversations that end in a repeat contact within 48 hours. If deflection is up and repeat contact is up, the bot is not resolving anything, it is delaying.

Also read a sample by hand every week for the first two months. Fifty conversations read properly will tell you more about where the grounding is thin than any dashboard will, and the pattern you find is almost always a document that is out of date rather than a model that is confused.

When not to build one

If your support volume is genuinely low, this is not worth it. A bot needs enough traffic to justify the maintenance, and below roughly a few dozen conversations a week a good help page and a fast reply beat anything you can build.

If your documentation does not exist or is wrong, fix the documentation first and you may find you no longer want the bot. Half the value people attribute to these projects is really the value of finally writing down how the business works.

And if most of your inbox is tier three, do not automate the front door at all. Some businesses are ones where every incoming message is somebody having a bad day, and speed is not what those customers want. For a marketing-side view of where chatbots fit and which type suits which business, Khaled Badr's breakdown of the different chatbot types is a useful companion to this one.

If you do go ahead, scope it to tier one only for the first release. It is a smaller build, it is the part that works, and it gives you a month of real conversations to design the rest from. The general case for scoping this way is in how to scope a software project before anyone writes code, and the honest ceiling of assembling it from off-the-shelf parts is in where no code stops.