The Quietest Cancellation You’ll Never Hear

image

The hardest clients to keep are the ones who never tell you they’re leaving.

I’ve been turning this over for a while. The clients who churn loudly — the ones who ring up annoyed, send the sharp email, ask for a refund — those are actually the easy ones. You know where you stand. You can fix something, part ways cleanly, or at least learn from it.

It’s the silent ones that hurt. The ones who stop replying to your monthly check-ins. Skip the review. Renew once out of inertia, then quietly don’t renew the second time. And somewhere down the track, you’ll hear from a friend of a friend that they felt burned by your business.

Nobody robbed them. They just never really bought.

Sold isn’t the same as bought

There’s a real difference between a client who bought and a client who was sold. Small word, big gap.

A client who bought made the decision. They walked in with a problem, recognised what you offered, and chose it. They own the outcome. Even when things get bumpy, they stay engaged because it’s their decision to defend.

A client who was sold went along with it. Maybe you were persuasive. Maybe they didn’t want to look uncertain in front of their team. Maybe the proposal looked sharp and they signed before they’d really thought it through. They never crossed the line from interested to committed — but on paper, the deal got done.

The first kind tells their friends about you. The second kind tells their friends about the business that talked them into something.

Where I see it most in MSP land

I see this constantly with Copilot rollouts right now. An MSP gets excited, runs a slick pitch, the client nods along, the licences get assigned in the Microsoft 365 admin centre, and then… nothing. Six months later the usage reports look flat. Nobody has Copilot pinned in Outlook. Nobody is asking it to summarise a Teams meeting they missed. Nobody is in Word using it to redraft a proposal or in Excel asking it to explain a column of numbers.

That client didn’t buy Copilot. They bought the meeting being over.

The same pattern shows up with backup uplifts, security stack changes, anything that lives behind a quote. If the conversation was about us getting the agreement signed instead of them understanding what changes on a Tuesday morning, the meter starts ticking on a quiet exit.

The signal isn’t loud. It’s a slower email reply. A “we’ll think about adoption training next quarter.” A skipped quarterly business review. By the time it shows up in your churn report, the relationship was over months ago.

Make them buy, don’t sell them

The fix isn’t softer language or better slides. It’s slowing the conversation down before the contract goes out. The best deals I’ve seen lately are the ones where the close was almost anticlimactic — because the buying decision had already been made out loud, by the client, weeks earlier.

I want the client describing the problem in their own words. I want them telling me what their inbox looks like on a bad day. I want them booking the adoption sessions before the deal is signed, not after. If they won’t put time in their calendar to actually use the thing, that’s the answer — and it’s better to hear it now than read it in a Google review later.

Selling closes a deal. Buying starts a relationship. One of those keeps the lights on this quarter; the other builds the kind of business worth referring.

Defender Vulnerability Management

image

Most people treat Defender Vulnerability Management like a weather report. They glance at the exposure score, nod, and close the tab.

That’s a waste.

The score isn’t the point. The workflow behind it is. And the part almost nobody uses — the bit that actually moves the needle — is the security baselines assessment sitting right next to it.

Here’s the thing. Patching tells you whether software is current. A baseline tells you whether it’s configured the way it’s supposed to be. Those are two completely different questions, and the second one is where most SMB environments quietly fall apart.

What are security baselines, really?

A baseline is a benchmark of configuration settings — things like password policy, BitLocker, account lockout, audit logging — measured against an industry profile.

In Defender, you assess your devices against the CIS or STIG benchmarks, pick a level (L1 is sensible-default, L2 is locked-down), and the tool tells you, device by device, setting by setting, where you comply and where you don’t.

Not “you’re missing 14 patches.” More like “BitLocker isn’t enforced on 9 machines and your audit policy is wide open.” That’s the stuff attackers love and scanners ignore.

The security baselines assessment documentation walks through the profile options if you want the full menu.

Step-by-Step: Build a baseline profile

You’ll need Defender for Endpoint Plan 2 with the MDVM add-on, or the MDVM Standalone licence. Then head to the Microsoft Defender portal → Exposure management → Baselines assessment.

Create the profile

Give it a name, choose your benchmark (CIS or STIG), choose your OS, choose your level. Start at L1. You can tighten later — leading with L2 just buries you in red.

Scope it to a device group

Don’t boil the ocean. Point it at one group — a handful of servers, or the managed laptops — and let it run.

Read the results by setting, not by score

Open the profile and sort by compliance. Each failing setting lists exactly which devices miss it. This is your work queue.

Now the part that earns its keep: exceptions

Here’s the reality every MSP knows. Some findings you can’t fix. The line-of-business app needs that legacy setting. The client won’t approve the downtime. The vendor says “don’t touch it.”

So what do most people do? Nothing. The finding sits there, red, forever — and after a while everyone stops looking because the dashboard is always angry.

That’s the trap. A permanently-red dashboard is the same as no dashboard.

The fix is the exception workflow. When you genuinely can’t remediate something, you file an exception — with a justification and an expiry date — and that finding drops out of your active exposure number. It doesn’t vanish. It’s parked, documented, and time-boxed.

Request the remediation first

For anything you can fix, connect Defender to Intune (it’s a toggle in the portal) and raise a remediation request straight from the recommendation. It lands in Intune as a tracked task instead of a Post-it note. The remediation request process covers the Intune connection.

File an exception for the rest

For the genuine “we can’t touch that,” create an exception with a real reason and a review date. The exceptions overview explains the justification types and how exceptions affect your exposure score.

“Doesn’t an exception just hide the problem?”

No. Hiding is when you ignore the red and hope. An exception is a decision — recorded, owned, and due for review. The difference is accountability.

Why this actually changes behaviour

Once you’re running baselines plus a disciplined exception workflow, “we can’t patch that one” stops being a silent gap. It becomes a documented, time-boxed choice with someone’s name on it.

That’s not a security feature. That’s a governance habit.

And it’s the exact thing that turns a vague “yeah, we’re secure” into a report you can hand a client.

If you’re not showing your clients their baseline posture and the exceptions you’ve signed off on, you’re leaving value — and trust — on the table.

The exposure score was never the deliverable. The conversation it lets you have is.

CIAOPS AI Dojo 13

MAI_af93e4a6a5f5c601

What’s the session about?

This month we will be focusing on new Copilot features and updates as well as optimising AI for Small Business.

Who should attend?

This session is perfect for:

  • IT administrators and support staff
  • Business owners
  • People looking to get more done with Microsoft 365
  • Anyone looking to automate their daily grind

Save the Date

Date: Friday the 26th of June 2026

Time: 9:30 AM Sydney AU time

Location: Online (link will be provided upon registration)

Cost: $80 per attendee (free for Dojo subscribers)

Register Now

CIA Brief 20260606

image

Events — Microsoft Build 2026
  • Build 2026: Furthering Windows as the trusted platform for development(opens in new window) At Build 2026, Microsoft laid out a wave of developer-focused Windows updates aimed at reducing setup friction and making Windows the place to build and run AI agents. Highlights include Coreutils for Windows, WSL containers, one-command Windows Developer Configurations, and a new security layer called Microsoft Execution Containers (MXC) that lets developers tightly control what an AI agent can access. It matters because it signals Microsoft’s push to fold secure, on-device AI agents directly into the Windows developer experience.
Announcements — New Products
Industry News — Security
image
AI
Announcements & Product Launches
AI Models & Research
Events
Productivity & Copilot Tips

After hours

Microsoft Build 2026: See All the Highlights in 15 Minutes – https://www.youtube.com/watch?v=1PSHObgyJpw

Editorial

If you found this valuable, the I’d appreciate a ‘like’ or perhaps a donation at https://ko-fi.com/ciaops. This helps me know that people enjoy what I have created and provides resources to allow me to create more content. If you have any feedback or suggestions around this, I’m all ears. You can also find me via email director@ciaops.com and on X (Twitter) at https://www.twitter.com/directorcia.

If you want to be part of a dedicated Microsoft Cloud community with information and interactions daily, then consider becoming a CIAOPS Patron – www.ciaopspatron.com.

Watch out for the next CIA Brief next week

Normal Is a Group Decision

image

I sat in a room recently with a group of MSP owners and listened to a conversation about pricing. Every person at the table was earning a decent living. Every person at the table was also quietly miserable about how hard they were working for it. Nobody was a bad operator. Nobody was lazy. They had simply, over years, settled into a shared idea of what “normal” looked like — and that idea was the ceiling.

That moment stuck with me, because I think most of us underestimate how much the people around us shape what we believe is possible.

Limited isn’t the same as bad

When something feels stuck — your business, your income, your role, your energy — the easy story is that someone is doing you wrong. A bad client. A bad supplier. A bad staff member. In my experience that’s rarely the real problem. The real problem is quieter. You’re surrounded by perfectly decent people who have made peace with a smaller version of the game than you secretly want to play.

Limited people aren’t villains. They’re warm, helpful, often very good at what they do. They just don’t think bigger than what they already have, and over time that becomes the air you breathe. You stop pitching certain projects. You stop charging certain prices. You stop applying for certain rooms. Not because anyone told you not to — because nobody around you is doing it either. The same thing happens with the clients you accept and the staff you hire. Like attracts like, and the average keeps quietly resetting itself downwards.

Audit the room

The room is bigger than you think. It’s the peer group you call when something goes sideways. It’s the chat you scroll while the kettle boils. It’s the three or four voices you hear most often inside your head when you’re making a decision. If those voices have all settled, you will too.

