Experience builds ideas. Insecurity borrows them.

image

There’s a clear line between people who are doing the work and people who are just talking about it.

You don’t need a title or a following to spot the difference. You see it in how they speak, not how loudly.

People with real experience tend to build their own thinking. It’s imperfect, occasionally blunt, and often inconvenient. It comes from trying things, getting them wrong, adjusting, and doing it again. Their ideas are shaped by reality.

Everyone else tends to borrow.

They echo whatever message is trending. They swap a few words, add a diagram, and pass it off as insight. Same advice, different branding. No scars. No evidence. No ownership.

Doing the work changes your language

When you’ve actually implemented something—whether that’s a security framework, a new service offering, or AI inside a business—you stop speaking in absolutes.

You don’t say “this will change everything”.
You say “this worked here, under these conditions”.

You don’t promise miracles. You talk about trade-offs.

That shift only happens when you’ve been responsible for the outcome. When you’ve had to answer the awkward questions. When you’ve watched users ignore the thing that looked perfect in a slide deck.

That’s why experience produces original thinking. It can’t help it.

The AI gold rush has exposed the gap

AI has made this divide painfully obvious.

Right now, it’s easy to generate confident-sounding content without having touched a real deployment. Tools can produce posts, prompts, courses, and “frameworks” at scale. The barrier to publishing has collapsed.

The barrier to credibility hasn’t.

Most AI commentary falls into the same bucket:

  • Vague promises

  • Recycled examples

  • Zero mention of friction

Very little of it answers the questions businesses actually ask:

  • Why didn’t staff use it?

  • What broke when permissions were wrong?

  • Where did the time savings not appear?

  • What did we stop doing to make this work?

Those answers only come from hands-on work. You can’t fake them convincingly for long.

MSPs live or die on credibility

This matters even more for MSPs and IT pros.

Our job isn’t to repeat vendor messaging. It’s to interpret reality for customers. That means filtering hype, testing claims, and sometimes saying “not yet” or “not like that”.

The strongest MSPs I know don’t rush to publish hot takes. They pilot first. Internally. With a handful of customers. They watch what actually happens, then they form a point of view.

When they speak, it sounds different. Less polished. More grounded. More useful.

That’s not an accident. That’s earned.

Borrowing ideas is safe. Creating them isn’t.

Borrowing someone else’s thinking feels low-risk. If it doesn’t land, you can shrug and move on. You were just sharing something interesting.

Creating your own position is riskier. It invites disagreement. It exposes what you don’t know yet. It ties your name to an outcome.

But that’s also where authority comes from.

Not from being first. Not from being loudest. From being responsible.

Ask yourself the harder question

Before publishing, presenting, or advising, it’s worth pausing and asking:

Am I speaking from repetition, or from experience?

Have I tested this, or just read about it?

Would I still hold this view if the tool, platform, or trend disappeared tomorrow?

If the answer is uncomfortable, that’s probably a signal—not to stop sharing, but to go deeper. To build something. To test something. To get closer to the work.

Because in the long run, people don’t follow confidence. They follow clarity. And clarity comes from contact with reality, not from copying what’s already out there.

That’s how real ideas are formed. And that’s what makes them worth listening to.

Progress Is Quiet. That Doesn’t Mean It Isn’t Working.

image

One of the hardest things to accept in business—and in life—is that real progress is mostly invisible.

We’re conditioned to look for obvious signals. Big wins. Public milestones. Announcements, launches, applause. If none of that is happening, it’s easy to assume we’re stuck. Or worse, going backwards.

But that’s not how meaningful progress actually works.

Every problem you solved before it became a crisis.
Every decision you didn’t rush just to feel productive.
Every shiny “opportunity” you said no to because it wasn’t aligned.

That’s progress. Quiet progress. The kind that happens in the background while no one is watching.

In MSPs and IT businesses, this shows up all the time. You harden security instead of chasing a new tool. You standardise processes instead of custom‑building for every client. You invest time learning Copilot properly instead of posting another “AI will replace us” hot take on LinkedIn.

None of that feels exciting in the moment. It feels slow. Boring, even. And because there’s no immediate payoff, the temptation is to assume those are “lost days”.

They’re not.

Those slow days are doing the heavy lifting. They’re building the foundation that lets everything else scale later—reliably, profitably, and without burning you out.

The problem is that we often misdiagnose what’s missing. We assume we need a better routine. A new framework. A clever hack. Another app, another system, another morning ritual.

Most of the time, that’s not the issue.

The issue is trust.

Trust that the work you’re doing—when it’s deliberate and aligned—actually compounds. Trust that saying no is as powerful as saying yes. Trust that progress doesn’t need to announce itself to be real.

This is especially true with long‑term capability building. Training staff properly. Improving documentation. Fixing fundamentals. Learning how to use tools like Microsoft Copilot effectively instead of dabbling and moving on.

