Most executive teams evaluating customer-facing AI open the conversation in the wrong place. They ask which chatbot, which vendor, which model. Dr. Jonah Tebaa argues that this is a product question standing in for a service-design question — and that until the service question is answered, no vendor comparison carries any weight.
His reasoning starts from an operational analogy. A contact center does not open without a written standard for how quickly a call is answered. A sales floor does not deploy representatives without rules for tone, escalation, and pricing discretion. Customer-facing AI, Tebaa points out, routinely launches with none of that scaffolding — a prompt, a personality brief, and a go-live date. The result is a system that impresses in a demo and behaves erratically in production. In his work advising teams on applied AI, he reframes that inconsistency not as a model-quality defect but as a specification gap, and proposes a fix he calls the Six Service Standards: a spec sheet written before any tool is chosen. Formal AI governance frameworks are converging on the same instinct — the NIST AI Risk Management Framework, the closest thing the US has to a reference standard for trustworthy AI, is itself being revised as part of the White House AI Action Plan, which is a reminder that a written standard is only useful if it is treated as a living document, not a launch-day checkbox.
The six standards Tebaa says every deployment must meet
- Speed. A stated maximum response time for every channel and urgency tier — a number, not an aspiration. A billing dispute during an outage sits in a different tier than a routine plan question, and each tier gets its own commitment.
- Certainty. The system states what it knows and explicitly flags what it does not, never guessing on price, policy, availability, or eligibility. A confidence threshold — not the model's fluency — decides whether an answer ships or defers to a human.
- Context. The AI enters every interaction already holding the customer's history, so a person who opened a case by email and follows up on chat never has to restate their order number. Tebaa notes this is a data-plumbing decision made before launch, not a function of the model's intelligence.
- Tone. Brand voice calibrates to the customer's emotional state rather than running one generic script. A routine password reset and a report of a downed production system demand different registers from the same assistant.
- Commercial sensitivity. The system is aware of account value and deal stage, so it does not apply a rigid, one-size-fits-all response to a strategic account mid-renewal — the same judgment a strong account manager already exercises, encoded as a rule.
- Recovery. When the AI is wrong, a built-in repair sequence takes over: acknowledge the error, own it without blaming "the system," remedy it, and log it so the failure does not recur.
Why the interface is not the product
A recurring theme in Tebaa's argument is that none of these standards change with the 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 requirements. The interface, in his framing, is packaging — a voice agent that fails the Certainty Standard is exactly as costly as a chat widget that fails it. Treating the chosen tool as the decision, he suggests, is what leads teams to buy capable models that still deliver an inconsistent experience.
The practical instruction he draws from this is one he says is almost never followed before a contract is signed: put written answers to all six standards on paper before evaluating a single vendor. What is the maximum response latency by channel and tier? What confidence threshold triggers a deferral instead of a guess? How is history carried across channels? How does tone shift with customer state? How is commercial context weighted? What is the exact recovery sequence when the system fails? Those six answers, Tebaa contends, become the procurement spec — handed to every vendor before the demo, because the demo always looks good, and only the spec reveals whether the system will hold up under real volume with a real customer who is not in a good mood.
