In many companies, conversations about AI start in much the same way.

Someone on the leadership team sees competitors experimenting with automation. Employees are using ChatGPT. LinkedIn is full of stories about companies “saving dozens of hours a month”.

Eventually, someone asks:

Where could we use AI?

It is a reasonable question. The problem is that it is often asked one step too early.

Before choosing a tool, model, integration or vendor, a company should answer a less exciting but more important question:

Do we actually have a process that is ready to automate?

AI will not organise a business for you.

It can speed up work, help analyse data, prepare recommendations or move information between systems. But if nobody in the company can clearly explain how a process works today, automation often will not solve the problem.

It will simply move the chaos from one place to another, faster.

In practice, the first problem is rarely a “lack of AI”. It is usually something more basic:

• the process exists only in the heads of a few people
• everyone performs it slightly differently
• the company knows the outcome it wants, but cannot describe the steps that lead to it

That is why so many automation projects start too early.

Start with the process, not the technology

“Where could we use AI?” sounds like a good question, but it can easily send the conversation in the wrong direction. You start looking for a use case for the technology instead of solving a specific business problem.

The result is fairly predictable. A company introduces AI where it really needed:

• a better form
• a simple integration
• cleaner data
• or an ordinary business rule

A few months later, it becomes difficult to answer basic questions:

• what exactly improved?
• how much time did we save?
• did the project actually make business sense?

A better first question is:

Which process is repetitive, creates unnecessary workload or errors, or takes up time on work that people should no longer have to do manually?

It is a less fashionable question, but a much more useful one.

In practice, I would not start by choosing an AI model. I would start by mapping the process:

• what comes in?
• what should come out?
• what are the main steps?
• where do exceptions occur?
• where does a person genuinely need to make a judgement call?

Only then can you see what the company actually needs.

Sometimes the answer will be an LLM. Sometimes OCR. Sometimes an integration with a CRM or ERP. And sometimes the answer is much simpler: standardise the way the work is done first.

The best automation opportunity is not always the most obvious one.

A process does not have to be simple. It has to be repeatable

A common mistake is to assume that only simple, linear tasks can be automated.

That is not true.

A process can be complex. It can involve multiple exceptions, several systems and points where a person has to assess the situation. It can still be a good candidate for automation. The key requirement is that the process can be described.

Problems begin when:

• every employee performs the task in their own way
• the decision criteria are unclear
• the outcome depends mainly on the experience of one particular person

A well-described process does not have to be perfect. It is enough to know:

• when it starts
• when it ends
• what data is required as input
• what output should be produced
• which steps happen almost every time
• where human judgement is required

If you cannot answer those questions, the problem is not yet technological. It is operational.

And you need to understand it before you automate it.

Three signs you do not yet have a process

Not every recurring problem is automatically a process that is ready for automation. Sometimes a company simply has an area of work that people handle through experience, intuition and individual workarounds.

There are three common warning signs.

1. Everyone describes the task differently

If three people in the same department give three different explanations of how they perform the same task, the company does not yet have a shared process.

It has several individual ways of working.

That does not rule out automation, but it does mean you first need to decide:

• which way of working is the right one
• or whether you need to design a new, shared process

In many companies, the first useful description of a process only appears when someone from outside the team starts asking simple questions:

• where do you get the data from?
• what do you check?
• when do you consider the case complete?
• what do you do when there is an exception?

2. Nobody can define what “done correctly” means

This often comes up in areas such as:

• document analysis
• lead qualification
• ticket handling
• proposal preparation

At first, everyone says: “We know what good looks like.”

Then you try to define the quality criteria and discover that everyone means something slightly different.

If you cannot define what a correct result looks like, you also cannot define what the automation is supposed to optimise for or protect against.

3. Exceptions are more common than the standard case

Every process has exceptions. That is completely normal.

The problem starts when the exceptions become the norm.

If most cases require individual interpretation, automating the entire process will be risky.

It is usually better to go one level down and automate a specific part of it, such as:

• classifying a request
• collecting data
• detecting missing information
• comparing documents
• or preparing a recommendation for a person to review

Very often, that alone creates meaningful value.

Do not automate a wish. Automate a way of working

Take a simple example: finding potential customers or suppliers.

The statement:

We want to find customers on the internet automatically.

sounds reasonable, but it is far too broad.

It does not tell us:

• what kind of customers we are looking for
• which sources we use
• how we decide whether a result is relevant
• what should happen next

That is a wish, not a process.

A much better description would be:

Every day, we collect a list of companies from selected industries, check their location, size, business profile, decision-makers and fit with our offer. We then score each company against agreed criteria, save the result in the CRM and generate a suggested first message for a salesperson.

Now we are starting to describe a process.

It does not have to be perfect, but it has defined:

• inputs
• criteria
• steps
• an output

Only then does it make sense to assess it for automation.

AI works far better with a defined way of working than with a vague ambition such as:

• “we want to sell more”
• “improve customer support”
• “do something with documents”

Are you automating a task, a recommendation or a decision?

Before anything else, it helps to be clear about what the company actually wants the system to take over.

This is not a minor distinction. It changes the risk profile of the entire project.

Automating a task

The system performs a repetitive step, for example:

• extracting data from a document
• moving information between systems
• classifying a request
• detecting missing fields

This is usually the safest place to start.

Automating a recommendation

