On this page
A runbook is a single operational reference that lets someone step in and keep things running when the usual person cannot. It comes from IT, where an on-call engineer needs to fix a system at 3am without waking anyone, but the idea transfers cleanly to a business of one. Here it is four documents: an operations reference for where everything lives, the procedures for tasks that repeat, a list of live client commitments, and a short set of decision rules for the things that go wrong. Together they answer one question. If you were unreachable for a week, could anybody else keep the business alive without calling you? The template further down is the whole runbook on one page, ready to fill in.
Most of what is written about runbooks assumes a server and a team. Incident response, escalation tiers, monitoring alerts, an on-call rota. That framing is correct for the world it came from, and it is why the top search results are all IT companies explaining how to recover a database.
None of it survives contact with a business where the on-call engineer, the operations manager and the person doing the work are the same individual. But the underlying problem is exactly the same, and for a business of one it is sharper: there is no second person to hand to. A business of one is one illness away from every client learning at once that there is nobody else to call.
What a Runbook Actually Is
A runbook is a reference you follow under pressure, when there is no time to work it out and no one to ask. That is the whole definition, and it is worth holding onto because it explains what belongs in one and what does not.
It is not a strategy document, because nobody reads strategy at the moment a system is down. It is not a full manual, because a manual is for learning and a runbook is for doing. It contains only what someone needs to keep the essential things running: where the money and the logins are, the steps for the tasks that cannot wait, who is owed what right now, and the rule for the handful of things that predictably break. Everything else can wait until you are back.
The test for whether something belongs is simple. Would a capable person who is not you need it to get through a week without damaging a client relationship or missing a payment? If yes, it goes in. If it is only useful for growing the business rather than keeping it alive, it belongs somewhere else.
Runbook vs SOP vs Playbook
These three words get used interchangeably and they are not the same thing. The difference matters because it tells you how much to write and when to reach for each one.
A standard operating procedure is the detailed, repeatable way to do one recurring task correctly every time: how you invoice, how you onboard a client, how you back up your files. It is deep and narrow. A written SOP is what you follow to do the thing well, whether or not anything has gone wrong.
A playbook is a decision tree for a scenario: if a client asks for a refund, here are the options and how to choose between them. It is about judgment under a known situation, and it usually has branches.
A runbook sits above both. It is the operational index that keeps the whole business running and points to the SOPs and playbooks when they are needed. An SOP tells you how to invoice; the runbook tells whoever is covering that invoicing happens on the 1st, where the template is, and which clients are on different terms. The runbook is the map. The SOPs are the detailed routes.
Aziz's take: If you only ever build one of the three, build the runbook, and keep it thin. A perfect SOP for a task nobody urgently needs is less valuable than a scrappy one-page runbook that means your business does not stop when you do. The mistake I see is people writing beautiful procedures for the interesting parts of the work and never writing down the boring, load-bearing facts: which bank account, which login, which client is halfway through a project. That is the stuff that actually strands a stand-in.
The Four Documents That Replace You for a Week
For a business of one, a complete runbook is four short documents. Not four folders, four pages. The point is not to be exhaustive, it is to be enough that someone competent could hold the line for a week.
- The operations reference. Where everything lives. The bank and how money moves, the logins and tools, where client files and work in progress are saved, the recurring bills that must be paid, and the two or three people worth calling. This is the document that costs nothing while everything is fine and everything when it is not.
- The recurring procedures. The tasks that happen on a clock and cannot simply pause: invoicing, whatever delivery is mid-flight, the weekly admin that keeps clients from noticing anything changed. Each one is a short procedure or a link to an existing SOP, not a full lesson.
- The live commitments. Who is a client right now, what stage they are at, what is due this week, and what money is outstanding in both directions. This is the only one of the four that goes stale fast, which is why it is a list you update rather than write once. Payments tied to milestones make this far easier to hand over, because the next step is written into the schedule.
- The decision rules. The short list of things that predictably go wrong and the rule for each: an invoice goes overdue, a client has an emergency, a tool or the site goes down, a new enquiry arrives. For each one, either the action to take or the instruction to leave it until you are back. Most of a week's panic is a handful of situations you could have decided in advance.
The template below is those four documents as a single fill-in reference. Complete it once, keep the live-commitments section current, and it is the thing you hand to whoever covers for you, or the thing you follow yourself when you come back to a week you would rather forget.
How to use this
Fill in
- Every highlighted value. Where something does not apply, write NONE rather than deleting the row, so the stand-in knows it was considered.
- Section 01 first. It is the one a stand-in cannot function without and cannot guess.
- Keep passwords in your password manager and put the manager and its emergency access here, never the passwords themselves.
Check before you file it
- Section 03 was updated this week. It is the only part that goes out of date fast.
- Every tool that touches money or client work appears in section 01.
- A person who has never seen your business could act on section 04 without calling you.
What goes wrong
- Writing it once and never updating the commitments, so the stand-in works from last month's clients.
- Putting real passwords in the file instead of pointing at the password manager.
- Making it exhaustive. A forty-page runbook is one nobody opens in the moment it is needed.
A Runbook Example, Filled In
The template is abstract until you see one completed, so here is a fragment of a real-shaped runbook for a freelance designer taking a week off. One row from each of the four documents, filled the way they should be: specific enough to act on, short enough to scan.
Operations reference, money and banking: "Payments arrive by Stripe into the business current account. My partner has view access via the joint login in the password manager. No card is needed for anything that comes up in a normal week." Recurring procedures, invoicing: "Invoices go out on the 1st. Template is in the invoicing tool under Drafts. Two clients are on 50 percent deposit terms, marked in their files; everyone else is on completion." Live commitments, due this week: "Corville Ltd final logo files due Wednesday, already prepared and in their shared folder, just needs the send button. Nothing else is due." Decision rules, new enquiry arrives: "Send the holding reply saved in email templates, say I will respond by the 12th, do not quote or commit to anything."
Notice that none of it is a lesson in how to be a designer. It is the load-bearing facts and the two or three decisions a week actually turns on. That is the whole art of a runbook: it assumes competence and supplies only the things a competent person could not guess. A written onboarding process and a record of what client data you hold feed straight into it, because both are already the kind of written fact a stand-in needs.
How to Build Yours in an Afternoon
You do not need to research any of this, which is why it takes an afternoon rather than a project. Every answer is already in your head, your inbox or your bank. Work in the order of consequence.
Start with section 01, the operations reference, because it is the one a stand-in cannot function without and cannot work out for themselves. Then section 04, the decision rules, because deciding the predictable disasters in advance is where most of the value sits and it costs nothing to write. Then section 02, the recurring procedures, linking to any SOPs you already have rather than rewriting them. Leave section 03, the live commitments, for last and get into the habit of updating it weekly, because it is the only part that goes out of date between one Friday and the next.
The purpose is not tidiness. It is that the business stops being a single point of failure that happens to be a person. This is the same instinct behind writing down your operations as a whole: every fact you record is a decision someone no longer has to improvise, and the tired or absent version of you benefits from it exactly as much as a stand-in would.
One honest caveat. A runbook with a section marked NONE because you genuinely have no cover arrangement is more useful than one filled with wishful thinking. The value is in seeing the real state of things. If section 04 says "there is nobody to call," that is not a failure of the document, it is the document doing its job and telling you the single most important thing to fix.