To write a standard operating procedure, choose one recurring task, define where it starts and ends, and record the steps while someone performs it. Add the information a second person needs to make decisions, then ask that person to follow the draft. Revise the places where they pause or guess.
For a small business, the first useful SOP can fit on a page. This guide follows a fictional design studio filing an approved client deliverable. The example includes a missing approval and an outdated file, so you can see how a procedure handles ordinary exceptions as well as a smooth run.
Key Takeaways
- Give one procedure a clear trigger, finish condition, and owner.
- Write observable actions with the exact location of the required information.
- Explain what to do when a prerequisite is missing.
- Test the document with another person and record the changes.
Which task should your first SOP cover?
Think of a task that repeats and regularly prompts a question. Filing a final client delivery is a reasonable first choice if someone keeps asking which version to save. You can observe the task, check its result, and correct the document without redesigning every stage of the business.
Start with a task whose finish condition you can inspect. In our studio, the procedure begins after the owner approves a delivery package. It ends when the approved package is in the client’s final folder and the project record contains a link to it. Sending the delivery email is a separate procedure.
Pick a task small enough to complete in one sitting and describe the audience. A colleague who already has access to the project folders needs different instructions from a new assistant. Shopify’s SOP guide compares procedure formats and scope. For a first draft, a numbered sequence with one clear exception rule is often manageable.
What information belongs on one page?
Give the document a title that names the action. Add the owner, version, date, and review trigger. Then write the prerequisite, the start point, and the finish condition. In the studio example, a link to the owner’s approval is a prerequisite. A file named final is insufficient evidence because someone could have renamed it before approval.
Name the files or records the user must open and explain any local shorthand. You can reference a shared folder without putting account credentials in the document. If a person cannot access the required location, the procedure should point them to the colleague who handles access before the task starts.
| Field | Example for the fictional studio |
|---|---|
| Title | File an approved client delivery |
| Owner | Studio project lead |
| Start | Owner marks the delivery package approved |
| Required inputs | Project record, approval link, delivery package |
| Finish | Final folder and matching package link in project record |
| Review trigger | Folder layout or approval method changes |
Keep this context near the top. Someone opening the SOP halfway through a busy day should be able to tell whether it applies to the task in front of them. The EPA’s SOP guidance comes from a more formal setting, but its emphasis on identifying and maintaining procedures is useful when adapting a smaller document.
How do you turn observation into usable steps?
Watch one complete run
Ask the experienced person to perform the task while you write down their actions. Notice where they switch between the project record, an approval message, and the folder. Ask why they chose a particular version. Experienced staff often make those checks automatically and leave them out of a first explanation.
Write a step around an action and a visible result. “Check the files” leaves the reader to invent a standard. “Compare the package filename and date with the package named in the approval” gives them something they can verify. The next step can say where to put the matched package.
Write the exception beside the decision
When the approval names a different package, the reader needs a choice immediately. Put the stop-and-ask rule at that check. If you collect every exception at the bottom of the document, someone may file the wrong version before seeing it. Ask the task owner who should resolve each exception and what information they need.
What does a complete small-business SOP look like?
The fictional studio stores each job in a folder with a Final Delivery subfolder and keeps a project record alongside its working documents. Its project lead approves the package by linking the exact file in that record. Here is the sequence the assistant receives after those locations are available.
- Open the project record and follow the approval link. Confirm that it names a specific delivery package.
- Compare the approved package’s filename and date with the file you are about to file.
- If the approval is missing or names a different package, mark the task awaiting confirmation and ask the project lead to identify the approved file. Resume after confirmation.
- Open the project’s Final Delivery subfolder. Check whether the same approved package is already present.
- If the matching package is present, use its existing link. If it is absent, place the approved package in that folder using the studio’s documented file-transfer method.
- Open the package from its final location and confirm that it is the approved file. Add its final link and the completion date to the project record.
- Mark the filing task complete only when the folder and project record point to the same package.
Read the sequence against your own tools before adapting it. Your business might approve a shared link instead of a downloaded file, or keep a version history in one document. Record the actual method your team uses so that a person can distinguish a current package from an older one.
The assistant’s authority is also clear. They can file a package that matches an approval and use an existing matching copy. They refer uncertainty to the lead. That boundary is especially useful when a filename looks plausible but the client has requested a late revision. A decision about the content belongs to the approver.
How do you test the SOP before relying on it?
Give a colleague the document and a sample project containing made-up files. Ask them to follow the steps while you observe. Wait to see where they hesitate before explaining. Keep a note of the exact phrase they read and the information they tried to find.
Suppose the tester sees two packages with the same date. The approval refers to one by a link, but the first draft said only to check the date. Revise that step to require the linked package or another unambiguous identifier. Repeat the test with the same pair of files to see whether the instruction now settles the choice.
Next, remove the approval from the sample project. The expected result is an awaiting-confirmation record and a question to the lead. If the tester picks the newest file instead, revise the exception rule and explain its purpose. Groundwork’s guide to writing an SOP also emphasizes testing instructions with a person unfamiliar with the task.
Keep the test record with the draft. List the sample case, the expected result, where the tester paused, and the wording you changed. A later owner can use that record to repeat the check after a software update, instead of relying on a vague statement that the procedure was tested.
How should you update a procedure as tools change?
Keep one current copy where the task happens, and name a person who can approve changes. When the team changes its folder layout, update the affected step and test that section again. Record the new version and what changed. Archive the old copy in a way that clearly identifies it as superseded.
If you use AI to turn rough notes into a draft, give it a made-up example or information you are authorized to share. Check each location and decision yourself. An invented approval rule can look polished on a page. The live test still needs to use the actual workflow and a responsible person.
For related planning, The One-Person AI Business discusses running a lean digital business, while this guide to small-business AI automation addresses a later question of which repetitive steps to automate. First establish how the task should finish. That gives you a result against which to check any future tool.
Conclusion
Choose one task that regularly needs clarification. Watch a complete run, write the start and finish conditions, and give a colleague the draft with a sample case. Use their first hesitation as your first revision. A short procedure becomes useful when someone can follow it and recognize a correct result.
FAQ
Can a checklist replace a full SOP?
For a familiar task with clear actions, a checklist may be sufficient. Add explanations when the user needs context, a choice, or a standard for judging the result. You can keep a short checklist for everyday use and link to a fuller procedure for training and exceptions.
How often should a small-business SOP be reviewed?
Set a review interval that matches how often the task changes, and review it whenever a tool, owner, or decision rule changes. Repeated questions also signal a possible gap. A stable filing routine may need fewer revisions than a procedure tied to software that changes frequently.
