Let’s get one thing out of the way: block hours aren’t evil. They aren’t the root of all margin erosion, scope creep, or engineer resentment. In fact, when used correctly, block hours are a clever tool.
But the keyword here is correctly, and using block hours in an MSP contract is like putting racing slicks on a snow plow. Technically doable. Horrifically impractical.
Let’s unpack why.
What Are Block Hours, and Why They're Popular in Non‑MSP Scenarios
Block hours are pre-paid, pre-packaged time slices clients can redeem like golden tickets for IT support. It’s a classic model: client buys 20, 50, or 100 hours up front, and those hours get pulled from the stash as work gets done.
Clients love it because it feels flexible. You love it because there’s upfront cash flow. Everyone’s happy, until someone starts treating block hours like a Netflix subscription that never expires and includes free project management.
Where block hours do make sense: project-based consulting, overflow support, and occasionally, helping an internal IT department triage an onslaught of self-inflicted printer issues.
Why Block Hours Should NEVER Be Used for MSP Engagements
Using block hours inside a managed services contract is like hiring a personal trainer, then paying them per sit-up. It encourages the exact behavior MSPs are supposed to prevent: reactive support, nickel-and-dime fixes, and a race to the bottom on pricing.
MSPs thrive on proactive service: standardized processes, automation, consistent monitoring. When you throw block hours into the mix, you’re inviting variability, unpredictability, and a whole lot of “Did that count as billable?”
It also confuses the client. If they’ve got an “all-you-can-eat” MSP plan, why are they chewing through block hours every time someone forgets their email password?
Worse, some MSPs discount block hours. Please don’t do this. That’s like handing out coupons for your time and expecting long-term profitability. Spoiler: you won’t get it.
One Acceptable Exception: Banking Hours for Future T&M Projects
If you’re going to use block hours in an MSP context, use them like a savings account. Reserve them strictly for future projects that fall outside of your managed services scope: things like network refreshes, cloud migrations, or helping Gary in Finance finally digitize that 2007 Access database.
This “banking” model lets clients pre-pay for upcoming work without muddying the waters of your core support agreement. Just make sure it’s crystal clear in the contract: block hours do not apply to support services already covered under the MSP umbrella.
When Block Hours Are Appropriate (But Not in Place of MSP)
Let’s give block hours a little credit. They do have their place, just not in your fixed-fee MSP contracts. Here’s where they shine:
-
Escalation support: Your client has an internal IT team, but they call you when the server catches fire or when someone accidentally deletes the finance department’s shared drive. You’re the bat signal.
-
Overflow help: The internal team is swamped, or they need extra hands for a new initiative. Enter: block hours.
-
Transitional clients: They’re not ready for a full MSP contract yet. That’s fine. Use block hours as a gateway drug to full-on managed services bliss.
Just don’t let them hang out in that phase forever. Wean them off the hourly mindset before it becomes permanent.
How to Structure Block Hour Agreements for Success
So you’ve found the right client and the right use case. Great. Now let’s talk about how to avoid the death-by-100-helpdesk-tickets scenario.
Set a Defined Expiration
This is non-negotiable. Block hours should expire after a set time (typically 12 months). Otherwise, you’re sitting on a liability that could surface during your busiest quarter, right after your lead tech goes on parental leave.
No rollover. No eternal access. These are not airline miles.
No Discounted T&M Under the Guise of Block Hours
Do not (and I repeat, do not) offer discounted hourly rates through block hours. This undermines your value, trains clients to expect less, and makes your engineers question life choices.
If they want a deal, they can sign up for your full MSP plan and enjoy the joy of unlimited support calls about “the Internet being slow again.”
Clear Scope Delineation
Be specific. What’s covered by block hours? What’s not? Are they for project work only? Escalation support only? What counts as a “project” anyway?
Put it in writing. Then explain it again during onboarding. And again in the quarterly business review. Clarity prevents conflict. And lawsuits.
Overage Clauses & Terms
What happens when the block runs out? Ideally, you set a rate for overages that either matches your standard hourly rate or, better, charges slightly more. That incentivizes clients to stick to the agreed hours or top up in advance.
Also, track hours transparently. Clients should always know how much remains. Nothing erodes trust faster than a surprise invoice for time they thought was “included.”
Key Risks to Mitigate
Block hours can become a trap. A beautiful, revenue-generating trap that slowly strangles your margins if you’re not careful. Here’s what to watch for:
-
Internal conflicts: Clients may try to route all support through block hours, even if they’re on an MSP plan. That’s a no-go. You’re not a vending machine.
-
Engineer inefficiencies: Without clear scope and expiration, engineers may treat block hour clients like hourly projects (no urgency, no optimization).
-
Revenue leakage: Hours that never expire are a future accounting nightmare. Unused hours create liability. Expire them or risk a call in 2029 from a client who just found their “IT tokens” in an old desk drawer.
Share via: