# Trust Not Ticket Volume Is the Right AI-Support Metric ## Claim A company deciding whether to expand an AI support agent's role should judge it by whether it can be trusted to represent the company accurately, not by whether it reduces ticket volume. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Applies specifically to AI systems that generate company-facing, trust-bearing output (support, sales, public-facing documentation agents). - Ticket-volume reduction remains a legitimate secondary metric for cost/efficiency reporting — the claim is about which metric governs the trust decision, not that volume is irrelevant to every stakeholder. - Doesn't specify how "trust" gets measured in practice beyond adversarial testing (see the companion note on release discipline) — this claim names the right target, not the instrument. ## Evidence GravityKit's support team explicitly rejected ticket-volume reduction as the deciding metric for expanding their DocsBot-powered widget's role, framing the real question as whether they were "deciding to trust software to speak for their company." They built a 44-scenario adversarial test suite instead — scored on factual accuracy, source-grounded answers, correct routing, and escalation behavior — as the actual gate. > "Teams that pride themselves on a VIP support experience do not evaluate AI support agents by whether they can reduce ticket volume. They are deciding whether to trust software to speak for their company." ## Links - [[3. Resources/Permanent Notes/Company-Facing AI Agents Need Release Discipline Not Ad-Hoc Edits]] — because extends; this claim names the right evaluation target, the companion note names the mechanism (adversarial testing + versioned release) that operationalizes it. - [[3. Resources/MOCs/AI Agent Safety MOC]] — because applies-in; metric selection is a precondition for any agent-safety evaluation process. - [[3. Resources/Permanent Notes/Decomposing a Capability Gap Into Tickets Makes It Closeable and Permanent]] — because extends: the same defect in ticket volume, arrived at from organisational design — closed tickets flatter precisely when they all share one unfixed cause. - [[3. Resources/Permanent Notes/A Ticket-to-Merge Clock Stops Before the Fix Reaches Users]] — extended by: ask where an agent-speed claim's clock starts and stops (Brad Vincent thread). ## Tests / falsifiers - Find a company that optimized for ticket-volume reduction alone and track whether trust-relevant incidents (factual errors, mis-escalations, brand-damaging responses) rose independent of volume trends. - If ticket-volume reduction and trust-worthiness turn out to be tightly correlated in practice, the distinction this claim draws matters less than it currently seems to. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Literature Notes/How GravityKit Made AI Support Earn Its Place on the Front Line]] — reports GravityKit's explicit rejection of ticket-volume as the deciding metric.