This is where I find Microsoft 365 quietly useful, in a way that has nothing to do with productivity. I use Copilot in Outlook to clear the noise faster, so the time I free up actually goes into conversations with sharper people — not back into more email. I use Copilot Chat to pressure-test my own thinking before I send a proposal: “argue against this”, “what would a more ambitious version look like”, “what am I leaving on the table”. It doesn’t replace good humans. It does stop me defaulting to the average opinion in my own head.

I also pay closer attention to which Teams communities and channels I actually show up in. If every conversation I’m part of is about doing the same thing slightly better, I’ve answered my own question about why my ceiling hasn’t moved. I keep a running Loop page of articles, podcasts and operators who think a level above where I am now, and I make myself read it before I make a decision I might otherwise rush.

Move the ceiling on purpose

You don’t have to fire your friends. You do have to be honest about what each room teaches you. Add one peer group that’s a level above where you are now. Subscribe to one voice who genuinely makes you uncomfortable in a useful way. Spend one hour a week somewhere your current “normal” would feel small.

The ceiling is invisible until you sit somewhere with a higher one. Then you wonder how you ever called the old one a roof.

CIAOPS Need to Know Microsoft 365 Webinar – June

laptop-eyes-technology-computer_thumb

Now in our tenth year!

Join me for the free monthly CIAOPS Need to Know webinar. Along with all the Microsoft Cloud news we’ll be taking a look at SharePoint Skills.

Shortly after registering you should receive an automated email from Microsoft Teams confirming your registration, including all the event details as well as a calendar invite.

You can register for the regular monthly webinar here:

June Registrations

