Before You Let AI Talk to Your Customers
A pre-launch checklist for customer-facing AI: scope, escalation, testing on real cases, disclosure, monitoring, ownership, and a kill switch.
An internal AI tool that makes a mistake costs you an hour. A customer-facing one that makes the same mistake costs you a refund, a complaint, or a screenshot on social media. The engineering is often similar. The exposure is not.
Most teams are ready to launch long before they have answered the questions below. Work through them before the system takes its first real conversation.
Write down what the system is allowed to do
Not what it can do — what it is allowed to do. These are different lists, and only the second one protects you.
Be specific and mechanical. "Answer questions about order status, shipping times, and return policy" is a scope. "Handle customer service" is not. Then write the second list: the actions the system must never take on its own. Issuing refunds above a threshold. Confirming a price. Making any statement about medical, legal, or financial outcomes. Changing account details. Promising a delivery date.
If a request falls outside the first list, the system hands off. That rule should be enforced in the system, not left to the model's judgment in the moment.
Decide what happens when it doesn't know
Every customer-facing deployment needs a defined path out. Who does the conversation go to, how fast, and what does the customer see while they wait.
Test the handoff before you test anything else. Does the human agent receive the full conversation, or does the customer have to repeat themselves? Does the handoff work at 11pm on a Sunday, when nobody is on shift? A system that escalates into an empty queue is worse than no system, because the customer has already spent five minutes getting there.
Test on your worst real cases, not your best invented ones
Pull one hundred real customer conversations from the last quarter. Not the easy ones — the angry ones, the ambiguous ones, the ones where the customer was wrong, the ones in your second and third languages. Run them through the system and read every response yourself, or have the team that handles those cases today read them.
Look for a short list of specific failures:
- Confident answers to questions the system has no source for
- Policy stated slightly wrong: the right idea, the wrong number or deadline
- Tone that goes flat or brittle when the customer is upset
- Anything that reads as a commitment your company would have to honor
- Behavior that changes when the customer writes in a different language
You are not looking for an accuracy percentage here. You are looking for the shape of the mistakes, so you can decide which ones you can live with.
Say what it is
Tell customers they are talking to an AI system, in plain words, at the start. Regulators in several markets now require it, and customers work it out anyway. The companies that get punished are the ones that appeared to hide it.
While you are at it, confirm what happens to the conversation data: where it is stored, how long you keep it, whether it leaves your jurisdiction, and whether it trains anything. Your legal and data protection people should sign that off before launch, not after the first subject access request.
Make the failures visible
Log every conversation and review a sample every week — genuinely read them, from the start. Set an alert on the signals that matter: escalation rate, conversations where the customer repeats themselves, drop-offs, and the volume of complaints mentioning the assistant.
Pick one number you will judge the system by, and agree on it now. Deflection rate, resolution rate, first-response time, satisfaction on handled conversations. Agree on the threshold that means you pull it back. Deciding that under pressure, three weeks in, goes badly.
Name an owner and build a kill switch
One person owns this system in production, by name, with the authority to turn it off. Turning it off should take one action and under a minute, and someone should have practiced it. If disabling the assistant requires a deploy, you do not have a kill switch — you have a hope.
Start narrow
Launch on one channel, one language, one category of question, ten percent of traffic. Widen it when the weekly review is boring. Teams that launch broadly and roll back rarely get a second attempt approved.
None of this is exotic. It is the ordinary discipline you would apply to any system that speaks for your company — which is what this is. We carry that weight for clients who would rather not build the scaffolding themselves, but the checklist works just as well in your own hands.