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 table further down sets out what goes in each of the four documents.
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 table below is those four documents on one page: what each one records. Write yours once, keep the live commitments 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.
| Item | What it records | Priority |
|---|---|---|
| Operations reference | ||
| Money and banking | account, how payments come in, who can access | ACCOUNT, HOW PAYMENTS COME IN, WHO CAN ACCESSMust exist |
| Logins and tools | password manager and its emergency access | PASSWORD MANAGER AND ITS EMERGENCY ACCESSMust exist |
| Where work lives | files, work in progress, backups | FILES, WORK IN PROGRESS, BACKUPSMust exist |
| Recurring bills | what must be paid, and when | WHAT MUST BE PAID, AND WHENMust exist |
| Who to call | accountant, key supplier, trusted peer | ACCOUNTANT, KEY SUPPLIER, TRUSTED PEERRecommended |
| Recurring procedures | ||
| Invoicing | when, template location, who is on different terms | WHEN, TEMPLATE LOCATION, WHO IS ON DIFFERENT TERMSMust exist |
| Delivery in flight | the steps, or a link to the SOP | THE STEPS, OR A LINK TO THE SOPMust exist |
| Weekly admin | what cannot slip, and how often | WHAT CANNOT SLIP, AND HOW OFTENRecommended |
| Backups | what is saved, where, how to restore | WHAT IS SAVED, WHERE, HOW TO RESTOREMust exist |
| Live commitments (update weekly) | ||
| Active clients | who, and what stage each is at | WHO, AND WHAT STAGE EACH IS ATMust exist |
| Due this week | deliverables and deadlines in the cover week | DELIVERABLES AND DEADLINES IN THE COVER WEEKMust exist |
| Money outstanding | owed to you, and owed by you | OWED TO YOU, AND OWED BY YOUMust exist |
| Do not touch | anything that should wait for your return | ANYTHING THAT SHOULD WAIT FOR YOUR RETURNRecommended |
| Decision rules | ||
| Invoice goes overdue | the action, or leave it until you return | THE ACTION, OR LEAVE IT UNTIL YOU RETURNMust exist |
| Client emergency | who decides, and what they can commit to | WHO DECIDES, AND WHAT THEY CAN COMMIT TOMust exist |
| Tool or site down | who to contact, what to say to clients | WHO TO CONTACT, WHAT TO SAY TO CLIENTSRecommended |
| New enquiry arrives | holding reply, and when you will respond | HOLDING REPLY, AND WHEN YOU WILL RESPONDRecommended |
| Anything not covered | the one person to call, and how | THE ONE PERSON TO CALL, AND HOWMust exist |
A Runbook Example, Filled In
The table 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 the operations reference, because it is the one a stand-in cannot function without and cannot work out for themselves. Then the decision rules, because deciding the predictable disasters in advance is where most of the value sits and it costs nothing to write. Then 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 the decision rules say "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.