Which Process Should We Automate First?

In the morning, someone downloads the webshop orders and manually enters them into the business system. In the afternoon, the warehouse checks the stock from another spreadsheet, and on Fridays, three people gather the numbers needed for the management report. In such a situation, the question is not simply which process to automate first, but also which task actually poses the most operational risk.

A poor initial choice can be costly, even if the technology works. If we automate a flawed, unnecessarily complex process, we will only produce errors faster and more consistently. Therefore, the first automation decision must be an operational decision, not a tool selection.

Don't choose what's most spectacular

In many companies, the first idea is a new system, artificial intelligence, or a large ERP implementation. These are justified in certain situations, but they rarely represent the first step. The best starting point is often a narrow, repetitive process that is well-defined, requires a lot of manual work, and has measurable business consequences.

For example, the daily copying of order data may not seem like a strategic problem. However, if this task occupies the time of two colleagues, causes incorrect billing, delays delivery, and stock data is not updated in time, we are no longer talking about an administrative inconvenience. This is an information chain that directly affects revenue, customer experience, and warehouse operations.

Therefore, the first process to automate is not always the one that consumes the most minutes. Often, the more important one is the one that connects multiple departments, carries many error possibilities, or relies on the knowledge of a single person.

Which process should we automate first? Four decision criteria

A good candidate is not chosen based on "we are tired of doing this." The process must be both business-critical and technically manageable. Four criteria help establish the order:

• Repetition and volume: does the same step occur many times daily or weekly?
• Error cost: what are the consequences of incorrect data, missed tasks, or late handovers?
• Process maturity: are the rules, responsibilities, and exceptions clear?
• Connection points: how many systems, departments, or external partners does the information move between?

The first two criteria show the size of the business loss. The second two indicate how predictably automation can be performed. A process can be very painful, but if no one knows exactly why and under what rules it is performed, its operation must first be clarified.

Frequent repetition alone is not enough

A colleague may copy data from email to spreadsheet fifty times a day. This seems like a good automation candidate, but first, we need to understand whether this spreadsheet is needed at all. It may have been created due to an old report requirement that no one uses anymore. It may be that the data is directly accessible from the source system, but the team does not know this.

Before automation, it is worth asking three questions at each step: what triggers it, who uses the result, and what would happen if this step were eliminated? Surprisingly much administration turns out to have persisted out of habit.

Errors often matter more than time savings

The cost of manual data entry is not just the few minutes the employee spends on it. A misspelled shipping address can mean resending. Late updating of stock data can cause overselling. An incorrect item number can lead to poor purchasing decisions, production delays, or dissatisfied customers.

It is worth examining where corrections, complaints, urgent phone calls, and "let's quickly check this" tasks repeatedly appear. These are not isolated human errors. They often indicate that the process relies too much on manual handovers or lacks a clear, reliable data source.

Human mediation can be a system error

In many growing companies, there are indispensable colleagues who keep track of where each order should go, what conditions each customer has, or when to deviate from the usual procedure. This is valuable experience, but it becomes risky if the operation relies solely on this knowledge.

The goal is not for automation to replace these people. The goal is for the system to handle regular, repetitive cases, while colleagues deal with exceptions, customers, and real decisions. If order processing or billing slows down during an employee's vacation, there is not just a capacity shortage, but an undocumented process dependency.

First, map out the actual operation

Process descriptions often show how the company should operate. However, for automation decisions, we need to see what actually happens. Where does the data come from? Who checks it? Where does it get transferred to email, Excel, or phone conversation? Who waits for whom? What exceptions are there, and who decides on them?

Let's take a simple webshop example. The order arrives, the stock is checked, the order is handed over to the warehouse, the invoice is prepared, and then the courier label. If data needs to be entered into five different systems for these, the possibility of automation is real. But the first step may not be to replace the entire chain. It may already bring significant improvement if order data and stock information reliably transfer between two critical systems.

The advantage of a smaller, well-defined development is that it can be validated faster. It becomes visible whether the lead time has decreased, if there are fewer corrections, and if the team is indeed relieved. This experience can later form the basis for larger integration, process redesign, or system modernization.

When should we not automate yet?

There are some situations where the correct next step is not automation. If the rules change weekly, responsibilities are unclear, or customer cases are so different that each requires individual consideration, the operational model must first be put in order.

The same is true if the input data is unreliable. An integration does not automatically correct incomplete product data, duplicate customer records, or inconsistent item number usage. In fact, the rapid transmission of poor-quality data can cause problems to appear in multiple systems.

Nor is the project that promises the greatest savings always the best first project. A full enterprise system replacement program can bring too many simultaneous changes: new processes, new roles, data transition, training, and operational risk all appear at once. In a growing organization, it is often safer to first stabilize a critical information transfer, then determine the next development step based on these lessons.

Measure the starting state, otherwise we won't know if anything has improved

Before an automation project, a complex analysis system is not necessary, but some basic data is needed. How much time elapses between order and processing? How many manual corrections occur in a week? How long does it take to prepare the monthly report? How many cases require data clarification by phone or email?

These numbers not only provide the business justification. They also help ensure that after the project, we do not evaluate the result based on impressions. It may happen that processing becomes faster, but more exceptions arise. It may also be that there is less manual work, but the information passed to the warehouse is not accurate enough. Good automation does not merely remove steps but makes the entire process more reliable.

The first success should provide an operational model

A well-chosen first automation is more than a completed technical solution. It teaches the organization how to uncover processes, clarify rules, manage data quality, and measure results. This is especially valuable where the business has grown faster than the internal operations could keep up.

So the question is not which task can be mechanized the fastest. We should look for the process where frequent repetition, errors, delays, and individual dependencies are present simultaneously, while the rules can already be clarified. There, a smaller, disciplined change can not only save hours but also create a more predictable foundation for the next growth phase.