The situation
Support organizations do not distrust AI in the abstract. They distrust it because they have already absorbed the cost of a bad answer. The ticket that comes back angrier. The specialist who has to undo the automation before starting the real work.
The queue is not one product either. Global support and billing covers invoicing, product configuration, deployment and endpoint security, and a wrong answer does not cost the same in each. A wrong billing answer is an inconvenience. A wrong answer about endpoint detection policy is an incident.
Two other conditions shaped it. Anything touching customer conversations at enterprise and MSP scale has to clear security review, and most AI programs reach that gate late, after the design has hardened. The second does not appear on any architecture diagram. Marcio led security technical support for the 19 months before this role, and had taken those escalations himself.
The decision
Two calls did most of the work.
The first was to scope the agent by consequence rather than by volume. Pointing automation at the highest-volume ticket types optimizes for the metric instead of the operation. Categories were chosen on what happens when the answer is wrong. Where the cost is cheap and self-correcting, the agent answers. Where it creates an incident, the agent gathers context and hands off. Deflection is a result of that choice, never the input to it.
The second was to write the security and compliance case as part of the design rather than as a submission at the end. Enterprise AI rarely dies in the model. It dies in review, when someone asks where conversation data goes, what the agent may say, and who is accountable when it says something else.
Rejected: a general-purpose assistant pointed at the whole queue, and a rollout that treated the security team as an approver rather than a designer.
What was built
Four layers, inside workflows that already existed.
Ada carries the customer-facing conversation. Mosaic AI runs the LLM workflows behind it. Zendesk stays the system of record, which matters more than it sounds. When the agent hands off, the specialist inherits the whole conversation inside the ticket instead of a summary.
Around that sit the guardrails. Scope limits define what the agent may answer. Stop conditions define when it must give up and route to a human: low confidence, a security-sensitive topic, a customer asking twice. The handoff is a first-class path, not an error state, because it is what the support floor judges the system on.
The fourth layer is the one most programs skip. MCP server integrations connect the Mosaic API and Ada so conversations can be pulled and analyzed as data rather than sampled by hand. That is the reading layer. Without it, the deflection number is the only thing anyone can see.
How it was proven
Evaluation runs on conversations, not on the dashboard. Because transcripts are queryable, failure patterns get grouped instead of anecdotally reported. Answers given confidently and wrongly. Questions refused that should have been handled. Phrasings that send the agent down the wrong path. Patterns get fixed at the workflow level.
Deflection was defined before it was reported. A conversation counts only if the customer’s problem ended there. A conversation that closes and reappears as a ticket is a delay, and counting it as a deflection is how an AI program loses the operation’s trust.
The guardrails carry their own review discipline: what the agent may say about security products, where conversation data goes, and who signs off on changes before they reach customers. That is what the security and compliance case committed to.
What it changed
32% ticket deflection across global support volume, measured on live customer traffic rather than a controlled pilot, with customer self-service capacity improved alongside it. The agents run inside workflows the support organization already used, so nobody on the floor had to learn a second system to work a ticket.
The second change lasts longer. There is a loop now: conversations get read, failure patterns get named, workflows get corrected, and the correction is checked against real traffic. A number reported once and never re-examined is a launch announcement, not an operating result.
One number is published here. The denominator and the measurement window are internal, and they are not reproduced on this site.
What I’d do differently
Three things.
Build the reading layer first. The MCP integration that makes conversations analyzable belongs in the launch requirements, not the fast-follow list. Every week the shipping layer runs ahead of it is a week of failure patterns nobody can see.
Put security in the discovery workshop. Writing the compliance case personally worked, and it is the reason the rollout happened. It would have been shorter if the reviewers had shaped scope from the first session.
Agree the definition of deflection across functions before publishing the number. Support leadership, finance and the AI team can each hold a different one without noticing. The disagreement then surfaces in front of the people who approved the program, with 3 spreadsheets that do not match.
“A deflection that puts the customer back in the queue an hour later is not a deflection. It is a delay with a nicer interface.”