How to Choose Business Processes to Automate

The first automation project should have a clear boundary and a measurable outcome. A large department problem is usually too broad to test. Break it into tasks, then choose one where the team can explain the input, the correct result, and what happens to exceptions.

Start with a task, not a department

“Automate procurement” contains intake, sourcing, comparison, approval, ordering, receipts, and invoices. Each has different inputs and consequences. A testable starting point might be preparing a complete request record from an internal form, or preparing a daily queue of outstanding supplier questions.

Microsoft’s Well-Architected guidance recommends prioritizing procedural tasks with a useful lifespan and notes that a process can benefit from automation while keeping human decision points. That is a useful starting principle, not a substitute for examining your own workload. Microsoft’s automation recommendations.

Observe the work before estimating the opportunity

Collect a representative sample across normal and busy periods. Record case count, active handling time, waiting time, rework, and exceptions. Ask the people doing the task to show the last difficult case, not only the clean example they use for training.

Separate effort from delay. A request may take three days to complete while requiring ten minutes of staff work. The delay might come from a supplier or an absent approver. A faster extraction step will not automatically remove that waiting time.

Use an evidence-based screening table

Questions for each candidate task
Factor	Evidence to gather	Reason to pause
Frequency and effort	Observed case count and handling minutes	Rare work with little recurring effort
Stable rule	A policy owner can state the correct result	Every case relies on an undocumented judgment
Input quality	Samples cover formats and missing fields	Critical inputs cannot be accessed or validated
Integration path	Required read and write actions are testable	Account access or supported operations are unknown
Consequences	Incorrect actions can be detected and contained	An error can commit spending before review
Exception ownership	A named person can resolve unresolved cases	The proposed queue has no owner

Use a simple ordinal score only to structure discussion. It is not a statistical prediction of success. A task with a high score can still be unsuitable if one necessary condition, such as authorized access, is absent. Keep disqualifying conditions separate from weighted preferences.

Choose recurring work with a defined outcome, observable errors and an exception owner.

Evidence	Meaning
Recurring	Enough cases to matter
Defined	Inputs and outcome are clear
Reviewable	Errors can be detected
Owned	Someone handles exceptions

Compare three concrete candidates

In an illustrative operations team, three candidates are a weekly status report, incoming request classification, and payment authorization. The report has known source records and stable formatting. Classification has variable language but can produce suggestions for review. Payment authorization has significant consequences and depends on authority checks.

The team might pilot the report first if producing it consumes meaningful repeated effort. It might pilot classification if routing delays are the larger problem and a reviewer can validate suggestions. It should not treat the payment step as the default first project simply because it has the largest monetary figure attached.

Document the reason for the choice and the evidence that could change it. For example, the reporting task may prove less valuable if the source data requires manual correction every week. That discovery is useful, because it identifies the prerequisite rather than disguising it as implementation trouble.

Remove avoidable work before automating it

Ask whether a duplicate report can be retired, a required field can move into the intake form, or an unnecessary approval can be removed by the policy owner. An automation that reproduces an obsolete step can make it faster while keeping the wrong process in place.

Do not remove controls merely to improve the proposed savings. Preserve the decision owner’s requirements and show where those requirements add review effort. Process simplification and authorization are separate discussions.

Write the pilot boundary in operational language

A useful scope reads: “Prepare a reviewable internal routing record for incoming project enquiries from this mailbox, excluding complaints and payment-related messages.” It identifies the trigger, output, included cases, and excluded cases. Add the reviewer, exception path, and success measure.

Use the workflow readiness tool to record the evidence and gaps. Then model time, review, support, and setup assumptions in the ROI tool. Choose a project only after the process owner can explain how the pilot will distinguish a useful result from a polished demonstration.

How to choose business processes to automate first