The First Five SOPs Every Growing Business Should Write

Your investor asks for documented processes three days before the board meeting. Or a new operations manager joins and asks how order approval actually works, and the honest answer is "call the owner". Either way, someone outside your head now needs to see how the business runs, and there is nothing written down.

This is the moment most owners try to document everything at once. A list gets made, twenty, forty, sometimes sixty processes. It gets handed to an admin executive or a fresh hire with instructions to "write our SOPs". Six weeks later there are a dozen half-finished documents, none of them current, and the exercise quietly dies.

The problem was never the number of processes. It was the order they were tackled in.

Why do most SOP efforts fail before they finish?

They start with whatever felt urgent that week, or with everything at once, instead of the one process that actually stops the business when the owner is unreachable.

When a list of forty processes lands on someone's desk, every process looks equally important because none of them have been tested against a real gap. The person writing them has no way to judge which matters more, so they start alphabetically, or with whatever the owner mentioned last. Three weeks in, the writer hits a decision point they cannot resolve without the owner, such as who approves a credit note over a certain value, and the document stalls. There is no urgency to unstall it because nothing has broken yet.

Documentation efforts fail from lack of sequence, not lack of effort. Covision Consultants and The Systems Effect both point to the same pattern: businesses that succeed with SOPs start narrow and prove the format works before expanding it.

Which process should you document first?

The one that breaks when you are unreachable for a day. Not the one that is repeated most often, not the one an auditor will ask about first, not the one that looks best filed away.

Ask yourself one question: if your phone was off for a full working day, what would stall? For most owners of growing businesses, it is not production or delivery. Production runs on its own momentum for a day. What stalls is approval: a credit limit override, a discount beyond a certain percentage, a purchase order above a threshold, a hiring decision. These sit with the owner because they always have, not because they need to.

Picture an actual sequence. A sales order for a long-standing customer needs credit terms extended by fifteen days beyond the usual thirty. The sales coordinator cannot approve it. The finance head cannot either, because the limit was always the owner's call, verbally, case by case. The owner is on a flight for six hours. The order sits. The customer calls twice. By the time the owner lands and replies, the shipment has missed the day's dispatch slot.

Nothing in that story required new software. It required one page that says who can approve what, up to what value, and what happens when that person is unavailable. That page is the first SOP, not the fifth.

What is the right order for the first five SOPs?

Sequence, not count. Each of the first five removes a specific dependency on one person, usually the owner, in order of how much damage that dependency does.

Order	SOP	What it fixes	Who owns the decision once written
1	Approval authority (credit, discount, purchase limits)	Orders and payments stall when the owner is unreachable	Whoever holds the delegated limit, by role, not by name
2	Customer onboarding	New customers wait days for a response no one else can give	Sales or accounts lead, with a fixed checklist
3	Order-to-dispatch	Confirmed orders sit because one handoff depends on a phone call	Production or operations coordinator
4	Hiring and onboarding	New hires start with no structure, repeating the owner's time each round	HR, or whoever currently does it informally
5	Cash collection and follow-up	Payment follow-up depends on whoever remembers to chase	Accounts, with a fixed follow-up calendar

Notice what is missing: quality inspection, vendor management, inventory counts, IT access, all real processes, all worth documenting eventually. They come after, because none of them collapse the business in a single day the way an unresolved approval does.

Growtoria's guide makes a similar point about format: an SOP that tries to cover every edge case on day one never gets finished. Write the common path first. Add exceptions once the core document has been used a few times and the real exceptions show themselves.

How do you know an SOP is done, not just written?

It is done when the person who normally handles that process is unavailable, someone else follows the document, and no one needs to call anyone to fill a gap.

That is the actual test, and it is stricter than it sounds. Most first drafts fail it. A written approval-authority SOP that says "sales coordinator checks with finance" is not done, because checking with finance is still a phone call in disguise. A finished version names the limit in numbers, names who holds it, and names what happens above that limit, in writing, with no verbal step left in the chain.

If the answer needs a phone call, it's not a system.

Run the test properly. Pick a day. Make the person who normally makes that decision genuinely unavailable, not just theoretically. Watch whether the business moves without them. If it does not, the document needs another pass before it counts as finished.

What should you avoid while writing these five?

Two habits sink this exercise more than any other.

The first is treating the SOP as a compliance document before it is a working one. Owners under investor pressure sometimes write SOPs to satisfy a checklist item in a due diligence request, worded for an outside reader rather than for the person who will actually use it on a Tuesday morning. That document gets filed and never opened again. Write for the person doing the work first. If it also satisfies an investor later, that is a side effect, not the goal.

The second is handing the whole list to one person, usually in HR or admin, and expecting them to invent the decision rules on their own. They cannot. Only the owner or the person currently making that call knows the actual threshold, the actual exception, the reason a particular customer always gets special terms. The person writing the document can structure it, but the decision rules have to come from whoever holds them today. Martine Bongue's guide covers this from a slightly different angle, framing SOPs as a way to capture decisions that currently live only in one person's head.

What happens after the first five hold?

Once the first five survive a real absence test, expand outward to the processes around them, not to a new unrelated list.

After approval authority, customer onboarding, order-to-dispatch, hiring, and cash collection are working without the owner in the loop, the next layer usually reveals itself on its own. Quality checks that were "whatever the supervisor decides", vendor evaluation that lived in one buyer's memory, inventory counts that only one warehouse hand knew how to reconcile. These matter, but less urgently, because none of them stop the business in a single unreachable day the way the first five do.

This is also the point where most owners realise documentation and software are two different projects that get confused with each other. A written SOP tells you who decides what. A system enforces it, flags what is overdue, and shows the owner what is pending without a status call. Read more on how the two connect in the Business Systems, SOPs and Visibility hub.

What to do next

Do not start a documentation project this week. Start with one question at your Monday morning desk: what happened the last time you were unreachable for a full day, and what stalled. Write that one process down properly, with numbers and names instead of "check with me". Test it by being unreachable again, deliberately, and watching whether it holds.

Once it holds, move to the second on the list above. Five processes, done properly and tested against real absence, will tell an investor or a new manager more about how your business runs than forty documents no one has opened. If you want a second pair of eyes on where the actual dependency sits before you write anything, that is the starting conversation for ThetaSol's business systems work. We understand how your business actually works first, then we design the system.