There is a particular kind of task that looks small on your to-do list and somehow takes forty minutes. You look for the right folder, check what you did last time, rewrite the same email, and wonder whether you have forgotten a step.
That is a good candidate for an SOP: a standard operating procedure. The name sounds formal, but the document can be beautifully simple. It explains how to complete a recurring task to a consistent standard without rebuilding the process from memory.
If you have been wondering how to write an SOP for your business, start with one task you already understand. You are creating a useful set of directions, not an operations manual for an imaginary future team.
Choose a task with a beginning and an end
“Manage clients” is too broad. “Set up a project folder after a client books” is specific enough to document and test.
Look for a task that repeats, contains several steps, and has a recognizable finished state. It might be preparing a weekly client update, publishing a newsletter, handing over final files, or checking a new inquiry.
Choose a process that is reasonably stable. If you are still changing the service every week, write a short working checklist and revisit it once the process settles. Detailed documentation of a process you dislike simply makes the wrong process easier to repeat.
Use this simple SOP structure
Keep the document close to the work: in the project template, linked from the recurring task, or in an obvious operations folder. A perfectly organized manual nobody opens is not doing much for you.
Purpose and trigger
Explain the result in one sentence, then name the event that starts the procedure. For example: “Create a consistent project workspace when a new client meets our booking requirements.”
A trigger is more helpful than an arbitrary date. It tells you when the process applies, including when you are busy or someone else is covering the work.
Owner and required inputs
Name the role responsible for completion. Even in a one-person business, this distinguishes work you must do from information the client needs to provide.
List the inputs before the steps: client name, agreed deliverables, project dates, and access to the current folder template. Link to the approved template instead of embedding a second copy that can drift out of date.
Steps, in the order you perform them
Use numbered actions. Start each with a verb and include the detail someone needs to make the next decision.
“Set up the folder correctly” is not an instruction. “Duplicate the project folder template and rename it using ClientName_Project_Year” is.
One action per step makes the procedure easier to check. If a step contains three decisions, split it or create a short decision rule beneath it.
Exceptions and a definition of done
Document the most likely point of confusion. What happens if an asset is missing, a file is too large, or the usual approver is unavailable?
You do not need to predict every possible problem. Give the reader a safe stopping point and someone to ask. “Do not share the folder until access permissions are confirmed” is more useful than “Use your judgment” when client files are involved.
End with a checkable result. That might be a working link, a saved confirmation, an approved file, or a completed item in your tracker.
A worked example: setting up a new client folder
Here is a sample you can adapt to your own tools and services.
Purpose: Create one reliable home for project files before the client receives their welcome message.
Trigger: The project meets the booking requirements recorded in our client onboarding process.
Owner: Project lead.
Inputs: Client name, project name, agreed deliverables, start date, and the approved folder template.
- Duplicate the current project folder template into the active-client directory.
- Rename it ClientName_Project_Year. Use the same spelling as the project tracker.
- Confirm that the folders needed for this project are present: Client Inputs, Working Files, Client Review, and Final Delivery.
- Keep internal working files private. Share only the folders the client needs, with access appropriate to their role.
- Test the client-facing link using an account without owner access, or ask the recipient to confirm access before relying on it.
- Add the correct link to the project tracker and welcome-message draft.
- Record the setup date and mark the task complete.
Exception: If the client’s email address is uncertain, confirm it before inviting anyone. If the template contains files from a previous project, stop and replace it with a clean template.
Done means: The right folders exist, permissions have been checked, the tracker contains the correct link, and no other client’s material is included.
Review: Update this procedure when the folder template, sharing approach, or project tools change.
This example belongs inside the larger client onboarding workflow. The workflow shows the whole journey; the SOP explains how to complete one part of it.
Test the document while doing the work
Follow your own instructions on the next real task, or use a harmless sample if the process affects clients. Notice every moment when you reach for knowledge that is not on the page.
Add the missing instruction, remove anything redundant, and check that the links open for the person who will use them. If you have a collaborator, ask them to follow the document without your commentary. Their questions are editing notes.
Screenshots can help when a tool is confusing, but they also age quickly. Use them where location matters, keep sensitive information out of view, and pair them with written actions that still make sense when a button moves.
Keep the useful version easy to find
Add an owner, a last-reviewed date, and a short change note. There should be one current version, with older copies clearly archived if you need to retain them.
Review after a meaningful change or a repeated mistake. A quarterly reminder can help you notice stale instructions, but the calendar should not be the only reason you update them.
For today, choose the task you explained twice this month. Write its trigger, the steps, and what “done” looks like. Then use that document the next time the task comes around. The first useful SOP is the one that saves you from figuring out the same small thing again.
