Business Process Automation: How to Decide What to Automate First

Most operations managers do not struggle to find things to automate. They struggle to choose. Every team has a list of tedious tasks, every software vendor has a demo, and the loudest request usually wins. The result is often a first project that is too large, too vague, or built on top of a process nobody had properly written down.

This guide gives you a practical method for deciding what to automate first: how to list candidate processes, how to score them, what to fix before you build anything, which type of automation fits, and how to check afterwards whether it worked.

Quick answer

Automate first the process that is frequent, takes real staff time, follows clear rules, uses data your systems can already reach, and is not about to change. To find it:

1. List 10 to 20 candidate processes with their volumes and owners.
2. Score each one on six criteria: frequency, time per run, cost of errors, rule clarity, data and API availability, and stability.
3. Rule out any process that scores very low on rule clarity or data availability, however painful it is today.
4. Simplify and standardize the winning process before automating it.
5. Use the simplest type of automation that does the job, and record a baseline so you can measure the result.

A good first project is small enough to finish in weeks, not quarters, and visible enough that the team notices the difference.

Step 1: List your candidate processes

Start with a list, not a tool. Ask each team lead for the recurring tasks that take the most time or cause the most rework. Then look for the patterns that usually point to automation candidates:

• Someone copies data from one system and types it into another.
• A spreadsheet sits between two systems because they do not talk to each other.
• Work starts from a shared inbox and someone has to read, sort and forward each message.
• A report is rebuilt by hand every week or month from the same sources.
• Requests wait in a queue for an approval that is almost always granted.
• People send reminders, chase missing information or check a status by hand.

For each candidate, write down one line for each of the following. This takes about fifteen minutes per process with the person who actually does the work.

• Trigger: what starts the process (an email, a form, a date, a status change).
• Steps: what happens, in order, and in which systems.
• Volume: how many times per week or month it runs.
• Time: how long one run takes, measured, not guessed.
• Exceptions: the cases that do not follow the normal path, and roughly how often they occur.
• Owner: the person who decides how the process should work.

If nobody can name the owner, note that. A process without an owner is hard to automate, because nobody can settle the questions that come up during the build.

Step 2: Score each process on six criteria

Give each process a score from 1 to 5 on the six criteria below. The first three measure how much you gain. The last three measure how feasible the work is. The descriptions are a starting point; adjust the thresholds to your own volumes.

Add the six scores for a total out of 30. Do not multiply them or weight them at first. A simple sum is easy to explain to colleagues, and the purpose of the exercise is a ranked shortlist you can discuss, not a precise number.

Two scores that act as gates

Rule clarity and data availability are different from the other four. A low score on either one means the process is not ready, whatever its total.

• Rule clarity of 1 or 2: if the team cannot describe how a decision is made, software cannot make it either. The first job is to document and agree the rules.
• Data and API availability of 1 or 2: if the inputs are on paper or locked in a system with no way in or out, the first job is getting access to the data. That might mean a new form, an upgrade, or an integration project.

Both are worthwhile pieces of work, but they are preparation, not a first automation project.

A worked example

The table below is an illustrative example for an imaginary wholesale distributor, not a client case study. The scores are invented to show how the method works.

Complaint handling is probably the biggest daily frustration in this business, and it still comes last. Each complaint is handled differently and the history lives in individual inboxes, so there is nothing consistent to automate yet. Invoice entry and the weekly report are both strong candidates. If the two are close, pick the one with the smaller scope. The report touches fewer systems and nobody is harmed if it runs a day late during testing, which makes it a safer first project. Invoice entry can follow.

Step 3: Fix the process before you automate it

Automating a poor process gives you a poor process that runs faster and is harder to change. Before any build work, walk through the winning process and ask four questions in this order.

1. Can the step be removed? Processes collect steps over the years: a second approval added after one incident, a report nobody reads, a copy sent to a team that no longer exists. Removing a step costs nothing and never needs maintenance.
2. Can it be simplified? Five approval levels may be reducible to one for low-value items. Three slightly different request forms may be one form.
3. Can it be standardized? If two offices or two people do the same job in different ways, agree on one way first. Otherwise you are paying to automate two processes.
4. What happens to exceptions? Decide which unusual cases the automation should handle and which should go to a person. Trying to cover every edge case is the most common reason first projects overrun. Automating the normal path and routing the rest to a named person is a perfectly good result.

It is common to find that part of the problem disappears at this stage. That is a success, not a wasted exercise.

Step 4: Choose the simplest type of automation that works

Once the process is clean, decide how much intelligence it actually needs. There are three broad options.

For a first project, the first or second option is almost always the right one. Processes that score well on rule clarity are, by definition, ones where you can write the steps down, and that is what a workflow is. Anthropic's engineering guide Building Effective Agents makes the same recommendation to developers: "finding the simplest solution possible, and only increasing complexity when needed". It also notes that agentic systems "often trade latency and cost for better task performance".

Also check whether the tools you already pay for can do the job. Many CRM, accounting and help desk products include their own automation features, and using them is often quicker than building something new. Custom development earns its place when the process crosses several systems, including ones with no built-in connectors, or when your rules are too specific for a generic tool.

We cover the differences in detail, including guardrails and running costs, in our guide to AI agents vs chatbots vs workflow automation.

Typical first projects by department

These are illustrative examples of processes that tend to score well, not recommendations for every business. Run your own scoring before committing to any of them.

Finance

• Capturing supplier invoices and matching them to purchase orders, with mismatches sent to a person.
• Sending payment reminders on a schedule based on invoice age.
• Collecting and checking expense claims against policy limits before approval.

