A 90-day automation audit guide for operations leaders

An automation roadmap that is not grounded in a structured audit of your current processes is essentially a prioritised list of assumptions. It may reflect good instincts from experienced operations leaders, but it is missing the baseline data that tells you whether those instincts are pointing at the highest-value targets, and what each target is actually worth.

A 90-day automation audit is the work that comes before the roadmap. It is the process of establishing what your workflows actually look like, what they cost, and which improvements are feasible and financially justified. Done well, it produces a ranked list of automation opportunities with credible ROI estimates that can be taken to finance for budget approval.

Here is how to structure the 90 days.

Days 1 to 20: scope and connect

The first phase is about limiting scope deliberately. Most operations functions have more processes than can be audited in 90 days, and the goal is not to map everything: it is to identify the processes most likely to contain high-value automation opportunities and to connect the data sources needed to analyse them.

Start by listing all significant operational processes with the following attributes: volume (how many transactions or instances per month), perceived pain level (from the team managing it), known cycle time (even if rough), and data system touchpoints (which systems record events in this process). Aim for a list of 15 to 25 processes.

Then apply a quick pre-screen to narrow to 5 to 8 candidates for the full audit. The strongest candidates share these characteristics: high volume, moderate to high cycle time, touchpoints in systems that have event logs you can access, and known pain that suggests structural rather than execution-only problems. Deprioritise processes that are low volume, highly judgement-intensive, or where the primary pain is external (client behaviour, supplier delays) rather than internal.

Once you have your candidate list, connect the data sources. For each process, identify the one or two systems that record the most complete event history: a CRM, a ticketing system, an ERP transaction log, a project management tool. Connect a workflow analytics tool to those event logs and confirm that you are getting timestamped state transitions at the level of granularity you need. This step often takes longer than expected because of access permissions, system complexity, or data quality issues. Budget at least a week for it.

Days 21 to 50: map and measure

With data flowing, the second phase is about building the actual workflow maps and collecting the baseline metrics that will underpin the ROI calculations.

For each candidate process, you want to understand: the full distribution of paths through the process (not just the documented happy path, but the actual variant distribution), the cycle time distribution for each path (median, 75th percentile, and 95th percentile are more useful than averages for identifying outliers), the rework rate and the most common rework triggers, the handoff duration at each transition point, and the exception rate and exception causes.

This analysis should produce a fact-based description of each process: what it actually does, how long it takes, where the time goes, and how variable the experience is. At this stage, you are not yet drawing conclusions about what to fix. You are establishing the facts.

Alongside the workflow mapping, collect the cost inputs you will need for ROI calculations. Loaded hourly cost by role type involved in each process, current automation tooling costs, and annual transaction volume by process. These will be combined with the cycle time data in the next phase.

Days 51 to 70: analyse and identify opportunities

The third phase is where the baseline data gets turned into a prioritised opportunity list. For each candidate process, calculate the annual cost using loaded hourly cost, transaction volume, and the average active labour time per transaction (not cycle time, which includes idle time). Then identify the specific improvement opportunities that the workflow data points to.

Improvement opportunities fall into roughly three categories. Elimination opportunities are steps, approvals, or checks that the data suggests are redundant: they consume time and resources but do not appear to change the outcome in any measurable way. Reduction opportunities are steps where cycle time is much longer than active processing time, suggesting that queue management or routing improvements could reduce cycle time substantially without requiring automation of the task itself. Automation opportunities are steps that are repetitive, rule-based, data-transfer-intensive, or high-volume and predictable enough to be candidates for automation without significant exception handling.

For each opportunity, estimate the annual savings using conservative assumptions. For automation candidates, estimate the labour time saved per transaction, multiply by volume and loaded cost, and subtract the annualised cost of the automation implementation and maintenance. The result is the net annual savings. Divide the implementation cost by the net annual savings to get the payback period.

Days 71 to 90: prioritise, document, and present

The final phase is preparation for the budget conversation. By this point you should have a list of 8 to 15 specific improvement opportunities across your candidate processes, each with a documented annual cost baseline, a specific improvement mechanism (what you are changing and why), a conservative savings estimate, a rough implementation cost estimate, and a payback period.

Rank the opportunities by payback period, with a secondary sort by total annual savings. The objective is to identify the 3 to 5 opportunities that represent the best combination of speed to value and total impact. These become the first phase of your automation roadmap.

The presentation to stakeholders and finance needs three things: the methodology behind the numbers (how you calculated the baseline cost and the improvement estimate), the underlying data (enough to validate that the numbers come from your actual processes, not from benchmarks), and the prioritised roadmap with implementation sequence.

What you should not expect from a 90-day audit is certainty. The baseline measurements will be reliable. The improvement estimates will be conservative but still estimates, because they are based on what automation can achieve given the process characteristics you have measured, not on a completed implementation. The payback periods have ranges, not point values. Present them as ranges with explicit assumptions, and finance will take them more seriously than a single number would suggest.

What the audit does not give you

A 90-day audit gives you a prioritised, evidence-based automation roadmap. It does not give you implementation specs, vendor selection criteria, or a change management plan. Those are the next stage.

It also does not resolve every question about which opportunities to pursue. Some of the highest-value opportunities may depend on organisational changes (removing an approval tier, consolidating two teams' responsibilities) that are outside the scope of an automation programme. Others may have dependencies on technology investments that are not yet in the budget. The audit surfaces the opportunities; it does not make the organisational decisions.

What it does is give you a defensible starting point: a clear picture of where your operations costs actually come from, which processes are costing more than they should, and which improvements are worth committing budget to. That starting point is worth considerably more than the 90 days it takes to build it.