Key Takeaways
-
Support performance for regional ISPs is measured by how reliably issues are resolved and what that resolution costs, not by how fast calls are answered.
-
Diagnosing the problem can take longer than fixing it. Adding agents may help manage the queue, but reducing repeat work also requires better diagnostic information and workflows.
-
Across four regional ISPs in Preseem’s operator data, each support rep served roughly 1,200 to 1,700 subscribers, which is a narrow band. Across three operators, contacts per subscriber ranged from about 0.1 to 0.4 a month, which is a four-fold spread.
-
A speed test taken during the call cannot see last night’s problem; most intermittent complaints need historical measurement to diagnose.
-
Measure first-contact resolution alongside repeat contacts, or prematurely closed tickets will look like wins.
What Is ISP Support Performance?
ISP Support performance is how reliably your team resolves subscriber issues, and what that resolution costs. Both halves matter. A desk that answers quickly and resolves badly generates repeat contacts, escalations and dispatches that cost more than the original call ever did.
Two numbers deserve closer scrutiny. A short average handle time can look like efficiency even when an unresolved problem leads to another call. Low ticket volume can indicate a healthy network, but it can also hide subscribers who experience degraded service without reporting it. Read both measures alongside repeat contacts, resolution quality and subscriber feedback.Â
A more useful question than “how fast are we?” is: when a subscriber calls about a slow connection, how often does the team find out what is actually wrong, and how long does that take?
Which ISP Support Performance Metrics Should You Track?
Start with a small set that separates activity from outcome.
Metric |
What It Tells You |
Where It Misleads |
|---|---|---|
|
First-contact resolution |
Share of issues resolved during the first contact, without escalation or repeat contact on the same issue |
Rises artificially if tickets are closed before the problem is confirmed fixed |
|
Repeat-contact rate |
Subscribers coming back about the same underlying issue |
Needs a defined window, or a callback three weeks later counts as new |
|
Time to resolution |
Report to actual resolution |
Not time to ticket closure, which is a different and friendlier number |
|
Escalation rate |
Cases passed to Tier 2, engineering or network operations |
Volume alone says nothing; the question is how many were necessary |
|
Avoidable dispatch rate |
Field visits that could have been resolved remotely |
Hard to measure without resolution codes on closed dispatches |
|
Cost per resolved issue |
Support labour plus escalation and field cost, divided by issues actually resolved |
Can appear artificially low if closed tickets are counted as resolved issues; review alongside repeat contacts |
Track them by access technology and issue type where you can. A fiber zone and a fixed wireless footprint generate different tickets, and an average across both hides the pattern you need.
One warning from the field: pressure agents to shorten calls and repeat contacts go up, dispatches go up, and cost per resolved issue goes up with them. The metric improves and the operation gets worse.
What Preseem’s Operator Data Shows About Support Load
Two observations from Preseem’s regional operator analysis are worth putting beside your own numbers.
Across four regional ISPs, each support representative served roughly 1,200 to 1,700 subscribers. These ratios describe the operators in this small sample; they do not establish an optimal staffing level. Contact volume, issue complexity and team responsibilities are also needed to interpret the workload.
Across three regional operators, support contacts ran from about 0.1 to 0.4 per subscriber per month. That is a four-fold spread, and it is the more interesting of the two findings.
Put them together and the implication is awkward. If staffing ratios cluster but contact rates vary four to one, then two ISPs of similar size can face wildly different support demand with similar teams. At 10,000 subscribers, 0.1 contacts per subscriber per month is roughly 1,000 contacts; 0.4 is roughly 4,000. That is an illustration of the observed range, not a forecast for your network.
What drives the spread is not settled by this data. Network conditions, technology mix, how contacts are logged, and how often a first call actually resolves the problem could each contribute. Repeat contacts are the one worth checking first, because they are the component you can influence without touching the network.
These are observations from small operator samples, not industry benchmarks. Four operators for the staffing ratio and three for the contact rate; whether the samples overlap is not recorded. Measure your own before drawing conclusions.
Why Troubleshooting Is Harder at a Regional ISP Than It Looks
A subscriber calls and says video keeps freezing, mostly in the evening, starting about a week ago. None of that is diagnostic yet.
So the agent goes looking: billing for the account and plan, one vendor portal for the radio or the ONT, another for the OLT or the access point, a graphing tool for the sector, and a ping test that comes back clean because at ten in the morning everything is clean. Ten or fifteen minutes later they still cannot separate congestion on a shared sector from a degrading link from a five-year-old router in a cabinet behind the television.
The difficulty is structural rather than a matter of effort or skill. Regional operators run several vendors across several access technologies, often with equipment inherited through acquisition, and the evidence needed to answer the subscriber’s question sits in different systems, none of which holds the one thing that would settle it: what that connection has been doing over the past week.
That is also why a new agent takes months to become useful. They are not learning to troubleshoot; they are learning eight interfaces and which one to believe.
How to Troubleshoot a Slow or Unreliable Connection
A repeatable sequence helps newer agents handle common issues consistently. The specific tests depend on your network, but the order holds.
1. Confirm the symptom precisely.
Low throughput, buffering, high latency, intermittent drops or a hard outage are different problems. When did it start, is it one device or the whole home, and does it happen at a particular time of day?
2. Check service and equipment context.
Plan, CPE status, recent changes at the premises, known outages, previous tickets on the account.
3. Look at experience over time, not just now.
For intermittent complaints, compare the reported timing with available historical latency, packet loss and throughput measurements. A test during the call may not reproduce last night’s problem.
4. Compare against shared infrastructure.
If several subscribers on the same access point or PON degrade at the same hours, the shared path is the suspect. If only this subscriber is affected, look at their connection and the home. These are clues rather than proof.
5. Act on the evidence.
Explain what you found, record the tests, and escalate or dispatch only when the evidence supports it.
Step three is where most of the value sits. A speed test is a snapshot taken under close-to-ideal conditions, with one device, usually while someone watches. Bufferbloat, intermittent packet loss, evening congestion and Wi-Fi interference each need a different measurement, and none of them reliably shows up in a test run at a moment when the problem is not happening.
How Do You Tell a Wi-Fi Problem From a Network Problem?
Distinguishing an in-home issue from an access-network issue is an important diagnostic step. Getting it wrong can lead to an unnecessary dispatch or delay the right repair.
Wi-Fi and in-home issues tend to affect some devices and not others, vary with distance from the router, worsen in a particular room, and persist regardless of time of day. Interference, router placement, an ageing CPE or an overloaded home network are common causes.
Access network issues tend to affect the whole home at once, follow a daily pattern tied to busy hours, and show up on neighbouring subscribers sharing the same sector or PON.
Four terms are worth a shared definition, because subscribers describe all of them as “slow internet”:
-
- Latency is the delay a packet experiences. High latency makes video calls and games feel broken while a speed test still reports a healthy number.
- Packet loss is data that never arrives. Small amounts wreck real-time applications and barely affect a download.
- Congestion is contention for shared capacity, which is why it clusters in the evening.
- Bufferbloat is excess delay when buffers fill under load. It is the connection that tests fast but feels unresponsive whenever anyone else in the house is uploading.
The practical rule is that throughput measures capacity and tells you very little about whether the connection feels good to use. Preseem has covered bufferbloat and why speed tests don’t predict subscriber experience in more depth.
How to Improve First-Contact Resolution
First-contact resolution rises when uncertainty is removed from the first interaction. Three things do most of the work.
Give the agent the subscriber’s recent experience before the conversation starts, so the call begins with evidence rather than a search. Give them a structured diagnostic path for the five or six issue types that make up most of the queue. And define when escalation is genuinely warranted, so it is a decision rather than a way of ending an uncomfortable call.
Then review a sample of repeat tickets every week. For each one, ask what the first agent lacked and what would have changed the outcome. That review is worth more than most training, because it tells you which information gap is actually costing you.
Measure first-contact resolution next to repeat contacts and customer satisfaction. On its own it rewards closing tickets, which is the opposite of what you want.
How to Reduce Escalations and Unnecessary Truck Rolls
Escalation is right when a problem genuinely needs another team’s expertise. It is waste when Tier 2 repeats checks Tier 1 could have done with better visibility, and the cost lands on the people you would rather have building the network.
One operator in Preseem’s analysis assessed roughly 40% of its escalations as avoidable and about 60% of interruptions reaching engineering as not requiring engineering involvement. These figures reflect that operator’s assessment and should not be treated as industry benchmarks. For your own operation, review which cases required specialist input and which could have been resolved with better frontline information.
The practical fix is a standard evidence package that travels with every escalation: symptom, time of occurrence, affected devices, recent subscriber experience, what the shared infrastructure looked like, and what has already been checked. It prevents the repeat work and it makes the avoidable escalations visible.
Dispatch deserves the same threshold. Before a technician is sent, someone should be able to say what can be verified remotely, whether the evidence points inside the home or at the access network, and what the visit is expected to fix. Not every truck roll is avoidable, and no metric is worth delaying a repair the subscriber actually needs. The target is the dispatch sent because nobody could tell, not the dispatch sent because something is broken.Â
In Preseem’s operator analysis, a fixed wireless operator with about 16,000 subscribers assessed 20% of its truck rolls as unnecessary, while a fiber operator with about 30,000 subscribers assessed 50% that way. These are operator-specific assessments. Differences in diagnostic visibility, network conditions and assessment methods may contribute to the gap; the figures alone do not establish the cause.
How to Get New Tier 1 Agents Productive Faster
Time to independent call handling is a useful support performance metric. Track it alongside resolution quality, repeat contacts and escalation rates.
The reason it runs long is the one described above: a new agent has to learn every vendor interface before they can be trusted alone on a technical call. Herotel, a large fixed wireless and fiber operator, needed two months of training before a new support rep could handle calls independently. After consolidating its visibility into one view, that dropped to three or four weeks. Netta Roetz from the support team described the effect on individual calls plainly: “We can escalate or close a ticket within five to 10 minutes.”
Mascon, a multi-vendor operator of roughly 20,000 subscribers, reported halving both support call times and training time. Both are customer-specific results rather than a promise of the same outcome elsewhere.
What generalizes is not the number but the mechanism: ramp time tracks the number of systems an agent must learn before they can answer a question. Reduce the systems and the ramp follows.
Two things help regardless of tooling. Turn your recurring issue types into documented diagnostic workflows with examples of what healthy and degraded measurements look like. And coach on real anonymized cases, reviewing why an issue was escalated rather than whether a script was followed.
Where Subscriber Visibility and AI Fit in Support Performance for Regional ISPs
Most of what is above comes down to one thing: whether the person on the call can see what that subscriber’s connection has actually been doing, and how it compares to the people around them.
That is Preseem’s job. It takes network, CPE and billing data and reconciles it into a continuous per-subscriber measure of experience across fiber and fixed wireless, so the agent opens one view instead of five, and the week of freezing video is visible as a week of freezing video.
AI sits on top of that, and only works as well as what it sits on. An assistant that can read a subscriber’s history and the state of their sector can suggest where the fault probably is. A chatbot with access to neither can collect symptoms and route a conversation, which is an improvement on hold music and is not diagnosis. When evaluating anything described as AI support, the question to ask the vendor is what data the model can actually see. The answer tells you whether you are buying a diagnosis or a better front door.
Your team remains responsible for the diagnosis, the next action and the subscriber conversation. Effective support requires both technical judgment and clear, empathetic communication. Tools should help agents bring those skills together.
How to Measure Whether Your ISP Support Performance Improved
Pick a baseline period and record the metrics closest to the workflow you are changing. If the change is Tier 1 diagnosis, that means repeat contacts, escalation rate, time to resolution and avoidable dispatches. Segment by issue type and access technology so a shift in ticket mix does not read as an improvement.
Record process changes alongside the numbers. A drop in support calls might be better diagnosis, or a mild autumn, or a change in how contacts are logged. Case reviews beside the metrics give you a defensible answer about what actually changed.
See What Your Support Team Would See
Book a walkthrough to see how Preseem brings subscriber experience and network context into the support workflow and improve ISP support performance.
Frequently Asked Questions
What is the most important ISP support metric?
There isn’t one. First-contact resolution, repeat contacts, time to resolution, escalation rate and cost per resolved issue have to be read together, because each can be improved at another’s expense. The most common failure is optimising handle time and paying for it in repeat contacts.
How many subscribers should one support rep handle?
Across four regional ISPs in Preseem’s operator data the ratio ran between roughly 1,200 and 1,700 subscribers per representative. That is a small sample and not a target. The more useful figure is your own contact rate per subscriber, which varied four-fold across three operators in the same data and determines how much work that ratio actually represents.
How can Tier 1 tell a Wi-Fi problem from a network problem?
Start with which devices are affected and when. In-home issues usually hit some devices and not others and vary with location in the house; access network issues usually affect everything at once, follow busy-hour patterns, and appear on neighbouring subscribers sharing the same sector or PON. Historical data settles it faster than any test run during the call.
Why don’t speed tests explain most subscriber complaints?
A speed test measures throughput at one moment under favourable conditions. Intermittent packet loss, latency under load, evening congestion and bufferbloat can all ruin the experience while throughput still tests fine, and none of them is likely to be happening at the moment the agent runs the test.
How do you reduce unnecessary truck rolls?
Set an evidence threshold for dispatch: what was verified remotely, whether the problem appears to be in the home or on the access network, and what the visit is expected to fix. Then add resolution codes to closed dispatches so you can see afterwards how many were avoidable. Most operators cannot answer that question today.
How long should it take to train a new Tier 1 agent?
Training time depends on the agent’s experience, issue complexity, coaching and the systems they must learn. To identify delays, review how long new hires spend finding information across interfaces and interpreting it. Consolidated visibility and documented workflows can help; measure the effect against your own baseline.
Can AI replace ISP support representatives?
Not on current evidence, and the framing misses where the gain is. AI is good at retrieving context and suggesting where a fault probably sits, which is the part of the job that takes the longest. Explaining the problem to an irritated subscriber and deciding what to do about it is a different skill, and it stays with people.
How do I know whether a support change actually worked?
Baseline before you change anything, then compare repeat contacts, escalation rate, time to resolution and avoidable dispatches over a period long enough to cover seasonal variation. Segment by issue type and access technology, and record what else changed at the same time, or you will attribute a mild autumn to your new workflow.




