How to choose your first business process to automate

Start with one workflow, not an entire department

“Automate finance” is an ambition. “Prepare a draft purchase request from an approved intake form, then send exceptions to the purchasing team” is a task you can describe, test, and assign to an owner.

For a first project, look for recurring work with a clear start and end, available inputs, and a person who can judge the output. A frustrating task is not automatically a good candidate: inconsistent rules, inaccessible systems, or costly errors can make a small-looking process difficult to automate.

Shortlist two or three workflows with the people who actually handle them. For each, ask:

• What triggers the task, and what counts as finished?
• How often does it happen, and how much active work does it take?
• Which systems and permissions are needed?
• What are the common exceptions, and who resolves them?
• Can an incorrect result be caught and safely corrected before it has consequences?

Prefer the candidate with a useful outcome and a manageable boundary. Do not choose it solely because it produces the most impressive demonstration.

Measure the manual process before changing it

Observe a representative sample that includes ordinary work and difficult cases. Record volume, active handling time, waiting time, corrections, and exceptions. Keep active effort separate from elapsed time: a request waiting overnight for approval does not represent eight hours of manual work.

For AI-assisted workflows, this baseline-first approach is also reflected in Microsoft’s agent evaluation guidance, which recommends comparing existing performance, representative scenarios, and operating costs.

Use the same definitions when evaluating the pilot. Our recommended comparison is:

• Human effort: preparation, review, correction, and exception handling—not just time spent typing.
• Output quality: the proportion meeting agreed requirements, with the types and consequences of errors recorded.
• Turnaround: time from an accepted input to a usable result, including waits and retries.
• Operating burden: software and infrastructure costs, support work, and maintenance.

For example, if a draft is generated quickly but every field needs checking, the net saving may be small. Treat anticipated savings as a hypothesis until measured with representative work. No customer performance result is implied by this example.

Use the simplest mechanism that fits the task

Fixed routing, known calculations, required-field checks, and exact data transfers often belong in ordinary workflow rules or system integrations. AI may help where the input varies—for example, classifying an incoming document or preparing a draft—but its output still needs an appropriate validation path.

One workflow can combine both: validate an intake form with rules, use a model to suggest a category, route uncertain cases to a person, and only then create a record through an approved interface. Keep business rules and access controls outside the model wherever they need to be reliably enforced.

Before adding an agent that can act, specify its permitted tools and the operations requiring approval. OWASP’s excessive-agency guidance recommends limiting functionality and permissions and retaining human approval for high-impact actions.

Write a one-page pilot agreement

Agree the following with the process owner before implementation. This is a suggested working checklist, not a fixed-price offer or a promise that every workflow can be automated.

1. Scope: one task, defined inputs, the participating team, and what remains manual.
2. Access: approved data and systems, with the minimum required permissions.
3. Evaluation: a representative sample, baseline measures, and agreed acceptance thresholds.
4. Exceptions: a named reviewer and a queue for missing, ambiguous, duplicate, or failed inputs.
5. Stop conditions: events that pause the pilot, such as an unauthorized change or repeated unacceptable errors.
6. Recovery: how work returns to the manual process without lost or duplicated records.

Begin in a test environment or a mode that prepares recommendations without changing operational records. Test ordinary work, failures, retries, and a handover to the human reviewer. Only add write access when its controls have been checked and approved.

Expand because the evidence supports it

Compare results with the baseline and the acceptance criteria. A reduction in manual effort should not conceal worse output quality, an unmanageable exception queue, or excessive maintenance.

There are three useful outcomes: proceed with a controlled rollout, revise the scope and test again, or keep the process manual. Stopping an unsuitable automation is a valid result when it prevents a more expensive rollout.

Before expansion, assign ownership for monitoring, access changes, software updates, and process-rule changes. The first successful run is not the end of the operating responsibility.