Margin Compression: When Cost‑to‑Serve Rises Faster Than Revenue

image

If margins collapse, nothing else matters.

Not growth.
Not MRR.
Not headcount.
Not how many logos are on your website.

This is why margin compression is the number one silent killer in the MSP industry right now.

On paper, many MSPs look healthy. Revenue is climbing. Client counts are up. Service catalogues are expanding. But underneath that surface-level success, net margins are flat at best—and often shrinking. The business is working harder for the same outcome, or worse, less profit. Multiple industry analyses point to the same culprits: labour, vendor/software spend, and a widening mismatch between scope and price, with labour consistently the largest cost line for most MSPs.

This is brutal because it hides in plain sight.

The profitability illusion

Margin compression doesn’t usually show up as a dramatic collapse. It shows up as a slow bleed.

You win a few more clients.
You add a couple more technicians.
You roll out another security tool “for free” to stay competitive.
You absorb a few extra requests because “it’s just easier”.

Your MRR graph keeps pointing up, so everything must be fine… right?

Except EBITDA isn’t moving. Cash flow feels tighter. Owners stop paying themselves properly. Every problem feels urgent because there’s no margin buffer left. That’s the illusion: growth masking decay.

Industry commentary has been calling this out more loudly over the last year. MSPs are growing, but profits aren’t keeping pace. The core issue isn’t sales—it’s that cost‑to‑serve is rising faster than contract value, driven by operational complexity and unpriced work.

Why cost‑to‑serve keeps exploding

Let’s be blunt about what’s changed.

Labour costs are rising
Good technicians are expensive. Great ones are rarer and cost more. Wage inflation, retention pressure, burnout, and higher expectations all push labour costs up. For most MSPs, labour is the single largest expense, and even small efficiency losses compound quickly.

Security workload per endpoint has exploded
Endpoints are no longer “patch and forget”. Each one now carries identity, conditional access, EDR, alert triage, reporting, compliance evidence, and incident response expectations. The workload per user has multiplied, but many contracts haven’t.

Fixed‑price contracts were written for a simpler era
“All‑you‑can‑eat” sounded great when environments were smaller, flatter, and less regulated. Today, that same pricing model absorbs cloud sprawl, security alerts, identity issues, SaaS churn, and board‑level reporting—without a matching price increase.

Scope creep is now systemic
This isn’t the odd favour. This is unbounded complexity baked into the operating model. New vendors roll out defaults. Microsoft changes behaviour. Security baselines shift. Clients expect it all to be “included”. The contract never gets revisited.

The result? MSPs are expected to deliver more, faster, and safer—without adding headcount and without raising prices. That maths simply doesn’t work.

Labour: the biggest margin leak

When people talk about margin problems, they often blame tools first. And yes, vendor and software costs matter. Tool sprawl hurts. Licensing creep is real.

But labour is where margins truly die.

Every extra ticket minute. Every manual process that should have been automated. Every alert that requires human triage. Every undocumented workaround that only “that one senior tech” knows.

Those minutes add up to hours. Those hours add up to FTEs. And those FTEs are increasingly hard to fund under legacy pricing models. This is why so many MSP margin leaks trace back to time—unbilled, under‑priced, or poorly controlled. [level.io]

Why this problem is so dangerous

Margin compression doesn’t announce itself.

You don’t get an alert. You don’t get an email. Your PSA won’t warn you.

What you get instead is exhaustion. Constant pressure. The feeling that you’re always behind, even though you’re “successful”.

And here’s the real danger: once margins are gone, you lose options.

You can’t invest. You can’t absorb shocks. You can’t say no to bad clients. You can’t slow down long enough to fix the model.

That’s why this is problem #1. Not because it’s flashy—but because it quietly removes your ability to respond to everything else.

The uncomfortable truth

You cannot out‑sell margin compression. You cannot hire your way out of it. And you definitely can’t ignore it.

If your cost‑to‑serve is rising faster than your revenue, growth will make things worse, not better.

The MSPs that survive the next phase of this industry won’t be the ones with the most clients. They’ll be the ones who understand their margins, price complexity properly, and stop pretending that “unlimited” still exists.

Because in 2026, unlimited delivery with fixed pricing isn’t a value proposition.

It’s a slow, quiet business killer.

If It’s a Supply Issue… What’s Actually the Constraint?

image

I hear this a lot from MSPs.

“We’ve got demand. Plenty of demand. The problem is supply.”

And on the surface, that sounds right. Phones ringing. Inbound leads. Existing customers wanting more. Projects stacking up. Everyone’s busy.

But here’s the question I think too few MSP owners are really asking:

If it’s a supply issue, what exactly is constrained?

