In many companies, the AI conversation starts the same way.

Someone on the board notices that competitors are experimenting with automation. Employees are already using ChatGPT. LinkedIn keeps serving up stories about companies "saving dozens of hours a month".

Sooner or later, the question lands on the table:

Where could we use AI?

It's a reasonable question. The problem is that it usually arrives one step too early.

Before a company starts choosing a tool, a model, an integration or a vendor, it should answer a less glamorous but more important question:

Do we actually have a process that's fit for automation?

Because AI won't tidy up your company for you.

It can speed up work, help analyze data, draft a recommendation or move information between systems. But if nobody in the company can clearly explain how a process works today, automation very often doesn't solve the problem. It just moves the chaos around faster.

In practice, the first problem is rarely "we don't have AI". It usually looks like this:

• the process exists only in a few people's heads
• everyone runs it slightly differently
• the company knows the expected outcome, but can't describe the path that leads to it

That's exactly why so many implementations start too early.

Start with the process, not the technology

"Where could we use AI?" sounds like the right question, but it easily leads you astray. You end up hunting for a use case for the technology instead of solving a specific business problem.

The result is predictable. The company deploys AI where all it really needed was:

• a better form
• a simple integration
• cleaner data
• or a plain business rule

A few months later, nobody can answer:

• what exactly improved
• how much time was saved
• whether the project made sense at all

The question that should come first is a different one:

Which process in the company is repetitive, wears people down, produces errors, or eats up time on work nobody should still be doing by hand?

Less fashionable, far more useful.

In practice, the place to start is not choosing an AI model. It's mapping the process:

• what comes in
• what should come out
• what the main steps are
• where the exceptions show up
• where a human genuinely has to make a call

Only then can you see what the company actually needs.

Sometimes it will be an LLM. Sometimes OCR. Sometimes an integration with the CRM or ERP. And sometimes the answer turns out to be much simpler: first, get everyone working the same way.

The best automation often isn't in the most obvious process.

The process doesn't have to be simple. It has to be repeatable

A common mistake is assuming that only simple, linear tasks are fit for automation. That's just not true.

A process can be complex. It can have plenty of exceptions, span several systems, and include moments where a human has to weigh the situation. It can still be a good candidate. The one condition: you have to be able to describe it.

The trouble starts when:

• every employee does the task their own way
• the decision criteria are fuzzy
• the outcome depends mostly on one person's experience

A well-described process doesn't have to be perfect. It's enough to know:

• when it starts
• when it ends
• what data it needs as input
• what result it should produce
• which steps repeat almost every time
• where a human decision is required

If you don't know these things, you don't have a technology problem. You have an operations problem, and you need to see it first.

Three signs the company doesn't have a process yet

Not every recurring problem is a process ready for automation. Sometimes a company just has an area of work that people handle on experience, intuition and personal workarounds.

There are three warning signs.

1. Everyone describes the task differently

If three people from the same team explain the same task in three different ways, the company doesn't have a shared process yet. It has several private ways of working.

That doesn't rule out automation, but it means you first need to decide:

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

In many companies, the first sensible process description only appears when someone from outside starts asking simple questions:

• where do you get the data from?
• what do you check?
• when do you consider the case closed?
• what do you do with an exception?

2. Nobody can say what "done well" means

This comes up all the time with:

• document analysis
• lead qualification
• ticket handling
• preparing quotes

At first everyone says "come on, it's obvious". Then, the moment you try to write down the quality criteria, it turns out everyone understands them a little differently. And if you can't say what a correct result looks like, you can't say what the automation is supposed to get right.

3. Exceptions outnumber the standard case

Every process has exceptions, and that's perfectly normal. The problem starts when exceptions become the norm. If most cases need individual judgment, automating the whole process is going to be risky.

At that point, it's better to go one level down and automate a fragment:

• classifying the incoming request
• gathering the data
• spotting what's missing
• comparing documents
• or preparing a recommendation for a human

And very often that alone delivers a real result.

Don't automate a wish. Automate a way of working

Take a simple example: finding new customers or suppliers.

The sentence:

We want to automatically find customers online.

sounds good, but it's far too vague.

It doesn't say:

• what kind of customers you're looking for
• which sources you'll use
• what criteria decide whether a result is good
• what's supposed to happen next

That's a wish, not a process.

A much better description looks like this:

Every day we pull a list of companies from specific industries, check their location, size, business profile, decision makers and fit with our offer. Then we score each company against agreed criteria, save the result in the CRM, and draft a first outreach message for the sales rep.

Now that's the beginning of a process. It doesn't have to be perfect, but it has defined:

• inputs
• criteria
• steps
• an output

Only a description like that can be seriously analyzed for automation.

AI works far better on a described way of working than on a vague ambition like:

• "we want to sell more"
• "let's improve support"
• "let's do something about the documents"

Task, recommendation, or decision?

Early on, it's worth being clear about what exactly the company wants to hand over to a system. This is not a detail, because the risk of the entire project depends on it.

Automating a task

The system performs a repetitive step:

