Write an SOP your team will actually follow

The real reason SOPs get ignored

A professional services firm in Brisbane had a client follow-up SOP that said: "Follow up with the client within 48 hours." The firm was proud of it. The SOP existed, it set a timeframe, and it was in the operations manual. The problem was that nobody agreed on what a follow-up actually was. One consultant sent a one-line email. Another called and left a voicemail. A third updated the CRM and considered that done. When a client complained about inconsistent communication, the owner reviewed three different records of the same follow-up step, each performed differently by a different person who had read the same SOP.

The SOP did not fail because it was too short or too long. It failed because it answered none of the questions a person actually has when doing the work: what does the follow-up say? Which channel? What if the client does not reply? Who checks it happened?

Ambiguity is the cause. Almost every SOP failure traces back to one of three structural problems.

Why SOPs die: three structural problems

1. Ambiguous triggers

"When appropriate" is not a trigger. "When a new lead comes in" is not a trigger. Neither tells a new starter when to start or what specific event kicks the process off. An ambiguous trigger means the process starts at different times for different people, producing inconsistent results from the very first step.

2. Missing exception handling

Standard SOPs describe the happy path: what happens when everything goes as expected. They rarely describe what the team should do when the normal path does not apply. The client has not signed the contract yet. The system is down. The contact person has changed. Without documented exception handling, every edge case becomes a conversation with the owner, which defeats the point of having an SOP at all.

3. No ownership

An SOP that belongs to no one is updated by no one. If the procedure is not assigned to a specific role, nobody feels responsible for keeping it current. Six months after writing, the SOP describes a process that the business no longer runs exactly that way, and people quietly stop following it because it does not match reality.

The six-section structure

Each section in this structure exists to answer a specific question that your team will have when doing the work. Remove any section and that question goes unanswered.

The trigger section is where most SOPs leave the most ambiguity. "When a new lead comes in" describes a category of event, not a specific one. The test: could a new starter, reading this for the first time, know exactly when to start without asking anyone? If the answer is no, the trigger needs rewriting.

The who section should always use a role, not a person's name. People change jobs. Roles persist. If you write "Tom handles this step" and Tom leaves, the SOP is immediately broken. Write "Client Services Coordinator" and it transfers automatically to whoever holds that role.

The what section is where the majority of the work sits. Every step starts with a verb. Every step describes one action. If a step contains the word "and", it is probably two steps. Active voice only: "Send the welcome email" not "The welcome email should be sent."

A worked example: client onboarding

Here is the same onboarding process written two ways. The first version is the kind of SOP that looks complete but fails in practice. The second version uses the six-section structure.

The ambiguous version

Trigger: When a new client is confirmed.
Who: The team.
Steps: Welcome the new client. Set them up in our systems. Get their documents. Schedule a kickoff call. Make sure everything is ready before we start work.

This SOP sounds reasonable. It fails because "confirmed" is undefined, "the team" assigns responsibility to no one, none of the steps name a system or platform, and there is no exception handling or escalation.

The specific version

Trigger: When a signed service agreement is received via DocuSign and payment of the deposit is confirmed in Xero.
Who: Client Services Coordinator.
What:

1. Open HubSpot and update the deal status to Won.
2. Create a new client folder in Google Drive using the /Templates/New Client folder as the base.
3. Send the welcome email using the template at /Templates/Email/Welcome — do not edit the template body, only fill in the client name and project name fields.
4. Create a Calendly booking link for the kickoff call and paste it into the welcome email before sending.
5. Add the client to the project management board in ClickUp using the New Client template.
6. Notify the lead consultant via Slack in #project-starts with the client name, start date, and ClickUp link.

Where: HubSpot, Google Drive, Calendly, ClickUp, Slack.
Exception handling: If the deposit payment is not confirmed in Xero within 24 hours of the signed agreement, hold all onboarding steps and notify the Operations Manager via Slack. If the client requests a change to the welcome email content, escalate to the Account Manager before sending anything.
Escalation: For any situation not covered above, contact the Operations Manager in Slack #ops-help before proceeding.

The second version takes a few minutes longer to write. It saves hours of clarification questions, inconsistent execution, and rework. A new starter reading it knows exactly what to do, in what system, in what order, and who to call if something unexpected happens.

The new-starter test

Before finalising any SOP, give it to the most recent person to join your team. Do not explain it verbally. Do not answer any questions before they start. Just hand it over and watch.

Every place they pause is a gap. Every question they ask is something the SOP should have answered. Mark each one. Revise the SOP to close those gaps. Run the test again with the revised version if there were more than two gaps.

This test is uncomfortable because it surfaces how much of the process currently lives in your head rather than on the page. That discomfort is useful. The knowledge that is hardest to write down is the knowledge that is most likely to cause failure when the person who holds it is not available.

The new-starter test also reveals a second problem: processes that only appear simple because experienced staff skip steps they have internalised. A consultant who has onboarded fifty clients does not think consciously about which folder structure to use. They just use the right one. A new starter does not have that shortcut yet. The SOP needs to make it explicit.

How AI changes SOP writing

AI can draft the structure and standard steps of an SOP from a plain-language description. Describe the process in a voice memo or a few bullet points, pass it to a capable AI tool, and you will get a structured first draft in minutes rather than hours. That draft will handle the trigger, the who, the numbered steps, and the where reasonably well.

Where AI falls short is exception handling and escalation. It does not know which client types in your business behave differently from the norm, what your team actually does when the CRM is unavailable, which escalation contacts exist in your specific organisation, or which edge cases have caused problems in the past. These sections require institutional knowledge that the AI does not have access to.

The practical workflow: describe the process to AI, get a structured draft, then spend your time filling in exception handling and escalation from experience. Run the new-starter test on the combined result. This produces a finished SOP in roughly half the time of writing from scratch, and the quality is higher because the structure is consistent from the start.

AI also helps with the ongoing maintenance problem. As a process changes, you can describe the change to the AI, feed it the existing SOP, and ask it to produce a revised version. This reduces the friction that causes SOPs to fall out of date.

Australian compliance notes

For SOPs that involve employees directly, particularly those covering performance management, leave approvals, or record-keeping, cross-reference the relevant obligations under the Fair Work Act and the applicable Modern Award. Notice periods, leave entitlements, and record-keeping requirements are minimum standards, not defaults that you can override in an SOP. An internal procedure that conflicts with a legislative minimum does not override it — it just creates a legal exposure if followed.

For businesses in allied health, psychology, or registered nursing, AHPRA requirements may also affect how certain clinical or client-facing processes must be documented and carried out. Where AHPRA guidelines and an internal SOP conflict, AHPRA takes precedence. Flag any SOP in these areas for review by a registered practitioner or a compliance adviser familiar with the relevant scope.

What to do next

Pick one process your team runs at least weekly that currently lives in someone's head. Write it out using the six-section structure above. Give it to your most recent hire without explanation and watch where they pause. Close the gaps. That single SOP, done properly, is worth more than a folder full of vague ones.

Once the process is documented and running cleanly, it becomes an automation candidate. A process you cannot describe in writing is a process you cannot automate reliably. Read which part of your business to automate first for the scoring method that ranks your candidates, and how to build a follow-up sequence for Australian SMBs for a worked example of a documented process converted into an automated workflow.