How to document a business process and write an SOP people can use

1. Decide which document you need

A process description explains how several participants produce an outcome together: what triggers work, who hands information to whom and when the process ends. An SOP, or standard operating procedure, describes the agreed way to perform a particular recurring operation. An ERP instruction can support it, but screenshots of buttons alone cannot explain ownership or decision rules.

Do not start with “everything the shop does”. Choose an operation that repeatedly generates questions or rework, such as receiving a physical return at a warehouse. Return eligibility, refunds and resale are connected but separate processes. Our teaching example assumes that the commercial decision has already been approved; it does not establish legal return policies.

There is also a terminology distinction. In Lean, standardized work has a specific meaning. LEI connects it with takt time, work sequence and standard in-process inventory. An ordinary office SOP does not become a complete standardized-work system by changing its name. What follows is Routio’s proposed procedure-writing method, not a translation of an LEI standard.

2. Write a process brief before drawing a map

A process brief is a short agreement about boundaries. Describe the outcome from the recipient’s perspective: not “a document was completed”, but “the responsible person can see what arrived, where it is and whether the next movement is permitted”. This distinguishes a useful completion from a purely administrative status change.

In the illustrative returns process, the start is a parcel arriving with an approved request reference. The end is identified goods in a designated area, handed over to the next agreed stage. The process owner maintains the rules; the operator performs a particular transaction. These can be different people. Ownership is necessary even when warehouse, support and accounting teams share the workflow.

• Name, purpose, starting event and an observable completion condition.
• Inputs: goods, request reference, expected items and an approved decision.
• Outputs: receiving record, actual quantity, condition, location and next owner.
• Process owner, operator, absence cover and recipient of the result.
• Explicit exclusions and connections to neighbouring procedures.

3. Observe the work before describing it

Ask an experienced operator to take you through a real transaction. Avoid suggesting the “correct” order or interrupting every step with a proposed improvement. Record what arrived, what information the person searched for, where they waited and whom they contacted. Keep observations, the operator’s explanations and your hypotheses separate. “Waited for confirmation” is an observation; “the manager is careless” is an unsupported conclusion.

One convenient transaction cannot reveal every variation. Compare a normal return, a mismatched item and an incomplete parcel. Where possible, observe another shift or the regular operator’s replacement. This is a search for variations that the procedure must handle, not a statistical study. Do not present the error frequency in this small selection as a business-wide rate.

Retain only the data needed for the exercise. An anonymized reference and a situation description often suffice. Do not put customer addresses, passwords, tokens or internal-system screenshots into a publicly accessible document. Agree access to evidence and training examples with whoever owns the data.

4. Map handovers, not just activities

Start with a simple sequence: event → action → decision → handover → outcome. At each handover, name what the next person receives and how they discover it is ready. An arrow labelled “warehouse to manager” without a record, status or notification hides the most important detail. BPMN is optional at this stage; shared understanding comes first.

In our example, the operator receives a parcel, checks the items and records discrepancies. An unidentified item does not automatically become available for sale. A clarification task gets an owner. When the information matches, goods enter the appropriate inspection area and the next participant receives a specific record, not a spoken “something has arrived”.

For each branch, check that the decision can be made using available information. Replace “if everything is fine” with observable conditions: the item reference matches, actual quantity is recorded and condition has been checked against agreed criteria. If people interpret a condition differently, you have an unresolved operational rule, not a diagram-formatting problem.

5. Make each instruction verifiable

A useful step contains an action, an object, a critical rule and an observable result. Compare “check the return” with “match each received item’s reference and size to the approved request; record actual quantities; flag discrepancies before handing goods onward”. The second version gives the operator a criterion and the reviewer something concrete to check.

Keep every possible system field out of the main narrative. The core SOP should remain understandable when the interface changes. Put exact button labels, anonymized screenshots and technical limitations into a linked, versioned instruction. Where an ERP action is irreversible or changes accounting records, identify the required permissions and approvals before that action.

Explain why critical rules exist. “Do not release an unidentified item into available stock because a new order could reserve it” helps someone reason through an unfamiliar situation better than a bare prohibition. Equally, do not create extra mandatory checks without an identified risk, an owner and a practical way to perform them.

6. Define exceptions and a safe stopping point

A procedure that only works under ideal conditions sends every difficult decision back to the manager’s chat. List known exceptions: missing request reference, unreadable label, quantity mismatch, unavailable system access or visible parcel damage. Each needs a temporary location or status, a responsible person and a condition for resuming work.