Because most of the time, it’s not what you think.

It’s Rarely the Market

Let’s get this out of the way first. In most regions right now, MSPs don’t have a demand problem. If anything, the opposite is true.

Security requirements are increasing. Compliance expectations are rising. Clients are confused, under-skilled, and increasingly nervous. Microsoft keeps adding more knobs, dials, portals, and acronyms.

There’s work everywhere.

So if growth has stalled, it’s probably not because there aren’t enough customers willing to pay for help.

Which means the constraint is internal.

Frontstage vs Backstage

A useful way to think about this is frontstage versus backstage.

Frontstage is what clients see:

  • Sales conversations

  • Projects

  • Tickets getting resolved

  • New customers onboarding

Backstage is what actually makes all of that possible:

  • Your time

  • Your team’s capability

  • Your systems and processes

  • Your standardisation (or lack of it)

Most MSPs focus their energy on the frontstage. More leads. Better proposals. New offerings. Better marketing.

But when supply becomes the issue, the real bottleneck is almost always backstage.

The Three Real Constraints

In my experience, it usually comes down to one (or more) of these.

1. Your time

If you’re still the escalation point, the sales engineer, the architect, the quality control, and the business owner, then your business can’t scale past you.

That’s not a staffing issue. That’s a design issue.

If every complex decision, every quote, every “just check this” flows through you, then you are the constraint. Not demand.

2. Your team

Many MSPs hire reactively. Someone leaves. Work piles up. You hire to relieve pressure.

But scaling requires capability, not just headcount.

If only one or two people truly understand identity, security, or automation, then growth stalls the moment they’re fully utilised. Everyone else becomes dependent on them, and velocity drops.

A team that can’t operate independently can’t scale sustainably.

3. Your systems

This is the unsexy one. And the most ignored.

If every customer is “a little bit different”, every deployment is bespoke, and every technician does things “their way”, then you’re not running a scalable service business. You’re running a collection of individual heroics.

The more customers you add, the slower everything gets.

That’s not because you’re bad at MSPing. It’s because standardisation, documentation, and automation haven’t been treated as first‑class work.

The Uncomfortable Truth

When MSP owners say “we can’t scale because of supply”, what they often mean is:

“The way we currently operate doesn’t scale.”

And that’s actually good news.

Because markets are hard to fix. You can’t control demand.

But you can redesign how work flows through your business.

You can:

  • Remove yourself as the bottleneck

  • Build repeatable delivery models

  • Train for depth, not just coverage

  • Invest in systems that make average staff effective, not heroic staff exhausted

None of this is glamorous. None of it is quick.

But it’s the difference between being busy and being scalable.

So next time you think you’ve hit a supply ceiling, don’t just ask how do we get more capacity?

Ask the harder question:

What backstage constraint is actually stopping us from growing?

Because that’s where the real work is.

From tribal knowledge to Copilot skills: seven patterns every MSP should write down

image

Every MSP I’ve worked with has a playbook. Some of it is written down. Most of it lives in the head of the engineer who’s been there longest. When that engineer is sick, on leave, or finally takes the holiday they’ve been promising themselves for two years, the playbook walks out the door with them.

That’s the gap I’ve been thinking about lately. We’ve built systems that handle tickets, monitor endpoints, and bill clients. We have not done a great job of capturing the judgement — the way a senior engineer triages a queue at 7am, the questions they ask before onboarding a new client, the tone they take when a CEO’s mailbox is broken on a Monday morning.

Microsoft 365 Copilot, with the right scaffolding, finally gives us somewhere to put that judgement. Not as a chatbot. As a set of repeatable skills your team can run consistently every time.

Why bother turning workflows into skills

A skill, in this context, is a short markdown file that tells Copilot how to handle a specific kind of work. It’s the difference between asking your assistant a vague “help me with this client” and handing it a defined process — what to ask, what to gather, what to produce, where the guardrails sit.

The payoff isn’t raw speed. It’s consistency. Every new starter at every client gets onboarded the same way. Every QBR pack tells the same story in the same shape. Every outage update lands in your house voice, at the right interval, instead of being workshopped at 9pm by a tired engineer.

I’ve drafted seven of these as examples to show what’s possible. Walk through them with me.

The client-facing rhythm

Four of the skills cover the moments that define your client relationship.

Client onboarding is the first. The new MSA is signed, and somewhere between sales and service delivery, things get dropped. The skill gathers the structured client profile — domains, contacts, service tier, compliance obligations — and produces three artefacts every time: a welcome email, an internal Teams announcement to the delivery team, and a technical checklist for the engineer. Wire it into the tenant via Graph so domain checks and the initial license inventory happen up front. Schedule the day-7, day-30, day-90 touchpoints into Outlook before the engineer even picks up the work.

