Claude Cowork vs Copilot Cowork: why the Microsoft answer wins for SMB

image

I’ve watched a lot of clients spend the last twelve months stitching together AI tools that don’t talk to each other. A Claude tab here. A ChatGPT tab there. A Copilot tab somewhere in the middle. Then a folder of CSVs they keep dragging in and out of each one.

That’s not a workflow. That’s a tax.

So when Anthropic shipped Claude Cowork and Microsoft shipped Copilot Cowork in roughly the same window, the question landed in my inbox: which one do we tell our clients to use?

I’ll save you the suspense. For an SMB already paying for Microsoft 365, it’s not close.

What is Cowork, really?

Cowork is the bit that does the work, not the bit that talks about it. You give it an outcome — “draft the quarterly update from these meeting notes and send it to the leadership team” — and it goes off and does the thing.

That’s the shared idea. Both products own it. The split is in where the work happens.

Claude Cowork lives on your desktop. You mount a folder, drop your files in, and Claude runs in a sandbox on your machine. It doesn’t see your inbox. It doesn’t see your calendar. It doesn’t see your Teams chats unless you’ve copy-pasted them in. You bring the data to the model.

Copilot Cowork is the inverse. It already lives inside Microsoft 365, grounded in your Outlook, Teams, SharePoint, OneDrive, and calendar through Work IQ. You don’t mount anything. The model is already where your data lives.

Notice what’s missing? The mounting step. The “let me copy this folder over” step. The “hang on, I need to paste in the email thread” step.

For SMBs, that’s the whole game.

Step-by-Step: getting Copilot Cowork going

If you’re licensed for Microsoft 365 Copilot and enrolled in the Frontier preview, the start is short.

Open Cowork in Microsoft 365

Browse to m365.cloud.microsoft, sign in, and pick Cowork from the agent list. If you don’t see it, check Frontier enrolment under Copilot settings.

Describe the outcome

Skip the prompt-engineering nonsense. Talk like a person.

Read my inbox from this week, find anything tagged from a client,
draft a Friday wrap-up email summarising open items, and post a
short version into the Operations channel in Teams.

Notice what’s missing? Any reference to a file path. Any “first export your inbox to CSV” step. Cowork already has the inbox, the calendar, the Teams channels, and the SharePoint files. It just needs the instruction.

Approve the action

Cowork shows you exactly what it’s about to send, post, or schedule before it does it. You hit Send, Post, or Cancel. The full flow is in the getting started doc if you want to walk a client through it.

Set the schedule

Want it to do this every Friday at 4pm? Schedule the prompt and walk away. Copilot doesn’t get tired. Use that.

Why this actually changes behaviour

Claude Cowork is a beautifully built tool. For a developer or a data analyst on a Mac with a folder full of CSVs, it sings. I’m not knocking it.

But that’s not the SMB picture. The SMB picture is a bookkeeper, a sales lead and a director who all live inside Outlook and Teams from 8am to 6pm. Their data isn’t in a folder on their desktop. It’s in their mailbox, their channel chats, their SharePoint sites and their meeting transcripts.

“But couldn’t we just pipe our M365 data into Claude?”

You could. You’d be paying twice — once for M365, once for Claude — and you’d be exporting business data into a different vendor’s environment to do work the platform you already own can do natively.

That’s not a productivity gain. That’s a procurement problem.

Here’s the real win. Copilot Cowork sits behind the same Entra identity, the same conditional access, the same Purview labels and the same retention policies your tenant already runs. The governance story is already built. There’s no second tool to license, secure, train, or audit.

My recommendation? If you’re an MSP and you’re not walking your SMB clients through Copilot Cowork, you’re leaving value on the table — theirs and yours.

Meet people where they already are.

Cowork isn’t a second AI app for your clients to learn. It’s the work, finally getting done in the place it was always supposed to happen.

A Great Product Scales. A Great System Scales. But Leaders Multiply.

image

Most MSPs I talk to are chasing scale.

More endpoints. More seats. More tools. More revenue per engineer.

And that makes sense—up to a point.

But here’s the uncomfortable truth: products scale. Systems scale. Dashboards scale. Yet the thing that actually determines whether an MSP breaks through the next ceiling isn’t any of those.

It’s leadership.

In particular, whether you’re multiplying your people—or slowly becoming the bottleneck without realising it.

The Hidden Scaling Problem in Many MSPs

I see this pattern constantly.

