Small Step, Big Impact — Where to Start Automating Your Business

The first instinct is to tackle the process that costs the most. That’s a good direction, but the wrong scope.

The processes that cost the most are usually the most complex. They involve several people, two or three tools, dozens of exceptions, and at least one client who is handled according to their own specific requirements. A project like this can begin with several weeks of alignment, deliver its first visible result only after a quarter, and by then the next step is being decided by a company that has already started to lose confidence that it works.

The scale of the problem can be misleading in another way. In the MIT “State of AI in Business” study, 50 to 70 percent of AI budgets at the companies surveyed were allocated to sales and marketing, even though higher returns were reported in operations and finance. The reason is simple: a sales project is easier to explain and easier to justify. Companies choose not what will generate the highest return, but what is easiest to show.

That’s why cost is better treated as an indicator of where to look rather than a ready-made task. Within each such area, there are usually several smaller, self-contained activities that can be fully automated without changing the rest of the process.

Let’s take customer payment settlements. The area is broad: overdue payments, monthly reconciliations, and irregular correspondence. But within it, there is one self-contained task that can be fully automated — sending a reminder for an invoice whose payment deadline has just passed. One rule, one owner, one measurable outcome. It can be up and running within a week, not a quarter.

There are usually several candidates. The right one has five characteristics — all of them at once. Four out of five means it’s a different project, for another quarter.

Frequency. The task is repeated daily or weekly. Quarterly tasks can be costly, but their impact may not be visible for six months, and the first project needs to prove its value quickly. Approval for the next project depends on it.

Clear Rules. The task can be described as “if X, then Y.” If “it depends” keeps coming up when documenting the process, it’s not suitable as a starting point. It can be second or third in line, once the company has gained more experience documenting its own procedures.

Stability. The process is unlikely to change within the next year. This criterion is often overlooked, yet it can have the most serious consequences. An automation built on a system that is due to be replaced may end up becoming the longest-lived part of the old architecture. A procedure that will change because of new regulations in six months can consume the budget before it delivers any return. A simple test: if the process has changed three times in the past six months, it isn’t ready.

Low Cost of Error. The first implementation should be allowed to make mistakes during the first week. If a mistake means a shipment is put on hold or a filing with a government authority is incorrect, the scope was chosen poorly. If it means correcting a single message, that’s the right scope.

Person Who Benefits. An employee for whom the task is a burdensome addition to their core responsibilities will know about exceptions that no one else is aware of and will test the finished solution more thoroughly than anyone else. And in the end, that person — not the process owner — will convince the rest of the team that it works.

When all five characteristics come together, the project scope fits into a single sentence. If it takes a paragraph to describe, it’s not one project — it’s three.

Before anything changes, it’s worth spending a week measuring the process. Not an audit, not workshops, not process mapping — just a regular week of taking notes. How many times the task occurred, how many minutes it took each time, who performed it, and what happened when things didn’t go as usual.

The latter is the most important. Exceptions are one of the most commonly cited reasons for failed implementations: automation handles the standard scenario but stops when it reaches a variation that no one mentioned because it seemed obvious. A process described from memory always looks more orderly than the one actually operating in the company, and the difference between the two versions is essentially a ready-made list of situations that later determine whether the project succeeds.

These notes have one more purpose that’s easy to overlook. Three months from now, someone will ask whether it paid off. Without a recorded baseline, the only answer is “I think so” — not enough to justify another project, and certainly not enough for something that could have been measured over just five days.

There is a serious argument against small projects, and it’s worth knowing before someone makes it. It goes like this: small implementations stay small. They work, make an impression in a presentation, and then nothing comes of them.

The argument has strong grounds. McKinsey described the phenomenon as early as 2018 as “pilot purgatory” — a state in which technically successful projects remain stuck in the pilot phase for years without moving into production. Since then, the pattern has repeated with every successive wave of technology. In the MIT study mentioned earlier, 60 percent of companies evaluated AI solutions, 20 percent moved to the pilot stage, and only 5 percent reached production with a measurable impact.

The conclusion usually drawn from this is the opposite of the right one. The same analyses show that moving beyond the pilot phase depends not on what a company does after the pilot, but on how the pilot was chosen in the first place. A pilot designed as an impressive demonstration remains a demonstration. A pilot designed as a part of the work the company already has to perform every day simply becomes part of the business.

This leads to a sixth condition that isn’t visible in the list of characteristics: the first project should be small, but it shouldn’t be isolated. It should use the data, systems, and permissions that are part of everyday operations, not a spreadsheet prepared specifically for the occasion. A demonstration using data prepared for the demonstration proves nothing — except that data can be prepared.

The main impact of the first implementation rarely comes from the hours saved.

Let’s go back to overdue invoice reminders. When handled manually, they are sent to clients irregularly. It’s an unpleasant task that always loses out to more urgent priorities, and each client requires a separate decision about whether it’s time to send a reminder. One reminder goes out on the fifth day past due, another on the twentieth, depending on the week. The automation sends it on the third day, in the same format, to every customer. The 40 minutes a week that go back to the team are the least important part. What matters more is that payments come in faster, and no one has to make the decision from scratch for every invoice.

That is the real difference between manual and automated work. It’s not about speed — it’s about predictability. On a good week, a person can outperform any automation. On a difficult week, they may not get to it at all.

The rest of the impact comes later. Once the implementation is up and running, the conversation around automation changes: there is no longer a need to defend new ideas as hypotheses — you can simply point to what already works. That puts the company in a completely different starting position.

The list itself changes too. Its items may look like separate projects, as any list drawn up in advance tends to. After the first implementation, it becomes clear that several of the next ones rely on the same data, the same permissions, and the same workflow. The second project costs less than the first, and the third may cost only a fraction of that — not because the company bought better tools, but because it now knows where its data is and who is responsible for it.