Employee onboarding is the same idea at the user level. New starter, Monday start, the client manager has asked for “the usual setup.” With a skill driving it, the usual becomes auditable: identity provisioned, license assigned from a role template (not copied from a colleague — that’s how entitlement drift starts), Intune enrolment, mailbox memberships, a manager briefing, and a quick-reference card the new hire actually opens on day one. Surface every drafted communication for review. Never auto-send.

QBR preparation is where most MSPs leave money on the table. The data is already there — tickets in the PSA, patch status in the RMM, Secure Score and license utilisation in the tenant. Pulling it together into a story takes hours. A skill turns it into a repeatable build: scorecard, security posture, license rightsizing, projects, roadmap. Compute every percentage with code, never by eye — a wrong MFA percentage in a QBR undermines the whole pack. Use the pptx generation to produce the deck and a Word leave-behind for the people who want detail. The trick is to lead with theme and support with data, not the other way around.

Incident communications is the one nobody wants to think about until it’s needed. When Exchange Online wobbles on a Tuesday morning, your engineers should be fixing the problem, not workshopping the wording of the customer email. The skill drafts the four stages — initial notification, progress update, all-clear, post-incident review — using only confirmed facts from Microsoft’s Service Health dashboard or your own monitoring. Never speculate about root cause in a customer-facing message. Promise an update time, not a fix ETA. Send via the channel you started on; don’t fragment.

The operational backbone

The other three skills run quietly in the background and pay you back every week.

Ticket triage applies a real Impact × Urgency matrix to your inbound queue. Most MSPs let priority drift to whatever the user typed in the subject line. With a skill driving it, every ticket gets classified the same way, security signals automatically bypass the matrix, and the engineer gets a drafted first response they can paste straight into the PSA. You’ll find it catches the “third password reset this week” pattern and quietly suggests a root-cause review — the kind of thing a good Tier 2 engineer does naturally and a stretched team often misses.

License rightsizing is the easiest commercial conversation you’ll have all year. Almost every tenant carries 10–25% waste — disabled accounts still licensed, E5 users who haven’t opened a Power BI report in a year, shared mailboxes nobody downgraded after the staff member left. The skill pulls full license inventory and sign-in history through Graph, applies a rule set, and produces a numbered list of decisions for the client with a dollar value next to each. Run it before every renewal. Run it again three months later.

Security baseline check is the one I’d implement first if I were starting fresh. Pick a standard — Essential Eight, CIS Microsoft 365 Foundations, or your own house baseline — and let the skill walk through every control. Conditional Access posture, MFA coverage, DMARC, Intune compliance, backup test recency. Each control gets a Pass, Partial, or Fail with cited evidence. The deliverable isn’t a Secure Score screenshot. It’s a 90-day remediation plan with named owners and real dates. That’s what survives an audit.

How to actually roll this out

Don’t try to deploy all seven at once. That’s how good initiatives die in busy MSPs.

Pick the one that hurts most this month. For most teams, that’s either ticket triage or QBR prep. Run it manually for a fortnight — meaning, your senior engineer literally walks through it for every relevant case and notes the spots where the prompt needs more local detail. Add your tier names, your SLA wording, your house security baseline, the SKUs you actually sell, the language your clients respond to.

Store the skill files where your team can edit them. Treat them like internal documentation — versioned, reviewed, owned by a named person. A skill nobody updates is a skill that quietly stops matching how the business actually works, and then it starts producing confidently wrong output, which is worse than no skill at all.

Keep a human in the loop on every customer-facing or change-making step. None of these skills should send a client email, remove a license, or modify a Conditional Access policy without explicit review. The aim is to make the engineer faster and more consistent — not to remove the engineer from the decision.

And track the saves. The first time the QBR skill cuts your prep from six hours to two, write that number down. The first time the rightsizing skill finds $4,000 a year of waste in a client’s tenant, write that down too. Those numbers are what you’ll show your team when you ask them to maintain the next skill, and what you’ll show your accountant when they ask why the Copilot licenses were worth it.

7 example skills MSPs could drop into their own setup. Each one targets a real, recurring pain point. They are located in my Github repo here – https://github.com/directorcia/Office365/tree/master/Cowork-Skills

client-onboarding.mdStandardizes the first 30 days of a new MSA — kickoff pack, technical checklist, recurring touchpoints

qbr-prep.mdBuilds a defensible Quarterly Business Review pack — service scorecard, security posture, license optimization, roadmap

ticket-triage.mdApplies a consistent Impact × Urgency framework to the support queue, drafts first responses

