Say you sign a 60-seat client with about 90 endpoints. Your spreadsheet says each tech carries 300 endpoints, you have room for another 400, so no new hire. Six weeks later the board is behind, the senior tech is answering phones again, and nobody can point to the number that was wrong.
The number that was wrong was the ratio. There is no reliable industry IT staffing ratio for MSPs, and the figures that get passed around disagree with each other and rarely cite data. A ratio of endpoints or users per technician is useful as a result of your own workload math, not as the starting point for it. This post covers what the published ratios actually say, how to work out headcount from ticket volume and handle time instead, and where AI changes the math and where it doesn't.
What published IT staffing ratios actually say
If you search for an endpoints-per-technician benchmark, you'll find a few numbers repeated:
- 250 to 350 endpoints per technician. NinjaOne calls this "the industry average" in its guide to forecasting MSP hiring from device growth, without naming the source or year.
- 350 endpoints per technician. An Acronis post on MSP business model benchmarks calls 350 fully managed endpoints per tech "the gold standard," and adds that it varies with service complexity and the technology stack. No source is cited.
- One technician per 70 to 100 users. This rule of thumb still gets quoted in MSP circles, usually as a shortcut rather than a measured figure.
Formal benchmarks exist for internal IT departments. Avasant's Computer Economics research publishes help desk and IT staffing ratios with percentile ranges, but the numbers sit behind a paywall. Its IT staffing ratios bundle makes a point worth taking even without the data: ratios are more accurate when they are based on the number of IT users rather than total employees. An older Avasant help desk staffing summary found that ratios differed sharply by industry, with healthcare at one end and utilities at the other, and warned that a gap from the norm can only be judged with a deeper look.
So the honest answer to "what's a good IT staffing ratio?" is: a range that varies by client mix, and that nobody publishes with enough rigor to staff from. Treat any single number, including the ones above, as a sanity check.
Why endpoints per tech drifts
Endpoints don't create work. Tickets do, and the time each one takes. Two clients with 100 endpoints each can produce very different loads:
- A dental group on a line-of-business app with a vendor that pushes updates you have to babysit.
- A ten-year client on standardized hardware with a stable staff and few new hires.
- A client in a regulated industry where every access change needs a verification step and a written record.
- A client with high turnover, where onboarding and offboarding tickets show up every week.
Average those together and you get a company-wide ratio that is right for nobody. Add one heavy client and the ratio barely moves on paper while the board falls behind.
How to calculate MSP staffing from workload
Start from the work and let the ratio fall out of it. The core formula:
Technicians needed = (tickets per month × hours per ticket) ÷ productive ticket hours per technician per month
Each input needs care.
Tickets per month. Pull it from your PSA by client, not as one company total. Count after duplicates are merged. If the same outage produced eight tickets, it's one piece of work, and raw counts will overstate the load.
Hours per ticket. This is where most MSPs get it wrong, because the PSA only knows the time techs logged. Work that never became a time entry, like the five-minute phone fix or the callback that got folded into another ticket, doesn't show up in your averages. If your techs under-log time, your hours-per-ticket number is too low and your staffing model will say you're fine when you aren't. We covered where that time goes in MSP time tracking.
Productive ticket hours per tech. A full-time tech is paid for about 173 hours a month (40 hours × 52 weeks ÷ 12). Subtract PTO, holidays, team meetings, training, project work and internal admin. What's left is the time actually available for tickets. Use your own number from your own time entries, not a target from a slide.
A worked example with round numbers: say your clients generate 1,200 tickets a month after merging duplicates, the true average is 45 minutes per ticket, and each tech has 120 hours a month for ticket work.
1,200 × 0.75 = 900 hours of ticket work ÷ 120 = 7.5 technicians.
If those clients have 2,400 endpoints between them, your ratio is 320 endpoints per tech. That ratio is an output. Change the client mix or the minutes per ticket and it changes too, and the formula tells you why.
Break the ratio out by client and by tier
Once you have the formula, run it per client. Tickets per endpoint per month and hours per ticket, side by side, will show you which clients are cheap to support and which ones quietly eat a tech. That feeds two decisions besides headcount:
- Pricing. If a client costs twice the hours per endpoint of your average, a flat per-device price is losing money on them. See MSP pricing models and where MSP margin leaks.
- Tiering. A level 1 tech and a level 3 engineer don't carry the same load. Split the workload by the tier that actually closes the ticket, and you may find the shortage is one senior engineer, not two more help desk techs.
The handle time nobody measures
Hours per ticket isn't all troubleshooting. A large part of it is work around the fix:
- Reading the ticket history and asking the user for the details they left out.
- Writing the ticket note after the call.
- Entering the time, often from memory at the end of the day.
- Merging or closing duplicate tickets.
- Taking after-hours calls, then writing them up the next morning.
None of this shows up as its own line in a PSA report. It's buried in handle time, or it never gets logged at all. That matters for staffing because it's the part of the job that grows with ticket count no matter how good your techs are at fixing things.
How AI changes IT staffing ratios, and how it doesn't
AI doesn't replace a server, reseat a cable or talk a frustrated CFO through a new MFA prompt. What it can change is the overhead minutes in each ticket and the tickets that never needed a person to begin with. In a staffing model, that shows up as a lower hours-per-ticket number and a lower ticket count.
Here's where Vight fits, specifically:
- Call documentation. Vight pulls recorded support calls from the phone system, matches each to the client and ticket, writes the ticket note (issue, steps taken, resolution) and logs the time entry in ConnectWise, Autotask, HaloPSA or Syncro. The tech doesn't write the note or the time entry after the call.
- Ticket triage. On ConnectWise and HaloPSA, Vight triage matches a new ticket to a scenario you set up, emails the requester for the details they left out, and posts an internal note with what's known and what to confirm before a tech picks it up. See our post on ticket triage.
- Duplicate tickets. A deduplication agent merges duplicate tickets from the same client and leaves an internal note on the duplicate.
- After-hours calls. An AI voice agent can answer after-hours calls, ask follow-up questions and open a ticket with the details, and an escalation agent pages whoever is on call for urgent ones. That changes how you staff the on-call rotation, not just the day shift. Related: should MSPs charge for after-hours support.
- Seeing the real workload. On ConnectWise, Vight's Time Review shows each tech's time entries for a day next to their calls and work notes, and flags overlapping entries and ticket work with no time logged. That's the gap that makes hours per ticket look smaller than it is.
What we won't do is give you a percentage. How much an MSP's ratio moves depends on how much of its handle time is documentation and intake today, and that varies a lot by shop. The right way to find out is to measure hours per ticket and tickets per month before you change anything, then run the same formula again after a month or two. If the ratio moves, it's because minutes per ticket moved, and you can see which ones.
One caution: better documentation can make your workload look bigger before it looks smaller. When every call gets a time entry, hours that used to go unlogged start appearing in your reports. That isn't new work. It's work you were already staffing for without counting it.
When to hire: signals that beat a ratio
Your workload formula tells you where you should be. These tell you that you're already behind:
- Average age of open tickets climbing over several weeks.
- Response or resolution SLA misses concentrated on certain clients or tiers.
- Senior engineers regularly picking up level 1 work.
- After-hours load landing on the same two people.
- Time entries backdated in bulk at the end of the week.
Track them weekly alongside the numbers in MSP KPIs. When two or three move together, rerun the staffing math with current ticket counts before you post a job.
Frequently asked questions
What is a good IT staffing ratio for an MSP?
There is no reliable published standard. Vendor blogs cite 250 to 350 endpoints per technician, and an older rule of thumb says one tech per 70 to 100 users, but none of these come with data you can check. A better approach is to calculate the technicians you need from tickets per month, hours per ticket and productive hours per tech, then express the result as a ratio.
How many endpoints should one technician support?
As many as your ticket volume and handle time allow. If your clients produce 1,200 tickets a month at 45 minutes each and a tech has 120 hours a month for tickets, you need 7.5 techs. Divide your endpoints by that number to get your ratio. A client mix with more complex environments or more user churn will push it down.
Should I measure per user or per endpoint?
Measure both, per client. Users drive requests like password resets, onboarding and how-to questions. Endpoints drive patching, alerts and hardware failures. Avasant's research recommends basing ratios on IT users rather than total employees, which matches how service desk work actually arrives.
Does AI let an MSP support more endpoints per tech?
It can, if it reduces hours per ticket or ticket count. AI that writes ticket notes and time entries from calls, triages incomplete tickets, merges duplicates and handles after-hours intake cuts overhead minutes, not troubleshooting. Measure hours per ticket before and after to see how much your ratio actually moves.
See it on your own tickets
If you want to see how much of your techs' handle time goes to notes, time entries and intake, book a Vight demo and we'll walk through it on your PSA and phone system.