Deciding how to scale an MSP starts with the work you're asking the service team to coordinate. Separate supervision, dispatch, and technical escalation before adding titles. I'd cut the future organizational chart down to the responsibilities that already lack an owner, then price the next change.
The MSP model puts a service manager or working lead at about 8 desk people, a dedicated dispatcher at about 10, and a split into pods or tiers at 12 to 15. Those are planning points for the desk. They aren't total-company headcount rules or proof that a particular hire will pay for itself.
Count the Desk Before You Draw the Chart
A business can have sales, account, project, and administrative staff without those people belonging in the support pool. The model's US example has 12.50 full-time equivalents across the company, with 4 support technicians. Its total staff count doesn't trigger the split-desk rule.
Start with the technicians handling support and the people coordinating that work. In the model's size ladder, desk people counts technicians plus a dispatcher when present; the manager is shown separately. Keep those definitions beside your chart so the threshold doesn't change when somebody includes the whole office.
Then calculate the work behind that count. The model uses tickets, labor minutes by tier, and alert hours, divided by productive hours and rounded to whole people. A revenue target alone doesn't establish how many support technicians you need.
At the model's well-run rate of 0.5 tickets per seat per month, its 700-seat example needs 4 technicians. A typical MSP runs 1.0 to 1.4 tickets per seat per month; at 1.0, the same 700-seat model needs 7 technicians. More demand can bring coordination work forward without adding a single seat.
Keep the Different Jobs Visible
Before choosing a hire, record which responsibilities are delayed, who carries them now, and what decision is waiting. A lead stuck assigning tickets has a different problem from a lead unable to coach the team. Both can sound like a request for another manager if you don't inspect the work.
| Planning Point | Responsibility to Address | What to Inspect |
|---|---|---|
| Below About 8 Desk People | A lead coordinates the pool while remaining part of delivery | Dispatch interruptions, escalation cover, and the work the lead still carries. |
| About 8 Desk People | Service manager or working lead for supervision | Coaching, delivery quality, team decisions, and the authority to resolve exceptions. |
| About 10 Desk People | Dedicated dispatch | Intake, assignment, queue changes, and cover when the dispatcher is away. |
| 12 to 15 Desk People | Pods or tiers under management | Work boundaries, escalation routes, coverage, and where shared expertise belongs. |
Each step addresses a different responsibility. Moving to tiers doesn't remove the need for dispatch; appointing a dispatcher doesn't assign technical authority. Give each job a deliverable and a decision it owns before putting a person's name in the box.
Larry Garcia recommends building an accountability chart around the functions a business needs before attaching people to them. In his practitioner advice, he then defines deliverables, daily tasks, and expectations for each role. I'd use that order here, particularly when a promotion would otherwise be shaped around the person already available.
Protect the Working Lead’s Capacity
Below the dedicated-dispatcher threshold, the model has a team lead dispatch from the support pool. It adds no separate headcount, premium, or dispatch minutes. That is how the planning model allocates the work, not a measurement that dispatch takes no time in your business.
Measure the interruptions and decisions the lead actually handles. Check who covers those tasks when the lead is resolving an escalation or absent. If the records show the same work waiting repeatedly, decide whether clearer authority, a different assignment, or additional capacity addresses it.
When you move from a working lead toward a manager, remove the old commitments explicitly. List the tickets, escalations, and scheduling work the person will stop carrying and name the new owners. A different job title doesn't create productive hours.
Keep account management separate. The model gives technical alignment work to the TAM and business planning to the vCIO, with both reporting to the owner. It doesn't make the service manager responsible for new-business sales or quietly add those account roles to the manager's span.
Split the Desk Around Actual Work
At the model's 12-to-15-person desk range, examine whether pods or tiers fit the workload. A tiered desk groups work by the skill it needs. A pod groups people around an assigned set of clients or work, while still needing access to specialist skills and absence cover.
I'd write the handoffs before moving clients or technicians. Name who accepts a ticket, who can reassign it, when an escalation changes hands, and who keeps the client informed. Use your actual repeated handoff problems to test the proposed structure.
Don't promise a margin improvement just from dividing the queue. The model prices the split no differently from the pool. Your case has to identify a measurable change in workload, coordination, or service, along with the cost of making it.
For comparison, the well-run size ladder at 2,000 seats shows 10 technicians, a dispatcher, and a manager. Its desk count is 11 because the manager is separate. At 2,500 seats, it shows 12 technicians plus a dispatcher and a manager, putting the desk count of 13 into the split range.
Those examples retain the well-run ticket assumption. They illustrate how a workload can reach the planning points, not universal seat thresholds. Use your own demand and coverage requirements before copying either structure.
Put the Added Role in the Right Cost Line
Service management belongs in delivery labor inside the managed-services margin calculation. The model targets 50% gross margin after burdened delivery labor and tools. Hiding a manager in general overhead doesn't make the service cheaper to deliver.
Build the proposed role from its actual compensation, burden, and supporting costs. Separate work reassigned from expenses removed. If the owner gains time but keeps the same salary, that may create useful capacity; it isn't a cash saving you can spend again.
Check onboarding separately from support. In the model, project engineers carry onboarding alongside billed projects. A growing sales plan can need more of that capacity even while the support desk remains below a management or dispatch planning point.
Choose the Next Change From the Records
I'd put the decision in front of the owner with a short set of assigned checks:
- The service lead records the supervision, dispatch, and escalation work that is waiting or displacing delivery.
- The proposed role owner receives written responsibilities, authority, and handoff expectations.
- Finance prices the change and checks the resulting delivery margin and cash commitments.
- The owner agrees which observed results would support keeping, revising, or expanding the structure.
After the handoff, use the same definitions to inspect the work you intended to improve. Investigate changes in demand, staffing, and client mix before attributing a better report to the new structure. Fund the next responsibility you can identify and measure, then let the chart follow that decision.
mspoutpost.com/articles/how-to-scale-an-msp-with-clear-service-roles-and-costs
Written by Owen Gallagher
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.