There’s no dopamine hit for that. No instant validation. Just steady, unglamorous effort.

But it adds up.

And one day, usually without warning, things feel easier. Decisions get clearer. Results come faster. Other people start calling it “overnight success”.

It wasn’t overnight. You just did the work when no one was clapping.

So if today feels slow, that doesn’t mean it’s wasted. If it feels like you’re laying bricks instead of building towers, that’s exactly how it’s supposed to feel.

You don’t need to overhaul everything.
You don’t need a new system.
You don’t need to panic‑pivot.

You just need to keep going.

Trust the work. It’s adding up—even when you can’t see it yet.

Prospects don’t buy in straight lines, so stop trying to force them down one

image

Most marketing is built on a comforting lie.

That lie is the “nice, neat funnel”.

Awareness.
Consideration.
Decision.
Purchase.

It looks logical. It’s easy to diagram. It makes marketers feel in control.

And it’s almost completely divorced from how people actually buy.

Prospects don’t move in straight lines. They loop, stall, disappear, reappear, second‑guess themselves, ask peers, ignore you for months, then suddenly act. If your marketing assumes linear progress, you’re not guiding buyers—you’re frustrating them.

The problem isn’t your funnel. It’s your assumptions.

Most marketing is designed around how we wish people bought:

  • Read the blog

  • Download the guide

  • Book the call

  • Buy the service

But real buyers don’t behave like that. Especially in B2B. Especially in IT.

An MSP prospect might:

  • Hear about you on LinkedIn

  • Ignore you for six months

  • Get hit with a security incident

  • Ask a peer in a WhatsApp group

  • Re‑read a blog they skimmed months ago

  • Watch half a webinar

  • Then finally reach out—already 80% decided

If your marketing only supports one “next step”, you lose relevance the moment they step off your rails.

People buy when their timing aligns, not when your campaign says so

This is where most MSP marketing falls apart.

You’re pushing:

  • “Book a call”

  • “Act now”

  • “Limited time offer”

While the buyer is thinking:

  • “I need to understand this better”

  • “Is this actually a problem for me?”

  • “What happens if I do nothing?”

Forcing urgency doesn’t create trust. It creates resistance.

Good marketing doesn’t push people forward. It removes friction wherever they are.

What non‑linear marketing actually looks like

If people don’t buy in straight lines, your marketing shouldn’t either.

That means:

  • Content that stands alone (not “part 3 of 7”)

  • Clear explanations without requiring prior context

  • Repeated ideas from different angles, not “new for the sake of new”

  • Easy re‑entry points for people who went quiet

It also means accepting that most prospects will consume far more content than you’ll ever see evidence of.

They’re watching. Reading. Lurking. Evaluating.

Silence does not mean disinterest.

Design for the buyer’s journey, not your sales process

Your sales process is internal. Your buyer’s journey is not.

When you design marketing around your CRM stages, you optimise for reporting—not conversion.

Instead, ask:

  • What questions are buyers asking before they talk to us?

  • What objections do they have that they’re not voicing?

  • What would make them feel smarter, safer, or more confident right now?

Answer those questions—over and over—without demanding anything in return.

Stop trying to control the path

Marketing isn’t about herding people down a funnel.

It’s about being present, useful, and credible whenever the buyer decides to engage.

So stop marketing the way you wish people bought.

Start marketing the way people actually buy: Messy. Non‑linear. On their own timeline.

Your job isn’t to force the journey.

It’s to make sure you’re still relevant when they finally decide to move.

If I had fun, it’s sustainable. And that’s the real game.

image

Most MSPs I speak to are exhausted.

They’re exhausted from chasing the next tool, the next framework, the next silver bullet that’s meant to “fix” their business. They’re exhausted from content they feel obligated to create, services they feel pressured to offer, and noise they feel they must contribute to just to stay relevant.

So let me offer a much simpler filter. One that’s kept me sane, productive, and moving forward for a long time.

If I had fun, it’s sustainable. I’ll do it forever.
If it’s useful, I’m adding value, not contributing to the noise.
If I learn something, it’ll get better and better.

Do those three things consistently and, over the long term, you cannot lose.

Fun isn’t fluff — it’s fuel

“Fun” gets a bad rap in business. It’s often dismissed as unprofessional or indulgent. But fun isn’t about mucking around. Fun is energy. It’s momentum. It’s the difference between something you force yourself to do and something you keep coming back to.

If you dread writing content, you won’t do it consistently.
If you hate delivering a service, you’ll eventually resent your customers.
If you’re bored by your own business, burnout is guaranteed.

Sustainability doesn’t come from discipline alone. It comes from enjoyment. The things you genuinely enjoy are the things you’ll refine, improve, and stick with when motivation dips — and it always does.

