What can be automated in your company: one question decides it

One question decides whether a process in your company can be automated: does someone do this by hand today, more than once a week? If the answer is yes, it can. If it is no, it is not an automation — it is a new feature of the system, and that gets estimated and priced differently. Everything else — the industry, the size of the company, the technology — comes after.

Why that question and not another

Both halves do work.

“By hand” means the process already exists and already has rules. Someone knows what to look at, in what order, and what to do when something doesn’t add up. That judgment is what gets automated. A process nobody does yet has no rules to copy: they have to be invented, and that is designing a product, not automating one.

“More than once a week” is the threshold where repetition starts to hurt. It is not a law of physics: it is the point where the cost of building something starts to pay itself back. A task that happens twice a year gets done by hand, and that is fine.

And here is the nuance people miss: count the hands, not just the times. An order that arrives twice a week but passes through three people — whoever receives it, whoever ships it, whoever invoices it — is being touched six times. The real frequency is the one you see when you follow the data all the way through.

Where it usually hides

There is no catalog of automations and there shouldn’t be: every operation is different. But repeated work tends to hide in the same three places.

Where a piece of data gets written twice. A sale recorded in a notebook, then in inventory, then on the invoice is the same data typed three times. Every copy is a chance for it to be typed differently.

Where something comes in through one channel and leaves through another. An order that arrives by WhatsApp and ends up in a spreadsheet. A bank email someone reads, interprets and writes down. That jump between channels is almost always done by a person.

Where someone has to remember. A due date, a follow-up, a renewal. If the system doesn’t flag it, someone is carrying it in their head — and that works until the day that person gets sick.

What not to automate: what your system already does

This is the most expensive mistake, and the most common.

Charging, invoicing, flagging due dates, scheduling: if your system already does it, it is not automated and not charged again. If your team is doing it by hand, it is because they don’t know they have it, and that is not fixed by building software on top. It is fixed by teaching the system you already paid for.

Before quoting anything, it is worth going through what your current setup actually does. It usually covers more than people think.

When it stops being an automation

When the estimated work goes past ten days, it isn’t one any more. It is a new product, and it is worth calling it that from the start: it gets planned, tested and delivered differently.

Most real automations land between one and five days of construction. That estimate comes from comparing against things already built, not from adding up imagined tasks — adding up tasks is how you get estimates that miss by three times.

The part almost nobody tells you

A finished automation breaks silently.

The bank changes its email format. A supplier changes a field on a form. An API returns a different date. None of it warns you: it simply stops working, and you find out weeks later, when something doesn’t add up.

That is why an automation has a monthly cost even when it is already built. You are not paying for the code: you are paying for someone to watch it and fix it before you notice. An automation with nobody watching it is a time bomb with good intentions.

What we don’t know

We don’t know how many hours it will save you. There is no measurement of hours saved at any Sonika client, so we don’t publish a figure. Anyone who gives you a percentage without looking at your operation is making it up.

What can be measured, from the first month, is duller and more useful: how many times the automation ran and how many times it failed. That is a fact, not a promise.

We also don’t know whether the once-a-week threshold is the right one. It is the rule we use, and it comes from looking at real operations, not from a study. The day a case contradicts it, we correct it.

---

If you want to see what building one costs and why it carries a monthly fee, it is all on the automation page and on pricing.