When an executive team sits down to evaluate customer-facing AI, the conversation almost always starts in the wrong place: which chatbot, which vendor, which model. That is a product question. The real question is a service-design question, and until it is answered, no vendor comparison means anything.
A contact center does not open its doors without a written standard for how fast a call gets answered. A sales floor does not send representatives out without rules for tone, escalation, and pricing discretion. Customer-facing AI, by contrast, usually goes live with none of this. We give it a prompt and a personality brief and call it done. Then we are surprised when it feels inconsistent — sharp in a demo, erratic in production. In my own work advising teams on applied AI, I have stopped treating this as a model-quality problem. It is a specification problem. Before anyone evaluates a tool, they need to write down the standards the system must meet. I call them the Six Service Standards.
1. The Speed Standard
Every channel and urgency tier needs a stated maximum response time — not a vague aspiration, a number. A telco chat window might commit to a first response under thirty seconds for live chat and under two minutes for an async query; a billing dispute during an outage is a different tier than a routine plan question. Meeting the standard looks like a customer never watching a typing indicator flicker for four minutes while a routing decision gets made somewhere upstream. Failing it looks exactly like that.
2. The Certainty Standard
The AI must say what it knows and flag what it does not — explicitly, every time. It should never guess on price, policy, availability, or eligibility. A regional bank's assistant handling a loan-eligibility question should say, plainly, "I don't have enough information to confirm your eligibility — let me connect you with a banker who can," rather than approximate an answer that turns out to be wrong. A confidence threshold, not the model's fluency, decides whether an answer ships.
3. The Context Standard
The AI should enter every interaction already holding the customer's history — prior tickets, order status, the channel they were just on. A retail customer who opened a return case by email and follows up on chat an hour later should not have to restate their order number. Meeting this standard is invisible; the customer simply feels remembered. Failing it is the single most common complaint about deployed AI, and it has nothing to do with the model's intelligence — it is a data-plumbing decision made, or not made, before launch.
4. The Tone Standard
Brand voice has to calibrate to the customer's emotional state, not run one generic script for everyone. A B2B SaaS support assistant fielding a routine password reset can be brisk and light. The same assistant fielding a message from a customer whose production system is down needs a register that is direct, accountable, and free of cheerfulness. Deploying a single tone script across both situations is a design failure disguised as consistency.
5. The Commercial-Sensitivity Standard
The AI needs to know account value and deal stage, because a response that is fine for a self-serve customer can be the wrong response for a strategic account. An AI assistant embedded in a sales conversation should not apply a rigid no-exceptions discount policy to an enterprise account mid-renewal at seven figures, and it should not extend concierge-level flexibility to an account that does not warrant it either. This is not favoritism — it is the same commercial judgment a good account manager already applies, encoded as a rule rather than left to a human's memory of the account.
6. The Recovery Standard
When the AI is wrong, there has to be a built-in repair sequence: acknowledge the error, own it without deflecting to "the system," remedy it — refund, replacement, correction — and log it so the same failure does not recur. An airline assistant that mis-books a seat and then apologizes without logging the defect will make the identical mistake for the next customer. Recovery engineered into the system's own behavior is what separates a service failure that costs one relationship from a service failure that costs a pattern of them.
None of this changes based on delivery channel. A chat widget, a voice agent answering the phone, and an AI assistant embedded inside a sales team's tooling are all held to the same six standards — the interface is packaging, not the product. A voice agent that fails the Certainty Standard is exactly as costly as a chat widget that fails it.
The action item is simple and, in my experience, almost never taken before a contract is signed: before you evaluate a single vendor or greenlight an internal build, put written answers to all six standards on paper. What is the maximum response latency, by channel and tier? What is the confidence threshold below which the system defers instead of guessing? How is history carried across channels? How does tone shift with customer state? How is commercial context weighted into responses? What is the exact recovery sequence when the system gets it wrong? Turn those six answers into your procurement spec, and hand it to every vendor before they hand you a demo. The demo will always look good. The spec is what tells you whether the system will hold up on a Tuesday afternoon, under real volume, with a real customer who is not in a good mood.