The MSP owner is sharp. Knows the stack inside out. Answers client questions quickly. Fixes problems fast. Reviews every proposal. Tweaks every process.

On the surface, it looks like control. Underneath, it’s fragile.

Because when knowledge, judgement, and decision‑making live in one or two heads, the business doesn’t really scale—it stretches. And stretched systems eventually snap.

This is where Microsoft 365 Copilot genuinely changes the conversation—not because it “does AI”, but because it shifts who can think, decide, and act with confidence.

Copilot Isn’t About Speed. It’s About Trust.

When I work with MSP teams implementing Copilot properly, the biggest change isn’t faster emails or prettier documents.

It’s trust.

A junior engineer can review a complex email thread and ask Copilot to summarise what actually matters—before responding to a client.

A service manager can draft options for a tricky renewal conversation without escalating every time.

An account manager can walk into a QBR already across usage, risks, and open issues—without waiting for someone else to spoon‑feed them.

That’s not automation. That’s capability transfer.

Instead of leaders being the thinking engine for the business, Copilot becomes a quiet amplifier that helps the team think better on their own.

Systems Scale. Leaders Multiply.

Here’s the distinction I think too many MSPs miss.

Systems help people follow rules. Leaders help people exercise judgement.

Copilot sits squarely in the second category—if you use it intentionally.

I’ve seen MSPs roll it out as “another tool” and get negligible value. Everyone plays with prompts for a week, then goes back to old habits.

The MSPs getting real results are doing something different: they’re pouring into their people.

They’re teaching staff how to reason through problems using Copilot as a second brain. How to sanity‑check assumptions. How to prepare before asking for help instead of defaulting to escalation.

That’s leadership multiplication.

And it compounds faster than any new tool rollout ever will.

What This Means for MSP Owners

If you’re serious about scaling, the question isn’t “Have we deployed Copilot?”

It’s:

  • Are my people making better decisions without me?

  • Are conversations getting clearer, not noisier?

  • Are we reducing dependency on tribal knowledge?

Copilot won’t fix weak leadership. But in the hands of leaders who invest time, context, and expectation into their teams, it accelerates growth in ways traditional systems never could.

The Return Might Surprise You

Here’s what tends to happen when MSP leaders commit to developing people—not just installing tools.

Fewer interruptions. Faster client responses without panic. Better internal conversations. More confidence across the business.

And eventually, something even more valuable: space.

Space to think strategically instead of reactively. Space to focus on the business instead of being trapped inside it.

So yes—great products scale. Great systems scale.

But if you want an MSP that genuinely grows without breaking, keep pouring into your team.

That return doesn’t just surprise you.

It changes everything.

Revisiting Copilot image generation analysis

A while back I shared the results of an identical image prompt in a number of AI tools. That article is here:

https://blog.ciaops.com/2026/03/07/image-generation-analysis/

Now that Copilot has access to OpenAI Image 2 model I thought I’d re-run and share the results.

This is the result from the previous test with Copilot chat:

image

This is the updated response using the identical prompt as before with Copilot Chat again:

image

This is the same prompt with Copilot Chat again BUT with ‘Create a detailed infographic using the new openAI image 2 model’ added at the beginning of the prompt:

image

This is the original prompt but used in the dedicated ‘Create Image’ part of Copilot:

 image

Still not perfect if you examine each closely but a significant improvement from the last round.

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.md – Standardizes the first 30 days of a new MSA — kickoff pack, technical checklist, recurring touchpoints

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

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

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

license-rightsizing.md – Finds unused, oversized, and duplicated M365 licenses and quantifies the savings

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

employee-onboarding.md – Provisions 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.

Why Copilot works differently now (and why that’s a good thing)

image

If you’ve noticed that Microsoft Copilot feels different lately—especially inside Word, Excel, PowerPoint, or Outlook—you’re not imagining it.

Nothing is “broken”.
What’s changed is how Copilot is positioned, licensed, and governed.

And while change can be frustrating, this shift is actually a step forward for security, reliability, and trust.

Here’s what’s going on—in plain English.


The short version

Copilot is no longer a “free helper everywhere”.
It’s now treated as a proper business system, with clear rules around:

  • Who can use it

  • What data it can see

  • Where it’s guaranteed to work

  • How it’s secured and audited

That’s good news for organisations that care about their data.


What Copilot was doing before

In late 2025, Microsoft made Copilot Chat broadly available across Microsoft 365.
For many organisations, this meant:

  • Copilot appeared inside Office apps

  • Users experimented freely

  • Expectations rose quickly

