MSP Staffing Ratios: A Tier 1–3 Sizing Guide For Your MSP

Key takeaways

• There's no universal MSP staffing ratio. The number of engineers you need depends on ticket volume by tier, endpoints per client, and your SLA commitments, not client count alone. Your own ticket data is the most reliable starting point.
• Size each tier separately. Tier 0–1 work is high-volume and repeatable. Tier 2–3 work has fewer tickets but takes far more engineering time per ticket.
• Your staffing number has a shelf life. New clients, endpoint growth, and tighter SLAs will all change the math at some point. Recalculate how many technicians you need on a regular cadence, such as quarterly.

Many MSPs estimate headcount by feel, and that can get expensive really quick. Understaffed teams miss SLAs. Overstaffed teams drive up labor costs through idle hours.

So the question of how many technicians per client your MSP should carry doesn't have a single right answer, but it does have a reliable method for finding the ratio that works for you.

How many Tier 1–3 engineers does your MSP actually need?

To estimate how many technicians or engineers you need, measure ticket volume by tier, divide it by the number of tickets each engineer actually resolves per month at that tier, then add headroom for SLA commitments, peak demand, and absences.

That calculation rests on three inputs:

1. Client count and endpoints: how much you support
2. Ticket volume by tier: how much work that generates, and how complex it is
3. SLA and response-time commitments: how fast that work has to be picked up

Two MSPs can each manage 50 clients and need very different teams. One might support standardized Microsoft 365 environments with strong automation, a mature knowledge base, and low ticket volume. The other might manage fewer endpoints but deal with complex networks, legacy systems, frequent software issues, and aggressive SLAs.

Why does tier mix matter more than client count?

Client count tells you how many customers you're supporting. Tier mix tells you how much engineering capacity those customers consume.

A helpdesk handling hundreds of password resets and routine requests can need fewer engineering hours than a smaller desk handling complex escalations, infrastructure problems, and security incidents. That's because tickets aren't equal units of labor. A password reset might take minutes, a server issue can take an hour, and a security incident may need multiple engineers, plus investigation, documentation, and follow-up.

Say you receive 800 Tier 1 tickets and 80 Tier 3 tickets in a month:

	Tier 1	Tier 3
Monthly tickets	800	80
Average handling time	10 minutes	90 minutes
Technician hours	~133	~120

It would be a mistake to conclude Tier 3 needs one-tenth of the staffing because it gets one-tenth of the tickets. The ticket counts are 10x apart, but the technician time is almost the same. That's why a tiered support model should be sized by workload within each tier, not by client count or total ticket volume.

Here's a practical way to think about each tier in a tiered model:

Tier	Typical ticket types	Relative staffing intensity
Tier 0	Self-service, password resets, basic how-to questions	Low (the goal is to keep as much work as possible out of the technician queue)
Tier 1	Common software issues, connectivity problems, routing and triage	Low to medium (typically the highest ticket volume)
Tier 2	Complex troubleshooting, escalations, server and cloud administration	Medium to high (fewer tickets but more technician time per ticket)
Tier 3	Advanced technical issues, architecture, security incidents	High (fewest tickets, but the most specialized engineering capacity per ticket)

Where does Tier 0 fit in your staffing math?

Tier 0 is your self-service layer: the knowledge base, RMM scripted fixes, and chatbots that resolve routine requests before they reach a technician. It doesn't need engineers of its own, but its quality affects how many you need everywhere else.

Every request Tier 0 resolves is a ticket your Tier 1 team never has to touch. When self-service is weak, that work flows straight into the Tier 1 queue, and headcount grows with client count.

Building and maintaining Tier 0 is a challenge in its own right. Someone has to write and update knowledge base articles, keep automation scripts working as client environments change, and review which requests still slip through. So treat Tier 0 as a lever, not a headcount line: a stronger self-service layer lowers the Tier 1 volume you're staffing for.

For how to set it up, and how an outsourced helpdesk handles the Tier 1 work that still needs a human, see what Tier 0 IT support is and why every MSP needs it before they scale.

For how the human tiers fit together, see how dedicated Tier 1–3 engineers work for MSPs.

Tip: Don't blend Tier 0, Tier 1, Tier 2, and Tier 3 into one tickets-per-technician ratio. A blended number hides the differences in handling time, complexity, escalation paths, and SLA coverage between tiers. It can make Tier 1 look busier than it is and Tier 3 look less demanding than it is.