incident-comms.mdDrafts every stage of outage comms — initial notification, hourly updates, all-clear, post-incident review

license-rightsizing.mdFinds unused, oversized, and duplicated M365 licenses and quantifies the savings

security-baseline-check.mdRuns an Essential Eight / CIS / house-baseline gap analysis and stages remediation

employee-onboarding.mdProvisions a new starter end-to-end — identity, licenses, devices, Day-1 experience

Each follows the same SKILL.md structure (frontmatter + when-to-use, inputs, workflow, guardrails, done-when), so they should slot straight into a personal skills folder. They’re all in your output folder ready to download. See this post:

https://blog.ciaops.com/2026/04/23/creating-custom-copilot-cowork-skills-that-actually-matter-for-smbs/

for more information about implementing Microsoft 365 Copilot Cowork skills in your own environment.

What’s available natively in Microsoft 365

The skills can pull directly from:

  • Microsoft 365 via Graph — mailboxes, calendar, Teams chats, SharePoint/OneDrive files, people directory, sign-in activity, license assignments, Conditional Access policies, Secure Score

  • Web search — vendor status pages, public DNS lookups, pricing references

  • Files the user uploads — exports from other systems dropped into the workspace

  • Ask User Question — anything the user can answer

Mapped per skill

client-onboarding – New client details, tenant info User input + Graph for tenant/domain verification. Mostly user-driven.

qbr-prep – Tickets, patch %, backup status, licenses, Secure Score

Mixed — Secure Score and licenses come from Graph; tickets, patch, backup need exports from your PSA/RMM/backup tools because there’s no MCP connector for ConnectWise/Halo/NinjaOne/Datto today.

ticket-triage – A list of open tickets. Currently the user pastes them in or drops a CSV export. No live PSA integration.

incident-comms – Outage facts, vendor status. User input for the facts; web search for vendor status pages.

license-rightsizing – License inventory, last sign-in, mailbox state. Almost entirely Graph API — this one works end-to-end with what’s available.

security-baseline-check – CA policies, MFA stats, DMARC, Intune compliance, Secure Score .Mostly Graph — CA, MFA, Secure Score, Intune all reachable. DMARC needs a DNS lookup (web search workaround).

employee-onboarding – Role template, manager, license SKU. User input + Graph to actually create the user, assign groups, license.

The honest gap

The MSP-specific data sources — PSA, RMM, EDR consoles, third-party backup, documentation platforms (IT Glue / Hudu) — don’t have native connectors here. Skills that need them currently fall back to:

  1. The user pasting an export

  2. Dropping a CSV/XLSX into the workspace

  3. The skill explicitly flagging “data not available, please provide”

Two practical paths forward if you want these to be more autonomous:

  • Short term: each skill assumes a standard export format (e.g., “drop your PSA ticket CSV with these columns”) and works from that.

  • Longer term: a custom MCP connector for the PSA/RMM in your stack — that’s where it becomes genuinely hands-off.

What to do next

The hard part of running an MSP has never been the technology. It’s been keeping a team of busy people doing the right thing the same way every time. Codified Copilot skills are the closest thing I’ve seen to a real answer to that — and they finally put the data already sitting in your clients’ tenants to work.

Pick one. Write it down. Run it for a week. See what changes.

The Question That Tells You What to Fix Next

image

There’s a deceptively simple question I keep coming back to when I talk to business owners, especially MSPs:

Am I demand constrained, or supply constrained?

In plain English:
Is your biggest problem “I can’t get enough clients”?
Or is it “If I had more clients, things would break”?

Most people think they know the answer. Many are wrong. And a surprising number have never stopped long enough to ask the question properly.

This matters, because these are two very different problems. Confuse them, and you’ll work very hard on the wrong thing.

Demand constrained: not enough clients

If you’re demand constrained, your bottleneck is sales and marketing. The phone isn’t ringing. Leads are inconsistent. Referrals have slowed. You’ve got capacity sitting idle.

The giveaway signs are obvious once you’re honest with yourself:

  • You (or your team) have time on your hands

  • Onboarding a new client feels exciting, not stressful

  • You’re discounting, chasing, or “just seeing what happens”

  • You spend more time tweaking services than talking to prospects

In this mode, polishing internal processes is mostly procrastination. Perfecting your PSA workflows or rewriting your SOPs for the fifth time won’t magically create demand. Neither will buying another tool “just in case”.

The uncomfortable truth?
If you’re demand constrained, you need to work on being seen, being clear, and being chosen.

That usually means:

  • Sharpening your message so people know exactly who you help

  • Saying no to being “everything to everyone”

  • Talking to customers and prospects more than your tools

  • Getting comfortable with selling, not hiding behind tech

