Standard operating procedures for a small business: start with one recurring failure

When a small business decides it needs standard operating procedures, someone may suggest documenting everything. That is a large assignment, and the team still has a business to run.

I would begin with a recurring failure that people can describe. A missed handover, an incomplete inquiry record or a task that is repeatedly finished too late gives you a useful place to start. You can see the problem and check whether the procedure helps.

Choose a problem with a visible consequence

Ask the people doing the work what they repeatedly have to correct or explain. Look at the cost in time, delay, confusion or customer frustration. Avoid choosing a process only because it is easy to write about.

Take a hypothetical example: a customer request reaches two team members, both assume the other is responding and the customer has to ask again. The problem is specific enough to examine.

Before writing instructions, find out what happened. Was there no owner? Was the record difficult to find? Did the usual person leave without a handover? The procedure should address the cause you can establish.

Write a short working version

Use these headings: when the process starts, who owns it, information needed, steps to follow, what completed means and what to do when the normal route cannot be used.

For the customer request example, the process might begin when an inquiry arrives in a shared channel. A named role records it, assigns responsibility and checks that a next action exists. Completion means the requested response has been sent or the next agreed step has a visible owner.

Set response expectations that your business can meet. Include a backup when the usual person is unavailable. A procedure that works only when everyone is present has left out an ordinary part of running a business.

Test it with the person doing the work

Ask someone to use the draft on a suitable real task while you observe. Notice where they hesitate, search for information or ask a question the document does not answer.

Do not explain every gap verbally and then mark the procedure complete. Put the useful explanation into the working version. Another person should not need the same extra conversation next week.

Give it an owner and a review trigger

Store the current version where people already work. Name the person responsible for updating it when the process changes. Make old copies clearly obsolete so staff are not choosing between conflicting instructions.

Review whether the original problem becomes less frequent. If it continues, check whether the procedure is accessible, realistic and actually addresses the cause. More detail is not always the answer.

One procedure that removes a recurring failure gives you a method to repeat. Build the next one from another real operating problem.