How do you calculate your MSP staffing ratio, step by step?

So, how many technicians or engineers do you really need? For the calculation to be accurate, start with your own ticket data. The result won't be perfect, but it will reflect how your MSP actually operates instead of a generic industry ratio.

Step 1: Pull 60–90 days of ticket data

For each ticket, capture the following data:

• Support tier
• Ticket type
• Resolution or handling time, if available
• Priority
• SLA target
• Whether it was escalated
• Whether it was reopened

Then group tickets by tier so you can see what your Tier 1, Tier 2, and Tier 3 engineers are actually handling.

Step 2: Calculate your actual throughput by tier

Measure how many tickets your current engineers resolve in a regular month. If three Tier 1 engineers resolve 900 tickets in a month, your observed Tier 1 throughput is:

900 ÷ 3 = 300 tickets per engineer per month

Do the same for Tier 2 and Tier 3. Your own throughput reflects your environment, tools, processes, client expectations, and ticket complexity in a way no outside number can.

Expert tip: Want to compare your throughput against outside data? MetricNet's desktop support benchmarks put it at 30 to 198 tickets per technician per month. That range is too wide to plan headcount from, and it reflects in-house desktop support, not a remote MSP helpdesk. Use it as a sanity check, not a target.

Step 3: Project your future ticket volume

Your staffing number should account for where your MSP is going. Start with your current tickets per client:

• 1,000 monthly tickets ÷ 50 clients = 20 tickets per client per month
• If your growth plan takes you to 60 clients: 60 × 20 = 1,200 projected tickets per month

Then split that projection by your current tier mix.

For example, if 75% of your tickets are Tier 1, 20% are Tier 2, and 5% are Tier 3, your 1,200 projected tickets become 900 Tier 1, 240 Tier 2, and 60 Tier 3 tickets.

If your client sizes vary a lot, project from tickets per endpoint instead. It's more precise than tickets per client.

Step 4: Divide projected volume by observed throughput

Calculate headcount separately for each tier:

Tier	Projected monthly tickets	Tickets per engineer per month	Baseline engineers
Tier 1	900	300	3
Tier 2	240	120	2
Tier 3	60	60	1

Throughput figures are illustrative. Use your own numbers from Step 2.

That gives you a baseline headcount estimate.

You can turn the same math into an endpoints per technician ratio. If your clients generate 0.5 tickets per endpoint per month and a Tier 1 engineer resolves 300 tickets a month, one Tier 1 engineer covers roughly 600 endpoints (300 ÷ 0.5). That's a useful planning number, but only because it comes from your own data.

Step 5: Add headroom for coverage and SLA commitments

You also need enough capacity to meet your SLA when demand arrives in bursts. Treat your calculated headcount as the baseline, then add a buffer based on your operating model.

The right buffer depends on your SLA targets, operating hours, how much demand varies, absence coverage, and how much non-ticket work your engineers do, like documentation, projects, and knowledge base updates.

Not sure your current team has enough headroom? LTVplus provides dedicated managed support teams that work inside your existing PSA, RMM, and documentation, so you can add capacity at the tier that needs it. Book a free consultation.

How do SLA commitments change your staffing math?

SLA commitments change staffing because they determine how much capacity must be available when a ticket arrives, not just over the course of a day.

• A four-hour response target gives your team room to absorb demand throughout the day.
• A 15-minute response target leaves very little room for a queue to build.

Don't size only against your daily average. An average can hide the hours when your SLA is most likely to break. But don't size your whole team around the single busiest hour you've ever recorded, either. One unusual spike can mislead you in the other direction.

Look for a recurring pattern instead. If your 10 busiest comparable hours over the last several weeks consistently run well above average, that's a better staffing signal than one exceptional Monday morning.

If you're committing to round-the-clock response, the math changes again. See how to offer your MSP clients a 24/7 SLA without staffing it yourself.

What does this look like in a real dedicated-team model?

Once you've calculated your headcount, you can map it to a practical team structure. Your workload determines the headcount. Team size determines the support structure around it. Here's an example from LTVplus:

	Start (1–2)	Grow (3–9)	Scale (10+)
