- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
Seven steps from watching the work to a procedure someone who never did the job can run, with the stranger test as the step that matters.
Steps to creating an SOP: from watching the work to a stranger running it
Most procedures are written the wrong way round. Someone who knows the job sits down and types what they think they do, and the document is finished when they run out of things to say. It reads well, and nobody can run it. The steps below produce the opposite kind of document, one that has been tested against a person who did not write it. what a runnable sop contains is covered in its own article, and so is why an SOP is required before an agency can hire; this one is the order of work that gets you from nothing to a procedure that survives its first stranger.
The steps at a glance
| Step | What it produces | Who does it | The usual failure |
|---|---|---|---|
| 1. Choose the process | One named process with a trigger and an end state | The person accountable for the outcome | Starting with the biggest process rather than the most repeated |
| 2. Watch it done | A raw record of the real sequence | Whoever does it now, observed | Recording the ideal instead of the actual |
| 3. Write the ends first | The trigger line and the done line | The writer | Steps with no agreed finish |
| 4. Write the steps | A numbered list, one action each | The writer | Prose, and steps that hide a decision |
| 5. The stranger test | A list of every place the tester stopped | Someone who has never done it | Testing on the person who wrote it |
| 6. Add the exceptions | The branches the test surfaced | Writer and tester together | Exceptions kept in someone’s head |
| 7. Sign-off | Owner, version, review date, location | The owner | A finished document nobody is responsible for |
Step one: choose the process, and name its edges
The first SOP should be the one that is done most often by the most people, not the most important one. Frequency is what pays the writing back, and a procedure that runs daily gets tested daily; the lead response procedure for the last 72 hours is the model of a narrow, frequent one. Name it as a single sentence with a trigger and an end state: when a new client signs, until their account is set up and they have logged in once. If you cannot write that sentence, you have chosen two processes, or half of one.
Step two: watch it done, and record what actually happens
Sit with the person who currently does the work and watch them do it once, for real, on a real case. Note every action, every place they pause to look something up, every message they send to someone else, and every point where they say it depends. That last phrase is the most valuable thing you will hear, because each one is an exception the finished document will need. Do not interrupt to ask how it should be done; you are recording how it is done, and the difference between the two is what the SOP exists to close.
Step three: write the two ends before any step
Write the trigger line, the event that tells someone to start, and the done line, what must be true for the work to be finished. Most disagreements about a process are really disagreements about the done line: one person thinks the onboarding is finished when the account exists, another when the client has replied. Settle it here, in one sentence each, and every step you write afterwards has a purpose to be checked against.
Step four: write the steps
Turn the observation notes into a numbered list. One action per step, starting with a verb, naming the system the action happens in, and ending with what the person should see if it worked. Where the notes said it depends, write the most common path only for now and mark the spot; the branches come in step six. Keep the first version short enough to test in one sitting, because the next step is the one that matters, and a forty-step version never reaches it.
Step five: the stranger test
Hand the steps to someone who has never done the job, give them a real case, and watch without helping. Every time they stop, ask what they were looking for, and write the answer down against that step. Do not explain; explaining is how the gap gets patched in the room and left in the document. A step the stranger could not follow is not a step yet. Run the test until the stranger finishes without stopping, which usually takes two or three passes, and rewrite between each.
The person who wrote the steps is the wrong tester, and so is the person who was observed; both fill the gaps from memory without noticing. A new hire, a virtual assistant in their first week, or a colleague from another team are the right ones, and the same test is the heart of training a virtual assistant. A person working through a new agent’s onboarding checklist is a tester you already have.
Step six: add the exceptions the test surfaced
Now return to the marked spots and to everywhere the stranger asked what if. Each becomes a short branch inside the step: if the client has no domain yet, do this; if the payment failed, stop and do that. Exceptions written into the SOP are part of the procedure; exceptions explained in a chat message are how the procedure quietly stops being followed. If a branch is long enough to need its own numbered list, it is its own SOP, and the step should point to it.
Step seven: sign-off, and the four fields that keep it alive
A procedure is finished when it has an owner whose name is on it, a version number, a review date a few months out, and a location that is where the work happens rather than a shared folder nobody opens. Then decide which steps the platform can execute for you, such as the reminder, the tag, or the task that appears when a stage changes, and which stay as a list for a person; whether a checklist counts as automation is the guide to that split, and the executable half is where an SOP stops depending on anyone remembering it.
What to do on the review date
Run the stranger test again with whoever is newest. If they finish without stopping, move the date forward. If they stop, the process has drifted from the document, and the fix is the same steps from step two onward, applied to the part that changed. That loop of watch, write, test and sign off is the whole method, and the reason to write it down as steps is that it survives the person who ran it first.
Frequently Asked Questions
What are the steps to creating an SOP?
Choose one frequent process and name its trigger and end state; watch it done for real and record the actual sequence; write the start and finish lines; turn the notes into numbered single-action steps; test it on someone who has never done the job; add the exceptions the test surfaced; then sign it off with an owner, a version, a review date and a home.
Who should test an SOP?
Someone who has never done the work, given a real case and watched without help. The writer and the person who was observed both fill gaps from memory without noticing. A new hire, a virtual assistant in their first week or a colleague from another team are the right testers.
Which process should get the first SOP?
The one done most often by the most people, not the most important one. Frequency pays the writing back and tests the document daily. A narrow, repeated procedure such as lead response is a better first candidate than a large, rare one such as a full client migration.
How long should an SOP be?
Short enough to test in one sitting. One action per step, a verb first, the system named, and what the person should see when it worked. If a branch needs its own numbered list, it is a separate SOP that the step points to, not more length in this one.
What if the process has a lot of exceptions?
Write the common path first and mark every place the observed person said it depends. After the stranger test, turn each mark and each what-if into a short branch inside the step. Exceptions that live in chat messages instead of the document are how a procedure quietly stops being followed.
Where should the finished SOP live?
Where the work happens, such as the task, the pipeline stage or the onboarding checklist the person is already looking at, rather than a shared folder nobody opens. The steps the platform can execute, like a reminder or a task on stage change, should be built into it.
How often should an SOP be reviewed?
On the review date set at sign-off, a few months out, and whenever the process visibly changes. The review is the stranger test again with whoever is newest; if they finish without stopping, move the date forward, and if they stop, rework the part that drifted from step two onward.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.