Standard Operating Procedures: Run a Business Without the Owner

You cannot take a week off without three calls a day. Not because your staff are careless, but because every decision above a certain size has nowhere to go except to you. That is not a staffing problem. It is a missing standard operating procedure problem.

A business runs on hundreds of small decisions a day: whether to release a dispatch on credit, whether to accept a discount request, whether a machine stoppage needs the second shift called in. If none of these decisions are written down anywhere, every one of them travels to the owner by default, because the owner is the only person who has ever made that call before.

What is a standard operating procedure?

A standard operating procedure is a written description of one recurring decision or task: what triggers it, the steps to follow, who is allowed to decide, and what gets checked afterwards. It is not a policy statement and it is not a flowchart for its own sake. It is the answer to "what happens next" written down once, so it does not need to be asked again.

A useful SOP fits on one page. Take a dispatch-on-credit decision in a trading or manufacturing business:

• Trigger: a customer orders goods and has an outstanding balance.
• Who checks: the accounts executive pulls the current outstanding and the approved credit limit.
• Decision rule: if the order plus outstanding is within the approved limit, dispatch proceeds. If it exceeds the limit, it goes to the credit controller, not the owner.
• Exception: a new customer with no credit history always needs sign-off, named by role, with a maximum response time of four working hours.
• Record: the approval and the reason are logged against the order, not held in someone's inbox.

Notice what this one page does not contain. It does not describe software screens. It does not explain why credit control matters. It states the trigger, the rule, the exception, and who owns each step. That is the whole job of an SOP.

If you want a working structure to copy from, the SOP template guide from Topicary lays out a similarly compact one-page format, and the Wikipedia entry on standard operating procedures is a fair starting reference on where the format originates and how it is used across industries.

Which five SOPs should you write first?

Start with the decisions that stall the moment you are unreachable, not the ones that are easiest to document. Most owner-dependent businesses find the same five decisions sit on their desk, whatever the industry.

SOP	What triggers it	Who owns the decision	KPI tracked
Credit and dispatch release	Order from a customer with outstanding balance	Credit controller (not the owner)	Days sales outstanding
Purchase order approval	Raw material or consumable falls below reorder level	Purchase head, within budget limit	Purchase order turnaround time
Customer complaint handling	A complaint reaches any staff member	Quality or customer service lead	Time to first response, time to close
Production or job scheduling	New order confirmed or machine breakdown	Production planner	Plan adherence (on-time completion)
Payment and expense approval	Invoice received or expense claimed	Finance executive, within defined limit	Payment ageing, approval turnaround

These five cover the decisions that generate the most calls to the owner: money moving out, money coming in, a customer unhappy, and the shop floor stuck. Write these five before anything else. If you want the reasoning behind approval limits specifically, the related post on how many approval levels a purchase order should have goes into that one decision in depth.

How do SOPs, roles and KPIs work together?

An SOP without a named owner is a suggestion. A role without an SOP is a job title with no instructions. Neither moves a decision off your desk on its own.

The credit control SOP above only works because "credit controller" is a role someone holds, with the authority written into the SOP itself, not implied. If the SOP says "accounts team checks the limit" without naming who decides on an exception, the exception will still land on the owner, because nobody else believes they are allowed to say no.

Every SOP needs three things attached to it, not just the steps:

1. A named role, not a person. Roles survive when people leave; names do not.
2. A decision boundary, stated as a number or a condition. "Up to USD 2,000 (locally, the equivalent in INR or AED) without further sign-off" is a boundary. "Use judgement" is not.
3. A KPI that shows whether the process is working, not whether the paperwork was filled in. Days sales outstanding tells you whether credit control is doing its job. A completed form tells you nothing.

This is where SOPs connect to what the owner actually looks at each week. If your dashboard still shows everything you can measure rather than the handful tied to a decision, start with the related post on what belongs on your first management dashboard. The KPI column in your SOP table should be the same handful of numbers.

How do you make SOPs live in a system, not a file?

An SOP in a PDF is a historical record of what someone once agreed. An SOP inside a system is a live constraint that shapes what happens next, because the system will not let the next step proceed until the current one is recorded.

This is the real difference between process improvement on paper and operational efficiency in practice. A written SOP tells a new hire what to do. A system built around the SOP stops the order from moving to dispatch until the credit check is logged, stops the purchase order from reaching the supplier until the budget check is logged, and shows the owner, at a glance, where something has been sitting too long.

Most businesses outgrow a spreadsheet exactly at this point. If three people are editing the same file for different reasons, the SOP cannot be enforced by the file itself, it can only be enforced by someone remembering to check. The related post on when Excel stops working covers the signs that this point has arrived.

The test for whether an SOP has become a system is simple: if the answer to "where does this stand" still needs a phone call to the person handling it, it's not a system. A system answers that question on its own, without anyone being asked.

How do you get your team to actually follow SOPs?

Adoption fails for one of two reasons: the SOP describes a process nobody believes in, or following it is harder than ignoring it. Fix both before blaming the team.

First, never automate or formalise a process that is broken in its current form. If your purchase approval SOP has four sign-off levels because that is how it has always been done, writing it down just makes the delay official. Ask whether the process should exist in that form at all before you document it. A good SOP removes steps as often as it adds them.

Second, make the SOP the easiest way to do the task, not an extra step layered on top of the real work. If logging a customer complaint into the system takes longer than solving it informally and telling the owner later, staff will solve it informally every time. The system has to be faster than the workaround, or the workaround wins.

Third, review SOPs on a schedule, not when something breaks. An SOP that nobody has touched in two years is usually being quietly ignored already, with staff running their own version. That gap between the written process and the real one is exactly what the related post on documentation debt describes, and it is worth reading before you assume your existing SOPs are still being followed as written.

Getting SOPs followed is less about discipline and more about whether the business genuinely needs the owner's judgement at that step, or whether it has simply never been asked to run without it.

We understand how your business actually works first, then we design the system. A free 30-minute call is usually enough to tell you which of your current decisions still depend on you and why. If the picture is more tangled than a call can untangle, a SCAN on-site diagnostic maps every decision point across your operations before anything gets built. For a longer view of how SOPs, roles and tracking fit into a wider transformation, the digital transformation service page and the Business Systems, SOPs and Visibility hub go into the surrounding pieces.