Which business processes should you automate first?
Find a useful first automation by comparing recurring effort, clear rules, reliable inputs and the ability to handle exceptions.
Start automation with a recurring task that has clear rules, reliable inputs and someone accountable for the result. A useful first project removes enough manual work to matter while keeping exceptions visible and manageable.
Approval chasing, repeated entry and inbox handovers are good places to investigate. They are signals to examine the process, not proof that it should be automated immediately.
Map the work before selecting a tool
Ask the people doing the work to walk through a recent case. Record every system, approval, handover and delay. Include the cases that arrive incomplete or need someone to exercise judgement.
Remove steps that no longer serve a purpose. Standardise inputs where that helps, such as a shared request form in place of several email formats. Then separate the predictable path from the exceptions.
Name the person responsible for the whole process. Automation that crosses teams still needs an owner when a request is rejected or a receiving system is unavailable.
Compare value and readiness separately
Use the questions below in a working session. They are a prioritisation aid, not a proven scoring model or an automatic instruction to proceed.
| Question | Evidence to gather |
|---|---|
| How much recurring effort could change? | Case volumes and hands-on time, including correction |
| Can the routine decision be described consistently? | Written rules that staff apply the same way |
| Are the inputs sufficiently reliable? | Missing fields, conflicting records and data ownership |
| What happens when the system is wrong? | Consequences, reversibility and appropriate approval |
| Can exceptions be recognised and owned? | A visible queue, responsible role and response process |
| Is the process stable enough to improve now? | Known system, organisational or regulatory changes |
A frequent task with a high cost of error may deserve attention, but it also needs stronger controls. Keep the value of improving it separate from the risk of allowing it to run unattended.
For each candidate, keep a row containing the process owner, case volume, current hands-on effort, written rules, known input issues, exception handling and proposed next step. Use “pilot”, “fix first” or “leave for review” as decisions supported by those observations.
For example, a routine request with agreed rules and an accountable reviewer may be ready for a pilot. A complaint outcome that depends heavily on judgement may first need a clearer support workflow. These are illustrative comparisons; the consequences and controls determine readiness in each business.
Choose the simplest supportable approach
First check the workflow features already available in the CRM, ERP or other platform. A supported configuration may be sufficient. A packaged application may suit a standard process, while an integration or custom workflow may be needed where work crosses several core systems.
Include ongoing ownership in the comparison. A flow created by one employee still needs access control, documentation, monitoring and a continuity plan. Check the current licensing and capacity terms of any platform under consideration before committing to a design.
AI can help interpret documents or prepare suggestions where inputs are less structured. Define what it may read and do, what a reviewer must check and how uncertain cases leave the automated path. The first AI project guide covers that evaluation.
Pilot a complete path with exceptions
Build a version that can complete a useful task and route cases it cannot handle. Test missing information, repeated requests, an unavailable destination and a person who lacks approval authority.
Keep the normal process available under a controlled fallback arrangement while the pilot is evaluated. Agree how staff report an issue and how pending cases are reconciled when the pilot pauses.
Measure the result beyond speed
Compare completion time, hands-on effort, corrections, exception waiting time and the proportion of eligible cases using the new path. A faster routine path is not a sufficient result if more work is quietly pushed to another team.
Ask users why they still keep a side tracker. It may reveal a missing status, unreliable update or exception the design has overlooked. Resolve the underlying need before retiring that tracker.
Twin's Mitsubishi Motors Vietnam work included connected sales, service and reporting programmes. Our workflow engineering approach applies the same practical discipline: define responsibility, keep exceptions visible and introduce useful changes in controlled stages.