Resource and capacity planning for MSPs

Every MSP owner has felt the same squeeze: the reactive queue is on fire, a project deadline slipped again, and the one engineer who can actually do the work is already booked at 120 percent. Resource and capacity planning is the discipline that keeps that from happening every quarter. Done well, it tells you how many billable hours you truly have, where they are going, and whether the work you just sold will fit. Done badly, it looks like a spreadsheet nobody updates and a schedule that only exists in your senior tech's head.

The core problem is that MSPs run two very different kinds of work through the same people. Reactive service tickets are unpredictable and interrupt-driven. Project work is planned, sequenced, and deadline-bound. When both pull from one shared pool of engineers, capacity planning stops being a math problem and becomes a triage problem. This guide walks through the pieces that matter.

Start with real utilization, not billable hours

Utilization is the percentage of an engineer's available time spent on work that moves the business forward. It sounds simple until you try to define the denominator. A tech is not available 40 hours a week. Subtract PTO, holidays, internal meetings, training, admin, and the unavoidable context-switching tax, and the realistic ceiling is closer to 32 to 34 productive hours. Planning against a fictional 40 is the single most common reason MSPs feel chronically underwater despite hiring.

Separate two numbers. Billable utilization is time a partner pays for. Total utilization includes internal projects, onboarding, and tooling work that is real effort but not invoiced. A healthy service desk often runs 70 to 85 percent billable, with the rest absorbed by internal load. If your team is pinned at 95 percent, you have no slack for the next emergency, and quality and morale will pay for it before the spreadsheet does. Capacity planning is as much about protecting headroom as it is about filling it.

Why shared ticket and project capacity is the hard part

Most PSAs schedule tickets and projects in separate places. Your dispatcher assigns reactive work in the service board; your project manager blocks out project tasks in the project module. Neither view knows about the other. So the PM schedules eight hours of a network cutover on Thursday, and the dispatcher, looking at a different screen, drops six hours of escalations on the same engineer the same day. Both were reasonable in isolation. Together they overbook a real human by 40 percent.

The fix is a single, honest picture of committed hours per person per day that spans both worlds. Reactive work needs a reserved allocation, not a hope that it will be quiet. Most desks can forecast their reactive load statistically: if a tech averages 20 hours of tickets a week, reserve 20 hours before you promise any project time. What remains is your true project capacity. Selling against gross headcount instead of net project capacity is how delivery dates slip without anyone making an obviously bad decision.

PTO and availability are not edge cases

Vacations, sick days, holidays, and part-time schedules are not exceptions to plan around later. They are the baseline. A schedule that ignores a two-week vacation will happily place a critical-path task on someone who is in another country, and you will not discover it until the task is already late. Capacity planning has to pull from a real availability calendar and subtract unavailable time before it ever assigns a task.

This matters most on dependency chains. When a task with three downstream dependencies lands on an engineer's PTO week, every task behind it should shift automatically, and the project end date should move with it, out in the open, before you commit to the partner. Scheduling that is aware of PTO and availability across the timeline, the dependency map, and your what-if scenarios turns a nasty surprise into a planning conversation. Current was built this way on purpose, and it is the difference between a plan that survives contact with reality and one that quietly lies to you.

Forecast demand before it lands

Reactive planning ends the same week it starts. Real capacity planning looks forward a quarter. Two pipelines drive future demand: sold-but-unscheduled projects, and your sales pipeline weighted by probability. A won quote that becomes a project needs hours reserved the moment it closes, not the week kickoff is due. Pulling closed-won deals straight into delivery, so a signed statement of work turns into scheduled capacity, closes the gap where MSPs consistently oversell what the calendar can hold.

Watch a few leading indicators. Backlog of unscheduled project hours tells you whether you are selling faster than you can deliver. Trend in reactive hours per endpoint tells you whether a growing base is quietly eating the capacity you meant to spend on projects. Both move slowly, then all at once.

How to stop overbooking your best engineers

Overbooking almost never comes from one big mistake. It comes from many small commitments made against different views of the same person. Three habits prevent most of it. First, plan against net capacity, after PTO and reserved reactive load, never gross headcount. Second, keep one shared view of committed hours so the dispatcher and the PM see the same number. Third, cap sustained utilization deliberately, leaving 15 to 20 percent slack so the next emergency does not detonate the project plan.

Also spread the depth. When one senior engineer is the only person who can do the hard work, every plan routes through that person and every plan is fragile. Track skills alongside availability, schedule pairing time as real capacity, and your bottleneck stops being a single calendar. Capacity planning is not about squeezing more from the team. It is about making honest promises you can keep, so the work is predictable, the partners trust your dates, and your best people are still here next year.