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.

You’ll Never Win Playing a Game That’s Rigged for Someone Else

image

You’ll never win playing a game that’s rigged for someone else to win.

Of course it feels hard. Of course it feels unfair. That’s because it is.

The problem isn’t that you’re bad at the game.
The problem is that you’re playing their game.

Most MSPs are exhausted not because they’re lazy, unskilled, or unlucky — but because they’ve bought into a model that was never designed to let them win. The race to the bottom on price. The endless bundle of “all you can eat” support. The expectation that you’ll absorb risk, complexity, and compliance… for margins that barely justify the stress.

And then we act surprised when it hurts.

If you’re selling the same stack, the same licensing, the same “per seat” offering as every other MSP down the road, you are not competing — you’re commoditising yourself. You’re playing a game where the rules reward scale, not quality. Volume, not insight. Marketing budgets, not experience.

That game is rigged.
And it’s rigged for vendors, marketplaces, and platforms — not for you.

Look at where the incentives sit.

Vendors want adoption. They want logos, seats, and usage metrics. They don’t care if you spend nights cleaning up conditional access, remediating insecure tenants, or explaining to customers why “secure by default” wasn’t actually default. You do the work. They report the growth.

Marketplaces want simplicity. Fixed pricing. Comparability. They want buyers to see MSPs as interchangeable — because that reduces friction. Unfortunately, it also erases differentiation.

Customers, conditioned by years of underpricing, want “everything included” and are shocked when security incidents, audits, or AI projects cost extra. Because no one ever taught them that outcomes have a cost.

And MSPs? MSPs are left trying to make a premium living inside a discount model.

That’s the rigged game.

The mistake most MSPs make is trying to win harder instead of changing the game.

They work longer hours. They add more services “for free”. They chase more customers instead of better ones. They hope automation will save margins that were never there to begin with.

It won’t.

You don’t escape a rigged game by playing it better.
You escape by opting out.

That means hard decisions. Uncomfortable positioning. Saying “no” to customers who only value price. Charging properly for risk, compliance, and complexity. Building IP instead of just reselling licences. Teaching customers that security, governance, and AI readiness are not add‑ons — they’re the foundation.

It means shifting from “we’ll do whatever you want” to “this is how we do it, and here’s why.”

It means working on your business model, not just in your ticketing system.

Yes, that’s harder in the short term.
Yes, you’ll lose some customers.
Yes, it will feel risky.

But staying where you are is riskier.

Because the current model doesn’t get easier with time. It gets tighter. More compliance. More security pressure. More AI complexity. More expectation — with the same margins.

The MSPs who will survive — and thrive — aren’t the ones who hustle harder inside broken rules.

They’re the ones who redesign the rules.

They stop competing on sameness and start competing on clarity.
They stop selling hours and start selling outcomes.
They stop apologising for price and start justifying value.

If what you’re doing feels impossibly hard, ask yourself this:

Are you failing…
Or are you just playing a game that was never designed for you to win?

Because once you see the rigging, you have a choice.

And the most powerful move isn’t working harder.

It’s stepping off the board.

More People Are Defeated by Blisters Than Mountains

image

Most MSPs don’t fail because the mountain was too big.

They fail because of the blisters.

Everyone loves to talk about the big challenges in this industry. Security threats. AI disruption. Microsoft changing the rules (again). Margin pressure. Talent shortages. Clients who don’t “get it”.

Those are the mountains. They’re visible. They’re dramatic. They make for great conference slides and LinkedIn posts.

But they’re not what usually beats you.

What actually takes MSPs out are the small, constant, grinding irritations that never quite get fixed.

The blisters.

Blisters are the daily annoyances you tolerate because “we’ll deal with that later”. The manual processes. The undocumented exceptions. The one client who’s “special”. The script that almost works. The onboarding checklist that lives in someone’s head. The sales process that depends entirely on you being in the room.

One blister on its own is manageable. You adjust your stride. You push through.

But blisters compound. They rub. They slow you down. They drain energy. And eventually, you stop walking altogether.

I see this constantly with MSPs.

They know where they want to go. Better margins. Fewer clients, higher value. Standardised stacks. Security-first offerings. Maybe even some actual time off.

But they never get there because the day-to-day friction is unbearable.

Take security as an example.

Most MSPs don’t lose customers because they can’t deploy Microsoft Defender or configure Intune. They lose because they never standardised how they do it. Every tenant is slightly different. Every exception is “just this once”. Every review is a bespoke exercise.

The mountain isn’t security.

The blister is inconsistency.

Or look at AI and Copilot adoption.

The mountain feels massive: “How do we sell this? Support this? Price this? Train clients?”

But the blister is simpler and far more dangerous: the MSP hasn’t even embedded AI properly inside their own business. No internal standards. No prompting framework. No documented use cases. No expectation that staff use it daily.

So it becomes yet another thing on the list. Another half‑done initiative. Another source of background frustration.

And then there’s the biggest blister of all: the owner bottleneck.

Most MSPs are not constrained by the market. They’re constrained by the person at the top trying to hold everything together.

If sales requires you. If escalation requires you. If documentation quality depends on you. If decision-making waits for you.

That’s not leadership. That’s friction disguised as control.

The mountain is “scaling the business”.

The blister is refusing to let go of how things are done today.

Here’s the uncomfortable truth:
You don’t need to climb faster.
You need better boots.

Better boots look boring. They’re not sexy. They don’t make great keynote topics.

They look like:

  • Ruthless standardisation, even when it annoys a few clients.

  • Saying “no” to edge cases that don’t fit your model.

  • Documenting the obvious so it stops living in your head.

  • Automating the unglamorous tasks that quietly drain hours.

  • Training your team properly instead of hoping they’ll “figure it out”.

  • Fixing internal friction before chasing external growth.

Mountains are conquered once.

Blisters are endured every single day.

If you want to win long term as an MSP, stop obsessing over the next big summit. Turn your attention inward. Identify the friction you’ve normalised. The pain you’ve accepted. The inefficiencies you excuse because “that’s just how it is”.

Because in this industry, it’s rarely the size of the challenge that defeats you.

It’s the small, preventable pain you refused to address early.