Teams often begin with an automation wish list. A more useful approach is to study how work actually moves. The official procedure may omit informal decisions, missing information, and quiet corrections. Those details determine whether automation will save effort or create a faster stream of exceptions.
Observe the process at the point of work
Ask someone to walk through a recent task using a safe example. Record the trigger, the systems opened, the information copied, and the decisions made. Note where they leave the main system to send a message or consult a spreadsheet. These detours can reveal gaps that a simple integration or process change might address.
Avoid asking only how the process should work. Compare the documented procedure with several real cases. Include busy periods and unusual requests where possible. A process that appears consistent in a demonstration may depend on experienced staff making judgement calls that have never been written down.
Separate handling time from waiting time
A request can take two days to complete while requiring only ten minutes of active work. Automating data entry will not necessarily remove the delay if the request spends most of its time waiting for approval. Measure both handling and waiting so the proposed improvement targets the actual bottleneck.
Record the reason for each pause. Missing information, unclear ownership, and limited approval availability need different solutions. Sometimes a clearer form or a better assignment rule creates more value than AI. Process analysis should leave room for those simpler improvements rather than assume automation is always the answer.
Document decisions and exceptions
For every decision, ask what information the person uses and whether the rule can be described clearly. Some decisions are straightforward, such as checking whether a required field is present. Others depend on context, experience, or an agreement outside the system. Mark those differences explicitly.
Create an exception list alongside the normal path. Include duplicate submissions, conflicting records, unavailable approvers, and requests outside the usual categories. Estimate how often they occur and who resolves them. A workflow with many exceptions may still be a candidate, but its design must account for the review effort.
Assess input quality and system access
Reliable automation needs usable inputs. Check whether information arrives in consistent formats and whether key identifiers are available. If staff spend time interpreting unclear documents or correcting customer details, decide whether the source can be improved before building an automated downstream process.
Also verify access to the systems involved. A proposed workflow may depend on an API, an export, or a subscription feature that the business does not currently have. Establish that dependency early. A promising process on paper may need a different scope once the available interfaces and permissions are understood.
Example: analysing a purchase request
Suppose employees submit purchase requests by email. A coordinator copies details into a sheet, checks the budget owner, asks for missing information, and forwards the request. The apparent automation opportunity is copying the email, but the larger delay may come from incomplete submissions and unclear approval responsibility.
A better first change could be a structured request form with required fields and an explicit owner. After that, rules can route eligible requests and create review tasks. AI might help summarise supporting documents if that remains useful. The analysis changes the solution from automating a messy inbox to improving a defined process.
Use a practical opportunity scorecard
Compare candidates using frequency, handling effort, waiting time, rule stability, input quality, and error consequences. Keep the scoring understandable to the people making the decision. The score should support a discussion rather than conceal uncertainty behind a precise-looking number.
Include implementation and operating effort. A task that takes little time but requires several fragile integrations may be a poor first choice. A modest workflow with clear ownership and reliable data may provide a better learning opportunity. Select a process the business can monitor and maintain, not just one with a large estimated saving.
Assign ownership before implementation
Name the person accountable for the process outcome and the person responsible for technical support. Decide who can change a rule, who reviews exceptions, and how staff report a problem. Without these roles, an automation can become an orphaned system that people work around when it fails.
Agree how the pilot will be assessed. Use a baseline and review both successful cases and corrections. A process owner should be able to explain whether the automation improved the work and what remains difficult. If the evidence is weak, revise the design before connecting more tasks to it.
Process discovery checklist
- Observe representative cases rather than relying only on descriptions.
- Record triggers, handoffs, decisions, outputs, and exceptions.
- Separate active effort from time spent waiting.
- Check source quality and access to the required systems.
- Compare potential value with implementation and support effort.
- Assign ownership and define evidence for a successful pilot.
Frequently asked questions
What are the clearest signs of an automation opportunity?
Repeated copying, predictable checks, regular reminders, and recurring reports are useful signals. They are starting points for investigation, not automatic approval to build. Confirm that the task has stable rules and that the business can handle exceptions without creating more work elsewhere.
Should we automate a broken process?
Usually the process should be simplified first, or the automation should target a stable part of it. Encoding unclear responsibilities and inconsistent rules can make the problem harder to change. Improve the source of confusion before increasing the speed or volume of execution.
Who should participate in discovery?
Include the people doing the work, the process owner, and someone who understands the connected systems. Each sees different constraints. Frontline staff often know the exceptions, managers understand the intended outcome, and technical reviewers can identify integration or access limitations.
Turn observation into a bounded pilot
Finish discovery with a clear process map, an exception list, and a first scope that can be evaluated. The output should make the decision easier: automate, simplify, investigate further, or leave the task manual. Choosing not to automate can be the right result when the evidence does not support it.
