Most operating procedures are written for the easiest version of the work. Open this screen. Copy that number. Choose this option. Send this message. The instructions look complete because they describe every click, but the moment something unusual appears, the person using them has no idea what to do.
That is because the procedure captured movement without capturing judgment. It explained how the last person completed the task, not how that person decided what a good result looked like. The difference matters in any business, but it matters even more in high-ticket ecommerce. A small decision about a supplier delay, an advertising exception, or a customer promise can carry a large consequence.
I want documentation that helps a capable person think, not documentation that tries to turn the person into a machine. The goal is consistency without pretending every situation is identical. To get there, you have to record the decisions around the steps.
Start with the outcome the process is supposed to produce
Before documenting the steps, write one sentence that defines the result. An order-review process may exist to release valid orders quickly while stopping the few that need a closer look. A supplier follow-up process may exist to give the customer an accurate update before the promised communication window closes. A campaign review may exist to protect contribution profit while preserving useful demand.
That sentence gives every step a purpose. It also makes it easier to notice steps that survived from an older version of the business but no longer improve the outcome. If nobody can explain why a field is copied, a report is exported, or an approval is requested, the procedure may be preserving work that should disappear.
A clear outcome creates room for good judgment. When software changes or the exact screen looks different, the operator can still move toward the intended result. Without the outcome, even a minor interface change can make the entire document feel obsolete.
- Name the customer, supplier, financial, or operating result the process protects.
- Define what complete means in observable terms.
- State the time window when timing affects the quality of the result.
- Remove any step that cannot explain how it supports the outcome.
Separate the normal path from the decision points
Every repeatable process has a normal path. Most orders, messages, feed updates, and reports should move through it with very little drama. Document that path simply. The procedure does not become more useful because it contains forty screenshots for a task that needs five clear actions.
Then mark the places where the operator must evaluate information. These are decision points: the address does not match, freight is higher than expected, a product specification conflicts with the supplier file, the customer asks for a promise the store has not made, or a campaign crosses a limit without enough data to explain why.
Decision points deserve more attention than clicks. For each one, explain which facts matter, what conditions allow the work to continue, what conditions require a pause, and who owns the next decision. This is where the real operating knowledge lives.
Give people boundaries, not vague instructions
A weak procedure says, ‘Use your best judgment,’ and leaves the risk with the employee. Another weak procedure says, ‘Ask the owner,’ and moves every uncertain case to the most expensive bottleneck in the company. Neither approach builds a capable team.
Useful boundaries explain what someone can decide on their own. They may define a dollar limit, a time limit, an approved set of remedies, the source that wins when information conflicts, or the conditions that make an issue urgent. The exact boundary depends on the process. The important part is that it is specific enough to guide action.
I also want the reason behind an important boundary. If someone knows that a particular promise creates supplier risk, they can recognize a similar risk in a new situation. If they only know that a box must remain unchecked, they will be stuck the first time the software changes the box.
- What can the operator decide without approval?
- What facts must be checked before that decision?
- Which limits must never be crossed?
- What requires escalation, and to whom?
- What evidence should be saved after the decision?
Use examples to teach the edge of the rule
Rules become clearer when people can see where they apply. Add a few short examples drawn from situations the business actually encounters: one obvious normal case, one case that can be resolved within the operator’s authority, and one case that must be escalated. Remove private customer details and keep the focus on the decision.
The value is not in creating a giant library of every event that could happen. You will never finish that library, and nobody will read it. The value is showing the shape of the rule. A well-chosen example helps the reader understand why two cases that look similar may need different treatment.
Examples also reveal weak documentation. If two experienced people read the rule and classify the same example differently, the standard is not settled yet. Resolve that disagreement before asking the rest of the team to produce consistent results.
Make escalation part of the process, not a sign of failure
People hide uncertainty when escalation feels like admitting they cannot do the job. That creates silent risk. The better system makes escalation a defined path for cases that genuinely require more context, authority, or experience.
A good escalation contains the facts already checked, the source of those facts, the decision that is needed, the available options, and the deadline. It should not be a forwarded message with the words, ‘What should I do?’ The operator still owns assembling the problem even when someone else owns the final call.
This standard protects everyone’s attention. The decision-maker receives a prepared issue instead of starting the investigation from zero. The operator learns how experienced decisions are framed. Over time, repeated escalations can become new boundaries, training examples, or fixes to the underlying process.
- Summarize the situation in one or two sentences.
- List what has already been verified and where it was verified.
- State the decision required and when it is required.
- Recommend a next action when the available evidence supports one.
- Record the final decision so the lesson does not disappear in a message thread.
Review exceptions before adding more procedure
When a mistake happens, the natural response is to add another rule. Soon the procedure becomes a history of everything that ever went wrong. It gets longer, the important instructions become harder to find, and people stop using it.
I would review the exceptions on a regular schedule instead. Which cases repeated? Which decision took too long? Where did the operator lack information? Which escalation could have been handled with a clearer boundary? Which problem started upstream and should be removed there instead of documented downstream?
Some exceptions deserve a new instruction. Others reveal bad source data, unclear ownership, missing supplier information, a broken automation, or a promise the business should stop making. Fixing the source is stronger than teaching everyone to work around the same defect forever.
Keep the main procedure focused on the normal path and the important decision points. Put rare reference material somewhere searchable. Archive rules that no longer apply. Documentation should become clearer as the operation improves, not longer by default.
Test the procedure with someone who did not write it
The author is the least qualified person to judge whether the document is complete. They already know the missing context, so their mind fills every gap. Give the procedure to someone capable who does not normally own the task and watch where they pause.
Do not immediately explain the answer. Ask what they expected to find, which fact was missing, and which sentence created uncertainty. Their questions are the test results. Update the document, then have the regular owner use the revised version during real work.
The final check is the output. Did the process produce the intended result? Was the right evidence recorded? Were exceptions visible? Could another person understand what happened later? A procedure is not successful because every checkbox was checked. It is successful because the operation produced a reliable result that can be reviewed.
Documentation should transfer judgment, not dependency
A business becomes easier to operate when more decisions can be made correctly without waiting for the owner. That does not mean distributing unlimited authority or removing experienced judgment from important situations. It means making the normal standards clear, giving people sensible boundaries, and reserving escalation for the cases that deserve it.
Start with one recurring process that still creates questions. Write the outcome. Simplify the normal path. Mark the decision points. Define the boundaries and escalation path. Add three useful examples. Then test it with someone else and improve it from the exceptions that actually occur.
The result will be more than an SOP. It will be a small operating system for one part of the business: clear enough to create consistency, flexible enough to survive reality, and useful enough that people will actually follow it.