Building an Internal AI Helpdesk: Architecture & ROI

Add headcount to an IT helpdesk and ticket volume finds a way to grow to match it. That’s not a staffing failure — it’s a structural one. A meaningful share of helpdesk volume is the same handful of request types, repeated hundreds of times a month, each one requiring a human to do something a system could largely do itself.

Where the Volume Actually Comes From

Password resets and account unlocks alone routinely make up 30–40% of total helpdesk ticket volume. In a real 600-employee financial services deployment, that translated to 1,200 tickets a month, 38% of them password resets and account unlocks, each handled manually by L1 staff at roughly £18 per ticket in fully loaded cost. None of that work required judgment — it required access to Active Directory and a defined process, both of which a properly scoped AI agent can be given directly.

The Architecture

A helpdesk bot that actually resolves tickets, rather than just routing them to the right queue faster, needs four things in place:

1. A knowledge base the bot can actually use. Existing IT runbooks, KB articles, and documented resolution patterns need to be catalogued and made retrievable — this is the training data for what “correct resolution” looks like for your specific environment, not a generic IT support script.
2. Scoped write access to the systems that matter. Read access alone produces a bot that can explain how to reset a password, which isn’t the point. Real resolution requires a service account with defined, auditable permissions into Active Directory or Azure AD, and an integration into the ITSM platform to create, update, and close tickets.
3. Deployment on the channel employees already use. Microsoft Teams, Slack, or a web widget — wherever the request would have gone anyway. Adding a new destination people have to remember to visit defeats the point.
4. A clean handoff path for what it can’t resolve. The bot’s job isn’t to resolve 100% of tickets; it’s to resolve the mechanical ones and hand off the rest with full context attached, so the human agent isn’t starting from a blank ticket and a “hi, I have a problem” message.

The Rollout Sequence That Works

Building this in the right order matters more than building it fast. A knowledge base audit comes first — cataloguing runbooks and common resolution patterns before any bot configuration happens, because a bot trained on incomplete or outdated documentation just automates bad answers faster. Bot design and integration follows: configuring AD/Azure AD access for account actions and wiring up the ITSM connection. Deployment happens on the channels employees already use. Then, critically, there’s a continuous training loop — a weekly review of unresolved intents (the questions the bot couldn’t answer) to expand coverage and improve resolution rate over time, rather than treating launch as the finish line.

What Realistic ROI Looks Like

In the deployment referenced above, the AI bot took over password resets, account unlocks, and around 40 other common request types autonomously, and the L1 team that used to handle those manually was redeployed to onboarding and project work instead. The measured results: 52% ticket deflection, roughly £11,200 a month in L1 cost eliminated, and average resolution time dropping from 3.5 hours to 90 seconds for the request types the bot handled directly.

That last number is worth sitting with. The win isn’t just cost — it’s that employees waiting on a password reset went from a multi-hour queue to effectively instant resolution, which is the kind of change that actually gets noticed and appreciated inside an organisation, not just reported in a cost-savings deck.

Getting the Scope Right

The mistake to avoid is treating this as “deploy a chatbot and see what happens.” The bot needs to be scoped to a defined, well-documented set of request types with real system access to resolve them — not launched broadly and hoped into usefulness. SG2’s AI Helpdesk Bot engagements start with the knowledge base audit specifically because that scoping work determines whether the bot resolves tickets or just generates a different kind of complaint.