Managed service providers live or die on three operational moments. Onboarding, because a rough onboarding poisons the entire relationship. Monitoring, because noisy alerts burn out engineers and missed alerts lose clients. And the QBR, because that is where renewal happens or does not.
Most MSPs obsess over the middle piece, monitoring, and underinvest in the bookends. That is backwards.
Onboarding Is Where Churn Gets Seeded
A new MSP client signs. Then the clock starts on first impressions. The industry average is that 30% of MSP clients churn in the first 12 months. Almost all of them churn because onboarding went sideways.
A disciplined onboarding process runs on a 30 to 45 day clock with fixed milestones. - Day 1 to 5, discovery, environment documentation, stakeholder map - Day 6 to 15, agent deployment, monitoring baseline, backup verification - Day 16 to 25, runbook review, escalation paths tested, known risks logged - Day 26 to 35, first operational review with client, everyone on the same page - Day 36 to 45, steady state, ticket intake normalized, SLAs in effect
The whole point is predictability. The client should know at week 1 what week 4 will look like.
Monitoring Is a Filter Problem, Not a Data Problem
Every MSP has monitoring. The problem is not detection. The problem is noise.
A mid-sized MSP managing 50 clients can easily generate 5,000 alerts a day. Most are informational. A handful are real. If engineers have to look at all 5,000 to find the real ones, they stop looking.
The fix is tiered filtering: - Layer 1, raw alerts from RMM, firewalls, cloud, backups - Layer 2, correlation and deduplication, related alerts collapsed into incidents - Layer 3, severity classification, based on impact and client SLA tier - Layer 4, human review queue, only incidents that passed filter, prioritized
A good filtering spine reduces 5,000 raw alerts to 30 to 50 actionable incidents per day.
Runbooks Are the Quiet Force Multiplier
For every recurring incident type, a runbook should include: - What the alert actually means - First 3 checks to run - Known causes and their fixes - Escalation path if the known fixes do not work - Client-specific notes
Every on-call engineer should be able to resolve 80% of incidents using runbooks alone.
Patch and Change Management Cannot Be Ad Hoc
Most client-visible incidents are self-inflicted. A mature MSP runs patching on a schedule and changes through a lightweight approval flow. - Patches tested in a canary group before mass deployment - Critical security patches, 72-hour SLA with documented exceptions - Standard patches, monthly maintenance window - Changes over a defined risk threshold require peer review - Every change logged with rollback procedure
The QBR Is a Renewal Mechanism
A bad QBR is a slide deck full of metrics the client cannot interpret. A good QBR tells a story.
The story has four parts: - Here is what we managed for you this quarter - Here is where you stand on security, backups, infrastructure risk - Here is what changed in your business and how we are adapting - Here is what we recommend for next quarter, with expected outcomes
The last part is where MSPs either expand the relationship or lose it.
Client Tiering Determines Everything
- - Tier 1, white glove, named engineer, same-day QBR, high-touch communication
- - Tier 2, standard, pool-based support, quarterly QBR, standard SLAs
- - Tier 3, efficient, self-service portal, ticket-based support, light-touch
Trying to give every client white glove service is how MSPs go broke.