Which business process should you automate first?

The best business process to automate first is often sitting halfway down somebody's complaint list. It wastes a few hours every week, creates an avoidable backlog and never becomes urgent enough to receive a proper fix.

Leadership workshops tend to surface bigger ideas: an agent for sales, automated proposals, a customer service assistant. Those may be worth building later. A first phase has another job as well. It must give the team a result they can understand and trust.

What makes a good first business process to automate?

A good candidate has repeated work, visible inputs and an outcome a capable employee can check. The process does not need to be perfect. It needs to be understood well enough that the team can explain the normal route and recognise an exception.

Use this test against each candidate:

Do not add the scores too quickly. A workflow can look attractive overall while one weak answer makes it unsuitable. A clean, frequent task with no practical way to verify the output is still a difficult first project.

Start with the person who feels the delay

Process maps are useful, but the first useful conversation is usually with the person doing the work. Ask them to show the last five cases, including the awkward one. Watch where they open another system, copy a value into a spreadsheet or message somebody for an answer they already requested yesterday.

This is where the actual process appears. The written procedure may say that invoices are matched to purchase orders. The employee may explain that three suppliers combine several orders on one invoice, one warehouse confirms deliveries late and a particular category always needs finance approval. None of those details makes the process impossible to improve. They change what should be automated and where a person must remain involved.

The AI for Enterprise Impact Playbook, developed after work with more than 1,000 enterprises, also looks beyond the software. It covers strategy, people, data, connections between systems and business value.

A useful first candidate is usually bounded

“Automate finance” is too broad. “Prepare the weekly overdue-invoice list, attach the relevant account history and draft the first reminder” is bounded enough to inspect.

The narrower description gives you:

• a known set of source records
• a clear point where the work begins
• an output somebody already knows how to review
• exclusions you can name before testing
• a small number of actions to permit

OpenAI's current workflow selection guidance recommends choosing a meaningful multi-step task, then finding the smallest useful scope that preserves value while reducing dependencies and risk. That is a sound first-phase discipline regardless of platform.

When ordinary automation is the better answer

Do not use AI to solve a rule you can state precisely.

If a customer completes a validated form and every valid submission creates the same CRM record, fixed automation will be cheaper to run and easier to test. The same applies to scheduled reminders, calculations, field mappings and approval thresholds.

AI earns its place when part of the input needs interpretation. It may classify free-form enquiries, extract information from varied documents or prepare a recommendation from several sources. Even then, clear business rules around the AI can stay fixed and predictable.

The distinction is covered in more detail in our comparison of AI agents, automation and chatbots. For process selection, one rule is enough: use AI where the input varies, and keep firm business rules fixed.

There are also workflows that should wait:

• the team cannot agree on the current policy
• errors would be difficult to detect before harm occurs
• the source records are incomplete or inaccessible
• the process changes every few weeks
• there is no owner willing to review failures and maintain the system

If a workflow has to wait, record the preparation task. That may mean documenting the policy, cleaning the source records or narrowing the proposed action. “We are not ready” gives nobody a next move.

Measure the old process, including the awkward cases

Teams often decide on a project and only then ask how success will be measured. By that point the old baseline has disappeared.

For two weeks, record what the process costs now. Useful measures include staff minutes per case, waiting time, rework, missed deadlines and the share of cases requiring escalation. You may find that the visible work is not the expensive part. A five-minute data-entry task can trigger two days of waiting because the next person never knows it is ready.

Pick one primary measure for the first phase. If invoice preparation is the target, it might be elapsed time from receipt to a review-ready record. Track error and escalation rates beside it, since speed without quality is a poor result.

A demonstration usually proves that the normal case works. The first live test should include the cases staff keep in a mental drawer labelled “annoying”. Missing attachments, conflicting customer details, unusual discounts and duplicate records will tell you where the boundaries belong. One awkward case may also reveal that the baseline was measuring the wrong part of the process.

Run the first version with a small group. Keep actions reversible where possible, and show the source records to the reviewer. When the system is uncertain, it should stop with a useful explanation.

Let the first process run long enough to expose month-end pressure, staff absence and the inputs people forgot to mention during discovery. A modest improvement that survives those conditions gives the team evidence for deciding what to automate next.