Write it down before the one person who knows goes on vacation

Every small business has at least one person who is the system. They know which login runs the phone line, why the invoice template has that strange extra field, and what to do when the booking calendar stops syncing on a Monday morning. Nobody planned it that way. It happened because they were the one who set it up, and then they were the one who fixed it the next time, and the time after that.

It works fine until that person takes a week off. Then a small problem turns into a long day. The office calls their cell phone at the beach. Someone guesses at a setting and makes it worse. A customer waits on hold while three people search old emails for a password.

When we build custom software and voice reception for service businesses, we ask early who that person is. Then we help them write down what is in their head before they need a break. This post covers what to write, how to keep it short enough that people use it, and how to test it without waiting for a bad week.

What belongs in the runbook

A runbook is a plain document that says how to keep something running and what to do when it stops. It does not need to be long or pretty. It needs to be findable and correct.

For most service businesses, we start with these sections:

• What runs where. A short list of every system the business depends on: the phone line, the scheduling tool, the payment processor, the texting service, the website, and any custom software. For each one, write what it does in one sentence and who the account belongs to.
• How to get in. Where the logins live. Not the passwords themselves in the document, but the name of the password manager entry or the person who can grant access. If the only copy of a login is in one person's browser, that is the first thing to fix.
• What normal looks like. How many calls come in on a typical weekday, roughly when the daily reports arrive, what the morning schedule usually looks like. People cannot spot a problem if they do not know what normal is.
• The common failures. The five or six things that actually go wrong, written as symptom first. "Bookings are not showing up on the tech's phone." "The phone agent is sending callers to voicemail." "Customers say they did not get a confirmation text."
• Who to call. For each system, the vendor's support number or page, the account number they will ask for, and the person inside the business who has authority to make changes.

That is usually two to four pages. If it grows past ten, it is probably trying to be a manual, and nobody will read it during a problem.

Write each fix as steps someone else can follow

The hardest part is writing fixes for a person who has never done them. The expert skips steps without noticing, because those steps are automatic for them.

A useful test is to write each fix as numbered steps, then hand it to someone who has not done it before and watch them try. Do not help. Every place they stop or ask a question is a missing step.

Here is the kind of entry we aim for. The details are made up, but the shape is real.

Symptom: Callers say the phone agent told them no times were open, but the schedule has openings.

1. Open the scheduling tool and check that tomorrow's slots are marked as bookable and not only visible.
2. Check that the connection between the phone agent and the calendar is still active. In the settings page for the integration, the status should say connected.
3. If it says disconnected, reconnect it with the shared office account, not a personal one.
4. Call the business line from a cell phone and ask for a time tomorrow. Confirm the agent offers one.
5. If it still fails, send the time of your test call to the person listed under "who to call" for the phone system.

Step four matters most. A fix is not done until someone has checked it from the customer's side.

Keep it where people already look

A runbook that lives in one person's personal drive is not much better than one that lives in their head. Put it somewhere the whole office can open without asking: a shared folder, the team wiki, or a pinned page in the tool everyone already uses.

Print one copy of the first page, too. If the internet is down, or the shared drive is the thing that broke, the phone numbers and account numbers on paper are what get the business moving again.

Then tell people it exists. The most common failure we see is a good runbook that nobody knew about. Mention it in a team meeting. Link it in the place people go when they report problems.

Test it before the vacation

The best time to find out a runbook is wrong is on a quiet Tuesday, not on the first day the expert is gone.

A simple drill:

1. Pick one common failure. Something that has actually happened in the last few months.
2. Hand the runbook to someone else. A front desk lead, an office manager, or a newer team member.
3. Ask them to walk through the fix. If it is safe, do it for real in a test account or after hours. If it is not safe, have them talk through each step and show where they would click.
4. Write down every question they ask. Each one becomes an edit to the document.
5. Have the expert stay quiet. This is the hard part. The point is to find what only they know.

Run one drill a month. It takes less than an hour, and after three or four rounds the document usually covers the problems that matter.

Keep it current without making it a project

Runbooks go stale the same way any document does. Someone changes a setting, switches vendors, or adds a new phone number, and nobody updates the page.

Two habits keep it honest. First, whenever a problem gets fixed, the person who fixed it spends five minutes checking that the runbook entry matched what they actually did, and updates it if not. Second, put a short review on the calendar every quarter. Read the "what runs where" list and cross off anything the business no longer uses.

When we hand over custom software or set up a voice reception line, the runbook is part of the delivery. It covers how the system behaves, what the common failures look like, and how to tell whether a problem is on our side or somewhere else. We would rather the office be able to handle the small things on their own than wait on us for a setting they can change in two minutes.

Start with one page this week

You do not need to document everything at once. Sit down with the person who knows the systems and ask one question: "If you were unreachable for a week, what would break first?"

Write down their answer, the steps to fix it, and who to call if the steps do not work. That is page one. Put it in the shared folder, tell the team, and run the drill next week. The rest of the runbook grows from there, one problem at a time, and the next vacation gets a lot quieter.