By Friday afternoon, most operations have a few pieces of work that finished because someone spotted a problem and stepped in. An order was missing a code, a delivery slot conflicted with the route, a spreadsheet total looked wrong, or a customer promise had no matching warehouse instruction. A person found the gap, chased the answer, and got the work moving.
The weekly report shows the completed order. It rarely shows the rescue.
That makes Friday a useful time for an operations director to ask a different question: what did the team have to rescue by hand this week? The answer can point to a more useful improvement than the loudest item in the systems backlog.
The work can finish and still be broken
Completed work can hide a weak process. An order may ship on time after customer service phones the warehouse and an experienced picker recognises an odd unit of measure. The customer sees a result, but the organisation still carries the extra work.
Most systems record the final state. They seldom record the chase, duplicate entry, interruption, or remembered exception that made it possible. Those interventions still consume capacity. They also create a dependency on the people who know where to look and whom to ask.
Good people can keep a weak process looking reliable for a long time. When they are on leave, busy with another problem, or replaced by somebody new, the real design becomes visible.
The Health and Safety Executive's guidance on managing human failures is written for safety-critical work, but one principle applies more widely. It warns against assuming that an operator will always be present, detect a problem, and take the right action immediately. The guidance also distinguishes unintended slips and lapses from well-meaning workarounds, then recommends looking at task design and the conditions that make errors more likely.
Treat a routine rescue as evidence about the process. Praise the person who protected the outcome, then study why the process needed protection.
Choose one rescue from this week
Keep the first pass small. Choose one order, booking, delivery, purchase, or job that was corrected, escalated, or unusually dependent on a particular person. Use the real record and speak to the people involved while the sequence is fresh.
Ask:
- What was supposed to happen?
- Where did the expected flow first change?
- Who noticed, and what gave them the clue?
- Which systems, files, messages, or paper records did they check?
- What decision required experience or authority?
- What did they have to chase, rekey, calculate, or remember?
- How long passed between the first weak signal and recovery?
Read the source records together. Follow the system history, spreadsheet, email, chat, and handwritten note in the order they appeared.
The Government Digital Service's guidance on mapping a whole problem recommends including online and offline touchpoints, backend processes, and the people involved. It also recommends mapping together so that those delivering the journey share an understanding of what needs fixing.
A rescued order gives an operations team a manageable version of that exercise. Draw a simple line from the original request to the completed outcome. Mark every handoff, wait, correction, and decision. Keep the sequence messy and factual. If the work passed through three applications and a phone call, put all four on the page.
Follow it back to the first weak signal
The final recovery step is usually obvious; the earlier deviation is easier to miss.
Suppose an order misses its dispatch cut-off because the warehouse release failed. Late picking is the visible problem. An invalid address or product-code mismatch may have appeared first. The same is true of a credit hold that never reached customer service or a batch import with an unowned warning.
Mark four moments:
- The expected state before the problem.
- The first point where reality differed.
- The first signal that a person could see.
- The action that restored the flow.
The gap between the second and third moments is detection delay. The work between the third and fourth is recovery load. Keeping them separate helps the team improve both.
Many projects start at the recovery step because that is where people feel the pain. A faster spreadsheet or an extra alert may reduce the immediate burden while the invalid record keeps entering the process. Follow the rescue backwards until you find the earliest point where a small control could prevent the exception or make it visible sooner.
The HSE's guidance on design recommends involving operatives, maintenance staff, and systems support in system design. That mix matters in ordinary operational work too. The person doing the rescue knows the exceptions. The person supporting the system knows what can be observed, changed, and recovered safely.
The first useful fix might be validation at data entry, a clearer status, an owned exception queue, or a change to a handoff. Start where the evidence leads.
Keep judgement and remove memory work
Separate the parts that need judgement from the parts that rely on memory.
Judgement belongs in decisions where information is incomplete or the consequences depend on context. A customer promise may conflict with available stock. A delivery exception may have several acceptable resolutions. Give the accountable person the relevant evidence, permitted actions, and a clear place to record the choice.
Memory work has a different shape. A coordinator remembers that one account needs a particular carrier code. Someone checks a shared inbox at 3 p.m. because no system raises an event. An operator spots a filename pattern and copies a value between screens. These are rules and detectable conditions hiding inside a person's routine.
Capture the rule before choosing the technology. A deterministic check is usually the calmer option when the input and outcome are known. For unstructured input such as emails, forms, or delivery notes, AI may help classify the item or prepare a draft. Keep validation and human approval where an uncertain result could affect a customer, payment, stock, or safety.
ORBN's AI automation work follows this boundary: automate the repeatable handling around a decision and keep an accountable review point where uncertainty matters.
Measure the reduction in manual rescue time and repeat exceptions. The number of automated steps says very little about the operational result.
Give Monday one useful change
A 30-minute review of one real rescue should end with one owned change. It might be:
- Capture the exception reason and elapsed time for the next two weeks.
- Validate one field closer to its source.
- Show one missing or failed handoff in an exception queue.
- Assign an owner and escalation time to a recurring problem.
- Remove duplicate entry between two systems.
Choose the smallest change that will produce evidence. A short observation period will show whether the problem repeats, how much time it consumes, and whether the proposed control would have caught it.
The pattern also guides the next investment. Clarify and test an unclear business rule. Use system integration when staff repeatedly move or reconcile the same data. Consider a focused internal tool when people must assemble the same cross-system context before every decision. Use bounded AI when the input is unstructured and a review step can contain uncertainty.
Set a baseline before changing the process. Count occurrences, elapsed time, hands-on rescue time, and the effect on service or cost. Review the same measures after the change. A week with no visible incident may mean the control worked, or it may mean nobody recorded the exception. Keep the evidence simple enough that the team will maintain it.
The weekend question is simple: if the same event happens on Monday, what should the operation detect before a person has to go looking for it?
Bring one real rescue to Monday's meeting. Keep the judgement that mattered. Turn the repeated chase into an owned signal and a better rule. Build software when the evidence shows where it will help.