Dedicated full-time staff	✓	✓	✓
Buffer agent	—	Shared	Dedicated
Customer success manager	Shared	Shared	Senior CSMs
QA oversight	Shared	Shared	Dedicated
Team lead/coach	Shared	Shared	Dedicated
Workforce management	Shared	Shared	Dedicated
Training and development	Shared	Shared	Dedicated
PTO/sick-day coverage	Best effort	✓	✓

Source: LTVplus pricing

Teams rarely stay in one band. The practical approach is to staff for the capacity you need now, monitor the workload, and grow before service quality slips. Here's how that looked for one MSP we served:

"We started with two helpdesk engineers. Eighteen months later, we have nine. LTVplus runs our entire Tier 1 and Tier 2 — and our clients have no idea they're not in-house." — MSP Operations Director, 50-person MSP, Midwest US

That's a move from the Start band to the upper end of Grow, without the MSP rebuilding its support structure along the way. LTVplus's eCommerce clients show the same pattern: DIVBrands grew from two live chat agents to 11 as it added brands, and Pink Lily doubled its team from four to eight within two months after a 60% jump in ticket volume.

What are the signs you're understaffed at a specific tier?

Even after you've done the math, check whether the calculation holds once the team is running. Watch for these signs:

• Tier 3 engineers are doing Tier 1 work. You're using your most expensive technical capacity to cover a lower-tier capacity gap, and it shows up on your bottom line.
• SLA misses cluster around one tier. You may have enough total staff but not enough capacity where those tickets need attention.
• Backlog grows at one tier. A steady backlog at a single tier is a capacity signal, not a one-off.
• Escalations rise without faster resolution. If complaints keep mentioning slow responses to escalated issues or long waits for one type of request, investigate that tier.

Often, these problems surface internally before clients notice slower response times. That's your window to fix them. If you'd like to free up capacity before adding headcount, see 7 practical ways to handle more tickets with the same MSP team.

How often should you recalculate your MSP staffing ratio?

There's no permanent "correct" number of Tier 1–3 engineers. Start with your ticket data, break it down by tier, factor in your SLA commitments, and revisit the model on a regular schedule, such as quarterly. That way you adjust before a temporary workload problem becomes a service quality problem, and your staffing holds up over the long term.

Recalculate sooner after any of these:

• A major client win
• Significant endpoint growth
• A new SLA
• A sustained change in ticket volume

If the math says you need engineering capacity you can't hire fast enough, you don't have to build it all internally. LTVplus is the managed technical support partner MSPs trust to handle their most important clients. It provides dedicated technical teams, including helpdesk and Tier 2 support, NOC, security, and escalation roles. Teams work inside your existing PSA, RMM, and documentation systems, while LTVplus handles recruiting, management, onboarding, and ongoing oversight. Your managed service stays yours, and your clients stay your clients.

Explore LTVplus's managed technical support for MSPs or book a free consultation to size a team that fits your actual workload.

Frequently asked questions

What is a good MSP staffing ratio?

There's no universal technician-to-client ratio for MSPs, because staffing depends on ticket volume, support tier, endpoints, ticket complexity, and SLA commitments. A good ratio is one based on your actual workload. Calculate ticket volume and engineer throughput separately for Tier 1, Tier 2, and Tier 3, then add enough capacity for SLA requirements, absences, and demand spikes.

How do SLAs affect MSP staffing requirements?

SLAs determine how much capacity needs to be available when tickets arrive, not just how much work the team can complete over a day. Tighter response targets leave less room for queues to build, so staffing calculations should account for recurring demand patterns and peak periods, not just daily averages.

How many endpoints can one MSP technician support?

It depends on how many tickets your endpoints generate and how many tickets a technician resolves per month. Divide a technician's monthly throughput by your tickets per endpoint per month. For example, at 300 tickets per engineer and 0.5 tickets per endpoint, one engineer covers about 600 endpoints. Build the ratio from your own data, since environment complexity changes it significantly.

How often should an MSP recalculate its staffing needs?

Review your staffing model regularly, such as quarterly. Recalculate sooner after a major client win, significant endpoint growth, a new SLA, or a sustained change in ticket volume. Don't wait for persistent SLA misses or client complaints, since by then the gap has usually already affected service quality.

Can MSPs outsource dedicated technical support instead of hiring internally?

Yes. A dedicated support model can add capacity at the tier where an MSP needs it, while the team keeps working within the MSP's existing PSA, RMM, and documentation systems. LTVplus provides dedicated technical teams for MSPs and handles recruiting, management, onboarding, and ongoing oversight.