MSPs who last aren’t the ones who “work the hardest”. They’re the ones who build a business they don’t secretly want to escape from.

Useful beats loud. Every time.

The internet doesn’t need more hot takes, recycled vendor slides, or AI‑generated waffle pretending to be insight.

Your customers don’t need more noise either.

Useful content and services do one thing well: they help someone move forward. They answer a real question. They reduce confusion. They remove friction. They save time, money, or stress.

That’s value.

If what you’re producing wouldn’t genuinely help one of your own customers tomorrow, stop. Don’t publish it. Don’t sell it. Don’t build it just because “everyone else is”.

Being useful compounds. Noise disappears.

Learning is the unfair advantage

Here’s the part most people miss.

When you’re having fun and being useful, learning becomes automatic.

You notice gaps.
You spot patterns.
You refine your thinking.

Each iteration gets slightly better than the last. Your writing improves. Your delivery sharpens. Your positioning clarifies. Your confidence grows — not from hype, but from competence.

This is how authority is actually built. Not by claiming expertise, but by accumulating it through repetition and reflection.

MSPs who keep learning don’t panic when tools change. They understand principles. They adapt faster because they’ve already done the thinking.

Consistency beats optimisation

Everyone wants the “right” strategy. The perfect offer. The ideal funnel.

But long‑term success doesn’t come from perfect planning. It comes from consistent execution guided by simple rules.

Ask yourself:

  • Did I enjoy doing this?

  • Did it genuinely help someone?

  • Did I learn something along the way?

If the answer is yes to all three, keep going. You’re on the right path.

You don’t need to win today. You just need to avoid losing over time.

And if you build a business where you’re having fun, adding value, and getting better every iteration?

That’s not just sustainable.

That’s unstoppable.

Why So Many MSPs Never Scale (And It’s Not the Market)

image

TONS of businesses never scale, and it’s rarely because the market is too competitive, margins are too thin, or clients are too demanding.

Most of the time, it’s because the owner can’t get a grip on their own issues.

In the MSP world, this shows up in a very specific way: the owner sees themselves AS the business.

Not running the business.
Not owning the business.
But being the business.

And that’s where scaling quietly dies.

When You Are the Business, Everything Is Personal

If your identity is welded to your MSP, every problem hits harder than it should.

A client complaint isn’t feedback — it’s an attack.
A staff mistake isn’t a process gap — it’s proof you’re failing.
A slow month isn’t normal variance — it’s existential panic.

So what happens?

You micromanage.
You hoard decisions.
You jump back into tech work “just to be safe”.
You delay hiring because no one can do it “as well as you”.

From the outside, it looks like dedication.
From the inside, it’s fear dressed up as responsibility.

And fear does not scale.

Separation Is the First Real Growth Lever

The moment things start to change is when you separate who you are from what your business does.

This isn’t about being cold or detached.
It’s about creating space.

When your MSP is something you own — not something you are — a few important things happen:

• You ride highs and lows better
• You think more calmly
• You make better decisions

Why? Because problems stop being personal.

A bad quarter becomes a data point.
A client loss becomes a signal.
A broken process becomes… a process to fix.

Not a judgement on your worth.

That emotional distance is not weakness. It’s leverage.

Calm Thinking Beats Heroic Effort Every Time

Most MSP owners think scaling is about working harder, being smarter, or “just pushing through”.

In reality, scaling is mostly about not panicking.

Panicked businesses make short‑term decisions:

  • Discounting to win the wrong clients

  • Delaying price rises they know are overdue

  • Overloading good staff because hiring feels risky

  • Chasing every opportunity instead of choosing the right ones

Calm businesses do the opposite.

They design roles instead of reacting to gaps.
They document because they expect people to follow systems.
They invest because they’re planning for the future, not bracing for impact.

Calm comes from separation. Separation comes from identity clarity.

Scarcity Is an Identity Problem

Here’s the uncomfortable truth: most “scaling problems” are actually scarcity problems.

And scarcity almost always lives in the owner’s head.

If you believe:

  • “Clients are hard to replace”

  • “Good staff are impossible to find”

  • “If I stop doing this myself, it will fall apart”

Then every decision is defensive.

But when you stop seeing your MSP as a reflection of you, something shifts.

You start approaching growth from abundance instead of panicked scarcity.

You realise:

  • Clients come and go — systems remain

  • Staff are attracted to clarity, not chaos

  • Your job is to build the machine, not be the machine

That’s when scaling stops being stressful and starts being strategic.

The Business Is the Product — Not You

If your MSP can’t function without your constant presence, you don’t have a business. You have a very demanding job.

Real scale begins when the business becomes something that can be observed, improved, and grown — independently of your mood, energy, or ego.

Detach your identity.
Build with intention.
Lead with calm.

That’s how MSPs actually scale.

Not louder.
Not faster.
But clearer.

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.