Teams can usually produce a long list of tasks they would like to automate. The list is often dominated by whatever feels most irritating in the moment. That is useful input, but it is not yet an investment case.
Operational evidence helps identify where automation can remove material workload or delay without simply making a weak process run faster. It also changes the conversation: instead of debating whose frustration matters most, the business can look at where work actually waits, repeats and breaks.
Look for repeated operating patterns before looking for an automation tool.
Why brainstormed backlogs mislead
A workshop captures what people remember and what annoys them. It tends to over-represent visible, recent pain and under-represent quiet, distributed waste—the ten minutes a day that five people each spend checking a status, or the approval that sits for two days because nobody is notified. It also reflects the process as people believe it runs, which is often different from how it runs in the systems.
Brainstorming still has a role. It surfaces hypotheses and context that data cannot. The point is to test those hypotheses against evidence before committing build effort.
Where the evidence comes from
Most organisations already hold more evidence than they use. Useful sources include system audit logs and timestamps, ticket and case histories, shared mailbox volumes, approval records, spreadsheet trackers, error and rejection reports, and short observation sessions with the people doing the work.
Tooling can make this more systematic. Microsoft describes process mining in Power Automate as extracting event data from systems of record to visualise how processes actually run, so that organisations can find bottlenecks, determine root causes of inefficiency and identify automation opportunities. Its task mining capability works at the desktop level, recording the steps users take so that the organisation can see which activities take longest, how many variations of a process exist and which tasks could be automated. Neither replaces judgement, and both need careful handling of privacy and consent, but they illustrate the principle: the backlog should come from how work is performed, not from how it is described. For more on the difference, see what process mining can reveal that workshops cannot.
Start with volume and repetition
High-frequency work deserves attention because small improvements compound. Look for repeated data entry, status checks, routing, document creation, reminders, reconciliations and transfers between systems.
Do not assume every repetitive task should be automated. First ask whether the step should exist at all. A redundant approval or duplicated field may be better removed than automated.
Measure waiting and handoffs
Automation value often hides between tasks rather than inside them. Work waits for somebody to notice an email, copy information, assign an owner or confirm that the previous step is complete.
Queue age, handoff delay and repeated follow-up messages are useful evidence. They indicate where event-driven routing or explicit state could remove coordination work. A simple test: compare the time someone spends actively working on an item with the total time from start to finish. Where the gap is large, the opportunity is usually in routing and notification rather than in speeding up the task itself.
Study exceptions separately
A process may look easy to automate until the exception rate is understood. Record how often work deviates from the normal path and why. Some exceptions can be classified and routed automatically; others need judgment.
This is where human judgment should be protected rather than treated as inefficiency. Every automation also needs a defined route for the cases it cannot handle; see why every automation needs a failure path.
Use rework as a signal
Repeated correction can indicate weak input validation, ambiguous ownership, inconsistent reference data or an upstream process problem. Automating the correction step alone may hide the cause.
Track where records are reopened, rejected, re-keyed or manually reconciled. The best intervention may be validation at source, better integration or clearer workflow rules.
An illustrative example
Consider a hypothetical sales-order desk. The team's wish list asks for an automated order confirmation email. The evidence tells a different story: order records show that many orders are reopened after entry, and the most common reason is a missing or mismatched customer account code. Staff spend time chasing sales colleagues for the correct code, then re-keying. The confirmation email would save a little time; validating the account code at the point of entry, against the customer master, would remove most of the rework and the chasing. The evidence redirected the investment to the cause.
Translate evidence into an opportunity score
A useful automation candidate can be scored using frequency, time consumed, error exposure, delay created, stability of the rules, exception rate, system accessibility and business value. High-volume work with stable rules and reliable system interfaces generally makes a stronger candidate than rare work with ambiguous decisions.
Keep the scoring transparent and simple. A rough score that everyone understands and can challenge is more useful than a precise model nobody trusts. Score both the value of the opportunity and its readiness: a valuable process with unstable rules may need redesign before it is ready to automate. The value side can then feed a proper automation business case.
Warning signs your backlog is not evidence-led
- Candidates are ranked by who asked loudest or most recently.
- Nobody can say how many times a month the task happens.
- Exception rates are unknown until the build is under way.
- Success is defined as “automation launched” rather than a change in workload or delay.
Keep the baseline
Before implementation, record the current cycle time, manual touches, error rate or workload proxy. Without a baseline, teams often know that an automation exists but cannot demonstrate whether the operation actually improved.
Evidence also protects against automation theatre. If the process still requires the same amount of chasing and correction after launch, the workflow may have moved work rather than removed it.
Trade-offs
Gathering evidence takes time, and some processes generate little system data. Proportion matters: a few weeks of ticket data and a handful of observation sessions are often enough to rank candidates. Monitoring tools that capture desktop activity raise legitimate privacy and trust questions, so involve staff early and be clear about what is captured and why.
A practical evidence checklist
- Repeated manual actions per week or month.
- Average handling and waiting time.
- Number of handoffs.
- Rework or rejection frequency.
- Manual status-checking activity.
- Exception types and rates.
- Data already available in systems.
- Rule stability and decision complexity.
- Business impact of delay or error.
What better looks like
A strong automation portfolio is traceable to observable operating problems. The business can explain why each workflow was chosen, what burden it should remove and how improvement will be measured after launch.
Sources and further reading
- Overview of process mining in Power Automate - Power Automate (last verified 10 October 2026)
- Overview of task mining - Power Automate (last verified 10 October 2026)
Related Mellorca reading
- How to find the manual work nobody is measuring
- Before you automate, understand how the work actually moves
- How to calculate the real cost of a repetitive task