A list of repetitive tasks is useful, but it does not tell you which one to automate first. A crowded inbox may be frustrating yet depend on judgement, while a less visible reporting task has consistent inputs and an obvious owner. Use this decision framework to compare candidates against the same criteria and choose a pilot your team can evaluate.
Describe the candidates consistently
Write a short process card for each candidate. Record the trigger, input, steps, output, destination system and person responsible. Describe a completed task in concrete terms: an invoice is entered and ready for approval, a booking request reaches the right staff member, or a report reconciles with its source records.
Observe the task while someone does it rather than relying solely on memory. Include the checking and correction work that happens after the apparent end of the process. Note how often work is delayed because information is missing or a decision belongs to someone else. These details make comparisons more useful than a general statement that a task is repetitive.
Compare effort and business consequences
Assess recurring effort using records from your own team. Separate routine handling from exception handling, and distinguish active work from time spent waiting. A frequent task with a manageable manual step may be less valuable to automate than a task that blocks invoices, appointments or responses to genuine customer enquiries.
Also consider the consequence of an error. Copying a reference into an internal review queue has a different impact from issuing a payment or sending a sensitive reply. A process can remain a good candidate when the first version prepares work for approval instead of executing the final action. Define that boundary when comparing benefits.
Assess readiness of inputs and rules
Prefer inputs that are accessible, identifiable and reasonably consistent. Check whether records have reliable identifiers and whether staff agree on the source of truth. An automation built on conflicting spreadsheets may transfer the disagreement faster without resolving it. Improving the input process can be the most useful first intervention.
Ask staff to explain the rules for ordinary cases and for exceptions. If two people handle the same situation differently, agree the intended policy before automating it. Where judgement remains necessary, define what information the system should prepare for a reviewer. Do not score a process as ready simply because an AI demonstration can produce a plausible answer.
Use a simple comparison table
For each candidate, mark recurring effort, impact of delay, input consistency, rule clarity, connection difficulty and error consequence as low, medium or high. Add a sentence explaining each judgement. Treat those labels as a discussion aid drawn from your evidence, rather than an objective forecast of savings.
A strong first candidate combines meaningful repeated effort with clear rules, available data and a safe review path. A high-impact but poorly understood process belongs in discovery. A low-effort process that requires a complex integration may be better left manual. Compare candidates with the staff who perform them so that the decision reflects the actual workflow.
Select a pilot and define its stopping conditions
Choose a narrow part of the selected process and name its owner. Agree which inputs the pilot accepts, what it produces and which cases must return to a person. Document how staff continue working when the automation is unavailable. Keep the existing process available while the pilot is being evaluated.
Before implementation, agree what you will measure: handling effort, correct outputs, corrections, time awaiting review and missed handoffs. Use representative cases and review the results with the process owner. Continue only when the complete workflow improves. If checking takes more effort than the original task, revisit the rules, data quality or scope before extending the system.
The best first automation is a useful process with clear inputs, an accountable owner and a result you can check. Use the framework to prepare a shortlist, then test a bounded pilot. MindStack’s automations page is a starting point for discussing a specific workflow and the evidence needed to assess it.