Published by
Throne of Profit EditorialReviewed by
William Hassell
Founder & Chief Editor, Throne of Profit
Every MSP eventually lands a big one — a server migration, a tenant move, a firewall refresh across every site. It's good revenue and the kind of work that makes you look like a real partner. Then the rollout starts, the engineers running it are also the ones answering tickets, and within a week both are limping. The project slips because support keeps pulling people off. Response times blow up because the project is eating everyone's day. The problem is almost never the project itself — it's that the project was scheduled as if the steady support load would politely pause while you did it.
It won't. The tickets keep coming whether or not you're mid-migration. The MSPs that run big rollouts cleanly don't have quieter clients or faster engineers; they plan the project around a support load they already know is coming, instead of pretending it disappears the week they need their people most.
TWO WORKLOADS, ONE TEAM
steady support load ▇▇▇▇▇▇▇▇▇▇▇▇ (predictable, non-negotiable)
project rollout ░░░░▇▇▇▇▇░░░░ (planned in the gap that's left)
└── capacity reserved BEFORE committing dates
collision → both stall: slipped project + slow ticketsOwner symptoms
Projects consistently run long because engineers keep getting pulled onto support.
Ticket response times spike every time a big rollout is underway.
You commit a project timeline to the client before you know who's actually free to do it.
Why this happens
Support is unpredictable in timing but very predictable in volume — you know roughly how many hours a week it eats, even if you don't know exactly when. Projects feel like the opposite: a fixed scope with a date attached. So owners schedule the project against the calendar and treat support as something that will "fit around it." It's backwards. The support load is the fixed cost on your team's time; the project is what you fit into the capacity left over. Commit project dates without reserving that capacity and you've promised hours you don't have — so the two workloads fight for the same people every day.
Common mistakes
Committing a project date before checking real capacity — the timeline is set by the client's calendar, not by who's available.
Assuming full-time engineers are full-time available — a "40-hour" tech already spends a big chunk of the week on tickets.
Putting your best generalist on the project, then discovering they were also the person holding support together.
No buffer for the support spike a rollout creates — cutovers generate their own tickets you didn't budget for.
Running two big projects in the same window because both clients said yes, without checking whether the team can carry both.
Business consequences
When a rollout collides with support, you lose on both ends. The project slips, which burns margin and makes you look unreliable to the client who trusted you with it. Meanwhile your other clients — the ones paying a monthly fee for responsive support — watch their tickets sit, and their trust erodes quietly until one starts shopping. You end up doing the impressive work badly and the steady, contracted work badly at the same time. The owner who reserves capacity first delivers the project on schedule, keeps support responsive throughout, and turns a rollout into a reference instead of a scramble.
How experienced operators think about it
They treat the steady support load as a fixed reservation on the calendar, not a variable that flexes to make room. Before any project date goes to a client, they ask: how many engineer-hours a week does support consume, who covers it, and how many hours are genuinely left over? The project gets scheduled into that remaining capacity — and if there isn't enough, the honest answers are a later start, a longer timeline, or a subcontractor, not an optimistic promise. They also protect support explicitly during a rollout: someone is walled off to keep tickets moving so the project can't quietly cannibalize the team.
Practical actions
Measure your steady support load first. Know roughly how many engineer-hours a week tickets consume before you promise anyone a project date.
Reserve support capacity, then schedule the project into what's left. Treat the support number as fixed and the project as the thing that fits around it.
Wall off support during the rollout. Name who owns tickets that week so they can't be pulled onto the project the moment it gets busy.
Budget for the cutover spike. Migrations and go-lives generate their own tickets — plan for that surge instead of being surprised by it.
Stagger big projects and quote from capacity. Don't let two rollouts land in the same window, and set dates by who's actually free, not by the client's calendar. If the honest answer is later, say later.
Questions every owner should ask
Do I know how many engineer-hours a week my steady support load actually consumes?
When I commit a project date, have I checked who's genuinely free — or just assumed the team will absorb it?
During my last big rollout, did support quietly get worse, and did I plan for that or just live through it?
Frequently asked questions
Should I just hire a dedicated projects person so support and projects never compete?
Eventually, maybe — but only when your project volume is steady enough to keep that person busy and the margin supports it. Hiring ahead of steady project revenue just moves the strain to cash flow. Until then, the fix is scheduling discipline: measure the support load, reserve it, and fit projects into the real capacity that's left. Dedicated capacity answers consistent project demand, not a scheduling problem you can plan around today.
A client wants a hard date I can't hit without wrecking support. What do I do?
Give them the honest version. A later start or a longer timeline delivered cleanly beats a promised date that slips and drags your other clients' support down with it. Most clients will take a realistic schedule over an optimistic one that fails. If the date is truly fixed and truly worth it, that's your signal to bring in a subcontractor for the overflow rather than borrow the hours from support.
Related articles
Running a Profitable Managed IT Services Business — the pillar.
Choosing the Core Tools That Run Your MSP Without Overbuying — the systems that surface your real support load.
Getting Your Software Subscription Costs Under Control — controlling the cost side of the same operation.
Why Jobs Take Longer Than You Quoted — the general estimating problem.
Where Time Leaks on a Typical Job — where hours quietly disappear.
Every business has more decisions than time
Whether you need help solving one problem, evaluating a major opportunity, or making a company-changing decision, Throne of Profit gives you consulting capacity on demand.
Purchase only the consulting capacity you need and use it across Weekly Focus, Strategic Focus, Financial Focus, and ThinkTank engagements.