Smart automation: what to delegate to machines, what to keep human

Automation is one of the most overrated topics in the SMB world. Overrated not because it doesn't work — it works very well — but because it's pitched as a universal solution, while in reality it's a lever that breaks in your hand if applied to the wrong place.

The dream is simple: automate everything and the team focuses on value. The reality of those starting from that dream is just as simple: marginal things get automated, the real bottlenecks stay manual, and after twelve months you have a more complex system without a clear saving.

This article is a practical guide to avoid that fate. It's not about the tools of the moment. It's about the way to decide what gets automated, what stays human, and in what order — because the order, in automation, matters almost as much as the choice.

The main mistake: automating before standardising

Before talking about what to automate, it's worth saying what not to do, because it's the most common risk: automating a process that isn't yet standardised.

That means: taking an activity done differently depending on who does it, encoding it into automation based on one person's version, and ending up with rigid rules that don't match reality. Result: the system "works," but people start working around it, making exceptions, double-managing. You've automated the confusion.

The practical rule is one: standardise first, automate after. Standardising means writing the process down, agreeing on how it should be done, applying it for a few weeks. Only when the process is stable and shared does it make sense to encode it into a system. Never before.

The four kinds of activity that should almost always be automated

Not all activities are equal. Four categories almost always have a positive return when automated:

1. Repetitive high-volume activities

If the same action gets done ten times a day or a hundred times a month, every minute of automation frees many minutes of human time. Examples: sending receipt confirmations, updating standard statuses, notifications, generating identical documents.

The cumulative human cost of these activities is often two to three times higher than people think. It's worth measuring before deciding.

2. Time-dependent activities (the ones that fail because someone forgot)

Reminders, deadlines, escalations on stalled projects, periodic reports, follow-ups to dormant customers. Anything that "should fire automatically at a certain moment" is a perfect candidate. People forget. Systems don't.

3. Validations and checks with clear rules

Verifying a tax code is valid, that an invoice has all required fields, that an order doesn't exceed a threshold, that a customer has available credit. They're objective, repetitive rules that humans do worse because they get distracted or rush. A machine does them at the same quality every time.

4. Data aggregation and propagation

Collecting data from multiple sources to produce a consolidated one (e.g. monthly client report combining hours worked, open tickets, revenue). Or the opposite: propagating a piece of data from a source to multiple systems that need it (e.g. new client registered → CRM, invoicing, inventory system).

In both cases, automation removes human error and frees hours.

The four kinds of activity NOT to automate

Same honesty for the other half. These are the activities that, when automated, make things worse instead of better:

1. Decisions that require human judgement

When a choice depends on context, on the relationship with a client, on intuition, on complex trade-offs between different goals — don't automate. A machine can support the decision (e.g. surfacing relevant data, proposing options), but the final call stays human. Trying to delegate it leads to mechanical decisions on situations that needed nuance.

2. Sensitive communications

Replies to unhappy customers, complaint handling, negotiations, pricing communications. Automation here sounds cold and damages reputation. You can automate the triggers ("a complaint came in, alert Mario"), but the content of the reply stays human. Always.

3. Processes still in evolution

If the process is changing — because you're testing a new model, a new offering, a new flow — automating it means freezing in code something that will be different in a month. The right logic is: if it hasn't been stable for at least three months, leave it manual.

4. Exceptions and edge cases

Every process has 80% standard cases and 20% exceptions. Automation works for the 80%. For the 20% — complex situations, rare cases, real exceptions — building automatic logic costs much more than the benefit. The healthy rule: the system handles the standard cases, the exceptions go to a designated person.

A decision framework in five questions

For every automation candidate, these five questions help you choose without bias:

1. How many times does this activity happen in a month?

Indicative threshold: under 10 times a month, automation rarely is the first right intervention. Over 100, it almost always is.

2. How much time does each instance take?

Five minutes? Thirty? Two hours? Calculate: time × frequency × hourly cost = annual cost of the manual activity. That's the number you'll compare against the cost of automation.

3. Are the rules clear and stable?

If the activity is done by following a precise procedure, it's automatable. If every case "depends," it isn't. When it's in the middle — some clear rules, some cases that require judgement — the right thing is to automate the clear part and route exceptions to people.

4. How much does an error cost?

The higher the cost of an error, the more robust the automation has to be: with logs, sanity checks, human fallback. In high-risk cases (payments, taxes, security), automation has to be treated as a critical asset, not a shortcut.

5. Will the process change in the next six months?

If the answer is "probably yes," wait. If it's "no, it's been stable for a year," the moment is right. If it's "I don't know," it's probably not the moment yet.

A simple formula for ROI

After answering the five questions, it's worth doing the math roughly. A useful formula:

Annual saving = (time per activity × annual volume × internal hourly cost) − automation cost (build + maintenance)

If the result is positive within twelve months, the automation is typically worth it. If break-even is past 24 months, better to wait: the process will probably change, the tools will evolve, or something more important will become priority in the meantime.

There's a cost many people forget in this formula: maintenance. Automation isn't "build once and done." It needs updating when APIs change, when the process evolves, when unexpected cases come up. Count it as an annual recurring cost, typically 15–25% of the build cost.

The incremental approach: don't automate everything at once

Even when the opportunity is clear, the order in which you automate makes a big difference. The typical trap is wanting to automate everything in one go, with a big project, going live in six months. It rarely works.

The approach that almost always works:

1. Pick the process with the best pain-to-complexity ratio: maximum pain (time lost, frequent errors) and minimum complexity (clear rules, few dependencies).
2. Automate it minimally: no generalisations, no "in case one day," only the actual current use case.
3. Measure the real benefit after 30 days: actual time saved, actual errors avoided, not estimates.
4. Iterate or move to the next: if the automation produces a clear benefit, move on to the next process. If not, understand why before going further.

This way of working has three advantages: you find out quickly if the automation actually works, you build the team's confidence, and each step pays back before the next one starts. It's less spectacular than a grand project, but infinitely more effective.

Common mistakes that derail automation projects

Three recurring situations worth actively avoiding:

1. Automating to "be modern"

Automation introduced because "everyone else is doing it" — not because there's a concrete problem — doesn't generate value. Often it adds complexity with no return. The starting question shouldn't be "what can we automate?" — it should be "what's the biggest pain we want to remove?"

2. Skipping the measurement phase

Without measuring the real benefit, every automation ends up being "claimed success" even when it isn't. Six months later, nobody knows if it actually helped. Measure before, during and after. Concrete numbers.

3. Building automation without a maintenance plan

Automation is alive. When the external tool changes, when the process changes, when a new case arrives — someone has to take care of it. Without a designated person or vendor for maintenance, automation ages badly and creates problems.

In summary

Smart automation isn't "automate everything." It's understanding where people lose precious time on repetitive, codifiable activities, and freeing that time for the things that really need a human: decisions, relationships, judgement.

The framework is simple: standardise before automating. Pick processes with high frequency, clear rules, significant human time. Keep human what requires context and sensitivity. Move in small measurable steps.

Done this way, automation becomes one of the most powerful efficiency levers a company has. Done badly, it's just another source of complexity dressed up as progress.