Section 1
Competence, honesty, and recourse
Trust in an automated interaction rests on three things, and they fail independently. Competence: the system gets it right often enough that using it beats the alternative. Most teams measure this one. Honesty: it does not claim to be a person, does not invent a policy, and says it does not know when it does not know. Most teams assume this one. Recourse: when it fails, the customer reaches someone with authority to fix it, quickly, without repeating themselves. Most teams skip this one, and it decides whether a failure becomes a complaint or a churn event. A highly competent system still destroys trust with the third leg missing. A moderately competent one holds trust perfectly well if failures resolve fast.
Section 2
Design the exit before the entrance
Build the escalation path first, then build the automation around it. In practice: a visible route to a human at every stage, not buried after three rounds of clarifying questions. A handoff that carries full context, so the customer does not restate their problem to the person who finally picks up. A defined response time on that path, published and met. The failure pattern is familiar because most of us have lived it. The bot loops, the escalation link is hidden, and the customer complains in public because that was the only channel that reached a human. At that point the automation has not reduced your support cost. It has moved it to your reputation. Buy versus build decisions shape how much of this you control: see [DIY vs. Outsourcing: Building vs. Buying AI Automation](/blog/diy-vs-outsourcing-building-vs-buying-ai-automation).
Section 3
Disclosure that helps rather than hedges
Two companies disclose AI use. One writes a legal sentence in the footer. The other says, at the top of the chat, that this is an automated assistant, that it can answer questions about orders and returns, that it cannot change a price or issue a refund above a threshold, and that typing one word connects a person. The second is not more transparent because it is longer. It is more useful because it sets an accurate expectation of capability. Customers calibrate their trust to what they think a thing can do. Over-claiming produces a failure they experience as deception. Under-claiming produces a customer who bypasses a system that would have helped them. Say what it does, say what it cannot do, say how to leave. That is the whole disclosure.
Section 4
The failures that actually cost you
Confident wrong answers. A system that hedges appropriately loses a little efficiency. A system that states a wrong delivery date, a wrong policy, or a wrong price with full confidence creates a promise you will either honour at a loss or break at a cost. Fake humanity. Giving the assistant a human name and a casual voice while never saying it is automated is a short term conversion trick with a long term bill. The customer finds out eventually, usually at the worst moment. Silent handling of complaints. If an automated triage closes a complaint without a person seeing it, you have not resolved anything. You have removed your ability to learn. The internal equivalent is covered in [AI Automation and Job Displacement: What Founders Should Know](/blog/ai-automation-and-job-displacement-what-founders-should-know). Asymmetry. Automating the parts that save you money while leaving the parts that help the customer manual is entirely legible to customers, and they read it exactly as it is.
Section 5
Controls that keep the promise
NIST frames AI risk management around trustworthiness, design, evaluation, and use. Translated to customer-facing systems: know what the automation can access, what it can change, what it must never decide alone, and who answers when it reaches a customer wrongly. The operating controls are unglamorous. Ground answers in your actual policy documents rather than model recall, so the system quotes your refund terms instead of inventing them. Cap the actions it can take without approval, particularly anything touching money or account status. Sample real conversations weekly and read them yourself. And keep a kill switch that any duty manager can use without a deployment.
Section 6
Measure trust, not deflection
Deflection rate is the metric vendors quote and the one most likely to mislead you. A conversation that ends without reaching a human is counted as a success whether the customer was helped or gave up. Better indicators: resolution on first contact, repeat contact rate within a week, escalation rate and time to human, the proportion of automated answers a reviewer would have sent, complaint themes, and retention among customers whose last interaction was automated. Watch the gap between deflection and resolution. When it widens, the system is getting better at ending conversations and worse at ending problems. How you narrate the change to customers matters alongside the mechanics: [How to Connect with Customers Through Brand Stories](/blog/how-to-connect-with-customers-through-brand-stories) covers that half.