Writing operating procedures your team can use after automation

Operating procedures for automated workflows explain how a task runs, what staff must check and what to do when the expected outcome does not appear. They give the business a way to keep working when the colleague who designed the process is unavailable.

Automation changes a procedure even when the customer sees no difference. A person may stop entering a record but become responsible for reviewing exceptions. A manager may approve work in a new interface. Unless those changes are written and practised, the business can acquire software while retaining an uncertain way of operating it.

This guide describes a practical procedure structure, a handover exercise and a method for keeping instructions current. The examples are illustrative operating designs for established organisations; they do not replace your sector's required controls or professional standards.

Begin with the outcome and the boundary

Give the procedure a recognisable name based on the task, such as “Review an unmatched supplier invoice” or “Resolve a failed order transfer”. A title describing only the software package gives staff little help when they are looking for the instruction relevant to a customer problem.

State the intended outcome in one or two sentences. For an invoice review, that might be a checked record ready for an authorised decision, or a documented query assigned to the right owner. Avoid defining success as clicking the final button; the business outcome may depend on a later confirmation.

Describe where the procedure starts and ends. Explain the preceding event and the next owner. If another team confirms delivery before finance reviews an invoice, identify that dependency. Instructions that assume somebody else has already completed an unnamed check leave an important gap between departments.

Include explicit exclusions. A routine customer-address update may exclude a change to payment details or a request involving a disputed identity. Staff need to recognise when they have left the ordinary procedure and should use a different approved route. That is particularly useful when the system presents similar-looking screens for different risks.

Write for the person doing the work

Speak with the people who handle the task on ordinary busy days. Ask them to demonstrate the last difficult case, including any notes or spreadsheets used outside the formal system. Those workarounds can reveal missing information or instructions that no longer reflect how the operation functions.

Use the language staff recognise, then define any system term they need. A queue labelled “exceptions” may contain missing references, rejected records and customer queries with very different next actions. Explain the actual situations instead of repeating the label as though it were self-explanatory.

Keep each instruction focused on an observable action and its expected result. “Check the transfer” is vague. “Open the order reference in the receiving system and confirm that one matching order exists” tells the reader what to examine. Include what to do if they find zero records or more than one.

Choose a format that staff can access where they work. A lengthy PDF on a shared drive may be inconvenient on a warehouse handheld or at a reception desk. A concise controlled page with linked detail can work better, provided its access, versioning and availability are maintained.

Use a repeatable procedure template

The following headings form a reusable starting point. They are a suggested structure, not a certification standard. Adapt the amount of detail to the consequences of getting the task wrong and the experience of the people expected to perform it.

• Purpose and scope: the outcome, the starting event and the work excluded.
• Responsible roles: the operator, decision owner, absence cover and escalation contact.
• Before starting: required access, source records and checks already completed.
• Ordinary steps: actions, expected results and evidence to retain.
• Exceptions: recognisable problems, safe next actions and points where work must stop.
• Recovery and reconciliation: how to resume safely after a failure or manual workaround.
• Maintenance: owner, version, review date and the event that triggers an earlier review.

Avoid placing passwords, private keys or confidential customer examples in the procedure. Link to an approved access process instead. Instructions need to remain usable without becoming a second place where sensitive credentials accumulate or where former staff can find information they no longer need.

Add a small revision history explaining meaningful operational changes. “Updated” is less useful than “Added a check for orders already created before retrying a failed transfer”. The history should help someone covering the task understand whether their previous training still applies.

Explain the difference between automated and human steps

Mark the events the system performs and the decisions a person retains. A workflow might capture a document automatically, compare fields through rules and ask an employee to confirm a discrepancy. Writing all three as “the invoice is checked” conceals who is accountable for the final judgement.

For each automated step, state how staff know it completed. The evidence may be a destination reference, a reconciled count or a status confirmed by the receiving application. A notification from the sending tool proves that an attempt occurred; it may not prove that the business record was created successfully.

For each human step, explain the authority required. Someone can be trained to identify a pricing discrepancy without being authorised to accept it. The procedure should direct the issue to the relevant decision owner rather than making a confident operator responsible for a decision outside their role.

Our guide to AI and rule-based automation provides useful background for mixed workflows. Where AI suggests text or a classification, the procedure should specify what the reviewer checks against the source and what information is insufficient for an automatic decision.

Document exceptions with a recognisable trigger

Write exceptions around what staff will see: an order has no customer reference, a connection reports a timeout, two possible supplier records match or a total differs from the source. Specific triggers reduce dependence on someone noticing that the system “looks wrong”.

For every trigger, describe the immediate safe action. That may be to hold the item, record the reference and assign it to a named role. Be explicit about actions to avoid, such as repeatedly pressing a submit button when the first attempt may already have reached the destination.

Distinguish urgent operational problems from ordinary queries. A delayed management report and an incorrectly released customer order may need different escalation routes. Set the route and coverage against the organisation's actual risks and working hours rather than using the same alarm level for everything.

Check that exception instructions work for a colleague with ordinary permissions. An instruction that says “ask the administrator to fix it” is incomplete if the administrator is unavailable and no cover exists. Record the fallback, the information to preserve and who can authorise temporary manual operation.

Work through a failed-transfer example

