SOP format: a section-by-section Shopify example

The six blocks

A usable SOP format comes down to six blocks in this order:

1. Header: title, document ID, owner, version, last-verified date.
2. Trigger: the exact event that starts the run, plus any prerequisite that decides whether the procedure applies at all.
3. Numbered steps: one action each, imperative verb, the object named, a screenshot only where it changes what someone does.
4. Decision branches: explicit if/then forks sitting under the step where the fork happens.
5. Exceptions and escalation: what to do when no branch fits, and the named role it goes to.
6. Last-verified: who checked the steps, when, and against what state of the interface.

The first five are well-covered ground. This piece builds each one against a single workflow you can go and check yourself: fulfilling an order manually from the Shopify admin. It is a fair test case because the procedure is short and every step sits inside a vendor's interface, which is the situation most ecommerce SOPs are actually in.

The header

Regulated industries run headers with document title, unique identifier, department, owner, version, approval status, effective date and page control. A four-person DTC team does not need that and will not maintain it. Trimmed to what actually gets kept up to date:

The ID matters more than it looks. A stable identifier in a predictable shape, a category abbreviation and a number, is what lets someone tell a current procedure from a superseded copy that got emailed around in March. Drop scope, definitions and approval signatures unless something forces you to keep them. Cut the owner field and the document stops being maintained by anybody.

The trigger

A trigger is one named event, not a scope statement. "This SOP covers order fulfilment" tells nobody when to open it. "An order appears in the Unfulfilled section of Shopify admin > Orders" does.

For this workflow the trigger carries a real prerequisite. Shopify stores use manual fulfilment by default, and fulfilling manually requires automatic fulfilment to be off. That setting lives under Settings > General > Order processing. So the block reads:

Trigger: an order shows as Unfulfilled in Shopify admin > Orders. Prerequisite: automatic fulfilment is deactivated under Settings > General > Order processing. If it is active, this procedure does not apply.

Writing the prerequisite into the trigger prevents the most common failure with a borrowed SOP: someone runs it on a store configured differently, the screens do not match, and they conclude the document is wrong rather than inapplicable.

Numbered steps and screenshots

One action per step. Imperative verb first, object named, measurable criteria wherever judgement is involved. Avoid words that sound like instruction but carry no obligation: periodic, typical, appropriate. "Handle appropriately" is not a step, it is a hope.

The core sequence, from Shopify's own documentation on fulfilling orders individually:

1. Open Orders in the Shopify admin.
2. Click the order to be fulfilled.
3. In the Unfulfilled section, click Mark as fulfilled.
4. Enter the tracking number supplied by the shipping provider.
5. Confirm the carrier. A carrier may be pre-selected, and a rushed hire will accept whatever is already there.
6. Select Send a notification to the customer. This option only appears when the customer's email address is on file.
7. Click Mark as fulfilled.

Step five is the one worth spelling out, because it is the step where the interface does something on your behalf and the operator has to decide whether to accept it. Steps like that are where errors enter a procedure that otherwise reads as mechanical.

On screenshots: add one only where it clarifies orientation, selection, placement, or a quality checkpoint. A screenshot added for decoration costs maintenance without improving execution, and every image you paste in is a thing that has to be replaced when the tool changes. Unreadable screenshots are worse than none, because they imply a check nobody can actually perform.

Branches and exceptions

Write conditionals as if/then forks, indented under the step where the fork occurs. Prose caveats get skimmed. A fork does not.

This workflow has four real conditionals, all documented by Shopify:

• If no single location holds enough inventory, the order splits automatically into separate fulfilments by location, and each one has to be fulfilled separately.
• If a hold is in place, release it first. Fulfilment is blocked until the hold is released, and held orders are excluded from the Unfulfilled list entirely.
• If the order is assigned to a third-party fulfilment service, stop. That service controls the status and marks the order in progress when it accepts the request.
• If the order has no shipping address, a tracking number cannot be added. Route it to the exception path.

That last one is where the exception block starts. An escalation path names a specific role rather than a department: no branch fits, or the customer was notified incorrectly, so hold the order, add a comment in the Timeline so the team can see the state, and hand it to the role named in the header.

Keep the step list to what is needed to complete the task. Notes, warnings and background belong in their own block. Branches belong next to the step they affect; rare exceptions belong at the end.

The last-verified line

This is the field that decides whether the other five blocks describe reality, and it is the one almost every template treats as decoration.

"Last verified: 12 March" says a file was opened. "Last verified: 12 March by the fulfilment lead, against the Shopify admin Orders view, all seven steps re-run on order #10428" says somebody did the work. Three parts: the date, the verifier, and the state of the interface it was checked against.

The interface part matters most here, because the steps live inside somebody else's product. When the button in step three moves, your document does not know. Nobody sends a release note to your SOP folder. You find out when a new hire gets stuck, or when a customer gets the wrong notification.

Approval is not the finish line either. A procedure that has been approved but not assigned, not understood, or not reachable from the place the work happens is not finished in any sense that matters operationally.

How often to refresh it is a question about your tools rather than your calendar. Regulated documents run review cycles of one to three years. A procedure sitting on top of a vendor's admin needs re-checking whenever that interface changes, whenever somebody new runs it, and whenever it produces a mistake. Anyone who hits a step that no longer matches should be able to raise it with the owner without asking permission.

Disclosure, since it is our product: ReccordSOP is built around this specific gap. You record the task again and it compares the new recording against the published SOP, so you see which steps moved rather than replacing the document wholesale. It does not watch your Shopify admin and notice on its own, and nothing on the market does. Somebody still has to record the task. What it removes is the cost of the comparison, not the need for one.

The check before you publish

Fill the six blocks in order, in one sitting, for one workflow where getting it wrong costs real money. Fulfilment, refunds, or high-risk order review. Not the easiest one.

Then do the part most teams skip. Hand the document to somebody who has not done the task and watch them perform it in silence. Every point where they hesitate, look somewhere else, or ask a question is a defect in the document rather than in them. Revise at each of those points.

Then have that person sign the last-verified line, with their name and the record they tested against. They are the best possible verifier, because they had no prior knowledge to fill the gaps with.

A step list is a claim about how a screen looked on the day someone wrote it. The format above is just the machinery for keeping that claim honest.