Demand problems are uncomfortable because they expose mindset issues. Fear of rejection. Fear of being visible. Fear of being judged. That’s why so many business owners avoid them and retreat into “busy work”.

Supply constrained: growth would hurt

If you’re supply constrained, demand isn’t the problem. You could sell more. In fact, you probably already are. The issue is that growth feels fragile.

Adding one more client means:

  • Response times slip

  • The same fires keep reappearing

  • Only a few people really know how things work

  • You’re the bottleneck for decisions, approvals, or fixes

This is where things get dangerous. From the outside, the business looks successful. Revenue is up. The pipeline is full. But internally, it’s held together with duct tape and heroics.

If you’re supply constrained and you push harder on sales, you don’t get leverage — you get burnout.

This is the stage where “working harder” finally stops working.

The fix here isn’t more leads. It’s leverage.

That usually means:

  • Documented, repeatable ways of delivering outcomes

  • Fewer services, done better, not more options

  • Clear standards instead of tribal knowledge

  • Letting go of being the smartest person in every room

Supply constraints force you to confront control issues. If everything depends on you, growth will always feel unsafe.

The trap: fixing the wrong constraint

The real danger is misdiagnosis.

I regularly see MSPs who feel supply constrained, but are actually demand constrained. They blame process, tools, or staff when the real issue is inconsistent sales. So they over-engineer systems for a scale that never arrives.

I also see the opposite: businesses with strong demand that keep pushing sales harder, hoping revenue will magically fix operational cracks. It doesn’t. It just widens them.

Revenue hides problems. Scale reveals them.

You can’t outgrow a broken delivery model. And you can’t systemise your way out of obscurity.

Constraints change — your focus must too

Here’s the part most people miss:
Constraints move.

Early on, you’re almost always demand constrained. Later, if you do things right, you become supply constrained. That’s not failure — that’s progress.

The mistake is clinging to last year’s strategy because it once worked.

What got you from zero to one won’t get you from one to ten.

This is why the most successful business owners spend more time working on themselves than on their business. They’re constantly reassessing where the real bottleneck is — and adjusting their behaviour accordingly.

Not chasing shiny tactics. Not copying someone else’s playbook. But doing the honest internal work.

Ask the question. Answer it honestly.

So ask yourself, properly:

  • If I doubled my leads tomorrow, would things improve or collapse?

  • Where do I personally spend time because “it’s quicker if I do it”?

  • What problem am I avoiding because it feels uncomfortable?

There is always a constraint. The job isn’t to eliminate it — it’s to identify it and work on the right thing at the right time.

Growth isn’t about doing more.
It’s about fixing what’s actually in the way.

And that starts with asking the right question.

The Coach Won’t Just Give You a Strategy. They’ll Give You a Mirror.

image

Most MSPs don’t have a strategy problem.

They have a self‑awareness problem.

If you’re honest, you already know what needs fixing in your business. You know which services are messy. You know where margins are leaking. You know which clients drain energy, which staff issues you’ve been avoiding, and which “temporary” workarounds have somehow become permanent.

What’s missing isn’t another framework, playbook, or shiny roadmap.

What’s missing is someone who will hold up a mirror and make you look at yourself.

That’s the real value of a coach.

Strategy Is the Easy Part

Every MSP conference, podcast, and LinkedIn post is overflowing with strategy.

  • Productise your services

  • Standardise your stack

  • Raise your prices

  • Niche down

  • Automate more

  • Hire better

  • Delegate sooner

None of this is new. None of it is secret.

Yet many MSPs stay stuck for years, implementing some of it, occasionally, when things calm down. Spoiler: things never calm down.

The issue isn’t that you don’t know what to do.

It’s that strategy doesn’t force behaviour change.

A mirror does.

The Mirror Is Uncomfortable (That’s the Point)

A good coach doesn’t just say, “Here’s what successful MSPs do.”

They say things like:

  • “Why are you still approving every invoice?”

  • “Why do you keep saying you want scale, but act like a firefighter?”

  • “Why are you blaming the team when you won’t let go of control?”

  • “Why are you still selling bespoke work when you claim to want freedom?”

That’s not advice. That’s reflection.

And reflection is confronting because it removes your favourite excuses.

You can’t hide behind tools, vendors, or market conditions when someone calmly points out that you are the bottleneck.

MSPs Don’t Stall Because of Technology

MSPs stall because of identity.

At some point, the skills that made you successful become the very things holding you back:

  • Being the best tech

  • Being the fixer

  • Being indispensable

  • Being the hero

Letting go of that isn’t a technical challenge. It’s an emotional one.