Imagine a hypothetical service business transferring accepted quotes into a job system. A connection times out after sending a job request. The operator sees an error, but the destination may already have created the job. Retrying without checking could create duplicate work and two conflicting schedules.

The procedure first asks the operator to retain the quote reference and look for a matching destination record. If one correct job exists, they link its reference and complete the reconciliation. If none exists, they follow the authorised retry route. If the result is ambiguous, they hold the item for investigation.

The instruction also states what happens to customer communication. A failed internal transfer should not trigger several contradictory booking confirmations. The team agrees which status permits a confirmation and who can contact the customer if manual clarification is necessary.

Finally, the procedure records the resolution and whether the fault is recurring. A temporary workaround should not become a permanent hidden responsibility. If staff repeatedly repair the same transfer, assign a technical or process improvement with an owner and a review date, rather than accepting the rework as normal.

Design screenshots and checklists to survive change

Screenshots can help someone recognise the right area, but they become stale when software changes. Pair them with a description of the task and expected result. Avoid instructions based only on colour or position, such as “press the green button on the right”, because layouts and accessibility settings vary.

Use fictitious or appropriately redacted records in illustrations. Check that redaction removes the underlying information rather than merely drawing a shape over it in an editable file. Preserve any example needed for training in the controlled documentation area, separate from live customer records.

A short checklist works well for high-consequence checks that must occur every time. It should not repeat every obvious mouse movement. Ask whether each item prevents a known error, supports a decision or confirms completion. Remove steps that add reading without changing the quality of the work.

Accessible instructions help the whole team. Use meaningful headings, readable text and actual lists rather than images containing all the wording. The W3C page structure tutorial explains useful principles for web-based guidance. Test the document with the devices and assistive tools your colleagues actually use.

Test the handover without coaching

Give the draft procedure to a trained colleague who did not write it. Ask them to complete representative test cases in a suitable non-production environment or controlled rehearsal. Observe where they hesitate, search elsewhere or ask a question. Avoid answering immediately; first record the missing instruction.

Include an ordinary case, an exception and an interruption. For example, pause the exercise halfway through and ask the colleague to resume later using only the working record. A procedure that works only when someone remembers every preceding action will be fragile during busy shifts and absence cover.

Ask the colleague to explain the stopping points in their own words. Can they recognise when they lack authority, when evidence is missing and when a retry could duplicate a transaction? Being able to repeat the steps is less useful than understanding the decisions those steps protect.

Revise the instruction after the rehearsal and repeat only the affected parts. Keep a record of who is trained for each role and what version they practised. This gives a new manager a concrete way to arrange cover without assuming that everyone with system access can perform every operational task.

Connect the procedure to support and maintenance

Assign an operational owner and a technical support route. The operational owner decides how the work should run; technical support investigates whether the tools are behaving as intended. Some issues require both. An undocumented gap between those roles can leave staff waiting while each assumes the other is responsible.

Define what a useful support request contains: the task reference, observed result, expected result and time of the incident. Provide a controlled way to share relevant evidence. Discourage staff from copying confidential files into informal group chats merely because that is the quickest way to attract attention.

Decide how urgent changes are communicated. A revised procedure stored silently in a folder does not tell today's operators that a step has changed. Use an appropriate notice, acknowledge affected staff and provide brief practice where the change alters a decision or recovery action.

The business process audit service can help identify these responsibilities before implementation. A good handover includes the process, the exception routes and ownership of ongoing operation. Documentation should be an agreed deliverable with acceptance criteria, rather than an optional file added after the technical work is complete.

Review after changes and real incidents

Set review triggers beyond a calendar date. A new system release, revised approval policy, changed supplier interface or recurring incident can make a procedure inaccurate immediately. The owner should know which events require a check and how affected staff will be told while the review is underway.

Use incident reviews to improve instructions without blaming the person who encountered the problem. Ask what information was visible, which instruction they followed and whether the expected result was clear. If several people make the same mistake, the design may be asking too much of memory or interpretation.

Check that retired versions are clearly marked and removed from ordinary use. Keep any historical copies required for accountability in a controlled archive. Multiple apparently current documents are particularly dangerous where one describes a superseded approval route or a recovery step that can now create duplicates.

Review the manual fallback as part of maintenance. A fallback can stop working when staff permissions, forms or destination systems change. Practise it proportionately to the business risk so it remains a credible option. An instruction nobody has tried since the original project is an assumption, not evidence of resilience.

Make the procedure part of everyday management

Use a short review of exceptions and recurring questions during the early operating period. Update the procedure when the agreed way of working changes. Keep improvement ideas separate from current instructions until they are reviewed, so a promising suggestion does not accidentally become an unofficial policy.

Track avoidable rework, recovery time and the questions raised by cover staff. These observations help prioritise instruction changes. Do not measure documentation quality by page count; a shorter procedure that enables the right decision is more useful than a comprehensive-looking manual nobody can navigate under pressure.

Before closing an automation project, ask an ordinary operator to demonstrate the task and an exception using the delivered instructions. Ask the owner to explain maintenance and support. Those checks reveal whether the business has received an operating capability or merely a functioning technical demonstration.

For the wider release context, see rolling out an automation pilot. The written procedure is one part of readiness alongside testing, access, monitoring and ownership. Together they help the team keep control of the work as the system and the organisation evolve.

Checked sources

• W3C WAI: page structure tutorial