• extracts data from a document
• moves information between systems
• classifies a request
• detects missing fields

This is usually the safest place to start.

Automating a recommendation

The system suggests a decision, but a human still signs off on it.

It can:

• rank a lead
• draft a reply to a customer
• propose a category for a complaint
• summarize a contract

This is the right model where AI is meant to speed up work while accountability stays with a person.

Automating a decision

The system, on its own:

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

And this is where things get serious. Automatically extracting data from an invoice is a completely different project from automatically rejecting a complaint, or making a call that affects a payment, a customer or legal exposure.

The closer you get to a business, financial or legal decision, the more these things matter:

• quality criteria
• auditability
• a full history of actions
• clear rules for handing a case over to a human

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

You don't have to automate the whole process

The second common mistake is thinking that automation means taking over the entire process end to end. It usually doesn't, and it usually shouldn't.

A process can be too big, too changeable, or too dependent on people to automate in full. But it can still contain fragments that are repetitive, well described and easy to measure. And that's where the best first result usually comes from.

Fragments like:

• pulling data together from several sources
• an initial classification of a request
• checking a document for correctness
• detecting missing information
• comparing offers
• drafting a first version of a reply
• moving data between systems
• preparing a recommendation for a human

In practice, the bigger return often comes not from trying to automate everything, but from picking one specific fragment of a process well.

Small. Repeatable. Measurable.

Example: customer support

The company says:

We want to automate customer support.

Still too broad.

Customer support can cover:

• complaints
• order status questions
• invoice requests
• data changes
• technical questions
• returns
• escalations
• cases that need a manager's decision

Trying to automate all of it at once is going to be risky. Better to start by checking what actually repeats.

In many companies, it turns out that a large share of tickets boils down to a few topics:

• order status
• resending an invoice
• updating contact details
• missing information in the request

Then the first step doesn't have to be "AI for all of support". It can be:

• classifying tickets
• detecting missing data
• drafting replies for the agent

That doesn't replace the support team, but it removes repetitive work from a fragment of the process you can clearly describe. And that's exactly what a good first implementation is about.

A problem that's too broad has to be narrowed down

Plenty of automation ideas sound great until you try to write them down. "Let's grow sales." "Let's find new customers." "Let's improve customer support." "Let's do something about the documents."

These aren't bad goals. They're just too broad to be a starting point for automation.

A process sounds different:

• classifying leads by fit with the offer
• analyzing RFQs and drafting a first response
• routing customer tickets to the right categories
• reading data from invoices and matching it against orders
• preparing a weekly sales summary from CRM data

A goal says what the company wants to improve. A process says what happens, step by step. AI needs the second one.

A quick test: process or chaos?

Before the company starts talking tools, models and vendors, take one process and answer a few questions.

1. Does this process repeat in a similar way each time?
2. Do you know when it starts?
3. Do you know when it ends?
4. Do you know what data it needs as input?
5. Do you know what result it should produce?
6. Can you describe the main steps?
7. Do different people run it in a similar way?
8. Do you know which decisions are simple and which need a human?
9. Do you know where the errors usually happen?
10. Could you start by automating just one fragment?

If the answer to most of these is "yes", the process is probably worth analyzing further.

If most answers sound like:

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

then automation is premature. Not because AI isn't up to it, but because the company doesn't yet know what exactly is supposed to be automated.

A 30-minute mini-audit

The simplest readiness test needs no workshops, no slide decks and no tool selection.

Pick one process that weighs on the team today and answer four questions:

1. How does this process start in practice?
2. What specific result should it produce?
3. Which three steps repeat almost every time?
4. Where is a human most often needed?

If you can't answer these in 30 minutes, the process isn't ready for automation yet. It needs to be described first.

If the answers are clear, you can move on: point to the fragment that is the most repetitive, the least risky and the easiest to measure.

What usually comes out of this analysis?

Most often, one of three scenarios.

1. The process is ready for automation

It has:

• inputs
• an output
• repeatable steps
• clear points where a human decides

Then you can look for the best fragment to start with.

2. The process needs tidying up first

Different people run it differently. The decision criteria are fuzzy, or nobody can say what a good result is supposed to look like.

Then the work starts with straightening out the process, not with deploying AI.

3. The process is too chaotic

It has:

• no clear beginning
• no end
• no defined inputs
• no defined output

The company can't say how the task is done today. Then AI is not the first step. The first step is understanding what is actually going on inside the company.

That may sound less exciting than a quick tool rollout, but it usually saves a lot of money and frustration.

Process first, AI second

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

• speed up work
• reduce errors
• analyze documents
• clean up data
• support people in making decisions

But it won't replace thinking about the process.

If the company doesn't know:

• how the task is done today
• who makes the decisions
• what data is needed
• what a good result means

then automation is going to be risky. Not because AI is bad, but because nobody knows what it's actually supposed to do.

A good first step is to pick the two or three processes that weigh on the team the most and run them through a simple checklist.

Only once you know which processes are ready for automation is it worth moving on to the next question:

Which of these is worth automating first?