Your Support Team Isn’t Broken — It’s Drowning
Industry data shows 60–70% of support tickets aren’t actually problems. They’re knowledge base questions, incomplete reports, false alarms, and duplicates. Your six-figure engineers are spending 2–3 hours a day on triage work that shouldn’t require their skills. Here’s the math.
By Shawn Ennis•June 1, 2026•5 min read
Twenty-five years in telecom operations has taught me something most support leaders learn the hard way: the day-to-day work that consumes your engineers’ time isn’t engineering. It’s triage. Reading tickets. Asking customers for missing logs. Pointing people at documentation that already exists. Determining which team should handle what.
And that triage work — the work nobody includes in a job description — is silently eating your support organization alive.
The breakdown that should scare you
I’ve spent a lot of time looking at ticket flows across operators of every size. The pattern is remarkably consistent. Roughly 60 to 70 percent of incoming tickets are not, in fact, problems that require human judgment. They break down like this:
- 40–50% — Questions answerable directly from your existing knowledge base. How to reset a password. Which SNMP fields the alert engine uses. What the default threshold is. Customers know the answers exist somewhere; they just can’t be bothered to find them.
- 15–20% — Incomplete reports missing the information needed to even start work. No logs. No reproduction steps. No system version. No affected node. Your engineer reads the ticket, then sends an email asking for the missing pieces.
- 5–10% — Duplicate tickets. Two customers from the same company report the same outage in the same hour. Three different engineers pick up each one, do partial work, and nobody connects the dots.
- 3–5% — False alarms. Customer reports an outage. Your monitoring shows green. Your on-call gets paged anyway, loses sleep, and confirms there was nothing wrong.
That leaves 15–25% of incoming tickets that are what humans are supposed to handle: real bugs, real engineering challenges, real customer escalations that require judgment.
Read that again. In a typical telecom support organization, less than a quarter of incoming tickets actually need the engineer’s skills. The rest are triage tax.
What this costs you
A fully loaded support engineer in the telecom sector — salary, benefits, tools, overhead — runs $150,000 to $200,000 a year. That’s roughly $75 to $100 per hour.
The average support engineer I’ve measured spends 2 to 3 hours per working day on pure triage activities. Reading new tickets. Categorizing them. Asking for missing information. Looking up answers in documentation. Routing to the right team.
That’s not 2-3 hours of high-leverage engineering work. That’s 2-3 hours of administrative work being done by people you hired because they could solve hard problems.
$5MWasted per year (50-person org)
10FTEs spent on triage
2–3hPer engineer per day
In a 50-person support organization, you’re effectively running 10 full-time engineers — five million dollars per year — on activities a well-designed automation could handle. And every new hire you add just absorbs more of the same.
The strategic cost is worse
The financial cost is bad. The strategic cost is worse.
Your best engineers — the ones who could be redesigning your network, optimizing your costs, building automation for the next decade — are stuck answering tickets. They’re not learning new skills. They’re not growing into architect roles. They’re not mentoring the next generation of operators.
They’re processing tickets.
And they know it. The high-performers will leave for companies where their skills get used. The ones who stay slowly disengage. Either way, you lose.
Why hiring won’t fix this
The instinct is always the same: hire more people. If we just had two more engineers, the queue would shrink. If we had a Tier 1.5 layer, the senior folks could focus.
This buys you about six months. Every engineer you hire spends 30% of their first year ramping up. Every new hire costs $150K loaded. And if you just hand them a pile of triage work, you’re not fixing the system — you’re feeding it.
The problem isn’t capacity. It’s that triage shouldn’t be a human job.
What changes when triage gets automated
Picture a different operating model: questions get answered before they become tickets. Bug reports come in complete because intake is automated. Duplicates get linked before two engineers work the same problem. False alarms get downgraded before the on-call gets paged.
Your engineers don’t disappear. They just stop doing administrative work and start doing engineering work. The high-performers stay because the job is finally what they signed up for.
That’s not a fantasy. That’s what AI-native Tier 1 automation looks like, and it’s deployed in production today.
In the rest of this series, I’ll walk through how it works, what it costs, and what the ROI actually looks like.
Get the full white paper
Frank’s deployment playbook, ROI math, and live use cases in 12 pages.
About the author Shawn Ennis is the Founder & CEO of Rapax and Citus Technologies. With 25+ years in telecom operations, Shawn previously founded Assure1 (acquired by Oracle in 2021), holds 12 patents in telecom OSS/BSS, and hosts the Transformation Leaders Podcast. Connect on LinkedIn.


Leave a Reply