The runbook is the product

Most managed-services engagements treat documentation the way most software engagements treat tests: a thing you do if there’s time. There’s never time.

We’ve inverted it. The runbook is the deliverable. The work happens in service of the runbook. The client owns the runbook when they leave.

This piece is about why that change matters and what falls out of it.

The case against tribal knowledge

The default mode for small managed-services firms is tribal knowledge. The senior engineer remembers how to fix the VPN. The same engineer remembers the workaround for that one Exchange Online quirk that breaks signed S/MIME on Outlook for iOS. None of it is written down. When the engineer leaves — sick day, vacation, new job — the knowledge leaves with them.

Customers tolerate this until they can’t. The moment a tribal-knowledge MSP fires its best engineer is the moment its customers feel it. Tickets that used to close in 15 minutes take three days. The customer files an RFP.

The reason this happens is that writing things down feels like overhead. It isn’t billable, the immediate customer doesn’t notice, and the engineer who’d write it is the same engineer with the longest ticket queue.

What changes when the runbook is the product

When you treat the runbook as the deliverable, three things shift:

1. The work is finished when it’s written down. A ticket that’s “resolved” but undocumented is half-done. The engineer’s queue can’t move until the runbook entry exists. This sounds expensive — it isn’t. The first time you save the runbook is the only expensive time.

2. The AI gets useful. All those runbooks become the corpus for document Q&A. The next operator asks the question, the system answers from your own writing. The knowledge stops being tribal because it’s literally on disk.

3. The customer can leave with their dignity intact. When a client cancels, they get the runbooks. Every one of them. We hand back tenant ownership and the documentation we wrote while we were inside. There’s no clawback, no leverage move, no “well actually you’ll need us to maintain those.” If the runbooks are good, the customer might come back. If they’re bad, we deserved to lose them.

What this looks like in practice

We use the portal for both ticket work and runbook storage. Runbooks live alongside the tickets that produced them, so the next operator can see what triggered the writing, not just the writing.

A representative runbook in our system:

Title: Restore an accidentally-disabled Conditional Access policy Context: Happened in Acme Co’s tenant, 2026-04-15, after a misclick during a baseline review Detection: Users started getting MFA prompts on every M365 connection within ~10 minutes Resolution: Entra admin centre → Policies → Restore from change history (Microsoft retains 30 days) Prevention: Always review policy changes in audit log before closing the change window Time to fix: 4 minutes once we knew. Time to write down: 8 minutes. We’ll never spend 4 minutes on this again.

That runbook turned a four-minute resolution into a permanent reference. The next time it happens — to anyone in any of our tenants — the answer is in the corpus.

Why we tell clients this up front

We say “the runbook is the product” in the first meeting because it sets the expectation correctly. If a customer thinks they’re buying hours, they’re going to be frustrated when we spend the last 15 minutes of an issue writing it up. If they understand they’re buying compounding institutional memory, the documentation time stops being a tax — it’s the thing they paid for.

Our oldest runbook is from before Limestone existed in its current shape. It’s still in the corpus, still cited, still saving someone an hour every few months. The runbook is the product. The work is in service of it.

---

If you’d like to see what one of our runbooks actually looks like — anonymised — email us. Happy to share.