When a business process is ready for AI automation

The useful question is not “should we do AI?”. It is “is this specific process ready?”.

AI automation helps when the same work comes back often, the data already exists, and there is a clear line between the standard case and the exception. It helps much less when the starting point is “all support”, “all admin”, or “the whole company”.

A business process is ready for AI automation when three things are true at the same time: the work repeats, the data already exists, and a human decides the exceptions. If one of those is missing, you can run a trial, but you do not yet have a reliable process.

What “repeats” actually means

Repeating does not mean “we often do something similar”. It is stricter than that.

The inputs look alike. The steps are stable. The volume is regular enough to observe. The expected output is known.

Work that often fits includes sorting requests that arrive through the same channel, copying information already written into another system, drafting the standard reply when the case is standard, checking that a file contains the expected documents, or routing a request to the right person.

Work that does not fit includes a decision whose criteria change with each customer, rare work even when it is painful, a task nobody can describe because it lives in one person’s head, or a case where every request requires a full negotiation.

Business process automation starts without a tool. Write the normal path on one page: what comes in, what the team checks, what is produced, and what blocks the process. If that path cannot be written clearly, the process is not ready.

The data is already there

AI does not recreate a job that was never written down. It uses traces.

Those traces can be messages, files, rows in the system the team already uses, past decisions, replies sent, accepted files, rejected files, or status changes. They do not need to be perfect at the start, but they must exist and show what actually happened.

Look at one month of this process. Can you find what came in, what went out, and who approved it? Can you compare a well-handled case with one that caused trouble? Can you see the fields, documents, or decisions that keep coming back?

If not, the first job is not automation. It is keeping a reliable record. Without usable history, you may ask a system to repeat a step nobody can verify. The result can look plausible and still be wrong.

This is where many projects are decided. Not in the model choice, but in the quality of the material the process gives you.

A human handles the exceptions

A process almost always contains two types of cases: standard cases and exceptions.

Automation takes the standard ones. A person keeps the exceptions: incomplete file, unusual situation, missing document, deadline outside the rule, ambiguous request, sensitive customer, unusual amount, contradiction in the information.

Decide that split before you build anything. What can move forward on its own? What must stop? Who receives the alert? How quickly? With what information?

Without that line, you do not just move faster. You move mistakes faster. A wrong classification, an overconfident reply, or a copied field that nobody checks may not look dramatic at first. Repeated often enough, it damages trust in the system.

AI workflow automation should therefore be understood simply: an input, known cases handled, doubtful cases stopped, then a human review. The goal is not a system that comments on everything. It is a precise flow where manual handling goes down and responsibility stays clear.

The three conditions on one example

Take a team that receives the same requests every day through a form.

The usual handling is stable: read the request, check the required fields, classify the subject, create or update a record in the tracking system, send the standard reply. A person looks closely only when the request is incomplete, urgent, or unusual.

The three conditions can be checked.

The work repeats. Requests arrive through the same channel and most follow the same path.

The data exists. Past requests are in the inbox, form system, or tracking tool. Replies and statuses are available.

The exception is visible. Something is missing, the request falls outside the expected categories, or the timing requires a human decision.

The test is concrete: take ten old requests. How many followed exactly that path? How many could have been prepared automatically and reviewed quickly? How many should have stopped?

If most follow the standard path, AI automation may be useful. If every request requires a different interpretation, this is a poor candidate. You can see that before you build anything.

When not to do it

Three signs should make you slow down or stop.

The work is not the same from one case to the next. Each case requires full judgment. In that case, AI automation mostly adds a layer someone must reread in full.

The data does not exist. There is no history, or the history is too messy to trust. Building on that is building on an impression.

Nobody can define the exception. If the team does not agree on the normal case, no system will decide it cleanly for them.

In these situations, the useful move is to clarify the process. Reduce the scope. Write the rules. Keep better records for a few weeks. The AI project can come later, if it still makes sense.

Decide on one process

Take one process. Not a wish list.

1. Name it in one sentence: who receives what, and who must produce what.
2. Count it over two weeks: number of cases, time spent, and share of cases that are truly similar.
3. Pull ten cases you already handled and sort them into standard or exception.
4. Write the rule for standard cases in a few lines.
5. Decide who handles the exceptions, and how quickly.
6. Apply the rule by hand to the ten cases before any tool.

The last point matters. If a person often gets it wrong while following the rule, a system will too. If the rule holds, you have a serious starting point.

This test takes a few days. It does not yet give you the architecture, budget, or tool choice. It tells you whether this process is worth automating, or whether you should simplify it first.

What comes next

If the three conditions are met, the subject is clear: which process, which data, and where the human line sits.

That is a strong basis for a conversation with Perfusion, without starting from a vague promise or choosing a tool too early.