In the previous article, I argued that AI will not fix a chaotic process. Before automating anything, you first need to know whether the company actually has a process that can be described, repeated and improved.

Let's assume you have already done that work.

You now have several processes that look like reasonable candidates for automation. Each has a clear starting point and outcome, and you can identify the steps that currently consume people's time.

The next question is:

Which process should we start with?

In many companies, the answer comes quickly: the most important one. The process that hurts the most. The one that, if automated successfully, would make the biggest impression on the board, the owners or investors.

It sounds sensible.

And that is precisely what makes it dangerous.

The most important process in a company is not always the best first process to automate. It is often too complex, too visible and too costly for the organisation to learn how to automate on it.

A well-chosen first process does not need to be the biggest one. It should, however, offer a good balance of impact, cost and risk. It needs to produce a noticeable business result while giving the company room to learn a new way of working without taking on unnecessary risk.

This article is for CEOs, owners and leadership teams that already have several automation ideas but do not want to waste budget on the wrong first project.

Your first project should teach the company how to automate

We often hear a version of the same argument:

Let's start with a mission-critical process. If it works, it will be a major success. The board will see the value and release budget for further automation.

I understand the logic. A CEO wants to see business impact. A board wants a clear investment case. An owner does not want to fund an experiment that makes little difference.

The problem is that a company's first automation project is rarely just a technology project.

It is also the point at which the organisation learns several things at once: how to describe processes, prepare data, define a correct outcome, discuss errors, test a solution before production, and decide when a system can act autonomously and when a person should approve the result.

That is a lot to learn in one project.

Which is why it does not always make sense to learn those lessons on a process you cannot afford to get wrong.

If the first automation project touches a strategic area, every mistake costs more. Every delay is more visible. Every misunderstanding between the business and technology teams turns into frustration more quickly.

And pressure to demonstrate a quick win can lead to poor decisions: an overly broad scope, too much automation too soon, or too little testing.

A good first project should matter enough for the result to be meaningful, but not be so critical that the company has no room to learn.

If you can automate a smaller, repeatable process and demonstrate a concrete result, the conversation with the board becomes much easier:

We standardised this less strategic process and produced a measurable benefit. Now let's see what we can achieve in our core processes.

That is a safer path than beginning with the hardest part of the business.

The biggest problem is not always the best first project

Your most important processes usually have several characteristics that make them difficult places to start.

First, they are complex. They contain exceptions, dependencies, judgement calls, informal agreements and people who “just know” what needs to happen. While everything is handled manually, the company may not even notice this complexity. It becomes obvious only when you try to explain the process to a system.

Second, the cost of an error is high. A mistake in a small administrative task may simply require a correction. A mistake in a financial, legal, sales or operational process can have much more serious consequences.

Third, they are highly visible internally. If the first automation project targets a process the entire leadership team is watching, there is very little room to learn. Yet a first implementation almost always exposes something the company could not previously see: missing data, inconsistent rules, undocumented exceptions, or differences in how teams actually work.

None of this means that core processes should not be automated. In many cases, that is exactly where the greatest value lies.

The point is the order in which you do it.

Build your automation capability on a safer process first. Then move into more strategic areas with greater confidence.

A good first process should create value while limiting risk

I would not look for a perfect first process. Perfect candidates rarely exist.

I would look for a process that meets a few straightforward conditions.

First, it happens often enough. If something occurs once a quarter, even a well-designed automation may not produce an effect that is visible enough to win over the organisation.

Second, it is repeatable. It does not have to be simple, but it should contain elements that can be described and checked.

Third, an error should not immediately cause a major loss. Early on, it is better to choose processes where a mistake can be detected and corrected quickly.

Fourth, ideally the process allows for a hybrid rollout. In practice, a first project rarely means the system does everything by itself. More often, the system takes over part of the work while people continue to handle the difficult cases.

And fifth, you should be able to show an early result reasonably quickly. This does not mean deploying a complete production system in two weeks. It means being able to demonstrate within 30–60 days that the direction makes sense: less manual work, faster handling, fewer errors or better-prepared data.

The impact, cost and risk matrix

To avoid choosing a first process based on instinct or internal pressure, use a simple matrix.

It does not need to become a complicated financial model. At the beginning, it is enough to assess each process across six areas.

The first three criteria describe the potential. The higher the score, the better.

The last three describe cost and risk. The higher they are, the more cautious you should be about choosing that process as your first project.

The point is not to turn the matrix into a piece of board-level mathematics. It is much simpler than that: you want the automation discussion to stop being driven by whoever is most vocal about their problem.

Example: using the matrix

Suppose a company is considering three processes.

The table is not meant to replace a proper analysis. It is there to help with the initial decision.

One thing becomes immediately clear: the financial process may have the greatest business impact, but it also has a high implementation cost and a high error risk. That does not mean it should never be automated. It means it may not be the best place for the organisation to learn.

Document classification, by contrast, may not be the most strategic process in the company, but it has good volume, a relatively quick path to value and manageable risk. That often makes it a better first project.

How to interpret the result

Once you score a few processes, they usually fall into three groups.

Best first candidate

This is a process with high or moderate business impact, strong repeatability, a relatively quick path to a first result, reasonable implementation cost and manageable error risk.

Typical examples include document classification, initial analysis of requests, extracting data from repeatable documents, preparing a draft response for a person to review, or organising data before a decision is made.

These may not be the company's most strategic processes, but they are good places to learn, build trust and demonstrate value.

Good candidate, but not for the first project

This is a process with high impact but also high implementation cost or high error risk.

It may absolutely be worth automating. It is simply better to return to it once the company has more experience, test data, monitoring, better-documented exceptions and greater confidence in how it works with AI.

Poor first candidate