A coach doesn’t replace your thinking. They expose the gaps between what you say you want and how you actually behave.

That’s why coaching feels different from consulting.

A consultant gives answers.

A coach asks questions you’ve been avoiding.

You Can’t Out‑Learn a Behaviour Problem

Many MSPs respond to discomfort by learning more.

Another course.
Another book.
Another certification.
Another vendor demo.

Learning feels productive, but it’s often just procrastination in disguise.

A coach cuts through that by asking, “What are you going to do differently this week?”

Not next quarter. Not after the next hire. Not when the tool is fully deployed.

This week.

And then they remember what you said last time.

That accountability is the mirror.

Growth Starts With Brutal Honesty

The MSPs that grow sustainably aren’t smarter than everyone else.

They’re more honest.

Honest about their time.
Honest about their energy.
Honest about what they enjoy.
Honest about what they’re avoiding.

A coach helps you see patterns you’re too close to notice. Patterns in how you lead, sell, hire, and react under pressure.

That’s not comfortable work.

But it’s the work that actually changes outcomes.

If You’re Feeling “Stuck”, Look Inward First

If your MSP feels stalled, chaotic, or heavier than it should, don’t immediately look for a new strategy.

Look for a mirror.

Ask yourself:

  • Where am I the constraint?

  • What am I protecting that no longer serves the business?

  • What hard decision have I been delaying?

A coach won’t magically fix your MSP.

But they will help you see it — and yourself — clearly.

And clarity beats strategy every time.

“No” Is a Complete Sentence (And a Bloody Good MSP Strategy)

image

The most successful MSP owners I know aren’t superhuman.

They don’t have more hours in the day.
They don’t wake up at 4:30am to journal, ice-bathe, and manifest ARR.
They’re not running some secret productivity stack you’ve never heard of.

What they have done is get brutally honest about one uncomfortable truth:

Every yes has a price.

And once you see that clearly, you start saying no. A lot.

Not because you’re lazy.
Not because you don’t care.
But because you finally understand that attention is your scarcest resource.

The Hidden Cost of “Sure, Why Not”

MSPs are especially bad at this.

We say yes to:

  • “Can you just jump on a quick call?”

  • “Can you have a look at this while you’re here?”

  • “This could turn into something big…”

  • “We’ve always done it this way for this client.”

Each one feels harmless in isolation.
Collectively, they’re lethal.

That “quick call” blows out to 45 minutes.
That “small favour” turns into ongoing unpaid support.
That “opportunity” drags you sideways for six months with nothing to show for it.

And suddenly you’re busy all day… but somehow still stuck.

Busy is not the same as effective.

Why the Best MSP Owners Say No More Than Yes

The sharpest operators I know have made peace with disappointing people.

They say:

  • No to meetings that could have been an email.

  • No to shiny tools dressed up as “game changers”.

  • No to custom work that doesn’t scale.

  • No to clients who drain energy, margin, and morale.

  • No to doing work outside their chosen lane.

Not aggressively.
Not rudely.
Just calmly. Clearly. Consistently.

Because they understand something most MSPs don’t learn until burnout hits:

Every yes you give is a no to something else.

A yes to low-margin work is a no to building IP.
A yes to reactive firefighting is a no to strategic services.
A yes to everyone else’s priorities is a no to your own.

“No” Is How You Protect the Work That Matters

Here’s the uncomfortable bit.

Most MSPs don’t have a time problem.
They have a boundary problem.

They haven’t decided:

  • What kind of MSP they actually want to be

  • Who they are not for

  • What work they will never do again

  • What a “hell yes” client looks like

Without those decisions, everything feels equally urgent.
And when everything is urgent, nothing is important.

Saying no forces clarity.

It forces you to choose:

  • Productised services over bespoke chaos

  • Fewer better clients over more mediocre ones

  • Depth over breadth

  • Long-term leverage over short-term busyness

That’s not easy. But it’s necessary.

The Myth of the Missed Opportunity

MSPs are plagued by FOMO.

“What if this client becomes huge?”
“What if this product takes off?”
“What if I say no and regret it?”

Here’s the reality:
Most opportunities aren’t opportunities. They’re distractions.

The real risk isn’t missing out.
It’s being spread so thin you never execute properly on anything.

Focus compounds.
Fragmentation exhausts.

The MSPs that win aren’t chasing everything.
They’re doubling down on a few things and executing them relentlessly well.

How to Say No (Without Being a Jerk)

You don’t need a speech.
You don’t need a justification essay.

You need a default posture.

  • “That’s not something we offer.”

  • “This isn’t aligned with how we work.”

  • “We’re at capacity for that right now.”

  • “That sits outside our support model.”

