Turn work you carry in your head into a tested process with a trigger, decisions, exceptions and proof, so another person can complete it correctly.
Short answer: Document one repeatable outcome using a clear start trigger, required inputs, numbered actions, decision rules, exceptions and evidence of completion. Give the draft to someone who has not watched you do the work, then revise every point where they ask a question, guess or produce the wrong result. A process is ready when that person completes one real case correctly without your intervention.
Most process documents fail because they describe the work rather than direct it. “Check the order and update the customer” sounds reasonable, but it leaves the reader to decide what to check, which customer record to update and what message is acceptable.
Writing more pages does not solve that. You need to make hidden choices visible.
Use the Action-Proof Process Card
The Action-Proof Process Card is a seven-field framework for one outcome. Keep the first version to one normal case and the exceptions that could cause meaningful loss.
- Outcome: What to write: The finished state, including quality and time; Test question: Can two people recognise the same correct result?
- Trigger: What to write: The event that starts the process; Test question: Does the responsible person know when to begin?
- Inputs: What to write: Information, materials, access and approvals required; Test question: Can work start without chasing you?
- Actions: What to write: Numbered verbs with a named object and location; Test question: Could a new person perform each action?
- Decisions: What to write: If-then rules with thresholds; Test question: Has your judgement been converted into a rule?
- Exceptions: What to write: Conditions that stop, reroute or escalate work; Test question: Is risky improvisation prevented?
- Proof: What to write: The record showing completion, owner and date; Test question: Can you check the result without repeating the work?
My position is that you should not begin by documenting your most complex process. Start with a frequent task that creates customer or cash errors. One process tested in live work is worth more than a folder of untested procedures.
Define the boundary before the steps
Name the process with an outcome, not a department. “Accept a custom framing order” is clearer than “sales administration”. State the trigger and finish in one sentence: “Starts when a customer approves a quote and finishes when the production record contains the confirmed specification, deposit status and collection date.”
Then list what is outside scope. Measuring the artwork may be part of intake; cutting the frame is a later production process. Without a boundary, the document expands until nobody uses it.
Assign one role as process owner. That person keeps it accurate, but does not need to perform every step. Use role names such as order coordinator rather than a person's name, because people change.
Set a completion time only when it matters. “Within two working hours of deposit receipt” is actionable. “As soon as possible” is not.
Observe the work before writing it
Watch one normal case and one awkward case. Ask the experienced person to say what they notice before every choice. The valuable material is often not the click sequence. It is the sentence “I stop here if the delivery postcode does not match the quote.”
Capture actual inputs and outputs. Use a real anonymised order, not an ideal case invented from memory. Note every interruption, lookup and correction. If the operator keeps information on a scrap of paper, that is evidence the official process is incomplete.
Do not turn one person's workaround into policy automatically. Ask whether the step controls a real risk, satisfies a requirement or merely compensates for a poor system. Remove work that serves no purpose before documenting it.
Write actions and decisions differently
Each action should begin with a specific verb and name where the result goes. For example: “Enter the approved internal frame dimensions in the production record” is stronger than “Process measurements”.
Each decision should state the condition and route:
- If any measurement is missing, return the order to the measurer before taking the production deposit.
- If the requested collection date is earlier than the current standard lead time, obtain production approval before confirming it.
- If the artwork is visibly damaged, photograph it with the customer's permission and record the condition at intake.
Use tables where several decisions share the same inputs. Avoid paragraphs that make a reader hunt for a threshold.
- All dimensions present and within offered range: Continue: Create production order; Escalate: None; Record: Dimensions and initials
- Non-standard material requested: Continue: Hold order; Escalate: Production lead confirms method and price; Record: Decision and revised quote
- Deposit not received: Continue: Save as pending; Escalate: Contact customer after stated interval; Record: Payment status and contact date
- Customer property appears damaged: Continue: Pause intake; Escalate: Owner or duty manager reviews; Record: Condition evidence and decision
Make proof part of the process
“Done” needs an observable record. It might be a completed order entry, sent confirmation, signed inspection, labelled package or reconciled total. State the minimum fields.
Proof protects the person doing the work as well as the business. If an order later fails, you can locate the step and evidence instead of asking who remembers a conversation.
Keep evidence proportionate. Photographing every routine stationery delivery would create clutter. Photographing the condition of valuable customer property at handover may resolve a material dispute. The process should state why the evidence exists and how long it is retained under your applicable policies and law.
Screenshots and short recordings can clarify a spatial or physical action, but they age quickly. Put the written decision rule beside them and record the interface or process version. Never let an image be the only place a critical threshold appears.
Worked example: Kilnbridge Picture Framing
Kilnbridge Picture Framing accepted 45 custom orders last month. Six needed remaking because a measurement, mount choice or collection date had been entered incorrectly. Two customers also received £65 refunds for the delay.
The direct remake cost is £34 of material plus 1.5 hours of workshop labour at an internal £24 per hour.
Remake cost per order = £34 + (1.5 × £24) = £34 + £36 = £70.
- Six remakes: Calculation: 6 × £70; Amount: £420
- Two refunds: Calculation: 2 × £65; Amount: £130
- Total evidenced monthly failure cost: Calculation: £420 + £130; Amount: £550
The owner observes three orders, writes an Action-Proof Process Card and tests it with the Saturday assistant. Four hours at an internal £28 per hour costs 4 × £28 = £112.
The card defines the finish as a production-ready order with four measurements, material code, mount choice, deposit status and accepted collection date. It blocks production if any field is absent and requires a customer confirmation as proof.
The writing cost is recovered if the process prevents £112 ÷ £70 = 1.6 remakes, meaning two remakes at the stated cost. Kilnbridge should test the next ten real orders and compare first-pass accuracy, questions and completion time. It should not claim success because the document looks professional.
Test with silence
Give the process and a real low-risk case to somebody who did not help write it. State the outcome, then do not coach. Observe where they pause, search, infer or choose differently from you.
Mark four types of defect:
- Person asks what a word means: What it reveals: Undefined language; Revision: Replace it or define it beside the step
- Person cannot find an input: What it reveals: Missing access or location; Revision: Name the source and access requirement
- Two choices both seem valid: What it reveals: Hidden decision rule; Revision: Add condition, threshold and route
- Work is completed but cannot be verified: What it reveals: Missing proof; Revision: Add the completion record
Run the revised version with a second case. If you must explain the same point again, the process still depends on you.
Do not demand blind obedience. Give the operator a route for reporting that reality differs from the document. A process that cannot be challenged will become fiction while staff build a hidden workaround.
Related guides
Publish one process within five working days
Today, choose one frequent task that caused an error or consumed owner questions in the past month. Observe it twice tomorrow. Write the seven fields on day three, keeping the normal route visible and placing exceptions beside the decisions they affect.
On day four, ask a less-experienced person to run one safe case while you stay silent. Revise from what happens. On day five, release the process with an owner, version date and review trigger. Check the next ten cases for completion proof, questions and defects. Only then choose the next process.
Frequently asked questions
How long should a business process document be?
As short as it can be while still producing the correct result without oral explanation. A routine task may fit on one page, while a regulated or exception-heavy process may need several linked sections. Measure usefulness by test performance, not page count.
Put the normal route first and move rare background detail to clearly labelled notes. If operators scroll past several paragraphs to find today's action, shorten or separate the document. If they guess at decisions, add the missing condition even if that makes it longer. One process should still have one outcome and boundary.
Should I use screenshots or video instead of written steps?
Use them to support actions that are hard to describe visually, but keep triggers, thresholds, exceptions and proof in searchable written form. Screenshots become wrong when an interface changes, and video makes a single decision difficult to locate. Date each visual and name the version or physical setup it shows.
Test whether the operator can complete the work when the screen differs slightly. For a physical technique, a short demonstration plus written acceptance criteria can be effective. The process owner should review visuals whenever the system, equipment or layout changes.
How much detail is too much detail?
Detail is excessive when a competent new operator can already make the step correctly and the extra words do not control risk, quality or timing. Remove obvious movements such as “pick up the pen”, but retain values an insider takes for granted, including file location, units, naming rules and escalation thresholds.
Use the test to decide. If nobody hesitates or makes an error at a point across ten cases, you may simplify it. If different people produce different outcomes, the document needs more precision, not necessarily more background explanation.
Why do staff ignore procedures I have already written?
Usually because the procedure is inaccurate, difficult to find, slower than the real work or carries no visible consequence. Observe what people actually do before blaming compliance. Ask which step fails and why, then remove needless work or fix missing access.
Make the current version available at the point of use and retire obsolete copies. Managers must follow the same process or explicitly approve exceptions. If the procedure controls safety, law or material loss, train and supervise accordingly. A document people bypass every day is operational evidence, not merely an attitude problem.
How often should I update a process?
Update it when an input, system, supplier, rule, customer promise or recurring exception changes, and set a scheduled review based on risk. A low-risk monthly admin process might be reviewed every six months, while a high-consequence procedure needs more frequent control.
Those are working intervals, not universal requirements. Record the owner, version and approval date, then make sure operators use the current version. Do not revise for cosmetic wording during live work unless it causes confusion. Bundle minor improvements, but correct a dangerous or loss-making instruction immediately.
What should happen when the process does not fit the situation?
The operator should stop at a defined point, preserve the work completed and escalate with the facts needed for a decision. State who can approve the exception, the response time and how the decision is recorded. Do not write “ask the owner” for every variation because that recreates dependence. After resolution, decide whether the case was genuinely rare or exposes a missing branch. Add repeated exceptions to the process. Keep one-off decisions as case records rather than expanding the main route until it becomes unreadable.
Is a checklist the same as a process?
No. A checklist confirms that known items or actions were considered, while a process directs work from a trigger to an outcome and explains decisions and exceptions. A checklist can sit inside a process, particularly before dispatch or handover.
It cannot tell an inexperienced person what to do when an item fails. Use a checklist when the method is already understood and omission is the main risk. Use a full process when sequence, judgement, access or escalation matters. Test either format against a real case before relying on it.
Comments (0)