The first process to automate is not necessarily the one with the most visible manual work. Look for a repeated task with a verifiable result, an owner and a manageable path for exceptions.
Compare bounded processes using observed work, authorised data access and a clear way to review mistakes. The example below is hypothetical; it does not describe a client or imply a measured volume.
Start with repetition and errors
Record how often the task occurs, which inputs vary and where errors or delays appear. A small but costly recurring exception can matter more than a large volume of straightforward cases. Ask the team doing the work to describe the corrections that the formal procedure omits.
Map the whole process
Draw the input, systems, decisions, approvals and final output. Mark who owns each exception. Check whether the necessary data can be accessed through a stable, authorised interface. If inputs are inconsistent, improving their quality may create more value than adding a model.
Compare candidates without adding arbitrary scores
A favourable answer in one area cannot cancel a blocking dependency. Discuss each row with the process owner, the system administrator and whoever will review outputs.
| Criterion | Ready to test | Resolve before testing |
|---|---|---|
| Frequency and effort | Recurring cases and observable effort | Unknown volume or unrelated tasks grouped together |
| Exceptions | A named owner and a manual path | Nobody owns unusual cases |
| Input data | An identifiable, consistent source | Missing or conflicting fields |
| Integration and access | Stable, authorised system access | Pending permissions or an unstable connection |
| Cost of error | Output can be checked and corrected | An irreversible action without approval |
| Review and upkeep | Capacity and an owner to maintain the flow | A review queue with no owner |
If several candidates clear these conditions, choose one with a small testable scope. Record why the others need preparation instead of hiding dependencies behind a total score.
Example application: order-status emails
Imagine a shared mailbox receiving requests about order status. The first pilot prepares a draft for a person to review; it does not send a reply automatically.
| Field | Check | Pilot decision |
|---|---|---|
| Input | Is there a usable order identifier? | Accept only a verifiable identifier |
| Source | Who maintains the order status? | Use authorised read-only access |
| Exception | Unknown order, multiple matches or complaint | Route to a human queue without guessing |
| Output | Can a reviewer compare the draft with its source? | Review before sending |
| Measurement | Total work, corrections and returned cases | Compare like-for-like request types |
If there is no reliable status source, fix that dependency first. If most messages are complex complaints, this subset may be a poor first automation.
Define what improvement means
Record baseline time, error rates, backlog and review effort over a representative period. In a pilot, compare equivalent cases and include corrections, failed runs, operations and maintenance. Time saved on a draft is not the same as a correctly completed task; freed time does not automatically become a reduction in spending.
Choose a manageable first scope
Begin with a reversible outcome such as a draft or a proposed classification. Keep approval for consequential changes. If a single missing permission or source blocks the flow, solve that dependency before expanding. The ten-process guide shows concrete candidates.
For a specific workflow, our automation service can help define the first test and the manual fallback.
From knowledge to a working process
Start with the process.
We can examine inputs, exceptions and dependencies to define a first test.
Review your process with us ↗
