In the previous article I argued that AI won't fix a chaotic process. First you have to check whether the company actually has a process that can be described, repeated and improved.

Let's assume that part is behind you.

You have a few processes that look like good automation candidates. Each has a clear beginning, a final result, and fragments you can point to that eat up people's time today.

Which brings up the next question:

Which process do we start with?

In many companies the answer comes quickly: the most important one. The one that hurts the most. The one that, after a successful rollout, would most impress the board, the owner, or the investors.

That sounds reasonable.

And that's exactly what makes it dangerous.

The most important process in the company is not always the best first process to automate. It's often too complex, too visible and too expensive to be the place where the organization learns automation.

A well-chosen first process doesn't have to be the biggest one. It should, however, have a good ratio of impact to cost and risk. It should give the company a noticeable result while letting it learn a new way of working without unnecessary exposure.

This article is for CEOs, owners and boards who already have a few automation ideas and don't want to burn the budget on a badly chosen first project.

The first project's job is to teach the company how to automate

We often hear a version of this argument:

Let's start with the key process. If it works, it'll be a big win. The board will see the result and unlock budget for more automation.

I understand the thinking. The CEO wants to see business impact. The board wants the investment justified. The owner doesn't want to fund a project that's just an experiment of no consequence.

The problem is that the first automation is rarely just a technology project.

It's the moment the company learns many things at once: how to describe processes, prepare data, define a correct result, talk about errors, test a solution before production, and decide when the system can act on its own versus when a human should approve the outcome.

That's a lot of learning for one project.

Which is why it's not always wise to gain that experience on a process you can't afford to break.

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

And the pressure for a quick win can drive bad decisions: too broad a scope, too much automation, too little testing.

A good first project should be important enough that its result matters, but not so critical that the company can't afford to learn on it.

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

If we could clean up this less strategic process and get measurable benefits out of it, let's see what we can achieve in the core ones.

That's a safer road than starting at the hardest place in the company.

The biggest problem isn't always the best first project

The most important processes usually share a few traits that make them a hard place to start.

First, they're complex. They have exceptions, dependencies, judgment calls, informal arrangements, and people who "just know" what needs to be done. As long as everything runs manually, the company often doesn't see this. It becomes visible the moment you have to describe the process to a system.

Second, mistakes are expensive. An error in a minor administrative task usually means a correction. An error in a financial, legal, sales or operational process can have far more serious consequences.

Third, they're politically visible. If the first automation project touches a process the whole board is watching, there's little margin for learning. And a first implementation almost always surfaces something the company hadn't seen before: gaps in the data, inconsistent rules, undocumented exceptions, or teams working in different ways.

None of this means core processes shouldn't be automated. That's often exactly where the biggest value sits.

It's a question of sequence.

First build the ability to automate on a safer process. Then move into strategic areas with more confidence.

A good first process delivers a result and contains the risk

Don't go looking for a perfect process. Those rarely exist.

Look for a process that meets a few simple conditions.

First, it happens often enough. If something occurs once a quarter, even a well-built automation may not produce a result that convinces the organization.

Second, it's repeatable. It doesn't have to be simple, but it should have parts that can be described and verified.

Third, a mistake shouldn't immediately cause serious damage. Early on, it's better to choose processes where a system error can be caught and corrected quickly.

Fourth, it helps if the process allows a hybrid setup. In practice, a first project rarely means the system doing everything on its own. More often the system takes over part of the work while a human keeps the harder cases.

And fifth: the first result should show up fast. Not a full production system in two weeks, but within 30–60 days you should be able to show the direction makes sense: less manual work, faster handling, fewer errors, or better-prepared data.

The impact, cost and risk matrix

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

It doesn't have to be an elaborate financial model. To start, it's enough to score each process across six areas.

The first three criteria show the potential. The higher, the better.

The last three show cost and risk. The higher, the more carefully you should treat the process as a first project.

The point is not to turn the matrix into math for the board. It's something simpler: to stop basing the automation conversation on whoever talks loudest about their problem.

The matrix in action

Say the company is weighing three processes.

This table isn't meant to replace a proper analysis. It's meant to help with the first decision.

It makes one thing plain: the financial process may have the biggest impact, but it also has a high implementation cost and a high risk of errors. That doesn't mean it isn't worth automating. It means it may not be the best place to learn.

Document classification, on the other hand, may not be the most strategic process in the company, but it has good volume, quick results and contained risk. That's often the better first project.

How to read the result

After scoring a few processes, three groups of candidates usually emerge.

The best first candidate

A process with high or medium impact, high repeatability, quick first results, a reasonable implementation cost and contained error risk.

These are often processes built around document classification, initial triage of requests, reading data out of repetitive documents, drafting responses for a human, or cleaning up data before a decision.

They're not always the most strategic, but they're good for learning, building trust, and showing a result.

A good candidate, just not first

A process with high impact but also a high implementation cost or a high risk of errors.

It may well be worth automating. Just come back to it later: once the company has experience, test data, monitoring, better-described exceptions and more confidence in how to work with AI.

A bad first candidate

A process with low volume, expensive errors, difficult integration and a result that's hard to measure.

