Case study
.jpg)
Over the two years ending May 2026, the network capacity sustained by each Astreya engineer supporting this client grew 5.7x, and total capacity under the team's management grew more than 7x, against headcount growth of just 24%.
At the same time, monthly ticket volume climbed 164% — from roughly 7,500 to nearly 20,000 — and tickets handled per engineer more than doubled. Astreya's response, live in production as of July 2026:
Because growth in demand doesn't need to mean growth in support cost.
Astreya provides operational support across the client's global optical and IP network infrastructure. On a network this large, many faults trigger an alert, then clear on their own before an engineer can investigate. But a cleared alert still requires work. An engineer has to verify that the link is healthy, document what happened, assign the correct root cause, and close the ticket. These necessary steps take time, and too much time leads to backlogs.
But just closing tickets quickly isn’t enough. Teams also need to restore as much capacity to service as possible.
Astreya tracks restored network capacity per engineer: the amount of network capacity, measured in terabits per second (Tbps), that each engineer returns to service through incident resolution. Capacity data is recorded directly on tickets, covering more than 90% of capacity-affecting incidents.
Typically, the relationship between demand and headcount is almost 1:1. As demand increases, more engineers are brought on to support the added capacity. But between May 2024 and May 2026, demand spiked and headcount couldn’t keep pace. Monthly ticket volume nearly tripled, from approximately 7,500 to nearly 20,000, a 164% increase. Restored capacity per engineer grew 5.7x and total capacity supported by the team grew more than 7x, against headcount growth of just 24%.
The surge exposed two problems.
As ticket volume increased, engineers had less time to perform the repetitive checks required to confirm that self-resolving network events were truly clear, creating a backlog. As the backlog grew, high-value incidents became harder to distinguish from thousands of routine, transient events.
Every resolved ticket also requires a Root Cause Code. Over time, the client's taxonomy had become difficult to use at scale, with duplicate codes, unused codes, and too many choices for engineers working through high ticket volumes. When measured against client-adjudicated ground truth, manual root cause coding was only 50% accurate. That meant the problem wasn't simply how quickly tickets could be closed but also how to improve the underlying operational data.
The AI strategy: Automate the work that doesn't require human judgment
Instead of asking how many additional people were needed, Astreya asked which network tickets actually require an engineer. Many didn't. Tickets associated with self-resolving conditions still required verification and closure, but they didn't necessarily require human judgment. That distinction became the foundation of Astreya's AI automation strategy.
Astreya developed an AI agent to help automate network ticket resolution. The agent continuously checks link status and can close tickets associated with self-resolving issues without human intervention.
Automation is governed by predefined conditions rather than a simple elapsed-time rule. A ticket becomes eligible for automated closure only after it passes every required check. If a check fails — or if the AI cannot confidently complete the workflow — the ticket is routed to an engineer.
Astreya also determines automation scope empirically rather than assuming that an entire ticket category is safe to automate. The system analyzes ticket classes, attempts automation against defined criteria, and uses those results to determine where automation is appropriate. Straightforward workflows, such as status verification and certain configuration changes, are strong candidates. Tickets requiring expert diagnosis or complex fault isolation remain with engineers.
The AI agent can also execute changes from a pre-approved set. Authorization is established at the workflow level rather than requiring approval for every individual transaction. If a change cannot be completed successfully, the ticket returns to an engineer for review.
The goal isn't to remove engineers from network operations but to eliminate work that doesn't require an engineer in the first place.
Automating ticket handling solved only part of the problem. Astreya also needed to improve the quality of the operational data generated when those tickets were resolved. To do that, Astreya developed an AI recommendation engine for Root Cause Code assignment.
Against the same client-adjudicated ground truth used to evaluate human coding, the AI model achieved 95% accuracy, compared with 50% for manual coding.
As of July 2026, support engineers no longer assign Root Cause Codes manually. That improvement matters well beyond individual tickets because root cause data feeds:
A miscoded ticket doesn't stay isolated in a service management system. It can distort the decisions made from the data later.
At roughly 20,000 tickets per month, manually auditing every AI-generated decision would recreate the same scalability problem automation was designed to solve.
Instead, Astreya uses a sampling-based quality model. Approximately 5% of monthly tickets — roughly 1,000 tickets at current volumes — are selected for quality review. The objective is to identify errors and model drift without introducing another layer of manual work across the entire queue. Engineers can then spend more of their time on the work that genuinely requires expertise, like complex fault isolation, root cause investigation, and higher-value network engineering.
The first review cycle is scheduled for August 2026.
Two-year view (May 2024 – May 2026)
Ticket volume (May 2024 – May 2026)
AI capabilities live as of July 2026
The business impact: A scaling model where demand outgrows the team
The most important result is what happened to the relationship between demand and engineering capacity.
These changes create a different scaling model for network operations, one where demand can grow faster than the team supporting it, and where the value delivered is measured in network capacity returned to service.
Why the operating model matters as much as the AI
An AI team can automate a workflow, but without deep knowledge of the underlying operation, it can automate the wrong work, miss exceptions to the rules, or produce data that operators don't trust. Astreya built the automation with the people already operating the network and working the tickets. Their experience determined which workflows could be automated safely, what conditions needed to be checked, when a ticket should escalate, and what operational data could be trusted.
Astreya combined network operations expertise with enterprise AI to change the economics of the support model itself. The result is faster ticket closure and a network operations model in which productivity can scale faster than headcount.
Learn how Astreya's Enterprise AI services help organizations automate complex IT operations, improve service productivity, and scale without adding equivalent operational overhead.
Explore our Enterprise AI capabilities or contact an Astreya AI expert.