Is your MSP understaffed, or is your service desk just inefficient?

For many Managed Service Providers (MSPs), the decision to hire another engineer is driven more by frustration than financial analysis. The service desk is overwhelmed, ticket backlogs are growing, customers are complaining about response times and engineers are struggling to keep up.

The obvious solution seems to be to recruit another engineer. But is hiring more people really the answer?

An MSP supporting 2,000 users might need six service desk engineers, while another supporting the same number of users could require ten or more. The difference is not necessarily customer expectations or technical complexity. It may come down to how efficiently the MSP operates, how standardised its customer environments are, the technical capability of its engineers and how much repetitive support has been automated.

For MSPs on fixed-fee managed services agreements, these differences matter financially. Every additional engineer increases the direct cost of delivering services, potentially reducing gross margin unless the new resource creates capacity, enables growth or improves retention.

Running an understaffed service desk can be just as expensive. Overworked engineers, poor customer satisfaction, missed SLAs and staff turnover undermine profitability and make growth harder.

The objective is not the fewest possible engineers. It's the right team, with the right skills and capacity, delivering excellent support at a sustainable cost.

This guide explains how to calculate your MSP's engineering requirements, what staffing benchmarks can and cannot tell you, and how automation, proactive support and a better mix of L1, L2 and L3 engineers help you scale without continually increasing headcount.

How many engineers does an MSP need?

There is no universal staffing ratio that applies to every MSP.

Some industry guidance uses roughly 250–300 managed endpoints per technician as a broad starting point, but this isn't a reliable target without understanding what those engineers are responsible for. An MSP supporting highly standardised Microsoft 365 environments with effective automation may support far more users per engineer than one managing complex infrastructure, multiple technology stacks and high volumes of reactive support.

The number of engineers you need depends on eight factors:

Because of these variables, the most effective way to determine staffing is to calculate the actual engineering workload rather than rely solely on the number of users or endpoints you manage.

The MSP staffing calculator formula

Start by calculating how many engineering hours your customers require each month, then compare that against the productive capacity each engineer can deliver.

The result is full-time equivalent engineering capacity (FTE). The calculation is simple, but getting the inputs right is essential. Plug in your own PSA numbers below; the other tools in this article pick them up.

Covers reactive ticket workload only. Projects, proactive maintenance, technical leadership, account management, security operations and guaranteed coverage (e.g. 24×7 rosters) should be sized separately.

How to calculate MSP staffing, step by step

Here's where each input in the calculator comes from, using an example MSP with 2,000 users.

1. Calculate monthly ticket volume

   Extract ticket data from your PSA platform, such as HaloPSA, ConnectWise PSA or Autotask. Review at least three months of history, preferably six to twelve, to smooth out seasonal swings.

   Count the tickets that need engineering intervention and exclude fully automated activities that consume no engineer time. Our example MSP supports 2,000 users who generate 1,200 tickets a month:

   1,200 tickets ÷ 2,000 users = 0.6 tickets per user per month

   That ratio becomes your baseline for capacity planning and for watching how demand changes as you grow. Not every ticket needs the same effort, though.

2. Calculate average handling time

   Average handling time is the time engineers actually spend working a ticket: investigation, troubleshooting, customer communication, documentation and resolution. It is not elapsed resolution time.

   Ticket open

    

   2 days

   Engineer effort

   30 min

   For staffing, only the orange slivers count: the engineering effort, not the waiting.

   At 1,200 tickets and 30 minutes of effort each:

   1,200 × 30 min = 36,000 min ÷ 60 = 600 hours a month

   Include every engineer's time on a ticket, not just whoever closed it. If an L1 engineer spends 15 minutes before escalating to an L2 who spends another 30, the handling time is 45 minutes:

   L1 · 15 min→ L2 · 30 min= 45 min total

   This matters most for MSPs with high escalation rates, where poor ticket allocation significantly inflates total engineering effort.

3. Determine productive engineering hours

   A full-time engineer in Australia may work about 38 hours a week, but that doesn't mean 38 hours resolving tickets. Meetings, training, documentation, mentoring and breaks all take time, and leave, public holidays and unplanned absences reduce availability across the year.

   Where an engineer's month goes

   Illustrative monthly capacity model. Adjust the sliders to match your business; the calculator above updates too.

    

   RosteredLeave & holidaysMeetings & trainingAdmin & docsBufferFor tickets

   Average rostered working hours

   165

   Leave and public holiday allowance

   15

   Internal meetings and training

   12

   General administration and documentation

   13

   Operational buffer and unallocated capacity

   15

   Available ticket handling capacity

   110 hrs · 67%

   Actual productive hours vary with employment arrangements, service desk responsibilities and operational maturity.

   Here about 67% of scheduled time is available for tickets. The rest isn't wasted: meetings, training, documentation and operational flexibility are part of delivering a sustainable service. The key is to plan on realistic productive hours, not every paid hour.

