Picture the Tuesday it happens. Your best front-of-house lead, or your lead maintenance tech, or the one office admin who actually understands the booking software, calls in sick. By 10 a.m. the same problem shows up that always shows up, a double-booked room, a walk-in with a billing dispute, a vendor invoice that needs three approvals nobody remembers the order of. Normally that person handles it in four minutes without thinking. Today, three other people are standing around a screen trying to reverse-engineer what she does from memory, and the fix takes ninety minutes and one very unhappy customer.

That is not a staffing problem. That is a documentation problem wearing a staffing costume. The fix exists. It has existed for months, maybe years. It just lives in one person's head instead of anywhere your business can actually reach it.

Why the fix never gets written down

Nobody sits down and decides not to document the recurring fire. It happens by omission, and it happens for the same handful of reasons in a restaurant, a rental property office, a contracting company, or a medical practice.

First, the person who solves it fastest is usually your busiest person, and writing a process down feels like a task with no deadline attached to it. Second, the fix often started as a workaround, something improvised under pressure, so it never felt official enough to write up. Third, and this is the one owners miss most, writing it down makes the gap visible. If the fix is only in someone's head, nobody has to admit the business depends on one person showing up every day. Once it is on paper, that dependency is obvious, and obvious problems get pressure to fix themselves. So the workaround quietly survives another quarter, then another year.

The result is a business that runs fine ninety percent of the time and falls apart on the other ten percent, always in a way that looks like bad luck instead of what it actually is, which is an unmanaged single point of failure.

What actually needs to happen

This does not require a policy manual or a new software platform. It requires you to catch the fix the next time it happens and turn it into something that survives a sick day. That means sitting with the person who solves it, watching them do it once, and writing down the actual steps, not the polished version, the real one with the shortcuts they use.

A usable fix, written down correctly, includes:

  • The exact trigger that signals the problem is happening, stated plainly enough that a new hire would recognize it
  • The steps in order, including which system or phone call comes first
  • Who has authority to approve an exception, and who to call if that person is unreachable
  • Where the fix lives, one shared location, not a text thread or someone's personal notes app
  • A note on what changes if the situation is slightly different than usual, because it rarely plays out exactly the same way twice

That last point matters more than people expect. A written fix that only covers the textbook version of the problem gets abandoned the first time reality deviates from it, and then you are back to relying on the one person who can improvise. Write down the edge cases you have actually seen, not the hypothetical ones.

Start with the fire you are tired of

You do not need to document your whole operation this month. Pick the one problem that has cost you the most sleep, the one where you already know exactly who gets the panicked call. Write that one down this week. Test it by having someone else run it the next time it comes up, while the usual person is standing nearby to correct the parts that are wrong. Fix the instructions, not the person's memory of the instructions.

Do that once and you will notice something. The fire does not feel like a fire anymore. It feels like a checklist.

The business that survives a sick day is the one where the fix was never a person to begin with.