Map the work before choosing a tool
Describe what starts the process, its inputs, decisions, outputs and hand-offs. Include the systems involved and the person responsible when something goes wrong. Observe actual cases instead of relying entirely on the ideal process described in a meeting.
For a quoting workflow, the routine path might be straightforward while non-standard products, missing information and price approvals require human judgement. Those exceptions belong in the design from the start.
Build a shortlist using a simple score
| Factor | Higher-priority signal |
|---|---|
| Frequency and effort | Repeated work consumes meaningful staff time |
| Rules | People can explain consistent decisions |
| Inputs | Data is available and sufficiently reliable |
| Exceptions | Exceptions are identifiable and can be routed to a person |
| Business value | Fewer errors, shorter delays or capacity for useful work |
| Delivery effort | Access and integrations are feasible within scope |
Use a consistent low/medium/high assessment or a simple numerical scale. The score is a discussion aid, not scientific proof that a project will pay back.
Estimate benefits honestly
Calculate routine handling time multiplied by frequency, then subtract the time still needed for review and exceptions. Include maintenance, monitoring, licences and implementation in the cost view. If the process changes frequently, allow for keeping the automation up to date.
Time released is not automatically a cash saving. If staffing costs stay the same, the benefit may be additional capacity, faster response or less overtime. State which outcome the business expects and how it will be checked.
Choose a small but complete first process
Good candidates can include generating a standard document from approved data, transferring an order between systems, issuing a scheduled report or notifying staff of a status change. The useful boundary includes error handling and an owner, not just the happy-path demonstration.
A higher-stakes approval may still be suitable for partial automation: gather the information and prepare a recommendation, then retain a human decision. AI is one possible component; many workflows are better served by explicit rules and integrations.
Define completion and review
Agree sample cases, success criteria and what should happen when an input is missing or a service is unavailable. Run representative examples, compare outputs with the manual process and decide how staff will detect and correct failures.
Use the automation prioritisation template to compare opportunities. If one process is promising but poorly documented, a Business Process Automation Review can establish its scope before implementation is quoted.
Common questions
Should we automate the largest process first?
Not necessarily. A smaller, stable workflow may prove value and establish reliable operating practices with less disruption.
Do we need AI?
Only if the task benefits from its capabilities and the controls are appropriate. Data transfer and predictable business rules often do not need it.
What is a reasonable payback period?
That depends on cost, risk and the value the business assigns to the outcome. Use transparent assumptions rather than a universal target.