The system suggests an answer or decision, but a person still approves it.

For example, it can:

• suggest the priority of a lead
• draft a response to a customer
• recommend a complaint category
• summarise a contract

This works well when AI is meant to speed up the work while responsibility remains with a person.

Automating a decision

The system itself:

• approves
• rejects
• blocks
• escalates
• or triggers the next step in the process

This is where the risk becomes much more serious.

Automatically extracting data from an invoice is a very different project from automatically rejecting a complaint or making a decision that affects a payment, a customer or legal exposure.

The closer the automation gets to a business, financial or legal decision, the more important the following become:

• quality criteria
• auditability
• action history
• clear rules for handing a case over to a person

AI can support decisions, but the company still needs to know who is accountable for them.

You do not have to automate the entire process

Another common mistake is to assume that automation means taking over an entire process from beginning to end.

It usually does not, and often should not.

A process may be:

• too large
• too variable
• or too dependent on human judgement

for end-to-end automation to make sense.

But it may contain individual steps that are:

• repeatable
• well described
• easy to measure

Those are often where the best first results appear.

Examples include:

• collecting data from several sources
• performing an initial classification of a request
• checking a document for correctness
• detecting missing information
• comparing offers
• preparing a first draft of a response
• moving data between systems
• preparing a recommendation for a person to review

In practice, the best return often comes not from trying to automate everything, but from choosing one part of the process very well.

Small. Repeatable. Measurable.

Example: customer support

A company says:

We want to automate customer support.

That is still too broad.

Customer support may include:

• complaints
• order-status questions
• invoice requests
• changes to customer details
• technical questions
• returns
• escalations
• cases that require a manager's decision

Trying to automate all of this at once would be risky.

A better starting point is to identify what actually repeats.

In many companies, a large share of requests falls into just a few categories:

• order-status questions
• requests to resend an invoice
• changes to contact details
• missing information in a request

The first step does not need to be “AI for the whole support function”.

It could simply be:

• classifying incoming tickets
• detecting missing information
• drafting a response for an agent

That will not replace the customer support team. It removes repetitive work from a part of the process that can be clearly defined.

And that is exactly what a good first automation project should do.

A broad problem needs to be narrowed down

Many automation ideas sound sensible until you try to describe them properly.

“Grow sales.”

“Find new customers.”

“Improve customer support.”

“Do something with documents.”

These are not bad goals. They are simply too broad to be useful starting points for automation.

A process sounds different:

• classifying leads according to fit with your offer
• analysing requests for quotation and preparing a first draft response
• routing customer requests into the right categories
• extracting data from invoices and matching it against purchase orders
• preparing a weekly sales summary from CRM data

A goal tells you what the company wants to improve.

A process tells you what actually happens, step by step.

AI needs the second one.

Quick test: do you have a process or just organised chaos?

Before discussing tools, models or vendors, take one process and answer a few questions.

1. Does the process repeat in broadly the same way?
2. Do you know when it starts?
3. Do you know when it ends?
4. Do you know what input data is required?
5. Do you know what output should be produced?
6. Can you describe the main steps?
7. Do different people perform it in roughly the same way?
8. Do you know which decisions are straightforward and which require human judgement?
9. Do you know where errors occur most often?
10. Could you start by automating just one part of it?

If the answer to most of these questions is “yes”, the process is probably ready for further analysis.

If most of the answers are:

• “I don't know”
• “it depends”
• “everyone does it a bit differently”

then automation is premature.

Not because AI is the wrong technology.

Because the company does not yet know exactly what it wants to automate.

A 30-minute mini-audit

The simplest process-readiness check does not require a workshop, presentation or tool selection exercise.

Choose one process that is creating workload for the team today and answer four questions:

1. How does the process start in practice?
2. What specific output should it produce?
3. Which three steps happen almost every time?
4. Where is human input most often required?

If you cannot answer those questions within 30 minutes, the process is probably not ready for automation yet.

Describe it first.

If the answers are clear, you can move on to the next step: identify the part that is most repeatable, lowest risk and easiest to measure.

What usually comes out of this analysis?

Most processes fall into one of three scenarios.

1. The process is ready for automation

It has:

• clear inputs
• a clear output
• repeatable steps
• well-defined points where human judgement is required

You can now look for the best part of the process to automate first.

2. The process needs to be standardised first

Different people perform it differently. The decision criteria are unclear, or nobody can define exactly what a good result looks like.

In that case, the work starts with standardising the process, not introducing AI.

3. The process is too chaotic

There is no clear:

• starting point
• end point
• input
• output

The company cannot explain how the task is actually performed today.

In that case, AI is not the first step.

The first step is understanding what is really happening in the business.

That may sound less exciting than deploying a new tool quickly, but it usually saves a great deal of money and frustration later.

Process first, AI second

AI can be a very effective automation tool. It can:

• speed up work
• reduce errors
• analyse documents
• organise data
• support people in making decisions

But it cannot replace thinking about the process itself.

If a company does not know:

• how the task is performed today
• who makes the decisions
• what data is required
• what a good result looks like

then automation will be risky.

Not because AI is bad.

Because nobody has defined what it is actually supposed to do.

A good first step is to choose two or three processes that create the most workload for the team and run them through a simple checklist.

Once you know which processes are genuinely ready for automation, you can move on to the next question:

Which one should we automate first?