Sales

• Creating CRM records from web form enquiries and assigning them by territory or product.
• Generating quotes or proposals from a template using data already in the CRM.
• Reminding salespeople about follow-ups that are overdue.

Customer support

• Tagging and routing incoming tickets to the right queue.
• Answering order status questions with a lookup in the order system.
• Requesting missing information, such as an order number, before a ticket reaches an agent.

HR

• Onboarding checklists: creating accounts, requesting equipment and scheduling introductions when a start date is confirmed.
• Routing leave requests for approval and updating the team calendar.
• Collecting documents from new starters and chasing what is missing.

Be careful with anything that decides an outcome for a person, such as screening job applicants. That is a poor first project and a regulated one, as the section on decisions about people explains.

Operations

• Low-stock alerts and draft purchase orders based on reorder levels.
• Scheduled reports assembled from several systems.
• Keeping order, stock or job status in sync between two systems that are currently updated by hand.

Measuring results honestly

Automation projects are easy to declare successful and hard to prove. A few habits keep the numbers honest.

• Record a baseline before you build. Measure volume, time per run and error rate for a few weeks. Without a baseline, any later claim is a guess.
• Measure the same things afterwards. Use the same definitions and a similar period, and allow for seasonal differences in volume.
• Count the exceptions. Track what share of runs the automation completes without help and what share falls back to a person. If most runs still need manual intervention, the saving is much smaller than it looks.
• Count the new work. Someone reviews flagged cases, fixes failed runs and updates the automation when a system changes. That time belongs in the calculation, along with license, hosting and any AI model usage costs.
• Separate time saved from money saved. Hours released are only a financial saving if they reduce overtime, avoid a hire or are spent on work that produces revenue. Otherwise report them as capacity, which is still a real benefit.
• Check quality, not only speed. Compare error rates, customer response times and complaints before and after. Faster output with more mistakes is not an improvement.

Review the figures after the first month and again after about three months. Early results often look better or worse than the settled picture, because the team is still adjusting and the unusual cases take time to appear.

When the process makes decisions about people

Most first automation projects move data and send notifications, which carries little regulatory risk. That changes when software decides something significant about an individual, such as a job application, credit terms or eligibility for a service. The points below are a high-level summary and not legal advice.

United Kingdom. The Data (Use and Access) Act 2025 changed the rules on significant decisions made by automated means. The UK government's summary says organizations must apply safeguards, including giving people information about significant decisions made about them, enabling them to make representations and challenge those decisions, and enabling them to obtain human intervention.

United States. Rules vary by state. In California, the privacy regulator has announced that businesses using automated decisionmaking technology to make significant decisions must comply with its ADMT requirements beginning January 1, 2027. Other states have their own rules.

In practice, keep a person in the decision for anything of this kind and take legal advice before you automate it.

For technical readers

If you are the CTO or IT lead reviewing a shortlisted process, these checks refine the feasibility scores:

• Integration method. Prefer documented APIs and webhooks. Scheduled file exports are workable. Automating clicks in a user interface is fragile, because it breaks when the screen layout changes.
• Triggers. Decide whether the process is event-driven or runs on a schedule, and what happens if a trigger is missed or delivered twice.
• Safe retries. Steps that write data should be safe to run again without creating duplicates, since failures and retries are normal.
• Credentials. Use a dedicated service account with only the permissions the process needs, not a staff member's login.
• Error handling. Failed runs should go to a queue that a named person reviews, with enough detail to fix and rerun them.
• Logging. Keep a record of each run and its outcome. The same logs supply the measurement data described above.
• Test environment. Confirm that each connected system has a sandbox or test account before estimating the work.

Frequently asked questions

What is business process automation?

Business process automation is the use of software to carry out recurring business tasks, such as entering data, routing requests, sending notifications or producing reports, with little or no manual effort. It ranges from simple rules inside one application to custom software that connects several systems.

Which business processes should be automated first?

Start with a process that runs often, takes meaningful staff time, follows rules that can be written down, uses data your systems can already access, and is stable. Processes that depend on case-by-case judgment or on paper inputs should wait until the rules and data are in better shape.

Should we automate our most painful process first?

Not necessarily. The most painful process is often painful because it is inconsistent, full of exceptions or poorly documented, and those are the features that make automation difficult. A smaller, well-understood process usually makes a better first project and builds the skills and confidence for the harder one.

Do we need AI to automate a business process?

Often not. If the inputs are structured and the steps are fixed, rule-based automation is cheaper, faster and more predictable. AI is useful for specific steps that involve reading or writing unstructured text, such as emails and documents.

How long does a first automation project take?

It depends on the number of systems involved, the quality of their APIs, how many exceptions must be handled and how quickly the process owner can make decisions. A first project should be scoped so that it can be delivered in weeks. If the estimate runs to many months, the scope is probably too wide for a first step.

What if our software has no API?

Check first whether the vendor offers an API on a higher plan or a newer version. If not, options include scheduled file exports and imports, direct database access where the vendor permits it, or replacing the system. Each adds cost and risk, which is why data and API availability is a gating criterion in the scoring.

Your next step

Block out half a day, list your candidate processes with the people who do the work, and score them. The shortlist that comes out is useful whether you automate with features in tools you already own, a low-code platform or custom software, and it gives any developer you speak to a much clearer starting point than "we want to automate things".

Entrant Technologies builds web applications, mobile apps and custom software, including the integrations that connect business systems. If your top-scoring process spans several systems and you would like a second opinion on scope, you can look at our development services or request a quote with your process notes attached.