Start with friction you can observe
A team says, “We spend too much time on reporting.” That is a signal, not yet an automation opportunity. Reporting may be slow because source data is inconsistent, because ownership is unclear, or because five stakeholders request different definitions. Automating the final spreadsheet could make the confusion arrive faster.
Watch the work. Note where information is copied, where people wait, where an approval lacks context, and where a failed case returns for rework. Count the frequency over a representative period. Ask what happens on the strange day, not just the typical one.
The useful unit of analysis is a bounded process with a trigger, an outcome, an owner, and a known exception path. “Improve operations” is too broad. “Validate approved orders and create delivery records” is something a team can map and test.
Score value and feasibility separately
A process can be expensive and still be a poor first build. High value does not cancel low readiness. Keep the two scores separate so enthusiasm does not hide weak data, unstable rules, or a missing owner.
| Factor | Question | Low score means |
|---|---|---|
| Frequency | How often does the process run? | Savings are hard to compound |
| Touch time | How much active human work occurs? | Little capacity to reclaim |
| Delay cost | What does waiting block or damage? | Speed has limited business value |
| Rule stability | Do the decisions stay consistent? | Logic will need constant repair |
| Data access | Can systems expose complete inputs? | The workflow starts with blind spots |
| Exception rate | How often does the normal path fail? | Human review may dominate |
| Ownership | Who approves and maintains the process? | No accountable launch decision |
| Consequence | What happens when the output is wrong? | Controls may cost more than the gain |
Find the smallest useful boundary
Do not begin by automating an entire customer journey. Pick a section that produces a useful result on its own. Lead intake might start with validation, deduplication, and assignment. Drafted outreach can remain outside the first release.
A smaller boundary improves testing. The team can compare before and after, inspect exceptions, and stop safely if the assumptions were wrong. It also exposes whether the real problem sits upstream. If most submissions lack required context, a better form may create more value than a complex enrichment agent.
Measure the work without inventing precision
Estimate weekly cases, active minutes per case, waiting time, rework, and direct tool costs. Use ranges when the data is uncertain. A sample of real cases is better than a confident guess from a manager who only sees escalations.
Separate capacity from cash. Saving ten hours of fragmented effort does not automatically remove ten paid hours from the business. The likely benefit may be faster response, fewer mistakes, steadier service, or room for higher-value work. State which kind of value the estimate represents.
Use the automation ROI calculator as a planning aid, then replace its assumptions with observed figures during discovery. The calculator deliberately avoids presenting the result as a quote or guaranteed saving.
Reject opportunities that fail the readiness test
Saying no is part of a useful automation audit. A manual redesign, form change, policy decision, or integration repair may be the right next step. Automation should follow clarity, not substitute for it.
- The process changes every week and no one can approve a stable version.
- The source data is inaccessible, routinely incomplete, or collected without a clear lawful basis.
- A wrong output could create material harm and there is no workable human review.
- The proposed value depends on evading a platform rule, consent requirement, or provider safeguard.
- The team wants automation to avoid deciding who owns the process.
- The work is rare enough that a checklist or template would solve the problem more cheaply.
Build a shortlist that can survive scrutiny
The shortlist should show why an idea ranks where it does. That decision record matters later, when a new tool demo makes the team want to jump to a more glamorous use case.
- Write the current trigger, outcome, owner, volume, and exceptions in plain language.
- Score value, feasibility, risk, and readiness with the people who run the work.
- Select one bounded pilot and define the manual fallback before building.
- Choose two or three measures that reflect the real objective.
- Set a decision date: expand, revise, pause, or retire the workflow.
Frequently asked questions
Which business process should be automated first?
Choose a frequent, bounded process with stable rules, accessible data, a clear owner, and manageable failure consequences. Avoid starting with the process that has the most political attention but the least clarity.
How many processes should an automation audit cover?
Inventory broadly, then examine a small shortlist in depth. The right number depends on the organization, but each shortlisted process needs enough evidence to score value, readiness, risk, and feasibility.
What if we do not have baseline time data?
Sample real cases for a short period. Record active work, waiting, rework, and exceptions. A modest observed sample is more defensible than a precise figure assembled from memory.
Is a high manual workload always a strong automation case?
No. Workload may be high because the policy, input, or system is broken. Fixing that root cause can remove more effort with less risk than automating the existing process.
If this topic maps to a real process, document the current volume, exceptions, systems, data sensitivity, owner, and consequence of error before selecting a tool.
Request an automation audit