4. Calculate required engineering capacity

   600 hours ÷ 110 productive hours = 5.45 FTE → plan for 6 engineers

   That isn't necessarily the full staffing requirement. You may also need dedicated resources for projects, proactive maintenance, technical leadership, account management, security operations or guaranteed coverage. Assess these separately rather than assuming the service desk can absorb them.

MSP staffing benchmarks: engineers per user or endpoint

One of the most common questions MSP owners ask is how many users or endpoints one engineer should support. The problem with endpoint benchmarks is that they count devices, not the work those devices create. 500 well-managed endpoints on a standardised stack can generate far less work than 300 endpoints spread across legacy environments.

Calculated scenarios rounded up to whole engineers. These are not recommended staffing targets or verified performance percentiles.

At 2,000 endpoints, a business running 200 endpoints per engineer needs ten engineers; one running 400 needs five. That can represent hundreds of thousands of dollars a year in employment costs.

Before assuming the leaner business is more efficient, compare customer satisfaction, SLA performance, escalation rates, working hours, ticket complexity and how much non-ticket work each team does. Engineer-to-endpoint ratios are useful indicators, but they should never replace workload-based capacity planning.

How many tickets should an MSP engineer resolve per day?

Ticket counts are often used to measure productivity, but comparing engineers purely on tickets closed is misleading. An L1 engineer handling password resets may close far more tickets than an L3 engineer investigating a network outage or security incident. That doesn't make the L1 engineer more productive or more commercially valuable.

A better lens is the relationship between average handling time and productive capacity:

This is why ticket count alone is a poor performance measure. An engineer resolving ten complex issues a day may deliver more value than one resolving twenty simple requests. Assess productivity by ticket category, technical level and total handling time, alongside quality and customer satisfaction.

Getting the right mix of L1, L2 and L3 engineers

Even with the right number of engineers, an MSP can struggle if the team has the wrong mix of capabilities.

Traditional service desks use a pyramid: many L1 engineers handling first contact, smaller L2 and L3 teams handling escalations. That works for high-volume, low-complexity requests, but it creates unnecessary handoffs when L1 engineers lack the skills or permissions to resolve most issues. Every handoff adds effort and delays resolution.

An alternative is a service desk with stronger L2 capability, supported by automation for simple repetitive tasks and L3 engineers for genuinely complex issues. A capable L2 engineer can resolve a broad range of issues without escalation, improving first-contact resolution and lowering the total labour cost of support.

That doesn't mean every MSP should eliminate L1 roles. The right mix depends on the complexity and volume of your work. Calculate workload separately for each level, allocating each ticket's effort to the levels that actually performed it:

This gives a more realistic view of skill requirements than an arbitrary staffing pyramid, and it highlights where to simplify processes, improve documentation and move routine tasks into automation.

Why automation changes MSP staffing requirements

One of the biggest opportunities for MSPs is reducing the engineering work needed per customer, instead of adding employees every time the customer base grows. Automation platforms such as Rewst, Pia and n8n, along with native PSA, RMM and Microsoft automation, eliminate repetitive activities and cut handling times.

Rather than immediately reducing headcount, an MSP can use released capacity to onboard customers, improve response times, complete proactive maintenance or defer recruitment.

Automation creates capacity first. Savings happen when that capacity becomes lower costs, avoided hiring or new revenue.

The role of Centralised Services Engineers in capacity planning

MSPs usually measure service desk capacity by how efficiently engineers resolve existing tickets. The bigger opportunity is reducing the number of tickets created in the first place.

A Centralised Services Engineer focuses on proactive maintenance, standardisation, monitoring, patch management, scripting and automated remediation across customer environments. Instead of repeatedly resolving the same issues, they eliminate the underlying causes: recurring device configuration problems, failed updates and common application issues.

This matters most for growing MSPs, because proactive service delivery changes the relationship between customer growth and staffing. Evaluate a Centralised Services Engineer on the reduction in reactive workload, improvement in system health and support capacity they create, not on tickets closed.

