Most MSPs I talk to are convinced their biggest constraint is time. Too much work. Too few people. No space to step back and “document everything” the way they know they should.

The uncomfortable truth? You don’t actually need more time. You already have the systems. You’re just not using them properly.

If you want to make progress with standardisation, scale, and eventually AI, step one isn’t buying another tool. It’s recording the work you’re already doing.

The Camcorder Method, Reinforced by AI

Years ago, we talked about the Camcorder Method: capture the work as it happens instead of trying to document it afterwards. With AI, that approach gets supercharged.

When you’re configuring a tenant, fixing a tricky issue, onboarding a client, or even handling an escalation, hit record.

• Screen recording
  

• Phone camera
  

• Meeting recording if you’re doing it live with a client or tech

The tool doesn’t matter. The habit does.

As you work, talk through what you’re doing and—more importantly—why. Explain the judgement calls. The checks you instinctively run. The things you don’t do, and why.

This is the stuff that never makes it into documentation, but it’s exactly what junior staff, new hires, and future-you need to understand.

From Recording to Playbook (Without Starting from Scratch)

Here’s where MSPs usually get stuck. They think recording is only half the job, and now they need hours to “turn it into a proper process”.

That used to be true. It isn’t anymore.

Take the recording transcript and give it to AI. Ask it to turn that raw thinking into a draft playbook, SOP, or checklist. Not a final version—a starting point that reflects how the work is actually done in your business.

Then use one of my favourite prompts:

“Ask me any questions that would make this process clearer or easier for the next person to follow.”

This flips the dynamic. Instead of you trying to remember everything you know, the AI actively looks for gaps, assumptions, and missing steps. You answer those questions once, and the documentation improves permanently.

This is exactly how senior staff think when they onboard someone: “They’ll probably get stuck here… they’ll ask me about this… they’ll miss that.”

Now you can capture that thinking without being interrupted mid-job.

The Stranger Test (Be Brutally Honest)

Here’s the litmus test I apply to every process document.

If a capable stranger from another MSP picked this up, could they execute it end-to-end without calling you?

If the answer is “probably not”, the process isn’t finished.

That doesn’t mean it has to be perfect. It means it can’t rely on tribal knowledge, hallway conversations, or “just ask Dave, he knows”.

Every time you have to jump in and clarify something, that’s feedback. Record it. Update the playbook. Feed it back into AI. Over time, the number of interruptions drops—and so does your personal bottleneck.

This is how you scale without cloning yourself.

Why This Actually Matters to the Business

This isn’t about documentation for documentation’s sake.

• It reduces risk when key people are away or leave
  

• It shortens onboarding for new techs
  

• It creates consistent outcomes for clients
  

• It gives you something solid to build automation and AI on later

AI doesn’t magically fix messy operations. It rewards clarity. If your processes only exist in your head, AI just amplifies the chaos.

Recording the work is the fastest way I know to get that clarity without stopping the business to “do documentation”.

Final Thought: Don’t Overthink Step One

If you’ve been putting this off because it feels too big, start smaller.

Record the next task you do that you’ve done a hundred times before. Talk it through. Transcribe it. Let AI help shape it.

You don’t need a transformation project. You need momentum.

Hit record. The rest follows.

I was talking to an MSP owner recently—let’s call him Antoni—who looked completely wrecked. His inbox was overflowing, projects were backing up, and every interruption felt like a crisis. I asked him a simple question:
“Why don’t you hand some of this off?”

He didn’t hesitate.
“I can’t.”

Not because his team wasn’t capable. Not because he didn’t trust them.
Because there was nothing to hand over.

No instructions. No documented process. No shared understanding of “how this gets done around here”. Just a guy drowning in work, telling himself the only solution was to work harder.

I see this exact pattern across MSPs all the time.

The Real Bottleneck Isn’t Workload

Most MSPs don’t actually have a volume problem. They have a systems problem.

Email becomes unmanageable because only one person knows how to triage it “properly”.
Hiring drags on because recruitment lives in someone’s head.
Content never scales because every post starts from a blank page.
Accounting breaks down at month‑end because the process was built for one person, not a business.

The common thread?
The business runs on tribal knowledge instead of repeatable systems.

And here’s the uncomfortable truth: until something is documented and shared, it doesn’t really exist. It’s just personal effort masquerading as process.

What Copilot Exposes (Whether You Like It or Not)

This is where Microsoft 365 Copilot becomes interesting—not as an AI tool, but as a force multiplier for reality.

Copilot doesn’t magically fix broken businesses. What it does is amplify whatever foundations already exist.

If your documentation is scattered, outdated, or non‑existent, Copilot will surface that instantly. If your processes are clear, well‑structured, and centrally stored, suddenly they become usable by more people, more often, without constant supervision.

I’ve seen MSPs try to “roll out Copilot” hoping it will reduce workload, only to realise their biggest problem wasn’t effort—it was ambiguity.

Copilot can summarise a process, draft a response, or explain a task. But it can’t invent clarity that isn’t already there.

Systems First, Scale Second

What Antoni really needed wasn’t better inbox management. He needed a system someone else could step into without panic.

That means:

• A documented way of handling incoming requests
  

• Clear decision boundaries (what to respond to, what to delegate, what to defer)
  

• Templates and examples that remove guesswork

Once those exist, Copilot becomes genuinely powerful. A junior staffer can ask, “How do we handle this type of request?” and get grounded guidance based on your way of working—not a generic answer from the internet.

The same applies to hiring, onboarding, sales follow‑up, project delivery, and internal reporting. If the process can’t survive you stepping away for a week, it isn’t a process yet.

Stop Confusing Heroics with Progress

MSPs are especially bad at rewarding hero behaviour. Late nights. Inbox zero at 11pm. Solving everything personally.

It feels productive, but it’s fragile. And it doesn’t scale.

The MSPs that grow without falling apart are the ones that treat systems as assets. They build once, refine often, and use tools like Copilot to extend capability across the team—not to prop up chaos.

Copilot works best when it sits on top of clarity. It helps people find answers faster, make better decisions, and spend less time reinventing the wheel. But only if the wheel has been built properly in the first place.

The Takeaway

If your first instinct under pressure is “I’ll just work harder”, that’s a warning sign—not a badge of honour.

Before you add more staff, more tools, or more AI, ask yourself this:
“If I had to hand this task to someone tomorrow, could I?”

If the answer is no, that’s where the real work starts.

Create systems that scale without chaos.
Copilot will do the rest—but only after you’ve done your part.

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

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

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

Everyone else tends to borrow.

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

Doing the work changes your language

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

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

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

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

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

The AI gold rush has exposed the gap

AI has made this divide painfully obvious.

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

The barrier to credibility hasn’t.

Most AI commentary falls into the same bucket:

• Vague promises
  

• Recycled examples
  

• Zero mention of friction

Very little of it answers the questions businesses actually ask:

• Why didn’t staff use it?
  

• What broke when permissions were wrong?
  

• Where did the time savings not appear?
  

• What did we stop doing to make this work?

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

MSPs live or die on credibility

This matters even more for MSPs and IT pros.

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

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

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

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

Borrowing ideas is safe. Creating them isn’t.

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

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

But that’s also where authority comes from.

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

Ask yourself the harder question

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

Am I speaking from repetition, or from experience?

Have I tested this, or just read about it?

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

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

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

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

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

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

But that’s not how meaningful progress actually works.

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

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

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

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

They’re not.

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

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

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

The issue is trust.

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

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

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

But it adds up.

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

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

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

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

You just need to keep going.

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