“Tell the manager” is not enough. Specify the agreed channel, necessary information and backup owner when the primary person is absent. Set internal response expectations with the team and its actual workload in mind. Copying an arbitrary fifteen-minute deadline into every procedure produces a requirement that soon becomes decorative.

If the ERP is unavailable, agree in advance whether a controlled temporary log is permitted. Recovery needs reconciliation, unique identifiers and a check that records were not entered twice. An improvised parallel spreadsheet without a reconciliation procedure introduces another source of discrepancies. Do not let a fallback process silently become the permanent source of truth.

7. Worked example: receiving a physical return

This is a fictional clothing-shop teaching scenario, not a customer case study. The approved request lists two shirts of the same style in sizes M and L. The parcel contains M and S. The operator’s job is to record what actually arrived, not to make actual data resemble expectations.

First, the operator links the parcel to the request. They check each item, record M and S and flag the size mismatch. Goods requiring clarification remain in the designated pending-decision area rather than becoming available stock. The responsible person receives the request reference, expected and actual item details, and any permitted inspection evidence.

After clarification, the responsible person records the decision in the agreed system. Only then does the operator complete the appropriate movement under the system’s rules. Acceptance means another authorized person can locate both received units, explain their statuses and identify the owner of the next action. This example does not determine refunds or legal eligibility.

8. Test the draft with someone who did not write it

Run a walkthrough using safe test data or supervised work under agreed conditions. Give the document to someone with the necessary basic skills who did not help write it. Ask them to perform the steps and mark places where they had to guess. The author observes rather than supplying missing explanations; otherwise you are testing the author, not the document.

Include at least a normal scenario and a significant exception. Record where a question arose, what information was missing and whether the document prevented an incorrect action. After revising the draft, repeat the troublesome part. A signature confirming that someone has read the document is not evidence that they can perform the task.

Finish training by asking the operator to explain the starting point, completion condition and escalation rule in their own words. If that differs from the intended rule, revise the document or training. Do not turn this exercise into a search for someone to blame for an incomplete draft.

9. Publish one current version

Choose a location where people actually look for instructions: an internal knowledge base, process page or ERP link. Include an owner, version number, effective date and short change history. Preserve old versions as clearly labelled archives so they do not compete with the current instruction in search results.

Decide who approves operational rule changes and who can correct wording without changing the process. When roles, fields or integrations change, review the linked instructions too. Printed workstation copies need a replacement procedure. A current-document link is usually easier to maintain than new PDFs in several chats, but only if it remains accessible where the work happens.

Schedule a review after the first real exceptions and then at an agreed cadence. The purpose is to close the gap between description and practice. If operators consistently bypass a step, first investigate whether they have the information, time and permissions required to perform it. Do not assume that publishing a revised file has changed working behaviour.

10. Measure the outcome, not the page count

Choose a small set of measures linked to the original problem: operations completed without clarification, returns for rework, decision waiting time or unresolved exceptions. Define the source and the start and end of each measurement. Compare similar work and account for workload changes rather than attributing every improvement to the document.

Keep a quality measure alongside speed. Faster receiving is not a success if item-identification errors increase. Do not establish individual performance standards from a handful of demonstration observations. First check whether the process is stable and working conditions are comparable.

Once the sequence is clear, evaluate automation: required fields, automatic task creation, duplicate-record checks or overdue-exception notifications. Every feature should support a specific SOP rule. Automating an undefined decision merely moves uncertainty between systems faster. Before implementation, assign an owner to integration failures and explain how interrupted work returns to the normal queue.

11. A reusable SOP structure

Copy the structure below into your internal knowledge base and complete it for one operation. Avoid placeholders such as “the responsible person performs the necessary actions”. Where a decision is still open, mark it as an unresolved question with an owner rather than presenting the draft as an active rule.

Before publication, review the document with both the operator and the recipient of the result. Each should confirm their side of the handover. Separately check that a new team member can access every referenced system and example. A procedure that works only with the author’s permissions is not ready for handover.

Keep the first release narrow enough to test. Once it works, use the same structure for an adjacent operation and check the connection between the two. A collection of individually clear procedures can still fail if each assumes the other team owns a missing step.

• Brief: name, purpose, boundaries, owner, version and effective date.
• Prerequisites: information, permissions, materials and approvals.
• Steps: action → checking rule → record or outcome → next participant.
• Exceptions: situation → safe stop → owner → condition for resuming.
• Acceptance: what must exist physically and in the system at completion.
• Training and changes: test scenario, questions log and update procedure.