(If you are having issues with the above link copy and paste – https://bit.ly/n2k2606 )

The details are:

CIAOPS Need to Know Webinar – June 2026
Friday 26th of June 2026
11.00am – 12.00am Sydney Time

All sessions are recorded and posted to the CIAOPS Youtube channel.

Also feel free at any stage to email me directly via director@ciaops.com with your webinar topic suggestions.

I’d also appreciate you sharing information about this webinar with anyone you feel may benefit from the session and I look forward to seeing you there.

Three Power Automate flows every MSP should productise

image

Every MSP I talk to has the same Power Automate problem.

Not a tech problem. A consistency problem.

Client A has a leave-request flow built by some intern in 2022. Client B has an onboarding flow that emails three people, one of whom left last year. Client C runs approvals through someone’s personal Outlook because it was “quicker that way”.

That’s not automation. That’s tribal knowledge held together by hope.

The fix isn’t more flows. The fix is three flows, built once, exported, and dropped into every client tenant you touch.

What is a Power Automate solution, really?

A flow on its own is a personal toy. It lives in someone’s default environment, it’s owned by one person, and the day they leave the tenant the flow dies with them.

A solution is that same flow, packaged with connection references and environment variables, exported as a file, and imported into any other tenant. Same flow. Different SharePoint site, different approvers, different mailbox — wired up at import time, not hardcoded.

That’s the move. Stop building per-client. Start building once and deploying everywhere.

If you’re charging your clients for automation as a service, this is what productisation actually looks like.

The three worth standardising

There are hundreds of templates in the Power Automate gallery. Most MSPs don’t need hundreds. They need three:

  • Approvals — anything that needs a yes/no with an audit trail

  • Joiner (onboarding) — new staff member, day one

  • Leaver (offboarding) — staff member out, access gone, evidence kept

Build those three properly as a managed solution and you’ve covered eighty percent of the automation requests you’ll get from an SMB client this year.

Step-by-Step: stand up the Approvals flow first
Open Power Automate inside a dedicated solution

Sign in to Power Automate, pick Solutions on the left, and create a new one. Give it a publisher name like YourMSP_Automation. Don’t skip this. Flows created outside a solution can’t be exported cleanly later.

Pick the right approval type

Open the Start and wait for an approval action and look at the dropdown. There are four real options — Approve/Reject – Everyone must approve, Approve/Reject – First to respond, Custom Responses – Wait for all responses, Custom Responses – Wait for one response — plus sequential. Most SMB approvals are First to respond. Document sign-offs are usually Everyone must approve. Pick deliberately. The full approvals reference is on Microsoft Learn.

Use environment variables for the approvers, not hardcoded emails

This is the bit MSPs skip and then regret. Don’t type finance@clientco.com into the Assigned To box. Create an environment variable called ApproverEmail, reference it in the action, and set the value at import time.

Here’s what the assignment looks like in the action:

@{parameters('ApproverEmail (yourmsp_approveremail)')}

Notice what’s missing? A client name. That’s the point. Same flow, twelve tenants, twelve different approver emails — none of them baked into the export.

Export it as a managed solution

Solutions > your solution > Export > Managed. You ship managed solutions to client tenants and keep the unmanaged copy in your build tenant. Microsoft’s import guide walks through what the receiving tenant sees — connection references prompt for new accounts, environment variables prompt for values, and your flow turns itself on when it lands.

Joiner and Leaver follow the same shape

For Joiner the trigger is usually a new Microsoft Lists item or a Forms submission. The flow creates the Entra user, assigns licences, drops them into groups, posts a welcome card to a Teams channel, and sends the manager an approval to confirm everything looks right before the password lands in the helpdesk mailbox.

For Leaver the trigger is the same list, different status. The flow disables sign-in, revokes sessions, converts the mailbox to shared, transfers OneDrive ownership to the manager, and writes a row to a SharePoint list that becomes your audit trail when the cyber insurance auditor asks “what was your offboarding process on the 14th of March?”.

Both flows reuse the same three environment variables — HelpdeskMailbox, ManagerApprovalGroup, OffboardingEvidenceList. Build once. Import twelve times. Done.

One more thing: lock the connectors down before you ship

Before you push any of this into a client tenant, set a Data Loss Prevention policy in the Power Platform admin centre. Put Office 365, Approvals, SharePoint, and Teams connectors in the Business group. Put Twitter, Dropbox, Gmail, and the rest in Non-Business or Blocked. Microsoft’s DLP guidance spells out why this matters: without it, any maker in the tenant can build a flow that pipes mailbox data into a personal Dropbox.

Before: “Can you build us a leave-request flow?”

After: “We’ll deploy our standard approvals solution to your tenant on Friday.”

That’s the shift. From bespoke build to productised deployment. From “this might take a few days” to “this is a forty-minute import”.

Why this actually changes behaviour

If you’re an MSP and you’ve built the same flow three times for three clients, you’re not running an MSP. You’re running a freelance bench with a logo.

The three-flow library — approvals, joiner, leaver — is the smallest automation product that pays back. It compresses delivery time. It standardises what “good” looks like across every client you touch. And when a client says “we’d like our offboarding to leave evidence for our cyber insurer”, you don’t quote a project. You import a solution.

Here’s the real win. Once these three are running cleanly, the conversation with the client changes. They stop asking if you can automate something. They start asking what else you’ve already got in the library.

That’s where the margin is.

Build the flow once. Sell the deployment every time.

The Pendulum Might Be Swinging Back to On-Premises

image

For years the story was simple. Move everything to the cloud, pay for what you use, never buy a server again. I bought into a lot of that, and for plenty of workloads it still holds up. But lately I’ve been having a different conversation with MSP owners, and it keeps circling back to one thing: the cost of running AI is climbing, nobody is quite sure where it stops, and it’s no longer a fringe worry — it comes up in nearly every planning chat I sit in on.

The bill that grows while you sleep

Here’s what I’m seeing. A client switches on an AI feature, the team loves it, usage goes up, and three months later the invoice has quietly doubled. Tokens — the units these models bill against — get consumed every time someone asks a question, summarises a thread, or drafts a reply. Individually they cost almost nothing. At scale, across a busy business, they add up fast.

The trouble is the meter never sleeps. A traditional software licence is a known number you can budget around. Token-based AI is a tap that’s always running, and the more useful it becomes, the more it costs. I’ve watched owners realise that the productivity win they were celebrating has a recurring price tag attached that grows in lockstep with their success.

Why bringing it home is back on the table

This is where on-premises starts creeping back into the conversation. Hardware that runs capable models locally is getting cheaper and far more practical. For a business with predictable, high-volume AI work — document processing, internal search, summarising the same kinds of records all day — a one-off box in the comms room can start to look smarter than an open-ended monthly bill.

I’m not saying everyone rips out the cloud. That would be daft. But the calculation has shifted. Five years ago, running your own AI infrastructure was exotic and expensive. Now it’s a line item a serious MSP can actually model for a client and stand behind, and that’s a service opportunity worth taking seriously.

The hybrid answer most businesses will land on

In practice I think most organisations end up somewhere in the middle, and that’s fine. Microsoft 365 Copilot is a good example of where the cloud stays. When someone asks Copilot in Outlook to draft a reply, or pulls a summary out of a long Teams meeting, that’s woven so tightly into the service that dragging it on-premises makes no sense. You’re paying for the integration, not just the tokens.

But the heavy, repetitive, high-volume jobs — the ones that chew through tokens by the thousand — are exactly the ones worth questioning. Does that bulk processing need to sit in a metered cloud, or could it run on a local model and feed the results back into SharePoint or a Power Automate flow? That’s the kind of question I think every MSP should be asking on behalf of their clients this year.

Where I’ve landed

The pendulum has swung hard towards the cloud for a decade, and it’s earned its place. But cost has a way of correcting fashion. When the meter starts hurting, people look for the off switch — and sometimes the off switch is a server you own. Watch your AI usage like any other variable cost. Know which workloads belong in Copilot and the cloud, and which ones might be cheaper closer to home.