Even if it sounds attractive, it can be a poor choice for a first automation. The risk is too high and the chance of a quick, measurable win too small.

What the examples teach

Document verification as a hybrid process

Manual document verification is a good example.

A company was receiving thousands of documents, all checked by hand. The natural idea was: let's automate document verification.

Analysis showed, however, that not all documents were equally suited to automation. Some were standard and repetitive. Others were more complicated, less predictable, or needed interpretation.

Fully automating everything would have been expensive and risky. A hybrid setup turned out to be the better answer.

The scheme was simple:

1. A document enters the system
2. The system classifies it
3. A simple, standard case is verified automatically
4. A harder case gets a preliminary classification from the system
5. A human gets it for a quick review and can confirm or change the call

The result was practical: human work dropped sharply where documents were repetitive, and nobody tried to force automation onto the hard cases.

That's an important lesson for a first automation project:

You don't have to automate 100% of cases for the project to make business sense.

Sometimes the best outcome comes from a split: the system handles the standard cases, the hard ones go to a human.

AI doesn't always mean an LLM

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

In one of the processes we analyzed, the documents looked like a natural fit for language models. They varied, some data came from photos, and the content needed analysis.

A closer look showed that despite the differences, the documents had a structure repetitive enough that cheaper algorithms, rules and heuristics could deliver the expected result more cost-effectively than a solution built mainly on an LLM.

The takeaway is simple:

Don't start by asking how to use an LLM. Ask what the simplest solution is that will deliver the expected result.

That topic deserves its own article: when not to use AI, and when simpler automation beats language models.

Not every accuracy point is worth its price

In another process, automating document classification paid off at around 95% accuracy.

The score could have been pushed higher, but the cost of getting there was greater than the cost of handling the remaining errors.

That matters, because the goal of automation is not always maximum possible accuracy. The goal is the best business outcome.

In one process, 95% can be an excellent result if the remaining errors are cheap to catch and fix. In another, even 99% can be too little if a single mistake carries heavy consequences.

That's another topic worth its own discussion: testing AI, the cost of errors, and what accuracy level is actually acceptable.

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

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

We analyzed a process built around long text documents. Based on their content, specific events mentioned in the documents had to be recorded.

Technically, automation was possible. The problem was elsewhere.

There were relatively few documents, and the cost of a single error was very high. A mistake could lead to consequences bigger than the potential savings from automation. Full automation made no sense as a first step.

It's a good example of a process that can look attractive technologically but scores badly on the impact, cost and risk matrix.

Low volume, expensive errors and difficulty judging quality are warning signs.

In a case like this, it's better to start by supporting the human: summarizing the document, flagging relevant passages, drafting a recommendation, or checking completeness. Fully automating the decision can wait.

When can you start with a core process?

The rule isn't "never start with an important process".

There are situations where starting with a core process makes sense, but specific conditions have to hold.

The process should be well described. The company should know when it starts, when it ends, what data it needs, and what a correct result means.

It should have high volume or very clear business impact. If a process is strategic but rare, it will be hard to show results quickly.

The automation should be possible in stages. Better to start with classification, recommendations, data preparation or human support than with fully automated decisions.

A human should stay at the critical points of the process, at least at the beginning. That limits the risk and generates data about how the system behaves.

And the board has 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 core process can be a good candidate. Not because it's the most important, but because despite its importance it meets the conditions for a safe start.

Processes I wouldn't pick first

Some processes may be important but are rarely a good first automation project.

Be especially careful with ones that combine several of these traits:

• low volume
• a high cost per error
• lots of exceptions
• no test data
• unclear criteria for a correct result
• difficult integrations across many systems
• a requirement to fully automate the decision
• results that only show after many months
• serious legal, financial or reputational risk

That doesn't mean such processes should never be automated. They're often worth tackling, but usually once the organization has its first implementations behind it, understands its data better, and knows how to judge the quality of a system's work.

What to do before choosing the first process

The simplest exercise looks like this: pick three processes that passed the initial test from the previous article. For each of them, answer six questions:

1. What real business impact would automation deliver?
2. How often does the process repeat?
3. Can you show a first result within 30–60 days?
4. How hard will implementation and integration be?
5. What will the technology cost to run?
6. What happens if the system gets it wrong?

Then drop the processes that combine a high cost of errors, low volume and difficult integration.

From the rest, choose one that delivers a visible result while letting the organization learn without excessive risk.

That's usually your best first candidate.

Build the ability to automate first

The first automation shouldn't be a show of force. It should be a well-chosen project that builds trust, skills, and data for the implementations that follow.

If the first project is too big, too risky or too hard, the company may draw the wrong conclusion: that automation "doesn't work here". Meanwhile the problem may not be the technology at all. It may be a badly chosen first process.

So don't start with the biggest problem just because solving it would make the biggest impression.

Start with a process that has a good ratio of impact to cost and risk.

If a smaller, repetitive process can be automated and delivers concrete benefits, that's a far stronger argument for automating the core processes than any slide deck full of promises.

Only once you've chosen a good first candidate is it worth moving to the next question:

Does automating this process actually pay off?

And that calls for simple ROI math: the cost of the work, the cost of errors, the cost of implementation, maintenance, and running the technology.