AI automation: what it is and how to tell whether you need it

Start with an ordinary quote request

An email arrives: “We need twenty units of product X by the end of the month. Can you send us a quote?”

Someone opens the message, checks what is missing, finds the correct price, confirms availability, drafts an answer and passes it to the person authorised to send it. Once, this takes little time. Repeated dozens of times, the same sequence becomes a meaningful part of the job.

AI automation can prepare some of that work. It reads the email, identifies the product, quantity and requested date, then puts those details into a short record with a separate field for each item. The price still comes from the company's approved price list. Availability still comes from the software that records orders and stock. If a required detail is missing, the request goes to a person instead of becoming a fabricated quote.

That is AI automation: a system uses artificial intelligence to understand variable information, then moves it through a controlled sequence of steps.

By the end of this guide, you will be able to take one activity in your company and choose among three routes: ordinary rule-based automation, AI-assisted automation, or process clarification before any automation.

When do ordinary rules work better?

Picture an online form with the same five fields every time. When it is submitted, software copies the name, email address and request into a customer system. The information already has a defined shape, so ordinary rules are usually enough.

Now picture the same request inside an email. One customer writes “twenty units”, another asks for “roughly two boxes”, and a third attaches a PDF but leaves out the date. The system has to understand the message before a rule can use it. That is where AI may help.

The practical distinction is simple:

• structured inputs and stable rules usually need ordinary automation;
• varied text, documents and messages may benefit from AI interpretation;
• decisions that nobody can explain consistently need process work first.

This prevents two expensive mistakes: buying AI for a problem that a form would solve more reliably, and asking AI to make a decision the company itself has not defined.

Follow the quote from input to decision

Return to the opening email. A sensible workflow could look like this:

1. The request arrives. The customer sends an email and an attachment.
2. AI prepares the details. It extracts product, quantity, requested date and missing information. Each detail keeps a reference to the sentence or document section it came from.
3. Company software verifies the facts. Price comes from the approved list. Availability comes from the system that records orders and stock. The AI does not guess either one.
4. A person handles the exception. If product X requires a variant the customer did not specify, the system drafts a question and stops.
5. The output is reviewable. Sales sees the original request, extracted details, consulted sources and unresolved points, then corrects, approves or asks for clarification.

The useful outcome is an organised request with checked facts and visible uncertainty. The responsible person still decides what to send.

The same pattern can support ticket routing, application preparation, document intake and first-response drafting. The data and responsibilities change; the logic remains understandable: AI interprets the varied input, company records supply the facts, and a person decides where consequences matter.

Which activity should you choose first?

Choose one activity that happens often enough to observe but is small enough to stop without causing harm.

It is a promising first candidate when:

• it repeats and usually follows the same steps;
• the input varies in form but contains recognisable information;
• the expected output has a clear shape, such as a record, category or draft;
• an experienced person can judge whether the result is correct;
• mistakes can be caught before reaching a customer, moving money or changing an important record.

A process spanning an entire department, many exceptions and difficult decisions makes a poor first test. It may become a useful project later, once the repeatable parts are visible.

Run the ten-case test

Collect ten recently completed examples of the same activity. For quoting, use ten requests received last month. Ten is not a scientific threshold. It is small enough to inspect every case and large enough to reveal the first repeating patterns. Include at least one incomplete or unusual case.

Record five things for each one:

Then look for the repeating pattern:

• The same fields and rules appear in almost every case: try ordinary automation first.
• The steps repeat, but the emails and documents vary: consider AI-assisted automation.
• People disagree about the correct result: stop and define the process with the people who do the work.

The third outcome is useful. When ten completed cases still have no shared logic, adding a model does not create clarity. It only makes the origin of each decision harder to see.

Test the system before giving it the job

The first test can use those ten completed cases. Keep the current process in place. The new system works on a copy, prepares its answer and changes nothing outside the test.

Before you begin, agree on minimum acceptance conditions with the people who do the work. For example:

• every important detail shows where it came from;
• missing information is flagged rather than filled by assumption;
• price and availability match the approved business sources;
• every exception reaches the responsible person;
• time saved is measured across the complete task, including review and correction.

Compare the system's result with the company's completed result, one case at a time. If it meets the agreed conditions, extend the test to new cases while keeping human approval. If it fails repeatedly at the same step, repair that step. If failures move unpredictably or review costs more time than the system saves, stop.

Here, a pilot simply means a limited, measured and reversible test before the automation is connected to live work.

The standard I use in automation projects

When I assess an automation, “What can it do in the demo?” is not the question I care about most. A demo usually receives a clean example. Real work brings the wrong attachment, an incomplete request, yesterday's price-list update and the customer who needs an exception today.

I pay more attention to the eleventh case, the one that does not quite resemble the first ten. I want to know whether the system exposes its uncertainty, where it gets its facts and who can stop it before an error becomes a consequence.

I prefer an automation that stops in the right place to one that continues elegantly from a false assumption. That choice is made at the beginning, when we decide which cases the system may handle and which ones it must return to a person.

This position also changes the commercial answer. Sometimes an existing product is the right choice. Sometimes the process justifies a custom build. Sometimes the useful work is to clarify the process and postpone automation. Starting from the technology makes all three look like sales opportunities. Starting from the work produces three different answers.

What you can do today

Choose one repeated activity, collect ten completed cases and fill in the five columns above. You will end with something concrete to discuss with the people who perform the work, and you should be able to rule out at least one of the three routes.

If the cases point to an AI-assisted route, see how I approach AI automation for Italian companies. For quoting, compare an existing product with a custom workflow.