Full stop.

No over-explaining.
No apologies for having a business model.
No discounting your own time to make others comfortable.

Professional boundaries increase respect. They don’t reduce it.

Final Thought

“No” isn’t negativity.

It’s prioritisation.
It’s maturity.
It’s leadership.

If you want a clearer business, a calmer head, and work that actually moves the needle, start here:

Say no to the noise.
Say no to the drains.
Say no like you mean it.

Because on the other side of all those no’s
is the space to build something that actually matters.

And that’s not just a mindset shift.

That’s a business strategy.

The Quiet Shame We Don’t Talk About in MSPs

image

Let’s talk about something uncomfortable.

Not ransomware.
Not margins.
Not Microsoft licensing.

Shame.

Most MSPs I speak to carry some form of business shame. Quiet, private, often unspoken. It’s the thing you don’t put on your website. The thing you hope no one asks too many questions about. The thing you keep tolerating because “we’ll fix it later”.

And “later” never comes.

Maybe it’s your internal documentation. You know it’s a mess. Half-written KBs, outdated screenshots, tribal knowledge locked in one senior tech’s head. You keep telling yourself you’ll clean it up “when things slow down”. They never do.

Maybe it’s that half‑finished project. A security uplift. A standardisation initiative. A proper onboarding process. You started strong, then client work got busy, fires popped up, and now it’s sitting there like an abandoned renovation — expensive, unfinished, and quietly mocking you.

Or maybe it’s you.

Your calendar is chaos. You’re still the escalation point for everything. You know deep down that the business relies too heavily on your heroics rather than good systems. You tolerate it because you’re capable, because clients like you, because it’s easier than changing.

But here’s the hard truth.

What you tolerate is what you choose.

If something in your business causes you embarrassment, frustration, or a knot in your stomach every time you think about it — that’s a signal. Not a failure. A signal.

What Have You Been Tolerating for Too Long?

Ask yourself honestly:

  • What do I avoid looking at?

  • What do I explain away with “that’s just how we do things here”?

  • What would I be embarrassed to show another MSP owner?

That’s your shame point.

And no, this isn’t about beating yourself up. MSPs are hard. Growth is messy. Most of us built our businesses reactively, not from some perfectly designed playbook.

But ignoring the shame doesn’t make it go away. It just makes it normal.

Now Flip the Question

Instead of asking “Why is this still broken?”, ask:

“What would this look like if I was genuinely proud of it?”

Not “acceptable”.
Not “good enough”.
Proud.

What would that neglected project look like if it actually reflected your standards?

  • Properly scoped

  • Properly finished

  • Properly documented

  • Properly embedded into how the business runs

What would change if you decided that this thing was no longer allowed to be embarrassing?

Here’s the interesting part: you already know the answer.

You know what needs to be done. You know the next step. You’ve probably written it down three times already.

What’s missing isn’t knowledge. It’s permission.

Permission to slow down briefly so you can speed up later.
Permission to say no to new work while you fix the foundations.
Permission to stop tolerating something that’s draining energy every single week.

Pride Is a Business Strategy

The MSPs that last — the ones that scale, that attract good staff, that don’t burn out their owners — they work on the unsexy stuff.

They finish projects.
They close loops.
They turn shame into systems.

Not because it’s fun, but because pride compounds.

When you’re proud of how something is built, you maintain it. You protect it. You improve it. And that pride quietly leaks into everything else — culture, delivery, confidence.

So here’s your challenge.

Pick one thing you’ve been tolerating too long.

Just one.

Decide what “I’d be proud of this” actually looks like.

Then take the first uncomfortable step towards finishing it properly.

You don’t need to fix everything.

But you do need to stop pretending that the shame isn’t there.

Because the moment you turn and face it, it loses most of its power.

And that’s where real progress starts.

3 Ready‑to‑Use Copilot Cowork SKILL.md Examples for MSPs

3 Ready-to-Use Copilot Cowork SKILL.md Examples for MSPs

image


Below are three practical, production‑ready Copilot Cowork custom skills designed specifically for MSP use cases.
Each skill follows Microsoft’s supported structure:
YAML frontmatter (name, description) followed by Markdown instructions,
and is intended to live in:

/Documents/Cowork/Skills/<skill-name>/SKILL.md


Copilot Cowork automatically discovers these skills at the start of each conversation.
Each one targets repeatable, high‑value MSP workflows rather than one‑off prompts.


1) MSP Client Monthly Executive Summary (QBR‑lite)

Folder: /Documents/Cowork/Skills/msp-client-exec-summary/
File: SKILL.md

