Which process first. The method, not the list of tools.

The question that stops almost every small business isn't which tool to use. It's where to put it the first time, so it produces something measurable rather than a novelty.

This piece is the method. The picture of the gap between businesses that use AI and those that have integrated it, with the numbers and the barriers businesses report, is in 81% of Italian SMEs use AI, and one in four has integrated it. Here we start from that figure and answer the next question: where do you begin?

Why a list of tools doesn't help

A list of tools answers the wrong question. It tells you what exists, and what exists changes every few months, while the structure of a business's processes rarely changes. Choosing by starting from the tool ends with the work being adapted to the software instead of the other way round.

There's also a more concrete reason. The same survey that measures 81% uptake finds that cost is named as the main barrier by only 6.6% of businesses: the real obstacles are the skills to use it independently and trust in how data is handled. Neither is solved by choosing a different tool.

Step one: map, don't imagine

The map is built by looking at what actually happens in a week, not what should happen according to the org chart. Take a sheet of paper and write down the processes that use up someone's time, one per line, with a description ending in a verb: what the process produces, and in what form.

There's one rule that makes this step useful: write down only what you've seen, or what someone has told you they did. An imagined process, or one described as it ought to be, produces a map that looks like a manual and doesn't help you decide anything.

For a small business the list is short, between ten and twenty lines. If you end up with fifty, you're almost certainly writing down activities rather than processes, and it's worth going back: a process is a chain that starts with something coming in and ends with something going out.

Step two: the four columns that decide

Next to each line you write four values. You don't need precise numbers: you need orders of magnitude you can compare, because the decision comes from the comparison, not from exact measurement.

Column	What you write	Why it matters
Frequencyhow often it happens	Times per week or per month. An order of magnitude is enough: ten, a hundred, a thousand.	It's the multiplier. An improvement to a process that happens twice a year won't show, however good it is.
Repetitivenesshow much it's always the same	Whether the person doing it follows a stable rule, or decides case by case using experience they've never written down.	A process governed by a rule can be described, and what can be described can be delegated. Unwritten judgement can't.
Cost of errorwhat happens if it goes wrong	Who notices, how quickly, and what it costs to put right. A customer noticing is the worst case.	It's the brake. The first process should be chosen where a mistake shows immediately and can be fixed, not where it leaves the business.
Data ownershipwhose information it is	Whether the process touches customer data, personal data, prices, or only material that's already public.	It's the second barrier businesses report. A written answer on where the data ends up has to come before, not after.

The first process to automate is the one with high frequency, high repetitiveness, a low cost of error and data that isn't very sensitive. It isn't the most interesting one, and it's almost never the one people in the business were talking about: it's the one where an improvement shows quickly and a mistake leaves no mark.

Step three: the baseline

Before changing anything, take a number by hand on the process you've chosen. It has to be a number the business already has or can count in an afternoon: how many minutes pass between arrival and reply, how many cases get closed in a day, how many enquiries go unanswered in a week.

It's the step almost everyone skips, and it's what makes everything else verifiable. Without the before figure, any later result becomes an impression, and impressions of your own processes are consistently generous.

An improvement with no baseline isn't an improvement. It's a feeling with an invoice attached.

Step four: the human checkpoint

Before switching anything on, decide in writing who checks what. The rule we follow is set out in Ethics: the system prepares and flags, but no message that commits the business reaches a customer until a person has read and approved it.

On an incoming enquiry the rule applies differently, and it's worth knowing that before choosing the process. There's still human approval, but it comes earlier and applies to the content: information the owner has already approved, such as opening hours and availability, can go out on its own, while quotes, prices and confirmations can't. The distinction, with its limits, is explained in how we reply to incoming enquiries.

There's also an obligation, and it concerns transparency. Article 50 of the European regulation on artificial intelligence applies from 2 August 2026 and requires that people interacting with an AI system are told so. What this means for a small business is covered in the AI Act for Italian SMEs.

Step five: what to look at afterwards

Once it's switched on, you look at three things, and none of them is how satisfied the users are. First, the baseline figure, taken again in the same way and at the same point. Second, how many times the human checkpoint corrected something. Third, how many times the process stopped altogether.

The second is the most informative and the most neglected. A correction rate that falls in the first weeks and then levels off tells you the system has learned the ordinary case; a rate that stays high tells you the process you chose involved more judgement than it seemed, and it's worth going back to the map.

That's also why the first process should be chosen where a mistake can be corrected. A high correction rate on a process with a low cost of error is useful information. On the same process with a high cost of error, it would have been damage.

What this method doesn't promise

It doesn't promise a percentage saving, because that depends on the process, the volume and how organised it already was. Anyone who gives you a figure before looking at your numbers is selling, and the figure they give you has no way of being true.

What can honestly be said is conditional and concerns you: if that process happens two hundred times a month and takes ten minutes of someone's time each time, those minutes add up to thirty-three hours a month, and the question becomes what thirty-three hours are worth in your business. You do the sum, with your own numbers, and it's the only one that means anything.

Where the map ends and the work begins

The map is an afternoon's work and needs no tools. It gets you from the question “should we be using artificial intelligence?”, which has no answer, to the question “can this process, which happens a hundred times a month, be described well enough to delegate it?”, which does.

When the answer to that question is yes, the next step is to build the piece. The systems we put into production, one per process, are listed in services, and each has its own page setting out what it does and what it doesn't. The map is for choosing which one, not for buying them all.

Questions and answers