The System That Runs Perfectly — Until You Go on Holiday
You took a week off. First proper break in eighteen months.
Before you left, you wrote it all down. The supplier contact details. The steps for processing returns. What to do if the card machine throws an error. You even recorded a Loom video walking through the Friday reconciliation.
You came back to fourteen Slack messages that all started with "Quick question" and a returns backlog because nobody was sure whether a scratched item counted as damaged or just cosmetic. The documentation sat exactly where you left it. Untouched.
This isn't a people problem. Your team isn't incompetent. They didn't ignore your notes out of spite.
The problem is that what you wrote down wasn't actually a system. It was a description of what you do — with all the judgment calls still living in your head.
The difference between a procedure and a decision tree
A procedure tells someone what to do when everything goes as expected. Step one, step two, step three, done.
But work doesn't go as expected. The supplier sends the wrong quantity. The customer's story doesn't match the order notes. The software shows an error code that isn't in the manual.
When you're running the process, you handle these without thinking. You've seen a hundred variations. You know which deviations matter and which don't. You make twelve micro-decisions per task and don't even register them as decisions.
Your team doesn't have that context. So when something doesn't fit the procedure exactly, they stop. They wait. They message you.
And you, on a beach trying not to check your phone, become the bottleneck again.
What a real system actually needs
A system that runs without you has to answer three questions your current documentation probably doesn't:
1. What counts as "normal" and what counts as an exception?
You need explicit boundaries. If a return is under £30, process it no questions asked. Over £30, check for photos. Over £100, escalate. Your team can't read your mind about where the lines are. Write them down.
2. When something falls outside normal, what's the decision logic?
This is where most SOPs fail. They describe the happy path and leave the forks unmarked. But the forks are where your team gets stuck. Map them out. "If the customer claims they never received it but tracking shows delivered, do X. If tracking shows attempted delivery, do Y."
3. Who has authority to make which calls?
Sometimes the blocker isn't knowledge. It's permission. Your team knows what the right call probably is, but they're not sure if they're allowed to make it. So they wait for you. Spell out the authority boundaries. "You can approve refunds up to £50 without asking anyone. Above that, check with Sarah."
The five-exception test
Here's a quick way to find out if your documentation is actually a system or just a description of you.
Pick a process you've documented. Now think of the last five times something went slightly wrong with that process — a customer said something unexpected, a supplier did something unusual, a number didn't match.
Is the answer to each of those situations in your documentation? Or would your team have had to message you?
If it's the second, you haven't built a system. You've built a script that only works when the world behaves itself.
The uncomfortable part
Building real decision trees takes longer than writing procedures. You have to think through edge cases. You have to make explicit the judgment calls you've been making on autopilot. You have to actually decide where the authority boundaries sit, which means trusting people with decisions you've always kept for yourself.
This is why most founders skip it. Writing "here's how to process a return" takes twenty minutes. Writing "here's how to process a return including every variation you might encounter and what to do about each one" takes a couple of hours. And it forces you to confront how much of your "process" is actually just you, every time.
But here's the trade-off: two hours now, or fourteen Slack messages every time you try to take a break. You pick.
Start with the one that burned you last time
You don't need to rebuild everything at once. Think about your last holiday, or the last time you were sick, or even just a busy day when you didn't check messages for a few hours.
What broke? What piled up? What decisions waited for you?
That's your first candidate. Take that process, add the exception handling, add the authority boundaries, and see what happens next time you step away.
If you come back to a clean inbox instead of a pile of "quick questions," you've built something real.
If this sounds like the kind of thing you've been meaning to sort out but haven't found the time to think through properly, that's exactly the work we do with founders. Happy to talk through it.