28% AI Ticket Deflection: What We Actually Built

28% of Tier 1 IT support tickets. Gone. Automated. No human involved. That was Year 1 of Tech-E — our internal AI support assistant built and deployed by the Enterprise Engineering team at GoTo Technologies.

I'm sharing the full story now because that number — which felt significant at the time — looks like a starting point compared to where enterprise AI is heading. And the way we got there is exactly the thing most organizations are skipping.

How Tech-E actually started

Tech-E didn't start as a full AI project. It started as a small, scoped prototype with a hard validation window — four weeks to answer one question: can an AI assistant handle high-volume, low-complexity IT support requests at sufficient accuracy to deflect tickets without increasing escalation rates?

The process was deliberately small: a focused problem statement, a small build team, weekly demos instead of monthly status updates, and a genuine willingness to stop if the evidence said to. Most IT organizations make experimentation too expensive — too much political capital, too much infrastructure commitment, too many stakeholders who need to approve before anything moves. We designed this to invert that. Make the cost of trying small so the cost of failing stays small too.

The prototype answered the question. The evidence at week 4 supported continuing. That discipline — deciding to scale based on proof, not enthusiasm — is what separated this from the AI initiatives most IT teams run once and never revisit.

The four things we got right

1. We defined success before we started. Not "reduce tickets" — that's an aspiration. We committed to specific metrics before deployment: deflection rate, CSAT delta, escalation rate, and bounce-back rate (tickets that the bot deflected but the user then re-submitted). Tracked from week one. Having pre-defined success criteria is what separates a pilot from a product.
2. We automated the boring stuff first. Password resets. VPN access requests. Common hardware questions. New hire equipment status. These are not glamorous. They are also the highest-volume, lowest-complexity, most repeatable tickets in any IT queue. Starting there gave us data volume fast, made the deflection numbers real quickly, and built internal credibility without touching anything that required judgment.
3. We built a feedback loop. Every deflected ticket that bounced back got reviewed. Bot wrong → retrain. User confused → fix the workflow. User phrased the question differently → update the intent model. We treated it like a product team doing sprint reviews, not an IT team doing maintenance. That loop is what makes the numbers improve over time instead of plateau.
4. We were honest with the team about what it wasn't replacing. Tech-E existed to remove friction — to route the easy, repeatable work away from humans so humans could do harder, higher-value work. That framing mattered more than any technical decision we made. Teams that feel like they're being replaced by automation protect the system from working. Teams that feel like the automation is working for them improve it.

What the numbers actually mean

28% deflection is the headline. What it actually represents: a meaningful percentage of the team's time freed up from routine triage. CSAT going up 12 points simultaneously — while reducing human touchpoints — tells you something important: the users who got fast, accurate automated responses were more satisfied than the ones who waited in queue for a human who was handling something just as routine.

The CSAT improvement wasn't because the AI was warm and empathetic. It was because the AI was fast and accurate for the problems it was trained on. Users don't care whether a human or a machine answered their password reset — they care that it was resolved in 2 minutes instead of 45.

What we'd do differently

We underinvested in intent modeling early. The initial training data was too narrow — it reflected the tickets our most vocal users submitted, not the full distribution of what the organization actually needed help with. It took two quarters of bounce-back data to fully understand the gaps. We could have caught more of that earlier with broader user research before deployment.

We also underestimated how much the quality of the underlying knowledge base mattered. The AI can only be as good as the documentation it draws from. Our KB had gaps and inconsistencies that we'd deprioritized for years. Tech-E exposed them immediately. In hindsight, the knowledge base cleanup should have been a prerequisite for deployment, not a parallel workstream.

The broader lesson for enterprise AI in IT

Every IT organization is under pressure to "do more with AI" right now. Most of that pressure is vague. Boards want AI ROI. CIOs want AI strategy. Nobody is funding the quiet experimentation layer that separates real AI capability from a collection of expensive pilots.

The disciplined experimentation approach was that layer. Low cost of entry. Fast kill criteria. Outcome-focused from the start. The 28% deflection didn't come from a big-bang AI project with a 12-month implementation timeline. It came from a small, intentional experiment that earned the right to scale — and a team that treated scaling as a product problem, not a deployment problem.

Building the infrastructure for disciplined experimentation is the real competitive advantage in enterprise AI right now. Not the AI model. The operating model you build around it.