Which Business Process Should You Automate First?

The first process you automate should solve a problem your team can measure. A loud complaint or an impressive demo won't tell you how often the work happens, whether the records are reliable, or what a wrong result would cost. Compare a short list of real workflows before choosing a tool.

Define the work and its owner

Write each candidate as a task with a start, a finish, and a person who owns the result. “Automate customer service” is too broad. “Classify incoming support requests and suggest the right queue before an agent confirms it” gives you a boundary you can observe and test. Follow several ordinary cases and several exceptions. Ask staff where they look for information, what they correct by hand, and when they need another person's approval.

The owner must be able to explain a good outcome and decide what happens when the system is uncertain. If nobody owns the process or its source records, settle that first. Automating an unclear handoff tends to move the confusion faster.

Measure volume and pain

Count how many cases pass through the task each month. Measure active staff time, waiting time, rework, and the share of cases that take an unusual path. Use actual work samples and system records when possible. Microsoft’s process mining guidance uses activity frequency, process variants, and time spent in each activity to locate bottlenecks. Those measures are more informative than asking which task feels repetitive.

Estimate the gross time at stake by multiplying monthly volume by active minutes per case. Then ask how much of that time the proposed change can really remove. If a person must still inspect every result, include that review time. Count errors and delays separately: a two-minute task can still matter if a wrong handoff causes days of waiting.

Score data, risk, and mistakes

Give each candidate a score from 0 to 3 on five questions. Higher scores mean a better first pilot. Keep the evidence beside each score so the total doesn't hide a weak assumption.

1. Volume: Does the task happen often enough for a small improvement to matter?
2. Pain: How much staff effort, delay, or rework could the change remove?
3. Data readiness: Can the team access current, permitted, representative records and check the right answer?
4. Risk control: Can you limit permissions, keep a person at the right approval point, and reverse a bad action?
5. Cost of a wrong result: Is an error easy to spot and repair before it affects a customer, money, or access?

Set a gate before adding the scores: do not start an automated action when the data rights, process owner, or approval authority are unresolved. A high total cannot cancel an unacceptable failure mode. The NIST AI Risk Management Framework asks teams to define business context, risk tolerance, and the people affected before measuring and managing an AI system. The same discipline helps with any consequential automation.

Compare three candidate processes

Imagine a company comparing support-request sorting, invoice data entry, and automatic customer refunds. The numbers below illustrate the method; each company should replace them with observed volumes and error records.

Support sorting wins this shortlist because the work is frequent, its labels can be checked against past decisions, and an agent can catch a bad suggestion before the request moves. Invoice entry may also merit a test once the team resolves missing fields and exceptions. The refund proposal needs a new boundary: draft a recommendation for approval, or start with a simple rule for low-value cases. The score does not justify sending money without control.

Run a narrow pilot

Suppose agents classify 1,200 support requests a month, spending four active minutes on each. That is 80 hours of current effort, not 80 hours of available savings. If a suggested label saves two minutes on 70% of requests but checking it takes half a minute, the measured opportunity is 21 hours a month before build and maintenance costs. Compare actual cases with this estimate.

Test a sample that includes ambiguous and misrouted requests. Track time to the correct queue, correction rate, agent review time, and customer delays. Begin with suggestions that staff confirm. Keep the existing route available, review mistakes each week, and stop or narrow the pilot if it increases rework or sends sensitive requests to the wrong team. Microsoft’s automation guidance also treats human decision points as compatible with automating the procedural parts of a task.

Choose the first process whose result improves after review and correction time are counted. That gives you a measured win and a repeatable way to assess the next candidate.