Hiring for an MSP: Service Manager, Techs and Ratios

Hiring is where an owner-run MSP either escapes the queue or doubles down on it. The usual advice is a ratio: so many technicians per user or per endpoint. The ratios online are vendor rules of thumb with no source, and they disagree. This guide shows which hire to make first, how to calculate whether you need it from your own workload, what the published ratios actually say, and what the 2026 surveys report about hiring.

Who should an MSP hire first?

Hire against the constraint, not the org chart. If tickets pile up because there are too few hands, hire a technician. If the queue is disorganised and you are firefighting, hire or promote a service manager. If growth stalls because nobody sells, hire sales. Fix the process first, because a new person inherits the mess.

ScalePad's 2026 survey says sales is the most planned in-house hire for the year ahead, at 36%. That is a plan, not proof it is the right first hire for you. If the constraint is the owner answering every ticket, the ticket-queue plan comes first: it shows how to audit your time and who should own the queue. The starting an MSP guide covers the very first technician hire.

How do you tell it is time to hire?

Use workload, not headcount. Add the weekly hours your tickets take, add project and admin hours, and divide by the productive hours one technician can deliver. If the result is above the number of technicians you have, you are short. Giant Rocketship puts it as "incoming work multiplied by time to resolve it".

The formula is: technicians needed = (weekly tickets x average hours per ticket + weekly project and admin hours) / productive hours per technician.

Our KPI guide gives a rule-of-thumb utilisation range of 65-80% and says that above about 85% quality tends to suffer. That is MSPCoach judgement, not a benchmark. Two cautions: average ticket time is skewed by a few long tickets, so use a median as well, and the formula ignores seasonality. Re-run it quarterly.

What ratios do MSPs use?

Two appear often, and neither has a source. Use them to sanity-check your own maths, not to set headcount. NinjaOne says "the industry average ranges from 250 to 350 endpoints per technician", with no citation. Giant Rocketship quotes "one technician per 70-100 users" as a shortcut and argues against relying on it.

To see what a rule implies, divide your endpoint count by it. At 1,000 endpoints, 250-350 endpoints per technician implies roughly 2.9 to 4.0 technicians. The spread is the point: the same rule gives answers a full technician apart, and it says nothing about your automation, documentation quality or client mix. Users and endpoints are different counts, so do not convert between the two ratios.

Why do ratios vary? Automation coverage, how standardised your clients are, how well you document, the response targets in your SLAs and whether clients are regulated all move the number. Better documentation, for example, shortens resolution time per ticket; see documentation best practices.

What is the market doing on hiring?

ScalePad's 2026 report found nearly a third of MSPs plan to increase headcount, while nearly half plan to slow, freeze or outsource hiring. The two surveys below ask different questions, so read the tables separately and do not combine them or compare their percentages.

Kaseya's 2026 survey shows the supply side. Difficulty hiring skilled technicians rose to 16% from 9%, struggles with training and upskilling staff rose to 15% from 7%, and gaps in technical expertise rose to 14% from 7%. Staffing was also named among their top three business issues by 32% of MSPs.

16%

Kaseya, 2026 State of the MSP Report, 2026Vendor surveyn=1,061Verified 2026-10-11

ScalePad adds a useful contrast. When asked about the top hiring and development challenge, 31% named finding skilled technical staff and 11% named retaining current employees. Retention matters more than that ratio suggests, as the next sections explain.

What does a service manager do in the first 90 days?

The role owns how work flows through the desk. BMK Community describes it as ensuring services are delivered efficiently, consistently, profitably and within SLAs, covering ticket queues, technician performance, escalation paths and resource balancing. BMK sells service-management training, so use its description as a job outline, not as evidence of results.

This scorecard is an MSPCoach template, not a benchmark. Give the role the same data you use, the authority to reassign work and a defined limit on what they can approve. Without those, a service manager becomes a messenger. NinjaOne warns that a senior technician who becomes the only route for complex work is a permanent choke point; the same applies to a manager everyone must ask.

What does a hire cost, and when does it pay back?

A hire pays back when the gross profit from the capacity it releases exceeds its fully loaded cost. Loaded cost is pay plus payroll taxes and benefits, equipment and licences, training, recruiting and the management time they consume. Check current local pay for the role, since we do not quote salaries.

Remember the other side: the cost of not hiring includes missed SLAs, burnout and client churn. Kaseya lists staff burnout among the problems affecting daily workload at 8% of MSPs in both 2025 and 2026, so it is not rising, but it is not solved. Use the KPI benchmark checker to see how your margin compares before you commit to a new salary.

How do you keep the people you hire?

ScalePad reports the retention practices MSPs use: competitive pay or bonuses (48%), flexible working (45%), career growth planning and promotions (42%), and ongoing education and training (37%). Only 6% have no specific retention strategy. It also reports that MSPs with lower client churn and higher satisfaction scores are more likely to invest in retention, which is a correlation, not proof.

That matters for the maths above. Replacing a technician means recruiting again and months of reduced productivity, none of which appears in the loaded-cost line. Training also costs: Kaseya found upskilling challenges more than doubled. Documented procedures shorten ramp time for every new hire, which makes them the cheapest retention and productivity investment on this list.

What goes wrong with first hires?

Most failures come from the setup, not the person. These patterns are MSPCoach editorial judgement drawn from the sources above, not measured rates, but each one is easy to check before you advertise the role, and each is cheaper to fix before the hire than after it.

• Hiring before the process exists. NinjaOne lists hiring before identifying the real constraint as a common mistake. If tickets are misrouted or noisy, a new person inherits the noise.
• No written outcomes. If you cannot say what the person should have achieved at day 30, 60 and 90, you cannot tell whether the hire is working.
• No onboarding material. A new technician with no runbooks asks you, and the queue stays with you.
• Hiring to avoid a decision. A sales hire does not replace a clear offer, and a manager does not replace a decision about who has authority.
• Pay set by guess. Check current local pay for the role and compare it with your loaded-cost maths before you post the job.

Should you hire, outsource or automate?

Compare the three on your own numbers. Hiring suits steady, growing volume. Contract or outsourced help suits peaks and after-hours cover. Automation suits repetitive tickets. ScalePad found 14% of MSPs are shifting to more contract or outsourced staff. Read the vendor's ownership and terms first.

Whichever route you choose, write the job's outcomes down first. The MSP operations hub collects the owner-side guides, and the sourced figures are on the research page.

A note on method

The ScalePad tables are as printed in the 2026 MSP Trends Report, Chapter 2. The Kaseya figures are from the 2026 State of the MSP report (Figure 22 and the talent section; Figure 2 for the top issues). The NinjaOne, Giant Rocketship and BMK articles were opened on 11 October 2026. All arithmetic in the illustrative boxes uses made-up inputs. Our methodology page explains how we source and verify data.