A prioritisation matrix for choosing a stable, frequent and reversible first automation instead of starting with the loudest complaint.
INPUT ─── DECISION ─── OWNER ─── RECORD
Start with a process, not an app
Specification detail
The first automation candidate should be a named flow with a clear trigger and finish, such as creating an internal follow-up task when an approved form arrives. ‘Automate the office’ and ‘use the CRM better’ are not candidates. List repeated processes and the people affected, then map the current steps. This prevents tool features from defining the problem and reveals whether a small rule, clearer template or removed approval could solve it without new software.
Favour stable rules and structured inputs
Specification detail
Good first candidates start from a reliable event, use fields in predictable formats and follow rules staff agree on. Poor candidates depend on reading ambiguous emails, negotiating exceptions or knowing unwritten customer history. If experienced staff cannot describe the same route, automation will encode confusion. Standardise the input and settle the rule first. One simple form with required fields may create more value than an elaborate workflow trying to infer missing information after it arrives.
Reduce the consequence of failure
Specification detail
Prefer actions that are easy to detect and reverse: creating a draft, adding an internal task or copying an approved field with validation. Be cautious with payments, deletion, customer promises, access changes and compliance decisions. Ask what happens if the automation runs twice, runs late, receives incomplete data or stops silently. Design idempotency, alerts, logs and manual recovery before launch. If failure would be noticed only by a customer or supplier, it is not a sensible unattended first project.
Practical matrix
First-automation prioritisation matrix
Score each candidate Low, Medium or High against the descriptions; choose a narrow candidate with strong suitability and manageable risk.
FrequencyLow: occasional; Medium: regular; High: repeated enough that staff can supply representative cases and will notice improvement.
Trigger clarityLow: starts through informal judgement; Medium: several known triggers; High: one observable event such as an approved form or status change.
Input structureLow: missing or free-form information dominates; Medium: mixed inputs; High: required fields, controlled values and a known source of truth.
Rule stabilityLow: staff disagree or policy changes often; Medium: core route agreed with caveats; High: explicit, approved rules cover the intended scope.
Exception rateLow suitability: exceptions are common or hidden; Medium: known exceptions can be routed; High suitability: normal cases are coherent and exceptions are easy to detect.
ReversibilityLow: action deletes, pays, grants access or commits externally; Medium: correction is possible; High: output is a draft, internal task or logged update that can be undone.
DetectionLow: customer discovers failure; Medium: periodic reconciliation finds it; High: validation, alerting and an owned queue expose failure promptly.
Data and permission riskLow suitability: sensitive data or broad privileges are central; Medium: access can be constrained; High suitability: minimum data and least-privilege access are straightforward.
Fallback readinessLow: no one knows the manual route; Medium: recovery depends on one person; High: documented manual processing, replay and ownership exist.
Decision ruleSelect a candidate only when trigger, inputs, rules, detection and fallback are strong. A high frequency score never cancels a severe consequence or unresolved control.