How to choose the first business process to automate

The first project should make the work easier to see

A business can have plenty of automation ideas and still struggle to choose a starting point. Finance wants fewer incomplete claims. Support wants clearer assignments. Operations wants updates to reach the next team without another message. Each request sounds reasonable; none is specific enough to become a useful project on its own.

The first decision is about scope. Choose one recurring piece of work with an identifiable beginning, a result someone needs and a person who can judge whether that result is correct. “Improve operations” is too broad. “Prepare a complete expense submission for the first reviewer” is something a team can examine.

Follow a real example from start to finish

Take a recent request and trace what happened. Where did the information arrive? Who checked it? Which details were copied into another application? What caused the request to wait? A conversation with the people doing the work often reveals a different process from the one shown in a policy document.

Keep the example close to the discussion. The missing attachment, rejected field or unclear owner is part of the requirement. Removing those details from the design can make a workflow look tidy while leaving its main source of delay untouched.

Separate necessary checks from repeated effort

Some steps exist for a reason. An authorised person may need to approve a claim or verify a sensitive change. Other steps exist because applications are disconnected or submissions arrive in inconsistent formats. These are different problems and should be treated separately.

A form can require the right information. A rule can choose an approval route. An integration can move an approved record. None of those tasks necessarily requires AI. If the difficulty is interpreting a varied receipt or a free-text request, an assisted step may be worth testing alongside the workflow rules.

Ask what happens when the normal path breaks

An automation design should account for an incomplete submission, an unavailable application and an approval that is declined. Someone needs to know when the workflow stops, what can be retried and which record is now authoritative.

Discuss these cases before the first release. A process that saves time on ordinary requests but creates an unowned exception queue may simply move the workload to another team. Include the people who will handle those exceptions in the design review.

Choose measures the team already understands

You need a baseline that relates to the task. For expense preparation, it might be the proportion of submissions returned for missing information. For request routing, it could be time to a correct assignment. For a system handover, it may be the amount of repeated entry and the effort spent correcting failed transfers.

The purpose of measurement is to support a decision. Use representative examples, record the checking effort and look at the exceptions as well as completed tasks. Avoid promising a percentage saving before the current work has been examined.

Expand from evidence

A limited rollout gives the team a chance to learn. It can reveal whether a form needs clearer wording, a rule has missed an exception or an interface behaves differently under real working conditions. Those findings help shape the next release.

The next step may be another department, another request type or an AI-assisted preparation task. It may also be a simpler change to the current workflow. The right decision is the one that improves the process the team actually uses.

Explore business process automation services or discuss a workflow with Arukus.