The financial impact of getting MSP staffing right

Technical labour is one of the largest direct costs of delivering managed services, so the staffing model has a direct impact on gross margin. Consider an MSP generating $250,000 in monthly managed services revenue:

In the example, cutting engineering labour by $20,000 a month through better processes, automation and more cost-effective staffing lifts gross margin from 40% to 48%: an extra $240,000 in annual gross profit without a single new customer.

Reducing labour cost should never be the only objective. An MSP without enough engineering capacity risks declining service quality, churn, burnout and recruitment costs that quickly outweigh short-term payroll savings. Optimise the total cost of delivering excellent support.

Seven ways to optimise your MSP staffing model

1. 1

   Base staffing decisions on actual workload

   Use PSA data to understand how many engineering hours customers require, rather than how busy the service desk feels. Measure ticket volumes, handling times, escalation effort and the workload at each technical level.

2. 2

   Improve first-contact resolution

   Every unnecessary escalation adds engineering effort and can reduce customer satisfaction. Better documentation, training, appropriate access and more capable front-line engineers resolve issues faster and reduce total workload.

3. 3

   Automate repetitive tasks

   Target high-frequency activities: onboarding, offboarding, password resets, account management, ticket classification and routine endpoint remediation. Small reductions in handling time create meaningful capacity across hundreds of tickets a month.

4. 4

   Reduce reactive support through proactive maintenance

   Invest in Centralised Services capability that reduces recurring incidents, improves standardisation and eliminates preventable requests. Reducing the issues customers experience is often worth more than resolving them faster.

5. 5

   Optimise the mix of engineering skills

   Make sure L3 engineers aren't routinely doing L2 work, and capable L2 engineers aren't spending excessive time on tasks suited to automation. Match the right skills to the right work at the lowest sustainable total cost.

6. 6

   Consider dedicated offshore engineering resources

   For Australian MSPs, experienced technical engineers are expensive once you account for fully loaded employment costs. Dedicated offshore engineers expand delivery capacity at a more competitive cost while you keep operational control of systems, processes and customer relationships.

   A properly integrated offshore L2 or L3 engineer should operate as an extension of your existing team, not as a disconnected external support provider.

7. 7

   Forecast staffing needs before you need to hire

   Base staffing decisions on expected workload over the next three, six and twelve months. If you plan to grow managed users by 25%, what happens to ticket volumes and engineering hours? Can existing capacity absorb it? Could automation offset some of it? Will you need specialist skills?

   Forward-looking capacity planning lets you recruit and develop the right skills before service quality deteriorates. See what 25% growth does in the calculator →

When should your MSP hire another engineer?

An additional engineer may be justified when forecast workload consistently exceeds productive capacity, backlogs grow despite process improvements, service quality is deteriorating or engineers regularly work excessive hours.

Before hiring, check whether the problem is actually inefficient processes, poor documentation, excessive escalations, underperforming automation or the wrong mix of skills.

The right response may be improving the existing team's productivity, introducing automation, establishing a Centralised Services capability or engaging a dedicated offshore engineer. The key is distinguishing a genuine shortage of capacity from an inefficient operating model.

How Dijital Team helps MSPs build the right engineering capacity

At Dijital Team, we believe staffing should help MSPs build more profitable, mature and scalable businesses, not just add more people. Through our dedicated offshore staffing model, our engineers become embedded members of your team, working inside your PSA, RMM, documentation and service delivery processes.

From staffing to a better business

Through our Better Business Pathway, we work with MSPs to strengthen the operational foundations for sustainable growth, looking beyond individual hires to how technical capability, automation, service delivery efficiency and operational maturity add up to a more profitable business.

Our goal isn't simply to help you hire more engineers. It's to help you understand where you need more capacity, where existing resources can be more productive, and how to build a delivery model that scales efficiently.

The bottom line: stop guessing how many engineers you need

Staffing decisions directly affect profitability, customer satisfaction and your ability to grow. Too few engineers leads to poor service, excessive workloads and churn. Too many, or the wrong mix of skills, creates costs that erode service gross margin.

Take a data-driven approach. Measure ticket volumes, handling times and productive hours. Understand the workload at each technical level, eliminate repetitive work through automation and proactive maintenance, then forecast the resources you'll need as you grow.

The most scalable MSP isn't the one with the most engineers. It's the one where people, processes and automation let it support more customers without costs rising as fast as revenue.

Frequently asked questions