While this was great for awareness, it also created problems:

  • People assumed Copilot was “free forever”

  • Capabilities varied by tenant size and workload

  • Security and governance were often misunderstood

  • Businesses struggled to tell the difference between trial and production use


What changed (and why)

Microsoft has now drawn a clear line between:

✅ Copilot Chat (Basic)
  • General AI chat

  • Limited guarantees

  • Not deeply integrated with your business data

  • Useful for exploration and light assistance
✅ Microsoft 365 Copilot (Premium)
  • Fully integrated into Word, Excel, Outlook, Teams, etc.

  • Grounded in your organisation’s data (emails, files, meetings)

  • Governed by your security, compliance, and access controls

  • Licensed per user, with predictable behaviour

This separation wasn’t about removing features—it was about making responsibilities clear.


Why this is a good thing for your business

1️ Consistency beats surprises

When Copilot is licensed properly, its behaviour is predictable.

  • It works where you expect it to work

  • It respects your data boundaries consistently

  • Users stop asking “why did it work yesterday but not today?”

That’s what businesses need.


2️ Security becomes visible (not optional)

Copilot doesn’t invent access to information.

It uses:

  • Your permissions

  • Your sensitivity labels

  • Your data loss prevention rules

If something looks risky now, it was already risky—Copilot just made it obvious.

That’s a feature, not a flaw.


3️ Responsibility stays with people

Copilot assists.
It does not replace judgment.

The new model reinforces that:

  • People remain accountable for decisions

  • AI output must be reviewed

  • Policies still apply

This protects both the business and the staff using it.


4️ AI is treated like any other system

No business runs email, accounting, or security tools without governance.

Copilot is now treated the same way:

  • Licensed intentionally

  • Enabled where it adds value

  • Governed like a business system—not a novelty

That’s how AI becomes sustainable.


What hasn’t changed

It’s important to be clear about this:

  • Copilot still doesn’t bypass permissions
  • Copilot doesn’t share data externally
  • Copilot doesn’t “learn” from your data for other customers
  • Copilot respects your Microsoft 365 security model

The fundamentals are the same.
The clarity is new.


What this means for your organisation

This is a good moment to pause and ask:

  • Who actually benefits from Copilot day‑to‑day?

  • Is our data organised well enough to support AI?

  • Do we understand what Copilot can and can’t see?

  • Are expectations set correctly with staff?

Answering those questions now avoids frustration later.


The bottom line

Copilot didn’t get worse.
It got more honest.

Microsoft has moved Copilot from:

“Try it everywhere”
to
“Use it properly”

That shift improves:

  • Security

  • Trust

  • Reliability

  • Long‑term value

And that’s exactly what businesses should expect from AI that works with their data.

Exactly How SMBs Should Measure ROI from a Microsoft 365 Copilot Investment

image

Most SMBs “measure” Copilot ROI the wrong way.

They count prompts.
They quote vendor stats.
They say “people feel more productive”.

That’s not ROI. That’s vibes.

If you want to justify Microsoft 365 Copilot to an SMB owner, you need numbers that connect cost → behaviour → business outcome. Here’s exactly how to do that, step by step.

Step 1: Lock in the true cost (don’t wing this)

Before measuring return, be honest about investment.

For an SMB, Copilot cost is typically:

  • Copilot licence per user per month

  • Time spent on onboarding and training

  • Light data clean‑up (because Copilot will surface your mess)

Write this down as a monthly cost per user. That’s your baseline. No magic. No “later we’ll optimise”.

If you can’t clearly say “this is what Copilot costs us per user per month”, stop here.

Step 2: Pick only three measurable activities (not everything)

SMBs fail when they try to measure Copilot “everywhere”.

Don’t.

Pick three everyday activities where Copilot realistically shows up:

  1. Email handling (Outlook)

  2. Meetings (Teams)

  3. Document creation (Word / PowerPoint)

Microsoft already collects behavioural data for these via Viva Insights and Copilot Analytics. You don’t need custom tooling or surveys. [learn.microsoft.com]

Step 3: Capture a before baseline (this is non‑negotiable)

You must capture a baseline before rollout or you’ll be guessing forever.

Do this for a pilot group (10–20 users is fine):

  • Average daily email time per user

  • Average meeting hours per week

  • Time to create a “standard” document (proposal, report, policy)

These numbers already exist in Viva Insights for email and meetings. For documents, do a simple timing exercise with 3–5 users. [petri.com]

