Windows LAPS via Intune: the quiet Business Premium win most MSPs still haven’t shipped

Walk into almost any SMB estate and you’ll find the same thing — a local administrator password that was set during imaging three years ago, shared across every device, and written down somewhere nobody wants to admit. It’s the sort of gap that never shows up on a client’s risk register until it does. What surprises me is how many MSPs haven’t yet rolled out Windows LAPS, even though it’s sitting right there inside Microsoft 365 Business Premium — Intune is part of the licence, the feature is part of Windows, and there’s no extra agent to push.

What it actually is

Windows LAPS is the successor to the old “Microsoft LAPS” tool — the one that needed an AD schema extension and a client-side extension pushed by GPO. The replacement is baked into Windows 10, Windows 11, and Server 2019+. Nothing to install. You just tell it what to do.

Each managed device backs its local admin password up to a directory — either on-prem AD or Entra ID. Pick one per device, and for cloud-joined SMB fleets it’s almost always Entra. The password is stored encrypted against an Entra key, and only users holding the right role can read it. The device itself never keeps the current password in the clear once it has rotated.

Deploying through Intune

In the Intune admin centre it lives under Endpoint security → Account protection → create a policy of type Local admin password solution (Windows LAPS). Under the hood you’re configuring the LAPS CSP, but the UI hides that detail.

The settings worth thinking through:

Backup directory — Azure AD or Active Directory. Disabled turns it off.
Administrator account name — leave blank and it manages the built-in Administrator, which is disabled by default on most modern builds. Name it explicitly if you want LAPS to manage a dedicated local admin.
Automatic account management — the newer setting that lets LAPS create and maintain the account for you, so you don’t need a separate provisioning step.
Password complexity, length, age — 14+ characters, full complexity, 30-day rotation is a sensible baseline.

Assign the policy to an Entra device group, not a user group — it’s a device-scoped CSP and won’t apply against user targeting.

Rotation, post-authentication reset, and retrieval

The bit that’s genuinely new — and the bit most pros miss — is the post-authentication reset. When the managed account signs in interactively, Windows starts a grace timer. When that elapses, it can rotate the password, sign the account off, or reboot the device. That behaviour alone shuts the door on a technician staying signed in for days with a password someone else might already have read. Scheduled rotation still runs on the age you set, and you can force an on-demand rotation from the device blade in Intune.

Retrieval is the other place it pays for itself. In Intune, open the device and click Local admin password. Or do it from Entra directly — Devices → the device → Local administrator password recovery. The role needed is Cloud Device Administrator, or an Intune role with the right retrieval action. Every read is audited, and by default reading the password triggers a fresh rotation, so a looked-up credential is a one-shot — useful if you’re handing it to a junior tech for a single call.

Worth the morning it takes

Rolling this out across a client tenant is an afternoon’s work per fleet, and it closes a gap most MSPs have been quietly carrying for years. If you’re already selling Business Premium, you’re already paying for it. The only real question left is why it isn’t deployed yet.

Are We Copilot‑Ready?

A practical readiness checklist for SMBs using Microsoft 365

Purpose:
Microsoft 365 Copilot works only within the permissions, data, and policies you already have. This checklist helps confirm whether your tenant is ready—or whether Copilot will simply surface problems faster.

You don’t need to score 100%. You do need to know where the risks are.

1️ Identity & Access (Foundation)

✅ We have Entra ID (Azure AD) accounts for all staff
✅ Multi‑factor authentication (MFA) is enforced for all users
✅ Admin roles are limited and reviewed periodically
✅ Former employees and guest users are removed promptly
✅ Conditional Access is in place for risky sign‑ins or devices

If “No” appears here:
Copilot will still work—but with higher security risk.

2️ Licensing Reality Check

✅ We understand the difference between:

Copilot Chat (Basic)
Microsoft 365 Copilot (Paid / Premium)

✅ We know which roles actually need Copilot licences
✅ We are not assuming “everyone gets it for free”
✅ Business Premium (or E3/E5) is in place for users handling sensitive data

If unclear:
Expect confusion, helpdesk tickets, and poor adoption.

3️ SharePoint & OneDrive Permissions (The Big One)

✅ SharePoint sites have clear owners
✅ Access is based on need, not convenience
✅ “Everyone” or “Anyone with the link” sharing is controlled
✅ Old project sites are archived or cleaned up
✅ We’re comfortable with Copilot summarising what users can access

Reality check:
Copilot doesn’t break permissions—it makes them obvious.

4️ Sensitivity Labels & Data Classification

✅ Sensitivity labels exist (even if only a few)
✅ Labels are applied to key documents and libraries
✅ Staff understand “Public vs Confidential” at a basic level
✅ We know Copilot respects sensitivity labels
✅ We are aware auto‑labelling may change labels automatically

