Lock in Systems: How MSPs Document the Work So It Runs Without Them

Lock in Systems is the L in SCALE — the fourth phase of the BSP transformation. By the time the firm reaches Lock, it has a real offer, a working factory, and an engine that produces revenue. What it doesn’t have yet is operational durability — the property that lets the business run for two weeks straight without the founder making a single decision.

Lock is where that durability gets built. The phase has three workstreams:

Standard Operating Procedures (SOPs) — documenting the recurring work
CESI problem-solving — a framework for handling everything that isn’t recurring
Growth systems — the operational rhythms that turn the SBR engine into a system, not just a meeting cadence

It’s the least glamorous phase, and the one that determines whether the BSP is a transferable business or a great job for the founder.

Why systems lock matters

There’s a question every BSP eventually has to answer, and it usually arrives unannounced: can the firm run for two weeks without you?

If the answer is yes, the firm is a business. It can scale, it can be sold, it can survive the founder taking a real vacation or getting hit by the proverbial bus.

If the answer is no, the firm is the founder. Revenue can be huge and margins can be excellent, but the asset is fragile — it depends on the founder’s continued presence and continued attention. That business sells, if it sells at all, at a steep discount.

The Lock phase is the operational answer to that question. Every workstream below moves capability out of someone’s head and into a system that survives without them.

Workstream 1: SOPs — documenting the recurring work

Most MSPs have some documentation. Almost no MSPs have enough.

The Lock-phase test for SOPs: can a new team member execute the work in their first month, without you in the room, using only the documentation?

If the answer is no, the documentation isn’t done. If the team’s response to questions is “ask Mike,” Mike is the documentation — and Mike is the ceiling.

What gets documented

Three categories:

Delivery SOPs. Every recurring delivery task — onboarding, monthly reviews, ticket resolution patterns, incident response, change management. The format matters less than the completeness: someone who hasn’t been on the team for six months should be able to execute the work from the document.
Process SOPs. How the business runs itself. Hiring, performance reviews, financial close, vendor selection, client renewals. These rarely get written until the business is hiring its third employee — by which point three different versions exist in three different heads.
Client-specific runbooks. Each client gets a runbook covering their specific stack, their specific people, their specific quirks. Anyone qualified should be able to pick up the runbook and serve the client. This is where most workshops fail — the senior tech “just knows” the client’s environment, and that knowledge never makes it onto paper.

How to actually get the documentation written

The biggest barrier to documentation isn’t motivation; it’s the founder still being the bottleneck of “what’s the right way to do this?” Two practical patterns:

Document during execution. Whoever is doing the work writes the SOP as they do it. The SOP gets reviewed by one other person — not the founder — and goes live.
Document by recording. Loom or similar — record the work being done, transcribe it, structure the transcript into an SOP. Fast and accurate, especially for technical procedures.

The mistake to avoid: trying to build a comprehensive SOP library in a quarter. That’s a six-month project disguised as a 90-day initiative. Better: pick the 20 highest-frequency tasks, document those first, build the library from there.

Workstream 2: CESI — handling everything that isn’t recurring

SOPs work for known, repeating problems. They don’t work for the 30% of the firm’s work that’s actually novel — a new client problem, a new technology decision, a process that just broke. For that work, the firm needs a framework, not a procedure.

We teach CESI — a four-step structure for problem-solving that anyone in the firm can use:

C — Clarify. Define the actual problem. Not the symptom, not the customer’s framing of it, not the first thing that comes to mind. The most common source of failed solutions is solving the wrong problem.
E — Explore. Brainstorm and hypothesize multiple solutions. Don’t commit to the first plausible one. Generate options, weigh them, pick the most promising.
S — Solve. Test the chosen solution. Small experiment first when possible — proof before scale. If it works, document the answer.
I — Implement. Deploy the solution at scale and document it for repeatability. The next time someone hits this problem, they’re inheriting your answer.

The reason CESI matters operationally: without it, every problem gets solved as a one-off. The firm learns nothing structurally. The same problem reappears in three months, gets solved again from scratch, and the founder gets to feel useful one more time.

With CESI, the firm builds an operating intelligence. The SOPs capture what’s repeatable; CESI captures the lessons from what wasn’t. Together they create a business that gets smarter over time, not just busier.

CESI lives in a real document — typically called a problem log or hurdle log — that the team reviews monthly. Each entry has the problem, the explored options, the chosen solution, and the result. After a year of disciplined use, the log is the firm’s most valuable operational asset.

Workstream 3: Growth systems

The third workstream is the operational rhythm that turns the Accelerate phase’s engines into systems rather than activities.

Three rhythms matter:

The weekly leadership meeting

A 90-minute weekly meeting, structured around: metrics review, issue resolution, strategic decisions. Without this, leadership decisions get made in hallway conversations and never communicate to the rest of the company.

The agenda typically runs: – 10 minutes: scorecard review (key numbers, last week) – 15 minutes: client and team headlines (good news + concerns) – 60 minutes: issue resolution (the longest block — work through the list) – 5 minutes: conclude with cascading messages — what does the team need to hear this week?

The monthly business review

A monthly look at the business in aggregate. P&L, pipeline, client health, hiring, project status. This is where small problems get caught before they become quarter-killers. Run by the founder; attended by the leadership team.

The quarterly planning rhythm

Every 90 days, leadership sets 3–5 quarterly “rocks” — non-negotiable outcomes that get the team’s full attention. Rocks are big-enough-to-matter, small-enough-to-finish. Each rock has an owner and a definition of done.

Quarterly rocks are also what connect the annual strategy (set in Expand with Intent) to weekly execution. Without them, strategy stays on the strategy doc and execution stays disconnected from intent.

Why these rhythms are part of “Lock”

These meetings aren’t optional management overhead. They’re the operating system of the firm. They’re what turns intent into outcomes systematically rather than heroically.

Most MSPs run some version of one or two of these rhythms inconsistently. The Lock-phase discipline is to run all three, on schedule, with documented outputs, regardless of how busy the week is. Skip a weekly leadership meeting twice and the firm degrades back toward hallway management within a month.

What “done” looks like for the Lock phase

You know you’ve completed L when:

A new team member can execute the recurring work in their first month using only the documentation
The firm has a problem log with at least 20 entries, reviewed monthly, with documented outcomes
The weekly leadership meeting runs every week — same time, same structure, even when the week is on fire
The monthly business review produces a written summary that the leadership team reads and acts on
Quarterly rocks are set, tracked, and completed at a 70%+ rate

The Lock test, again: can the firm run for two weeks without the founder? If yes, the phase is done. If no, find the workstream where the founder is still the system and finish it.

Where Lock typically sits in the calendar

Lock runs months 7–12 of the BSP transformation, overlapping with the late stages of Accelerate Success. The reason it comes here, not earlier, is that you can only document what’s stable — and the Foundation, Factory, and Accelerate work is what creates the stable thing worth documenting.

Documenting an unstable process locks in chaos. Document only the work that’s been running well long enough that the SOP captures the right way to do it.

Next phase: Expand with Intent — turning a locked, durable BSP into one that can scale beyond the founder.

For the full framework, see The BSP Framework. For your readiness score, take the BSP Readiness Assessment — the Lock section covers SOP maturity, CESI usage, and rhythm consistency.