Write them down. Freeze them. This is your “before” state.

Step 4: Measure the delta after 30 and 60 days

Now roll out Copilot properly (licences and training) and re‑measure at:

  • 30 days

  • 60 days

Look only for deltas, not absolute values:

  • Reduction in email time per day

  • Reduction in meeting time or improved meeting outputs (summaries used instead of re‑watching)

  • Faster first‑draft document creation

Ignore:

  • Prompt counts

  • “Active users”

  • Dashboard vanity metrics

Usage is not value.

Step 5: Convert time saved into capacity, not dollars

This is where most ROI models fall apart.

Do not say:

“We saved 5 hours per week, therefore we saved $X.”

Instead ask:

  • Did sales respond to leads faster?

  • Did projects finish earlier?

  • Did client work backlog reduce?

  • Did staff stop working unpaid overtime?

Example:

A 15‑person professional services SMB reduces document creation time by 30 minutes per day per consultant. That doesn’t mean “money saved”. It means one extra billable task per week without hiring.

That’s capacity gain. Owners understand that instantly.

Step 6: Track one business outcome per role

Different roles = different ROI.

  • Sales: speed to quote, proposal turnaround

  • Admin: email backlog, meeting follow‑up time

  • Management: decision latency (time from question to answer)

Pick one outcome per role, not ten. If Copilot isn’t moving the needle there, it’s not paying for itself.

Step 7: Do a simple sanity check at 90 days

At 90 days, ask three brutal questions:

  1. Are fewer hours being wasted on low‑value work?

  2. Are decisions and deliverables happening faster?

  3. Would removing Copilot cause disruption?

If the answer is “no” across the board, the problem isn’t Copilot. It’s adoption, data hygiene, or training—not licensing.

Final reality check

Copilot ROI is not magic and it’s not automatic.

But when SMBs measure behaviour change first, then tie that to capacity and outcomes, Copilot becomes defensible, repeatable, and scalable—exactly how an SMB expects technology to behave.

If your ROI story can’t survive a sceptical business owner, it’s not finished yet.

Proximity Is Power — Assemble Your AI Circle

image

Every real jump I’ve made with AI has come from a conversation, not a course. Not a YouTube deep-dive, not a whitepaper, not a bookmarked article I told myself I’d read later. A conversation. Usually over coffee, sometimes over Teams, almost always with someone who’d already done the thing I was still circling. I’ve stopped treating that as a coincidence.

The shortcut nobody uses

There’s a strange reluctance to ask for help with AI. People will spend three weekends wrestling with prompts, rebuilding the same agent four times, watching another hour of tutorials — before they’ll send one message to someone who has already solved the problem.

I don’t know why we do this. Maybe it feels like cheating. Maybe we think we have to earn it the hard way. But the person two steps ahead of you isn’t guarding anything. In my experience, they’re usually thrilled someone asked.

Open your phone right now. Scroll through LinkedIn. Flick through your contacts. There will be one or two names who are visibly doing more interesting work with AI than you are. Send them a message today. Not next week. Today.

Trade something for their time

If the person you want to learn from is properly ahead — running real projects, shipping real results — their time is the scarce resource. So offer to pay for it. Offer to buy them lunch. Offer the hour the way you’d pay any other professional.

Most people will wave the money away and take the coffee. A few will charge you, and they’ll be worth every cent. What you’re really buying is a compressed version of their last twelve months of learning — the dead ends, the tools they quietly stopped using, the one prompt pattern that changed everything for them. You don’t get that from a blog.

Even if nobody ever takes your money, the offer changes the tone of the conversation. You’ve signalled you take their experience seriously. People respond to that.

Make it a ritual

One of the best things I’ve locked into my week is a small AI lunch. Five of us, give or take, turning up to compare notes on what we’re actually doing — what we built, what broke, what surprised us, what we’re quietly worried about. No agenda, no slides.

A year of those lunches is worth more than any conference I’ve been to. Cadence matters. A monthly catch-up drifts to quarterly. A weekly one stays locked in. You start showing up with something to share because you know the others will.

You don’t need five people. Start with two. Pick a day, pick a cafe, and put it in the calendar on repeat.

The real edge

The tools are mostly the same for everyone now. Access isn’t the differentiator it was twelve months ago. What separates the people genuinely getting somewhere with AI from the people still reading about it is the circle they’ve built around themselves.

Assemble that circle on purpose. Proximity really is power — and the people you sit next to, even on a call, will shape how far you go.

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.

“