This is a process with low volume, a high cost of error, difficult integration and an outcome that is hard to measure.

Even if it sounds attractive, it may be a poor first automation project. The risk is too high and the likelihood of a quick, measurable success is too low.

What real examples can teach you

Document verification as a hybrid process

Manual document verification is a useful example.

A company was receiving thousands of documents that had to be checked manually. The obvious idea was: automate document verification.

After analysing the process, however, it became clear that not every document was equally suitable for automation. Some were standard and repeatable. Others were more complex, less predictable or required interpretation.

Trying to automate everything end to end would have been expensive and risky. A hybrid approach made more sense.

The flow was simple:

1. A document enters the system
2. The system classifies the document
3. A simple, standard case is verified automatically
4. A more difficult case is provisionally classified by the system
5. A person receives it for a quick review and can confirm or change the classification

The outcome was practical: manual work was reduced significantly for repeatable documents, without forcing automation onto the difficult cases.

That leads to an important lesson for a first automation project:

You do not need to automate 100% of cases for a project to make business sense.

Sometimes the best result comes from a split model: the system handles standard cases and people handle the difficult ones.

AI does not always mean an LLM

Choosing the process is one decision. Choosing the technology is another.

In one process we analysed, the documents initially looked like a good use case for language models. They varied, some of the data came from images, and the content needed to be analysed.

A closer look showed that, despite those differences, the documents had a sufficiently repeatable structure. Cheaper algorithms, rules and heuristics could deliver the required outcome more cost-effectively than a solution built primarily around an LLM.

The lesson is simple:

Do not start by asking how to use an LLM. Ask for the simplest solution that can deliver the required result.

This deserves a separate discussion: when not to use AI, and when simpler automation is better than a language model.

Not every extra percentage point of accuracy is worth the cost

In another process, automated document classification was commercially viable at around 95% accuracy.

It was possible to improve the result, but the cost of pushing accuracy higher was greater than the cost of handling the remaining errors.

That matters because the goal of automation is not always the highest technically achievable accuracy. The goal is the best business outcome.

In one process, 95% may be an excellent result if the remaining mistakes are cheap to detect and correct. In another, even 99% may be insufficient if a single mistake can have serious consequences.

This is another topic worth exploring separately when discussing AI testing, the cost of errors and acceptable accuracy thresholds.

When not to start with automation, even if it is technically possible

Not every process that can be automated should become the first automation project.

We analysed a process involving long text documents. Based on their content, the team needed to record specific events mentioned in those documents.

Technically, automation was possible. The problem was elsewhere.

The number of documents was relatively low, while the cost of a single error was very high. A mistake could create consequences greater than the potential savings from automation. Full automation therefore did not make sense as a first step.

This is a good example of a process that may look attractive from a technical point of view but performs poorly against the impact, cost and risk matrix.

Low volume, a high cost of error and difficulty measuring quality are all warning signs.

In this situation, it is better to start by assisting the person doing the work: summarising the document, highlighting potentially relevant sections, preparing a recommendation or checking completeness. Full automation of the decision can come later.

When can you start with a mission-critical process?

The rule is not “never start with an important process”.

There are cases where beginning with a mission-critical process makes sense, but only if several conditions are met.

The process should be well described. The company should know when it begins, when it ends, what data is required and what a correct outcome looks like.

It should have high volume or very clear business impact. If a process is strategically important but happens rarely, it will be difficult to demonstrate value quickly.

It should be possible to introduce automation in stages. Starting with classification, recommendations, data preparation or human assistance is usually safer than automating the final decision immediately.

People should remain at critical points in the process, at least initially. This limits risk and creates data about how the system actually performs.

The leadership team also needs to accept a pilot approach. If the expectation is full automation of a strategic process from day one, the risk of disappointment is high.

Under those conditions, a mission-critical process can be a good candidate — not simply because it is important, but because despite its importance it still meets the conditions for a safe first implementation.

Processes I would avoid as a first project

Some processes may be important, but they are rarely good first automation projects.

Be particularly careful with processes that combine several of the following characteristics:

• low volume
• high cost of a single error
• many exceptions
• no test data
• unclear criteria for a correct result
• difficult integrations across multiple systems
• a requirement for fully automated decisions
• benefits that only become visible after many months
• significant legal, financial or reputational risk

That does not mean these processes should never be automated. They may well be worth addressing later, once the organisation has completed its first implementations, understands its data better and knows how to evaluate system quality.

What to do before choosing your first process

The simplest exercise is this: choose three processes that passed the initial readiness check from the previous article. For each one, answer six questions:

1. What real business impact would automation create?
2. How often does the process occur?
3. Can we show an initial result within 30–60 days?
4. How difficult will implementation and integration be?
5. What will the technology cost to run?
6. What happens if the system gets it wrong?

Then remove any processes that combine a high cost of error, low volume and difficult integration.

From the remaining options, choose one that creates a visible result while giving the organisation enough room to learn without taking on excessive risk.

That is usually the best first candidate.

Build the capability to automate before taking on the hardest processes

Your first automation project should not be a show of strength. It should be a carefully selected project that builds trust, capability and data for the projects that follow.

If the first project is too large, too risky or too difficult, the company may conclude that automation “doesn't work for us”. The problem, however, may not be the technology. It may simply be that the wrong first process was chosen.

So do not start with the biggest problem simply because solving it would make the biggest impression.

Start with a process that offers the right balance of impact, cost and risk.

If you can automate a smaller, repeatable process and demonstrate concrete benefits, that will be a much stronger case for automating mission-critical processes than a presentation full of promises.

Once you have chosen a strong first candidate, you can move on to the next question:

Does automating this process actually pay off?

Answering that requires a simple ROI calculation: labour cost, error cost, implementation cost, maintenance cost and the ongoing cost of the technology itself.