What makes a process a good first candidate
Good first candidates share a handful of traits. The process is repeated often enough that the time adds up. Something clearly starts it, such as a form submission, an email or a new record. People can explain the rules they follow for the usual case. A mistake is visible and recoverable. And you can measure how it performs today.
Weaker first candidates are rare processes, processes where the rules change constantly or nobody agrees on them, and processes where a single error is costly and cannot be undone. Those can still be automated later, but they need deliberate review points and are better tackled after a simpler win.
A quick screening checklist
Score a few candidate processes against these questions. The goal is not a number. It is to see which process is easiest to understand and prove.
| Question | Why it matters | A good sign |
|---|---|---|
| How often does it happen? | Volume decides whether the time saved justifies the build. | Daily or weekly |
| What starts it? | Automation needs a clear trigger. | A form, an email, a new record |
| Can someone write down the rules for the usual case? | Written rules become the workflow's logic. | Most cases follow the same path |
| What does a mistake cost, and can it be caught? | This decides where a person must review. | Errors are visible and reversible |
| Which systems are involved? | Connecting systems is often most of the work. | Tools offer an API, integrations or reliable exports |
| Can you measure it today? | Without a baseline you cannot show improvement. | Someone can say how long it takes now |
Measure the process before you change it
Record how the process performs now, over a representative period. Useful measures for most workflows include:
- Cycle time: how long from start to finish.
- Manual touches: how many times a person handles each item.
- Exception rate: the share of items that need special handling.
- Response time: how long before the first reply or action.
- Error and rework rate: how often something has to be corrected.
- Completion rate: how many items finish without being dropped.
Be cautious of any provider who promises a specific percentage improvement before looking at your baseline. The right measures depend on the workflow, and the honest answer is to measure first.
Decide where people stay in control
Before building, decide which steps can run on their own, which need a person's approval, and which should escalate when the system is unsure. Approvals, exceptions, low-confidence results and high-impact actions are the usual places for a person to stay involved.
This works best as part of the design from the start. Our guide to human-in-the-loop AI automation covers the common review patterns.
Check your systems and data
List where the information lives, who is allowed to access it, and which tools would need to connect. Many projects can connect the systems you already use rather than replacing them. Replacement makes sense only when a current system cannot reliably support the process, data or security model.
Check which privacy obligations apply to the personal information involved, and keep sensitive data out of any step that does not need it. Messy or inconsistent data limits what any automation can do reliably, so note data quality problems early.
Start with one workflow you can observe
Choose a single workflow, agree the measures, run it with review switched on, and compare the results with your baseline. Expand only when the evidence supports it. The first project should prove a useful operating result and a safe control model. It should not try to automate the whole company at once.
Common first projects
These patterns suit many businesses. Each is described, with its review points and measures, on our AI automation page.
- Lead intake and sales follow-up
- Management reporting and alerts
- Invoice and document processing
- Customer-support knowledge assistant
- Approval and onboarding workflow
- Cross-system data synchronization
Questions to ask any provider
- What will you measure, and how will we know it improved?
- Where do people stay in control, and what happens when the system is unsure?
- What happens when something fails or a connection breaks?
- Who owns the workflow, the data and the code afterwards?
- How will sensitive data and access permissions be handled?
- What does ongoing support look like after launch?