Standard Operating Procedures for a Small Business: What to Document First, and How to Keep It Alive

For a growing small business, standard operating procedures should start with the ten or so processes that either touch revenue, carry risk or currently need the founder to make them work, written as short checklists in the tools people already use rather than as a wiki nobody opens. Documenting those first, with a named owner for each and a review date, removes most of the dependency on people's heads while leaving the judgement that makes the business good firmly in place.

What follows covers how to choose those first procedures, the formats that survive contact with a busy team, who should write and own them, and a template short enough that people will use it.

Why a small business needs standard operating procedures at all

In a business of somewhere between 20 and 60 people, most processes still work because a handful of long-serving people remember how they are done, and that arrangement holds until one of them goes on holiday, leaves, or is promoted into a role where they no longer do the work themselves. The cost shows up as inconsistent delivery, slow onboarding and a founder who becomes the routing layer for every question that nobody else feels able to answer.

It also shows up later, when a buyer or investor asks how the business runs without you, because undocumented processes are one of the clearest signals of the founder dependency that affects valuation and deal terms at exit. Procedures do not solve that problem on their own, but it is very hard to solve without them.

The 80/20 approach: what to document first

The temptation is to document everything, which produces a large library that goes out of date within a quarter and teaches the team that documentation is a project rather than a habit. A better filter asks three questions of each process: does getting it wrong cost money or a client, does it happen often enough that inconsistency compounds, and does it currently depend on one person, most often the founder.

Processes that score on two or three of those questions go first, and processes that score on none can wait, however untidy they look.

Your first ten SOPs, in priority order

For a technology services business, the list below is a sensible starting order, which you should adjust to your own risks rather than adopt wholesale.

1. Client onboarding: from signed contract to first delivery, including kick-off, access and who the client talks to.
2. Scoping and estimating: how work is sized, who signs off, and what assumptions must be written into the proposal.
3. Change requests: how out-of-scope work is spotted, priced and agreed before anyone does it.
4. Resourcing and allocation: how people are assigned to work and how conflicts are resolved without escalating to the founder.
5. Invoicing and time capture: what gets billed, when, and who chases.
6. Incident or escalation handling: what happens when a client is unhappy or something breaks, and who has authority to act.
7. New starter onboarding: accounts, equipment, first-week plan and who is responsible for each part.
8. Leaver offboarding: access removal, knowledge handover and client communication.
9. Project close and handover: how work is signed off and what the client receives.
10. Approvals and spending authority: who can commit the business to what, which is the procedure that most directly takes the founder out of routine decisions.

Formats people actually use, and the wiki nobody reads

A procedure only works if it is in front of someone at the moment they need it, which is why long prose documents filed in a shared drive tend to be read once at induction and never again. Formats that hold up are short checklists of numbered steps, templates embedded in the tool where the work happens, such as a project template in your delivery system or a saved proposal structure, and brief screen recordings for anything genuinely visual.

A central index still matters, because people need to find things, but the index should point to procedures that live where the work is done rather than holding long copies of them. If your team cannot find a procedure within a minute, they will ask a colleague, and the procedure has quietly failed.

Who should write and own each procedure

The person who does the work should draft the procedure, since they know the steps that actually happen rather than the steps that are supposed to happen, and the gap between those two is usually where the useful detail sits. A manager or operations lead then reviews it for consistency and for decisions that should sit with someone else.

Every procedure needs a single named owner, which is a role rather than a team, who is responsible for keeping it accurate and for reviewing it on a set date. The founder should approve the handful of procedures that transfer decision rights away from them, and otherwise stay out of the writing, because procedures drafted by the founder tend to describe how the founder would do it rather than how the business should.

A procedure without an owner is a historical document that happens to be written in the present tense.

A lightweight SOP template

Keep each procedure to a page or less, using the same headings every time so that people learn where to look.

• Purpose: one sentence on what this procedure achieves and why it matters.
• Trigger: the event that starts it, such as a signed contract or a new starter's confirmed date.
• Owner: the role accountable for the procedure being followed and kept current.
• Steps: numbered actions, each starting with a verb and naming who does it.
• Decisions and authority: where judgement is needed, who makes the call, and the limits within which they can act without escalating.
• Done means: the observable outcome that shows the procedure is complete.
• Links: templates, tools and related procedures.
• Last reviewed and next review: two dates, which are the cheapest guard against decay.

The decisions section is where procedures stop killing how things work, because it documents who holds judgement rather than trying to replace judgement with steps, and that distinction is what keeps experienced people from feeling that their craft has been reduced to a checklist.

How SOPs connect to founder dependency

Standard operating procedures make the founder's knowledge transferable, but they only reduce dependency when they also move decision rights, which is why the approvals and escalation procedures matter more than their length suggests. A business where every step is documented but every exception still goes to the founder has written down its dependency rather than removed it.

Procedures also become evidence, since acquirers and investors increasingly ask to see how operations run, and a current, owned set of procedures is a straightforward answer to several of the questions on an operational due diligence checklist.

Where Vitori fits

Most businesses can write their first ten procedures themselves, using the list and template above, and that is the right place to start whether you later work with Vitori or anyone else. Where outside help earns its keep is in deciding which processes and decision rights matter most at your stage and making sure the change holds once written, which is what the Operational Scale Framework is designed to assess across Growth, Delivery and Operations, and what the Operator model exists to implement alongside your team. If that would help, you can get in touch with Vitori to talk it through, with the aim of a business that runs, and scales, without the founder in every decision.

Common questions about standard operating procedures

How long should a standard operating procedure be?

A standard operating procedure for a small business should usually fit on a single page, with numbered steps, a named owner and a short section on who makes decisions. Anything longer tends not to be read at the moment it is needed, so detailed reference material is better linked from the procedure than written into it, keeping the procedure itself quick to follow.

How often should SOPs be reviewed?

Standard operating procedures should be reviewed on a fixed date set by their owner, commonly every six or twelve months, and also whenever the process, tools or people involved change. Recording both the last review and the next review date on each procedure makes stale documents easy to spot and keeps responsibility for accuracy with a named role rather than with nobody.

Should SOPs be written before or after hiring an operations lead?

Writing the first few standard operating procedures before hiring an operations lead gives that person a clearer starting point and shows where the real gaps are. The highest-risk procedures, such as onboarding, change requests and approvals, are worth drafting early, while the wider library and its upkeep can become part of the operations lead's remit once they are in post.