Which business process to automate first: the complete selection method

01Which business process should you consider first?

To decide which business process to automate first, start with a process that matters to an operating goal and can be tested within a clear boundary. The most annoying task, the biggest department, and the most impressive demonstration are not automatically the best starting points.

A useful candidate has a beginning, an end, and a person who cares whether the end was reached. “Automate finance” is not a candidate. “Check whether an incoming supplier invoice contains the information the accounts-payable team requires before review” is. The second description lets people examine inputs, exceptions, ownership, and a specific outcome without committing to automated payment.

List several candidates before choosing one. Otherwise, a team can spend weeks evaluating the first idea someone presented without discovering that a smaller neighboring process would remove the same obstacle. Include a non-automation alternative for each: simplify the form, remove a duplicate approval, change a handoff, or use an existing feature.

For each candidate, complete this sentence: “When this event occurs, this person needs this outcome, but this recurring obstacle gets in the way.” Keep the proposed technology out of the sentence. Choosing a process comes before choosing an agent, model, or software platform.

Digital NSW’s discovery guidance recommends involving process owners, users, technology specialists, and relevant policy or legal teams when identifying opportunities. It considers stability, exceptions, readable inputs, and business context. Those are useful prompts, not proof that any particular candidate will pay off.

The method below is ProblemSolver’s practical synthesis for an initial selection workshop. Its scores are discussion aids, not an externally validated model, financial forecast, or permission to deploy.

02What should disqualify a process before you score it?

Pause a candidate when essential ownership, authorization, evidence, or recovery arrangements are missing. A large potential benefit cannot compensate for a failed safety or permission gate.

Use these five gates before ranking anything:

1. An accountable owner exists. Someone can define an acceptable outcome, resolve disagreements, and accept the operating responsibility. A supportive sponsor is helpful, but a sponsor who cannot decide how exceptions are handled is not enough.
2. The proposed access and actions are allowed. The team knows which records, systems, and recipients are involved and which permissions or reviews are required. Being able to open a file manually does not establish permission to send it to a new service.
3. The scope can be tested safely. There is a permitted way to inspect representative cases and evaluate outputs without accidentally issuing payments, changing rights, or contacting customers. Unknown permission is a reason to investigate, not a green light.
4. Failure can be contained. Someone can stop the automation, identify affected cases, and move work to a documented manual path. If a mistake cannot realistically be recovered, narrow the proposed action or choose another starting point.
5. The process is worth retaining. The owner can explain why the step exists. If the work is duplicated or no longer needed, removing it may be better than automating it.

Mark each gate pass or hold with a reason. All five gates must pass before ranking a candidate. “Hold” should include the missing evidence, its owner, and a next review date. It does not mean the opportunity has no value; it means the proposed version is not ready for selection.

For example, drafting a suggested category for a service request and directly closing that request are different candidates. They have different consequences and recovery needs. Do not let the safer description quietly authorize the riskier action later.

For AI-enabled steps, NIST’s AI Risk Management Framework Map guidance emphasizes intended purpose, affected people, deployment context, and potential negative impacts. Here that informs the gates, rather than adding a small “risk” deduction to an otherwise attractive score. This article is not a substitute for organization-specific legal, security, or compliance review.

03How do you define a small pilot without missing the real problem?

Map the complete user outcome, then choose one bounded improvement inside it. A narrow pilot should shorten or improve that journey, not merely move the bottleneck to another team.

Draw the process from the requester's trigger to the result they actually need. Add handoffs, waiting periods, rework, and the person responsible at each stage. Then mark exactly which steps the pilot would change and which would remain manual.

Consider equipment requests. Faster form processing has limited value if requests still sit unassigned afterward. A better bounded pilot might check completeness and route valid requests to an existing staffed queue, while keeping approval and procurement manual. Its outcome is not “the automation ran.” Its outcome is “the right team received a usable request without extra chasing.”

GOV.UK’s service standard on solving a whole problem makes an important distinction: understand the broader journey without trying to fix everything at once. That principle helps prevent both an oversized transformation project and a tiny automation that improves a dashboard but not the work.