---
name: MSP Client Executive Summary
description: Creates a monthly executive summary for an MSP client using M365 activity evidence (emails, meetings, files) and a consistent MSP-friendly format.
---

## Purpose
Produce a client-ready monthly executive summary (QBR-lite) that is consistent, factual, and easy for non-technical stakeholders to read.

## Inputs to request (ask if missing)
1. Client name (exact)
2. Reporting period (e.g., "March 2026")
3. Where client artefacts live (SharePoint site / Teams name / OneDrive folder path)
4. Any key initiatives/projects to include (list)
5. Any sensitive exclusions (e.g., "do not mention incident details")

## Data gathering rules
- Prefer evidence from Microsoft 365 content: emails, meeting notes, and files in OneDrive/SharePoint.
- Use only artefacts the user has access to.
- If you can’t find evidence for an item, mark it as “No supporting evidence found in M365 sources provided”.

## Output format (Word document)
Create a Word document titled:
"Executive Summary - <Client> - <Reporting Period>"

Use these sections and headings exactly:

1. Headline Summary (5 bullets max)
   - Outcomes delivered (business language)
   - Risks/issues (non-alarmist)
   - Decisions needed from client (if any)

2. Service Health Snapshot
   - Identity & access notes
   - Device management posture
   - Security themes at a high level

3. Work Completed (Outcomes, not tasks)
   - Outcome
   - Evidence reference
   - Business value

4. Open Items & Blockers
   - What’s stuck
   - Who owns it
   - Next trigger/date

5. Recommendations for Next Month
   - 3–5 pragmatic recommendations
   - Include effort (S/M/L) and impact (Low/Med/High)

6. Appendix: Evidence List
   - Files, meetings, and email subjects used

## Tone & constraints
- Australian English.
- No vendor hype.
- Client-safe wording only.


2) MSP Incident Communications Pack

Folder: /Documents/Cowork/Skills/msp-incident-comms-pack/
File: SKILL.md

---
name: MSP Incident Comms Pack
description: Drafts an MSP incident communications pack (client update + internal summary + next-steps checklist) with approval-safe wording.
---

## Purpose
Create consistent, calm, defensible communications during an incident.

## Inputs to request (ask if missing)
1. Client name
2. Incident label (short)
3. Timeline of events
4. Confirmed facts vs suspected items
5. Client audience
6. Desired update cadence

## Data gathering rules
- Use M365 artefacts only (emails, meetings, Teams messages, files).
- Do not invent technical detail.
- Ask for clarification where facts are missing.

## Outputs
### A) Client Update Email (Outlook draft)
Subject:
"Update: <Client> - <Incident> - <Date>"

Include:
- What we know
- What we’re doing
- What we need from the client
- Next update timing

### B) Internal Technician Summary (Teams)
- Incident label + severity
- Current status
- Owner and next actions
- Links to evidence

### C) Next-Steps Checklist (Word)
Include:
1. Containment
2. Investigation
3. Recovery
4. Communications
5. Post-incident follow-up

## Tone & constraints
- Calm, factual, non-alarmist.
- Australian English.
- No blame, no absolutes.


3) MSP Onboarding Kickstart Pack (SMB‑friendly)

Folder: /Documents/Cowork/Skills/msp-onboarding-kickstart-pack/
File: SKILL.md

---
name: MSP Onboarding Kickstart Pack
description: Creates an MSP onboarding pack including welcome email, onboarding schedule, folder structure, and checklists.
---

## Purpose
Deliver a consistent, professional first-30-days onboarding experience for SMB clients.

## Inputs to request (ask if missing)
1. Client name and primary contact
2. Services in scope
3. Target go-live date
4. Preferred meeting times
5. Tenant state (new or existing)

## Outputs
### A) Welcome Email (Outlook draft)
Include:
- Week 1 expectations
- Required client inputs
- Communication model
- Links to onboarding artefacts

### B) Onboarding Plan (Word)
Title:
"Onboarding Plan - <Client> - First 30 Days"

Break down by week:
- Meetings
- Deliverables
- Dependencies

### C) Folder Structure
Create or propose:
- 01 - Commercial & Contacts
- 02 - Tenant Baseline
- 03 - Security & Compliance
- 04 - Devices & Intune
- 05 - Documentation & SOPs
- 06 - Projects
- 07 - Reports

### D) Onboarding Checklist (Word)
Include:
- Identity baseline
- Device enrolment
- Security configuration
- Documentation completion
- Client sign-off points

## Rules
- Step-by-step.
- SMB-realistic (no enterprise bloat).
- Australian English.



Implementation reminder:
Each skill must live in its own folder under /Documents/Cowork/Skills/,
must be named SKILL.md, and should have a specific description so Cowork knows when to load it.