Minimum viable setup:
Public / Internal / Confidential is often enough to start.

5️ Data Loss Prevention (DLP) Basics

✅ DLP is enabled for email and files
✅ Alerts or user warnings exist for sensitive data sharing
✅ We accept that Copilot follows the same DLP rules
✅ IT monitors DLP incidents (not just blocks them)

Without DLP:
Copilot can still answer—but may summarise data you’d rather it didn’t.

6️ Devices & Work Locations

✅ Devices are managed (Intune or equivalent)
✅ We know which devices are corporate vs personal
✅ Business data access is restricted on unknown or unmanaged devices
✅ Staff regularly work from approved locations

Why this matters:
Copilot uses the same trust signals as Outlook, Teams, and SharePoint.

7 Governance & Change Management

✅ Someone owns Copilot decisions (not “everyone”)
✅ We have user guidance for:

What Copilot is
What Copilot is not ✅ Staff know they remain responsible for final output
✅ We are prepared to say “not yet” to some AI use cases

Copilot readiness is organisational, not just technical.

8 Helpdesk & User Expectations

✅ Helpdesk knows Copilot behaviour changed in April 2026
✅ We can explain “why Copilot looks different now”
✅ We know where Copilot is expected to work (and where it won’t)
✅ We’ve set expectations around quality, limitations, and review

Silence here = frustration later.

✅ Copilot‑Ready Summary

Mostly ✅ → You’re ready to enable Copilot safely
Several ⚠️ → Fix fundamentals first
Many ❌ → Copilot will amplify risk and confusion

Rule of thumb:

If you wouldn’t be comfortable with an intern reading and summarising your Microsoft 365 data, Copilot isn’t the problem—your tenant is.

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

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:

The user pasting an export
Dropping a CSV/XLSX into the workspace
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)

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.

The Question That Tells You What to Fix Next

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.

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

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:

Email handling (Outlook)
Meetings (Teams)
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:

Are fewer hours being wasted on low‑value work?
Are decisions and deliverables happening faster?
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.

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

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.

Microsoft Fabric: Turning Your Business Data into Decisions (Without the Headaches)

Most small and medium businesses already have plenty of data.

It lives in your accounting system, your CRM, Microsoft 365, spreadsheets, and half a dozen other apps you rely on every day. The problem isn’t a lack of data — it’s that turning that data into clear, trusted answers is still harder than it should be.

That’s where Microsoft Fabric comes in.

Despite the grand name, Fabric isn’t about “big data” or enterprise complexity. It’s Microsoft’s attempt to fix a very real, very common SMB problem: why is it still so hard to get reliable answers from our own business systems?

The real problem Fabric is trying to solve

In most SMBs, reporting looks like this:

Sales has their numbers
Finance has a different set of numbers
Operations has spreadsheets that “mostly” line up
Meetings start with arguing over which report is correct

Even when Power BI is in use, it’s often built on fragile spreadsheets, duplicated datasets, or one‑off solutions held together by good intentions and caffeine.

The issue isn’t the tools — it’s the lack of a single source of truth.

What Microsoft Fabric actually is (in simple terms)

Microsoft Fabric is a single platform that brings together:

Data from all your systems
Secure storage for that data
Reporting and dashboards (via Power BI)
Analytics and forecasting
AI‑assisted insights

Instead of bolting tools together, Fabric gives you one shared data foundation that everything else plugs into.

Think of it as the difference between:

Twenty shared spreadsheets passed around by email
and
One trusted set of numbers everyone agrees to use

Why this matters for SMBs (not just big enterprises)

Fabric isn’t about doing more reporting. It’s about doing less work for better answers.

For SMBs, the benefits are very practical:

1. Everyone works from the same numbers

Sales, finance, and leadership stop arguing about whose report is right, because they’re all looking at the same underlying data.

2. Better use of Power BI

Power BI becomes a decision‑making tool, not just a chart generator built on shaky spreadsheets.

3. Faster answers to real business questions

Questions like:

Are we actually profitable by customer?
Which products are quietly costing us money?
Where are we growing — and where are we stalling?

become easier to answer without weeks of manual effort.

4. AI that’s useful, not gimmicky

Fabric includes AI features that help explain trends and surface insights — not replace your judgement, but support it.

What Fabric is not

Let’s be clear about expectations.

Microsoft Fabric is:

❌ Not a magic fix for messy data
❌ Not “set and forget”
❌ Not something every small business needs on day one

Fabric makes sense when your business:

Relies on multiple systems
Is growing or changing
Needs better visibility to make confident decisions

If Excel still works for you, that’s fine. Fabric is for when Excel no longer does.

The bigger picture

For years, businesses have collected more and more data while decision‑making hasn’t actually improved. Fabric is Microsoft’s attempt to close that gap — by simplifying how data is stored, shared, and analysed.

Used properly, it helps turn reporting from: