MSP capacity planning: Forecast hiring needs

Why MSP capacity planning usually breaks down

Most MSPs know when the service desk feels overloaded. Phones are stacked up, dispatch is moving tickets by hand, senior techs are interrupted constantly, and the owner hears about missed expectations before seeing the numbers.

The harder question is whether the fix is to hire, rebalance work, change client commitments, reduce noise, or automate the front of the desk. That is where MSP capacity planning becomes more useful than a simple technician-to-client ratio.

A good capacity model connects three things:

• Ticket demand: how much work arrives and what type it is
• SLA load: how much of that work is time-sensitive
• Technician availability: how many usable hours you actually have

When those numbers are visible together, hiring decisions become less reactive. You can see whether the team is short by 10 hours a week, one full-time role, or only during Monday morning intake spikes.

Start with ticket demand, not ticket count

Ticket count is the easiest number to pull, but it is also one of the easiest to misread. Fifty password resets are not the same as fifty network outage tickets. A backup alert storm may create volume without requiring the same effort as escalated application issues.

For capacity planning, group tickets by expected effort and handling pattern. You do not need perfection. You need categories that are consistent enough to forecast.

Useful demand categories include:

• Quick resolution tickets under 15 minutes
• Standard help desk tickets between 15 and 60 minutes
• Escalation tickets requiring Tier 2 or Tier 3 attention
• Onsite or field work
• Monitoring alerts and recurring noise
• Project spillover that lands on service technicians
• Client administration work, such as user changes and license requests

For each category, calculate average monthly volume and average handling time. If your PSA data is messy, start with the last 90 days and have dispatch or service leadership normalize obvious outliers.

The goal is not to build an academic model. The goal is to answer: if demand continues at this pace, how many technician hours will it require next month?

A simple formula works:

Estimated demand hours = ticket volume by category × average handling time by category

Then add a buffer for rework, follow-up, internal handoffs, and client communication. Many MSPs underestimate this by 15 to 25 percent because the time is scattered across notes, calls, Teams messages, and dispatcher interruptions.

Tools that classify and summarize tickets more consistently can make this demand picture cleaner. For example, autonomous tickets can reduce the manual work of classification, routing, and summary writing while giving managers more reliable categories to measure.

Convert SLA commitments into capacity load

A ticket that can be handled this week and a ticket that must be touched in 15 minutes place very different demands on the desk. MSP capacity planning has to account for urgency, not just volume.

SLA load measures the amount of work that must be handled within a specific time window. This is where many MSPs find the real reason they feel understaffed. They may have enough total hours for the week, but not enough available capacity during the windows when urgent work arrives.

Track SLA load by priority and time of day:

• How many P1 and P2 tickets arrive by weekday and hour?
• What percentage require immediate response versus same-day response?
• Which clients have tighter response commitments?
• How often do SLA risks occur because no qualified tech is available?
• How much time does dispatch spend reshuffling work to protect SLAs?

A common mistake is averaging SLA demand across the entire week. If most urgent tickets arrive between 8:00 and 11:00 a.m., weekly averages hide the coverage gap. You may not need another full-time technician. You may need different shifts, a dedicated triage role, or better intake automation during peak windows.

Phone demand matters here as well. Calls often create the highest interruption cost because someone has to answer, capture details, determine urgency, and either resolve or route the issue. AI phone intake can help convert calls into structured tickets, which makes call-driven demand easier to measure instead of treating it as background noise.

Measure true technician availability

Technician availability is not the same as payroll hours. A 40-hour technician does not produce 40 hours of ticket capacity.

Subtract the time that is real but unavailable for ticket work:

• PTO, holidays, and sick time
• Training and certification work
• Internal meetings and vendor calls
• Documentation updates
• Escalation support for junior techs
• Project assignments
• Onsite travel
• Administrative cleanup
• Context switching and dispatcher interruptions

Many MSPs find that a service desk technician has 26 to 32 usable ticket hours per week, depending on role and maturity. Senior technicians may have fewer direct ticket hours because they carry escalation, mentoring, architecture, and client relationship work.

For planning purposes, create different capacity assumptions by role:

• Tier 1 technician: higher direct ticket capacity, lower escalation capacity
• Tier 2 technician: balanced resolution and escalation work
• Tier 3 technician: lower ticket volume, higher complexity load
• Dispatcher or coordinator: protects technician time but may become a bottleneck
• Field technician: capacity constrained by travel and scheduling windows

This prevents the classic hiring mistake: adding a junior tech when the real gap is senior escalation capacity, or hiring a senior tech when the desk mostly needs intake and routing relief.

A dispatch view should show this in real time, not only in a spreadsheet. Corei's dispatch tooling is designed around scheduling, capacity, and reassignment help so service leaders can see where work is actually stacking up.

Build a practical hiring forecast

Once you have demand hours, SLA load, and available hours, you can build a simple forecast.

Start with the next 90 days. Longer forecasts are useful for budgeting, but 90 days is usually enough to make hiring decisions before the desk is in trouble.

Use this structure:

1. Calculate current monthly demand hours by ticket category.
2. Add known changes, such as new clients, device growth, project handoff, or contract changes.
3. Estimate demand growth based on the last three to six months.
4. Separate urgent SLA-driven work from flexible work.
5. Calculate available technician hours by role.
6. Compare demand to capacity by skill level, not just total hours.
7. Identify the recurring gap.

The recurring gap is what matters. One bad week may not justify hiring. A sustained 80-hour monthly shortfall in Tier 1 work probably does. A 25-hour monthly shortfall in Tier 3 escalation work might also justify a hire if it is blocking the entire desk.

A useful threshold is to consider action when any role is forecasted above 85 percent utilization for more than four consecutive weeks. Above that level, there is little room for sickness, outages, onboarding, or unexpected client demand. Quality drops before the spreadsheet says you are fully out of hours.

Separate hiring needs from process problems

Not every capacity problem should become a job posting. Before hiring, ask what kind of work is consuming the gap.

If the gap is intake work, you may need better call handling, chat intake, forms, or classification. If the gap is routing work, dispatch may need clearer rules or automation. If the gap is repeated client noise, account management may need to address environment health or contract scope. If the gap is alert volume, monitoring rules may need cleanup.

Look for these patterns before adding headcount:

• High volume of tickets with incomplete intake details
• Repeated reassignment between tiers
• Large numbers of stale tickets waiting for client response
• Monitoring alerts that rarely require action
• Senior techs spending time on low-complexity work
• Dispatch manually reading every ticket to decide next steps
• Clients generating outsized demand relative to agreement value

This is where dashboards and reporting matter. A service manager should be able to see the question behind the number: which clients, categories, priorities, and technicians are driving the capacity issue? Corei's operational dashboards and reports are built to make that analysis easier for service leaders.

Account for automation in the forecast

Automation does not remove the need for capacity planning. It changes the assumptions.

If AI can capture intake, classify tickets, summarize history, suggest routing, prepare client updates, or reduce dispatcher touches, those savings should be reflected in your model. The key is to be conservative. Do not assume every automated workflow removes the full ticket effort. Often, it reduces the first five to ten minutes of handling, cuts interruptions, or prevents rework.

Those small changes compound. If your MSP receives 2,000 tickets per month and automation saves six minutes per ticket across intake, routing, and notes, that is 200 hours of capacity recovered. That may delay a hire, change the role you need, or allow senior technicians to focus on higher-value work.

The same logic applies to client-facing support chat, monitoring triage, and agentic workflows. The planning question is not, "Will AI replace a technician?" The better question is, "Which parts of our ticket lifecycle can be removed, shortened, or made more consistent?"

If you are not ready to replace your PSA, you can still test these assumptions. Many MSPs prefer to run Corei alongside their current system through a pilot so they can compare capacity impact before making a broader operational change.

A simple capacity planning example

Assume an MSP has four service technicians with the following usable weekly ticket capacity:

• Tier 1 technician: 30 hours
• Tier 1 technician: 30 hours
• Tier 2 technician: 28 hours
• Tier 3 technician: 20 hours

That is 108 usable ticket hours per week.

The last 90 days show average weekly demand of:

• Quick tickets: 25 hours
• Standard help desk: 45 hours
• Escalations: 28 hours
• Monitoring and recurring alerts: 12 hours
• Client admin work: 10 hours

Total demand is 120 hours per week. On paper, the MSP is short 12 hours. But the role-level view is more important. If most of the shortage is escalation work, adding another Tier 1 technician will not solve the bottleneck. If the shortage is quick tickets and intake, a junior hire or automation may help.

Now add SLA load. If 60 percent of urgent tickets arrive before noon and the Tier 2 technician is frequently pulled into calls, the desk may need a morning triage block, dispatcher support, or intake automation more than a full new headcount.

This is the value of MSP capacity planning: it turns "we are drowning" into a specific operational choice.

Practical takeaway

Build your capacity model in four layers.

First, measure ticket demand by category and average effort, not only by ticket count. Second, overlay SLA urgency by priority and time window. Third, calculate real technician availability by role after meetings, PTO, projects, escalation support, and admin work. Fourth, compare the recurring gap against process improvements, automation opportunities, and hiring options.

If the shortage is sustained, role-specific, and tied to client commitments, hire before burnout sets in. If the shortage is driven by intake quality, routing, alert noise, or repeated manual steps, fix the operating model before adding payroll.

The best hiring forecast is not a guess about how busy the desk feels. It is a living view of demand, SLA pressure, and available capacity that service leaders can trust each week.