A one-page order SOP your team will actually use

A customer changes an order quantity in a chat. The owner has read the message, but the person preparing the goods has not. The package is assembled using the old quantity. Nobody deliberately ignored the customer; the information simply stopped with one person.

A standard operating procedure, or SOP, moves knowledge from individual memory into steps a team can follow. For a simple process, one page can be a useful start. Judge it by whether people can perform the task correctly, not by the length of the document.

Pick one process that regularly gets stuck

Do not begin by documenting the entire business. Choose a recurring workflow with a meaningful consequence when it goes wrong: receiving an order, checking goods, or confirming dispatch.

Involve the people who actually do the work. Ask what is unclear, which information must be available, and when they need an owner's decision. Describing the real workflow is more useful than creating an ideal procedure nobody can follow.

business.gov.au recommends identifying important tasks, documenting procedures, making them accessible to staff, and reviewing them regularly. The one-page format below is an editorial adaptation, not an official standard.

Define the start, finish, and process owner

At the top, write the process name, responsible person, revision date, and when to use the procedure. Set a starting and finishing point to keep its scope manageable.

For “processing an order for ready-to-ship goods”, the start could be an order confirmed under the business's terms. The finish could be handover to the carrier and recording the evidence. Returns and complaints can link to separate procedures rather than expanding this document indefinitely.

Do not force a process onto one page when it needs longer safety instructions, regulatory requirements, or technical detail. Being concise must not remove essential controls.

Write steps with checkable outcomes

This example is illustrative and must be adapted to the business:

1. The order receiver records the order number, items, quantity, recipient contact, and agreed deadline in the main order record. Outcome: one version of the order visible to the relevant team.
2. The preparer matches the items and quantities against that record. If stock differs, pause preparation and ask for confirmation rather than substituting items unilaterally.
3. The checker verifies condition, quantity, and destination before the package is closed. Record who checked it and when. If a small team uses the same person for both roles, still perform a distinct checking step.
4. The dispatcher hands over the package using the agreed method and saves handover evidence. Update the order status and share the appropriate shipping reference with the customer.

Use observable actions. “Provide the best service” is difficult to test; “match the item count against the confirmed order” is much clearer.

Explain what happens when the normal path fails

An SOP that only describes ideal conditions will quickly be abandoned. Add short rules for common exceptions:

• Order changes must reach the main record before preparation resumes.
• Unclear addresses or quantities must be confirmed with the customer.
• Problematic goods must not proceed merely to meet a deadline.
• Decisions outside a person's authority go to a named responsible person.

Identify who may approve changes and how the decision is recorded. Do not just write “tell a manager” if the team does not know whom to contact.

Test it with someone else, then improve it

Ask a colleague to work through a sample order using the document without extra explanation from its author. Watch where they stop or guess. Improve the instructions rather than blaming the reader.

Keep the latest version somewhere accessible and clearly mark old versions to prevent accidental use. Review it when tools, responsibilities, or recurring errors change. Connect the order process to agreed payment terms, and limit record access according to your document security needs.

Source and scope

• business.gov.au — Policies, procedures and processes, accessed 20 October 2026.

The workflow and roles above are editorial examples, not customer case studies or Ozone operating procedures. This article does not claim that one page satisfies all safety, legal, or industry requirements.