Writing Down How Your MSP Actually Delivers Service

Published by
Throne of Profit Editorial

Reviewed by
William Hassell
Founder & Chief Editor, Throne of Profit

Every managed services shop has a person who "just knows how we do it." How a new client gets onboarded. How a workstation gets imaged. How a mailbox migration gets staged so nothing breaks on Monday morning. It lives in that person's head, and the business runs fine — right up until they're on vacation, or out sick, or they quit and take fifteen years of judgment out the door with them. The work your MSP delivers every week isn't actually a system yet; it's a collection of habits living inside a few people, and habits don't scale, don't train, and don't survive the person leaving.

The fix isn't a fancier tool or a thicker manual nobody reads. It's the plain, unglamorous act of writing down how the recurring work actually gets done — the onboardings, the offboardings, the standard rollouts — so the procedure lives in the business instead of in someone's memory. This is systemization, and it's the difference between a shop that depends on heroes and one that runs on process.

   WHERE THE PROCEDURE LIVES

   in one tech's head   →  ░░░░░  works until they're gone
   in a chat thread     →  ░░▇░░  found sometimes, half-right
   in a written SOP     →  ▇▇▇▇▇  same result, any tech, every time

Owner symptoms

• The same task comes out different depending on which tech picks it up.

• You can't take a vacation because certain jobs only one person knows how to do.

• New hires take months to get useful because nothing is written down.

Why this happens

MSP work grows by accretion, not design. You solved a problem once, it worked, and it quietly became "the way we do it" — never written, never reviewed, just repeated from memory. Documentation always feels like the thing you'll do when the tickets slow down, and the tickets never slow down. So the knowledge stays tribal: passed tech-to-tech by watching and asking, with each person carrying a slightly different version. It works well enough day to day that the risk stays invisible — until the one person who knows the migration steps is unreachable during a cutover.

Common mistakes

• Waiting for the perfect template instead of writing down the messy real steps you already follow.

• Documenting the exotic, ignoring the routine — writing up the rare disaster while the weekly onboarding stays in someone's head.

• Making SOPs too long to use — a 40-step wall of text nobody opens mid-ticket.

• Writing it once and never touching it so the doc drifts from how the work actually gets done now.

• Leaving it to whoever has time, so procedures are scattered, inconsistent, and impossible to find under pressure.

Business consequences

Tribal knowledge caps the size of the shop. You can't hand off work you can't describe, so the owner and a couple of senior techs stay the bottleneck on everything that matters. Onboarding takes longer and comes out uneven, quality swings by whoever caught the ticket, and every departure is a small crisis. The owner who writes down the recurring work gets something different: any competent tech runs the standard job to the same result, new hires get useful in weeks instead of months, and the business keeps its knowledge even when people leave. The procedure becomes an asset the shop owns, not a liability walking around on two legs.

How experienced operators think about it

They treat a repeatable task as a product of the business, not a personal skill. The test is simple: could a competent tech who's never done this job follow the written steps and get the right result? If not, the work isn't systemized yet — it's still tribal, no matter how well their best person does it. They start with the highest-frequency, highest-pain jobs — onboarding, offboarding, standard deployments — because that's where consistency pays off fastest. And they keep SOPs short and usable, written for the tech doing the work at 2 p.m. under pressure, not for a binder on a shelf. The goal isn't documentation for its own sake; it's the same job coming out the same way, whoever runs it.

Practical actions

1. List your top ten recurring jobs — the onboardings, rollouts, and offboardings you do most — and rank them by how often they happen and how much it hurts when they go wrong.

2. Have the person who does it best narrate it while someone writes the actual steps down. Capture what really happens, not the idealized version.

3. Write for use, not for show. Short numbered steps, the decision points, the easy-to-miss gotchas. If a tech can't follow it under pressure, it's too long.

4. Test it with a different tech. Have someone who didn't write it run the job from the doc alone. Where they get stuck is where the SOP is wrong.

5. Give SOPs one home everyone knows, and put a name and a date on each so it's clear who owns keeping it current.

6. Review the routine, not the rare. Revisit the high-frequency procedures on a set cadence so they track how the work is actually done now.

Questions every owner should ask

• If my most senior tech quit tomorrow, which jobs would nobody know how to run?

• Does a standard onboarding come out the same regardless of who handles it?

• How long does a new hire take to run our common tasks unsupervised — and why?

Frequently asked questions

Where do I start when everything feels undocumented?
Don't try to document everything — you'll stall. Start with the jobs that are both frequent and painful when they go sideways: client onboarding, offboarding, and your most common standard rollout. Those three cover a huge share of the recurring work and give you the fastest payoff. Write one, use it, fix it, then move to the next. A shop with five real, used SOPs is far ahead of one with a fifty-page manual nobody opens.

How do I keep SOPs from going stale the moment I write them?
Assume they will drift, and build in a light habit instead of a heavy project. Put a name and a last-reviewed date on each one, and give your highest-frequency procedures a quick review on a regular cadence. The fastest way to catch a stale SOP is to have the tech running the job flag anything that no longer matches reality — the people using it are your best maintenance system.

Related articles

• Running a Profitable Managed IT Services Business — the pillar.

• Standardizing the Tools Clients Run So You Stop Supporting a Zoo — standardizing what you support so SOPs can exist.

• Shifting From Firefighting to Preventing the Fires — the proactive posture SOPs make possible.

• Why Jobs Take Longer Than You Quoted — the general time-overrun problem.

• Where Time Leaks on a Typical Job — where inconsistent process quietly costs hours.

Every business has more decisions than time

Whether you need help solving one problem, evaluating a major opportunity, or making a company-changing decision, Throne of Profit gives you consulting capacity on demand.

Purchase only the consulting capacity you need and use it across Weekly Focus, Strategic Focus, Financial Focus, and ThinkTank engagements.

Explore Throne of Profit