When errors repeat, organisations often blame carelessness or training. Sometimes that diagnosis is correct. Often the operating environment is asking people to remember too much, copy too much, interpret unclear rules, work across several systems and notice exceptions without adequate signals.
In that environment, error is not only an individual performance issue. It is also a systems-design issue.
Reduce the number of ways routine work can go wrong before trying to remove the human from the process.
Not all errors are the same
The UK Health and Safety Executive's guidance on managing human failure was written for workplace safety, but its distinctions transfer well to office and digital operations. It starts from the position that everyone can make errors however well trained and motivated they are, and separates several types of failure:
- Slips and lapses: unintended actions during familiar tasks, such as pressing the wrong button or forgetting a step. HSE notes that these cannot be eliminated by training, but improved design can make them less likely and the system more error tolerant.
- Mistakes: errors of judgment where the intended action is wrong, often because the situation is new or the person has not been properly trained. Training based on good procedures is the main remedy.
- Violations: deliberate deviations from a procedure, usually well meant and often caused by a poorly designed task or an unworkable rule.
HSE also points to factors that make errors more or less likely, including poor design, distraction, time pressure, workload and communication systems, and recommends controls that redesign the task wherever possible. In digital operations, the equivalents are familiar: copying values between screens, ambiguous fields, interruptions from several channels, and workarounds that exist because the official route is too slow. Sending everyone on another training course will not fix a slip caused by an interface that invites it.
Separate judgment from clerical burden
Human judgment is valuable when work involves ambiguity, conflicting evidence, customer context, ethical trade-offs or exceptions that cannot be represented safely as fixed rules. Human attention is less valuable when it is spent copying identifiers, checking whether required fields are complete, calculating deterministic values or remembering routine follow-ups.
Map the process and mark each step as one of four types: deterministic rule, data movement, human judgment or exception handling. This makes it easier to see where automation can reduce mechanical work without pretending that every decision is reducible to a rule.
| Step type | Typical example | Usual design response |
|---|---|---|
| Deterministic rule | Calculating a discount from a fixed table | Calculate systematically |
| Data movement | Copying an order number into a finance system | Integrate or prefill |
| Human judgment | Deciding whether to extend credit to a long-standing customer | Support with context; keep the decision human |
| Exception handling | An order that matches no standard product | Route deliberately to someone with authority |
Design better inputs
Many downstream errors begin with weak capture. Free-text fields where structured choices would work, duplicate entry, unclear definitions and fields requested before the information is actually known all create avoidable variation.
Improve validation at the point of entry. Prefill information already known. Use clear field definitions. Prevent impossible combinations where the business rule is deterministic. The cheapest error is usually the one that never enters the process.
Put checks near the risk
Do not rely on a final reviewer to catch every upstream mistake. Place controls where the error can occur. For example, verify required data before submission, check a threshold before approval, validate a record before synchronisation and flag an unusual value before it becomes part of a report.
This is different from adding approval layers everywhere. A control should address a defined risk. If it merely transfers responsibility to another person without improving detection, it creates delay rather than safety. A reviewer who approves fifty routine items a day will, quite reasonably, stop examining them closely.
An illustrative example
This is a hypothetical scenario, not a client case. A finance team keeps paying supplier invoices to outdated bank details. The first response is a second-person check on every payment, which doubles effort and still misses errors because reviewers see only the payment run. Tracing the error shows that bank details are changed by email request and re-keyed manually. Moving the control to the point of change, with a verified callback and a structured change record, removes most of the risk and lets the payment check focus on genuinely unusual items.
Make exceptions explicit
Automation is strongest on predictable paths. Human judgment becomes especially important when the case falls outside those paths. Design an exception route deliberately: what qualifies as an exception, what information the reviewer receives, who has authority, what happens if no decision is made, and how the outcome is recorded.
That prevents two opposite failures: forcing unusual cases through rigid automation, or sending every routine case to a human because exceptions exist. The related design of failure routes in automation is covered in why every automation needs a failure path.
Use automation to support, not obscure, decisions
A useful automation can gather evidence, pre-populate context, calculate deterministic values, identify missing information and route a case to the right person. The person then makes the decision with less clerical work and better information.
The automation itself must also be reliable, or it simply introduces a new class of error. Microsoft's guidance on testing cloud flows recommends checking flow logic before running it, testing against realistic triggers, and using mock results to simulate different scenarios and conditions. The principle applies to any automation platform: the scenarios worth testing are the unusual ones, because that is where silent failures hide.
Where AI is involved, the same principle becomes more important. The system should make clear what information was used, where confidence or uncertainty matters, what the human is expected to verify and how overrides are captured. Human review is not meaningful if the reviewer is given no usable basis for judgment.
The EU AI Act's Article 14 on human oversight, which applies to high-risk AI systems, describes what meaningful oversight requires. It expects the people overseeing a system to understand its capacities and limitations, to be able to detect anomalies, to correctly interpret its output, and to remain aware of the tendency to over-rely on automated output, which it calls automation bias. Most business workflows are not high-risk systems under the Act, but the design lesson is general: a human who rubber-stamps an automated recommendation is not providing judgment.
Warning signs
- The same error recurs across several competent people.
- Fixes consist mainly of reminders, emails and additional sign-offs.
- Reviewers approve almost everything they see.
- People keep private checklists or spreadsheets to avoid mistakes the system allows.
- Exceptions are handled by whoever happens to notice them.
Measure error patterns instead of anecdotes
Track error type, frequency, process stage, cause, rework effort and downstream impact. Look for clusters. If the same mistake appears across competent people, the process or interface deserves investigation. If one person repeatedly deviates from a clear, well-designed process, training or performance management may be appropriate.
This distinction matters because the wrong diagnosis produces the wrong intervention.
A practical diagnostic
For a recurring error, work through these questions:
- Is this a slip, a mistake or a deliberate workaround?
- At which step does it enter the process, and where is it first detected?
- Could better input design or validation prevent it from entering?
- Is the step deterministic, or does it genuinely require judgment?
- If judgment is required, does the person have the context and authority to exercise it?
- If an automation is involved, how would anyone know it had produced a wrong result?
The trade-offs
Tighter validation reduces error but can block legitimate unusual cases if the rules are too rigid. More automation reduces clerical slips but can deskill reviewers and encourage over-reliance. More checks can increase detection, or simply spread responsibility so thinly that nobody looks closely. Good design accepts that some judgment will be wrong occasionally and makes those cases visible and recoverable, rather than trying to remove judgment altogether.
What better looks like
A mature workflow uses software for consistency and people for judgment. Routine validation, calculation, routing and data movement are handled systematically. Humans receive the context they need for exceptions and consequential decisions. Errors are analysed as operational evidence rather than treated only as individual failure.
The objective is not zero human involvement. It is a system where human attention is concentrated where it adds value.
Digital Operations Improvement can redesign controls and exception paths around real work. Business Automation & AI Workflows can then automate deterministic steps while preserving explicit human decision points.
Sources and further reading
- Article 14: Human Oversight - EU Artificial Intelligence Act (last verified 10 October 2026)
- Test cloud flows - Power Automate (last verified 10 October 2026)
- Managing human failures: Overview - HSE (last verified 10 October 2026)