Record upstream assumptions and downstream capacity. If another team must first rewrite its policy, migrate a database, or clear a backlog, that dependency belongs in the selection decision. A proposed pilot that depends on an uncommitted project is not as ready as one that can be tested with current, authorized resources.

Choose technology only after this boundary is clear. Our AI vs RPA vs AI agent comparison addresses that separate decision. A fixed rule may be sufficient for a candidate even when the wider program is called an AI initiative.

04How can five questions produce a useful selection matrix?

Score only candidates that pass the gates, using the same evidence standards for each. Keep business importance, practical readiness, and uncertainty visible instead of hiding them inside an elaborate weighted formula.

Use the following original five-question matrix. Each row receives zero, one, or two points, for a maximum of ten. Equal weighting is deliberately simple: change it only before scoring candidates, explain why, and apply the change consistently. There is no universal passing score.

Attach evidence to every score. A score of two for recurring friction might reference a dated queue export and a short observation log. A one might reference several reviewed cases but acknowledge that a seasonal peak was not covered. Do not turn “someone believes this happens often” into two points because the team likes the idea.

Add a separate confidence label: documented, partly observed, or assumed. Do not multiply confidence into the total; that can obscure which evidence is missing. A candidate with eight points based largely on assumptions is not interchangeable with an eight supported by reviewed records.

Keep the table as a snapshot of what is known now. It ranks readiness to test a worthwhile improvement, not the ultimate strategic importance of the entire business process. A critical process can be a poor first pilot precisely because its consequences and dependencies require more preparation.

Microsoft’s guidance on prioritizing critical flows connects prioritization with business impact and observed measures such as response times, errors, and throughput. Its subject is workload performance, not this scoring method. The relevant lesson is to use operating evidence rather than let technical visibility determine priority.

05What evidence should you collect before assigning points?

Collect enough representative cases to explain the normal path and important exceptions. A small, clearly described sample is useful for learning, but it should not be presented as a reliable estimate of organization-wide savings.

Start with a recent time window that reflects the work you want to improve. Record its dates, volume, and known exclusions. Include completed cases, delayed cases, cases that required correction, and cases handled outside the official system. If month-end or seasonal work matters, examine it separately instead of assuming an ordinary week represents it.

Measure human handling time separately from elapsed time. A request may require a few minutes of effort but wait several days for a decision. Automating data entry does not necessarily remove that waiting period. Identify where the delay actually occurs before attaching a benefit to a candidate.

Write down the denominator for every measure. “Incomplete requests divided by all requests reviewed during the sample period” is interpretable. “Error rate” without a definition is not. Count exceptions that would still require human work and include time spent checking automated outputs in any later evaluation.

Check access using the intended route. A developer’s privileged account does not prove that a production integration will have suitable permissions. A manually exported spreadsheet does not prove that an authorized, maintained feed exists. The legacy integration guide explains why a controlled connection can be a separate design problem.

Finally, interview the people doing the work. Ask what happens on a bad day, which unofficial workaround keeps the process moving, and who notices a missing case. Treat their explanations as hypotheses to investigate alongside records, not as either unquestionable facts or noise to discard.

06How would the matrix work in a realistic example?

Apply the gates first, then rank the remaining candidates and test the assumptions that could change the winner. The following example is hypothetical; the organization, scores, observations, and decisions are illustrative, not a customer case or measured result.

Imagine an operations team choosing between equipment-request intake, weekly status assembly, and automatic supplier-bank-detail changes. Its current priority is reducing request rework without increasing operational risk. The team has reviewed example records and spoken with the relevant owners, but has not run an automation pilot.

The bank-detail proposal fails the gate review: the proposed automatic change lacks an approved verification and recovery design. It is placed on hold for the finance and security owners. Its apparent volume does not earn it a position in the ranking. A separately scoped verification-support workflow could be considered later, without automatically changing payment details.

The other two proposals pass the gates for limited, reviewable tests. The equipment pilot would check required fields and propose routing. The weekly-status pilot would assemble a draft from approved sources for its owner to review. Neither would make an external commitment or bypass an existing approval.

Equipment intake receives one point for readiness because the required fields are documented but one exception category still needs an agreed owner. That gap is bounded and does not prevent the proposed review-only test; it would prevent unattended routing of those exceptional cases. Weekly status receives one for measurement because the team has not yet recorded how much checking and correction a generated draft would require.

