Good automation removes repeatable effort from a stable process; bad automation accelerates ambiguity and hides exceptions.
The short answer
Prioritise frequent, rule-based work with reliable inputs. Delay automation when rules change constantly, exceptions dominate or an error creates consequences that cannot be repaired safely.
The next step is not choosing a tool. It is clarifying the decision, ownership and evidence that the team will accept.
Decision model
01. Frequency and volume
Measure repetition, manual time and interruptions.
02. Rule stability
Document decisions and exceptions before writing the workflow.
03. Data and integration
Identify the source of truth, validation and permissions.
04. Risk and visibility
Design idempotency, alerts, logs and exception ownership.
Applying the model
01. Starting context
Inventory repetitive work for two weeks and record volume, duration, interruptions, data source and exception rate. Start with the steps that consume time or create errors, not with a tool’s feature list. A five-minute action repeated hundreds of times may deserve priority over a complex monthly report because its cumulative cost and disruption are larger and easier to verify.
02. Controlled execution
Model the process as states and decisions. For each step define mandatory input, validation, action, confirmation and the person who handles an exception. Automate one narrow but complete path first so the outcome can be observed end to end. Expanding across several applications too early makes it difficult to distinguish a wrong rule from a failing integration.
03. Useful evidence
The business case includes development, licences, monitoring, repair effort and time saved. Measure success without intervention, cycle time, exceptions, duplicates and the impact on the next user. A workflow that removes data entry but creates additional reconciliation work has not proven value; it has moved the effort into a less visible part of the organisation.
04. Decision threshold
Automate when rules are stable enough, errors are detectable, data has an owner and the volume is repetitive. Keep human control where the case requires judgement, empathy, negotiation or accountability for a material consequence. Assisted modes sit between the two: the system prepares, validates or recommends and a person confirms. This often creates value earlier with less operational risk.
Scenario and working plan
01. Diagnostic example
Compare two processes. One copies validated orders into an internal system every day using stable fields and few exceptions. Another decides which customers receive special commercial terms from history, relationship and context. The first is a strong candidate for automated validation, deduplication and logged writing. The second may benefit from a prepared summary and recommendation while accountability remains human. Both can use technology, but autonomy and evidence differ because reversibility and the cost of error differ.
02. Implementation plan
For the first flow, document input state, order identifier, mandatory fields and confirmation from the destination. Run on a subset, compare with manual operation and create an exception queue before removing work. For the second, aggregate information and highlight unusual cases while the responsible person confirms the decision. Review time saved, errors, exceptions and downstream impact. Expand only where total effort falls without hiding ownership. The goal is not to maximise the number of automated steps; it is to create a complete, observable process whose exceptions remain manageable.
03. Decision log
To make the recommendations in “Which business processes are worth automating?” traceable, open a simple decision log before the first change. Record the observed problem, baseline, hypothesis, owner, evaluation window and the condition for stopping or continuing. Evidence should come from sources suited to the topic, while technical indicators remain separate from commercial outcomes. The first measure reviewed is manual time and cycle time, without treating it in isolation from data quality, total cost and downstream effects. This turns a favourable dashboard into an explainable decision rather than a conclusion based on intuition.
04. Review and next decision
At the end of the cycle, compare the result with the baseline and record what changed, what remains uncertain and which side effects appeared. Check explicitly whether “The process has an owner” and “The step is repeatable” are true. If the evidence cannot support a conclusion, keep the hypothesis open instead of declaring success. The risk “Automating an unclear process” stays visible during review so that pressure to show progress does not replace analysis. Choose the next step only when the team can explain what it learned and why the new priority matters more than the alternatives.
Pre-implementation checklist
- The process has an owner.
- The step is repeatable.
- Rules and exceptions are describable.
- The data source is known.
- Errors can be detected and repaired.
What to measure
Metrics are defined before launch and separate technical signals from confirmed business outcomes.
- manual time and cycle time;
- success and exception rate;
- duplicates and repair effort;
- adoption and operating cost.
Mistakes and limits
- Automating an unclear process.
- Writing before validation.
- Retry without idempotency.
- No owner or audit trail.
Conclusion
Automate the smallest complete workflow that can be observed end to end, then expand only after exceptions and economics are understood.