Which business process should you automate first? A decision workbook
Choose one process using evidence, exception costs, and conservative capacity estimates. Download an editable workbook with a fully worked synthetic example.
Published by DWKD. This decision workbook uses an original, synthetic example. Its estimates are not client results, DWKD prices, or promised savings.
The first process to automate should have a clear outcome, usable inputs, manageable exceptions, and an owner who can judge whether the result is correct. A process that meets those conditions can be a better starting point than the task with the most impressive estimated savings.
This guide helps you choose one bounded candidate, calculate what could change, and decide what evidence you need before paying for a build. Download the editable first-automation workbook. It includes the worked example, a blank decision sheet, and an exception log. No account is required.
Start with the work, then choose the tool
List three recurring processes that frustrate the people doing them. For each, write the event that starts the work and the observable result that ends it. “Automate operations” is too broad. “Take an approved request from the intake queue and create one correctly assigned work item” is something you can inspect.
Sit with an operator and follow actual examples, including an awkward one. Record systems, handoffs, missing information, approvals, waiting, and rework. Separate time actively spent working from time sitting in a queue: removing a two-day wait does not automatically save two days of labor.
Microsoft’s automation guidance favors procedural tasks with continuing value and asks teams to consider the overhead of managing automation. That supports a practical starting question: can we describe the repeatable part without pretending every case is the same?
Use readiness gates before a savings estimate
- Define: name the trigger, correct outcome, and process owner.
- Inspect: establish whether the required data and permitted access exist.
- Bound: identify eligible cases, exceptions, and actions requiring approval.
- Estimate: compare the current process with the entire proposed process.
- Decide: run a limited pilot, improve the manual process, or defer.
Ask who will handle a missing field, disputed match, failed connection, or unexpected result. If nobody owns that queue, the proposal has moved work out of sight rather than removed it. Identify who can stop the automation and how the original process will resume.
Also ask whether the rules are stable. A team changing its approval process every week may benefit more from clarifying that process first. AI is not a prerequisite: a form validation rule, shared checklist, or existing system feature may solve enough of the problem.
Measure a baseline that includes inconvenient cases
For each candidate, collect volume, active handling time, exception frequency, rework, and current outcome quality over a period that represents its workload. Record the dates, sample size, source, and person responsible. A quiet Tuesday may not represent month-end processing.
Keep uncertain inputs as ranges. If nobody knows what proportion is eligible, examine a sample before assuming every request can be automated. Record evidence separately from an operator’s estimate. Both can inform a decision; they should not look equally certain.
Define what matters beyond speed: fewer duplicate records, shorter customer waits, or better traceability. Microsoft’s business-value guidance recommends establishing objectives and metrics, comparing costs with benefits, and revisiting the result. Choose measures you can actually collect.
A worked example: where the apparent savings go
Consider a fictional queue receiving 500 requests per week. Each currently takes six active minutes, totaling 50 hours. The proposed workflow handles only eligible requests. People still review them, resolve exceptions, and maintain the workflow. These assumptions are invented to demonstrate the calculation.
| Measure | Expected | Downside |
|---|---|---|
| Eligible requests | 60% = 300 | 40% = 200 |
| Review of every eligible request | 1 minute each = 5 hours | 2 minutes each = 6 hours 40 minutes |
| Exceptions among eligible requests | 10%; 8 additional minutes each = 4 hours | 20%; 10 additional minutes each = 6 hours 40 minutes |
| Requests remaining fully manual | 200 × 6 minutes = 20 hours | 300 × 6 minutes = 30 hours |
| Monitoring and maintenance | 3 hours | 4 hours |
| Total work after automation | 32 hours | 47 hours 20 minutes |
| Capacity freed from the 50-hour baseline | 18 hours | 2 hours 40 minutes |
Exception handling here is additional to the review of every eligible request. In your worksheet, decide whether recorded exception time already includes review; otherwise you will count the same labor twice. If the calculation produces negative capacity, keep that result. Do not round an unfavorable estimate into a benefit.
Time freed is not automatically money saved
At an illustrative loaded labor cost of $40 per hour and 48 operating weeks, the expected case releases capacity valued at $34,560 annually. That does not mean the organization’s bank balance improves by $34,560. The same people may remain on the same payroll and use the time for other work.
Suppose a separately identified budget change converts 25% of that capacity value into cash savings, such as genuinely avoided overtime. That hypothetical benefit is $8,640 annually. With $4,800 in recurring annual costs, the net annual cash benefit is $3,840. A $12,000 implementation would have a simple, undiscounted payback of 37.5 months and a first-year net cash result of −$8,160.
Using the same cash-conversion assumption, the downside case yields only $1,280 in annual cash benefit, below the $4,800 recurring cost: a $3,520 annual cash deficit. There is no positive payback under those assumptions. The workbook starts cash conversion at zero until a specific budget change supports it. Its numbers are examples, not acceptable-return thresholds.
Useful capacity, quality, and customer experience can justify investment without payroll savings. Describe those benefits separately and define how you will observe them. Do not count time saved, labor savings, and increased throughput as three independent cash benefits from the same hours.
Choose the pilot that resolves the biggest uncertainty
Compare the candidates using evidence, implementation effort, operating burden, and the consequences of being wrong. Avoid multiplying arbitrary scores into an apparently scientific winner. Prefer a candidate whose important assumptions can be tested safely and whose owner will use the result.
For the fictional queue, eligibility and exception effort dominate the difference. A useful pilot would measure those inputs on representative cases, compare source and destination records, and observe the operator’s actual review time. It would test duplicate requests and recovery before allowing unattended changes.
Write the proceed, revise, and stop conditions before seeing the results. Name the approver and review date. If the pilot exposes poor source data or a costly exception queue, fixing those issues or keeping the work manual is a valid outcome.
To inspect a concrete failure-handling example, see the DWKD workflow recovery demonstration. It uses synthetic requests and local execution; it is not evidence of production savings. When you are ready to compare a supplier’s scope with your decision sheet, use the automation proposal buyer scorecard.
For a broader starting point, read what an AI readiness assessment should examine. For a specific process, explore DWKD AI and automation consulting or Work with Kenny. Bring the bounded process, the evidence you have, and the assumption you most need to test.