The equipment candidate wins provisionally because it fits the stated priority and offers a clear outcome to observe. The team does not claim that nine points means a specific return or a higher probability of success. Before building, it confirms the exception owner and checks whether the existing request form can remove the missing-field problem more simply.

That last check could reverse the decision. If a small form change resolves the friction, equipment automation is no longer the best use of effort. The team should update the record and reconsider status assembly rather than defend the original winner to protect the workshop result.

07How should you break ties and handle uncertain scores?

When totals are close, prefer the candidate with stronger evidence and a smaller meaningful test. Do not manufacture precision by adding decimal scores or a complicated weighting scheme after seeing the result.

Use this order for tied candidates:

1. Prefer the one whose proposed benefit directly serves the agreed operating priority.
2. Prefer the one supported by representative observations rather than optimistic assumptions.
3. Prefer the one that can test a complete, useful outcome with fewer unresolved dependencies.
4. Prefer the one with a clearer manual fallback and lower ongoing review burden, while still meeting all gates.

Then run a simple sensitivity check. Change any disputed score by one point in the plausible direction. If that changes the winner, document the uncertainty and collect the evidence that would resolve it. The next action may be a short observation exercise rather than an implementation contract.

A tie is also an opportunity to ask whether the candidates share a prerequisite. If both need a reliable request identifier, establishing that identifier might be the sensible first piece of work. Record it as an enabling task with its own acceptance criteria, not as proof that either automation is ready.

Avoid choosing the easiest task merely to announce a success. A low-risk pilot is useful only if it tests something that matters: a real handoff, a measurable outcome, an operating responsibility, or a dependency you need to understand before proceeding.

08What should the selected pilot’s decision record contain?

Finish with a decision that another person can inspect and operate, not just a ranked spreadsheet. The record should explain what will change, what will stay manual, and which evidence would cause the team to stop or reconsider.

Keep these fields together:

• Outcome and boundary: trigger, eligible cases, expected result, excluded cases, and unchanged decisions.
• Accountability: process owner, technical owner, reviewer, and manual fallback owner.
• Evidence: source dates, sample limits, baseline definitions, scored assumptions, and unresolved questions.
• Access and controls: approved systems and data, allowed actions, review checkpoints, and recovery path.
• Evaluation: outcome measure, correction burden, exception handling, and conditions for stopping or expanding.

Set acceptance thresholds with the owner before the test. There is no responsible universal accuracy target for every business process. A wrongly drafted internal summary and an incorrect customer-facing commitment carry different consequences. Where an error is consequential, a good average result does not excuse the failure.

Include operating effort in the decision. Someone must maintain rules, review exceptions, investigate failures, and respond when source systems change. A candidate that saves one team effort while creating an unstaffed queue elsewhere has not demonstrated an improvement.

Do not expand scope automatically after a promising demonstration. Reconcile the observed results with the original objective, inspect failures, and confirm that the next level of access and action is approved. Our first-90-days guide places this selection decision in a broader progression from discovery to controlled operation.

09What is the next practical step?

Bring a shortlist of real processes, representative examples, and the people who own the outcomes to one selection discussion. Leave with one candidate to test, one missing assumption to verify, and a written reason for setting the others aside.

If the shortlist is still vague, do not buy a platform to force a decision. First identify the operating problem and whether a simpler change can solve it. If every candidate fails a gate, improving ownership, access, or measurement is progress, even when no automation is launched immediately.

For help turning the shortlist into a bounded pilot, Book a 30-minute call for an AI Opportunity Audit with ProblemSolver. Bring the current process, the friction you can show, and the outcome you want to improve. The useful starting question is not how much work an agent can take over. It is which specific improvement you can justify, test, and support.

10Frequently asked questions

Sources and further reading

1. Stage 1: discover. Digital NSW, Accessed 2026.
2. Solve a whole problem for users. GOV.UK Service Manual, Accessed 2026.
3. AI RMF Playbook: Map. NIST, Accessed 2026.
4. Recommendations for prioritizing the performance of critical flows. Microsoft Learn, Accessed 2026.