Automation & AI
An AI bot that took 85% of the load off IT support
A three-bot IT support model built on Microsoft Foundry and grounded in internal knowledge: one routes tickets using past incidents, one helps L1 service-desk engineers from documentation, and one gives employees a self-service path before work reaches IT.
- Published
- Built on
- Microsoft Foundry
- Retrieval
- Azure AI Search
- Support model
- Triage · L1 service desk · End-user support
- Integrated with
- Internal knowledge base & ticketing system
IT leadership view
Routine demand moved out of the queue
Common requests stopped competing with incidents that needed an engineer, so the helpdesk could protect response time without adding headcount.Service desk view
L1 support with context
Engineers received technical guidance from internal documentation and inherited better ticket context when automation could not close the request.Employee view
Self-service before waiting for IT
Users could troubleshoot simple issues and create a ticket with the right context instead of starting every request as a blank message.Tools used
The platform behind the support model
Microsoft Foundry
The AI application layer used to design, evaluate, and operate the support assistants inside a governed Microsoft environment.
Azure AI Search
The retrieval layer used to ground ticket triage and support answers in historical incidents and internal documentation.
Support model
Three bots, each with a different job.
Ticket routing
Triage bot
Reads the ticket description, retrieves similar historical incidents through Azure AI Search, and routes the request to the queue most likely to resolve it.
Service desk assistance
L1 Help Desk Bot
Supports the service desk with technical answers grounded in internal documentation, so engineers spend less time searching and more time resolving.
Employee self-service
End User Bot
Gives every employee a basic troubleshooting path and creates a ticket with context when the issue needs a person.
The support queue, before and after
The result came from splitting support demand into distinct jobs — routing, documentation-backed assistance, and human escalation — instead of pointing one assistant at the whole queue.
Before
One queue for everything
- Every request landed in the same queue — simple, misrouted, and genuinely technical work mixed together
- Service desk engineers answered repetitive requests while searching documentation by hand
- Employees waited for IT even when the first step was basic troubleshooting
- Escalations often started with missing context and repeated clarification
After
Three bots around one workflow
- Requests are separated by type before a person is involved, so each kind of work follows its own path
- Engineers get documentation-backed answers inside the flow and keep their time for work that needs them
- Employees get a self-service first step and only reach a person when the issue genuinely needs one
- Work that reaches a person arrives with the conversation and attempted steps already attached
Core insight
The value was not a bot answering questions. It was a support queue redesigned by intent.
Ticket routing, L1 technical assistance, and end-user self-service are different jobs. Treating them as one chatbot would have recreated the same bottleneck in a new interface.The starting point
One queue was carrying three different kinds of work.
The IT support queue was not overloaded because every request was difficult. It was overloaded because different kinds of work were arriving through the same path: simple end-user troubleshooting, requests that needed the right queue, and technical L1 questions that required documentation.
Each category was reasonable on its own. Together, they consumed the team's day and pushed the issues that genuinely needed a person further down the queue.
The knowledge to handle much of this work already existed in documentation and historical incidents. The business problem was that people had to find it manually, one ticket at a time.
The approach
Design the support model around the work, not the tooling.
Caellix started from the work, not the tool. Rather than point one assistant at the whole queue, the support process was split into three distinct jobs — routing, service-desk assistance, and employee self-service — each handled by a bot built for that role (detailed below).
Microsoft Foundry provided the governed AI application layer, and Azure AI Search grounded every answer and routing decision in the company's own incidents and documentation — so the system relied on internal evidence, not generic internet output.
The ticketing integration closed the loop: whatever the bots could not resolve became a ticket for a human, carrying the context it had already gathered.
What was delivered
What the engagement put into production.
- A three-bot support model — triage, L1 and end-user — running as one process
- Retrieval grounded in the company's historical incidents and internal documentation through Azure AI Search
- A Microsoft Foundry implementation connected to the existing ticketing system
- An escalation path that hands unresolved work to people with full context attached
- Confidence-based handoff: anything the bots cannot resolve or classify still reaches a human
Business change
The helpdesk stopped being the first stop for every small problem.
The support experience changed because demand was handled at the right level. Employees did not need to wait for a person to try the first troubleshooting steps. Service desk engineers did not need to search the same documentation repeatedly. Ticket routing no longer depended only on how clearly the user described the problem.
The design also protected the support team from a common automation failure: deflection without ownership. When the bots could not resolve or classify something confidently, the work still moved to people — but with better context than the original ticket would have carried.
- Fewer routine requests reached the human queue
- L1 engineers received documentation-backed assistance inside the support flow
- Tickets arrived in better queues with more useful context
- Employees gained a faster first response without removing the human escalation path
The result
85% of the routine workload — handled without a human.
The repetitive requests that used to dominate the queue no longer had to start with a person — they were resolved, routed, or handed over with context before reaching one.
The outcome was an 85% reduction in routine helpdesk workload. The support team's time shifted toward work that needed judgement, ownership, or deeper technical investigation.
Because the bots were grounded in internal knowledge, the documentation finally became operational infrastructure: one maintained source of truth serving employees, service desk engineers, and the support workflow itself.
Automation did not replace the support team — it gave them back the work that genuinely needed people, and handled the rest.
Next step
Have a similar problem?
Tell us what it looks like in your environment. You'll get a straight answer about whether Caellix is the right fit — and what we'd do first.