A team I worked with celebrated when they finished their Zapier flow. It auto-routed inbound leads from a web form to the right sales rep based on territory, company size, and product interest. Took them a week to build. They were proud of it.

Six months later, it was broken. Nobody noticed for three weeks.

A prospect had filled out the form. The Zapier trigger fired. But the Google Sheet it referenced had been restructured during a CRM migration. The territory mapping no longer matched. Leads were going nowhere. Three weeks of inbound interest — vanished into a spreadsheet that no longer made sense.

This wasn’t a bad automation. It was an unsupported one.

Two kinds of automation

There’s a meaningful difference between automation that helps and automation that compounds. Most people treat them as the same thing. They aren’t.

Automation that helps saves you time on a specific task. It moves data from A to B. It sends a notification. It fills in a template. It replaces a manual step with a triggered one. This is useful. But it’s also fragile.

Automation that compounds does something different. It becomes more reliable over time. It handles its own failures. It tells you when something is wrong. It doesn’t depend on one person remembering it exists. It’s not a shortcut — it’s infrastructure.

The difference isn’t in the logic. The same lead-routing rule can be either one. The difference is in what surrounds the logic.

Why isolated automation breaks

Most automations are built as point-to-point connections. Form submits, Zapier fires, data lands in a sheet. Simple. Elegant. And entirely dependent on every link in the chain staying exactly as it was when you built it.

But tools change. APIs update. Someone renames a column. Someone restructures a sheet. Someone cancels a subscription to a middleware tool. Someone leaves the company and takes the institutional knowledge of why this Zapier exists with them.

Isolated automation has no memory. It doesn’t know why it was built. It doesn’t know who built it. It doesn’t know what to do when something upstream changes. It just fails — silently, often for weeks, sometimes longer.

The Google Sheets formula that calculates commission? It breaks when someone inserts a row above the reference range. The email auto-responder? It keeps sending the old pricing after the update because nobody thought to check it. The Zapier chain that syncs contacts between two platforms? It stops when the API key expires.

None of these are complex failures. They’re predictable ones. And that’s the point.

What compounding automation looks like

Automation that compounds has four properties that isolated automation lacks.

Error handling. What happens when the API is down? When the data format changes? When the input is malformed? Compounding automation has answers to these questions built into its structure. It retries. It falls back. It quarantines bad data instead of passing it through.

Monitoring. Does someone know when it fails? Not eventually. Not when a customer complains. Immediately. Compounding automation announces its own failures — through alerts, dashboards, or logs that someone actually reads.

Documentation. Does anyone besides the person who built it understand what it does? Could a new hire figure out why this automation exists, what it connects, and what to do when it breaks? If the answer is no, the automation has a lifespan equal to that person’s tenure.

Maintenance ownership. Is someone responsible for keeping it running? Not as a side task. Not as “whoever notices.” As an explicit part of someone’s role. Automation without an owner is automation with an expiration date.

These four properties don’t make automation more complicated to use. They make it less fragile. They’re the difference between something that works today and something that works next year.

The architecture question

Before automating anything, ask five questions:

Is this a repeatable process with clear inputs and outputs? If the answer is “mostly” or “usually,” you’re not ready to automate. You’re ready to standardize.

Does someone own the maintenance? If nobody is responsible for this automation continuing to work, it won’t. Not because it’s badly built — because nothing unowned survives contact with a changing environment.

Will this still work in six months? What changes could break it? A tool migration? A pricing update? A team restructuring? If you can name three plausible scenarios that would break it and you have no plan for any of them, you’re building something temporary.

Does this have error handling? Not “what happens when it works” — what happens when it doesn’t?

Is this documented? Not in the builder’s head. Somewhere a colleague could find it.

If you can answer yes to all five, you’re building infrastructure. If you can’t, you’re building a shortcut. Shortcuts save time once. Infrastructure saves time forever.

The rebuild

The team that celebrated the Zapier flow? They rebuilt it. Same logic — territory mapping, company size, product interest. Same outcome — leads routed to the right rep.

But different architecture. They moved it into a system with error handling that flagged malformed submissions instead of silently dropping them. They added monitoring that pinged a Slack channel when routing failed. They documented the mapping logic in a shared wiki. They assigned a quarterly review to verify the territory data was current.

Same automation. Different foundation.

It’s been running for over a year. Not because it’s more sophisticated. Because it’s supported.

Not more automation — better architecture. That’s the difference between something that helps once and something that compounds.

---

Related

• Service: Operational Systems & Backend Architecture — Backend architecture, automation pipelines, and AI workflows.
• Article: Building Internal Tools vs Buying Off the Shelf — When custom wins, and when off-the-shelf is enough.
• Article: Is Automation Worth It for Small Businesses? — The honest calculation most automation vendors won’t make.

---

Hrvatski

Tim s kojim sam radio slavio je kad su završili svoj Zapier tijek. Automatski je usmjeravao dolazne upite s web obrasca pravom prodajnom predstavniku na temelju teritorija, veličine tvrtke i interesa za proizvod. Trebao im je tjedan dana da ga izgrade. Bili su ponosni na to.

Šest mjeseci kasnije, bio je pokvaren. Nitko to nije primijetio tri tjedna.

Potencijalni klijent ispunio je obrazac. Zapier okidač se aktivirao. Ali Google Sheet na koji se referirao bio je restrukturiran tijekom migracije CRM-a. Mapiranje teritorija više se nije poklapalo. Upiti nisu stizali nikamo. Tri tjedna dolaznog interesa — nestalo u tablici koja više nije imala smisla.

Ovo nije bila loša automatizacija. Bila je nepodržana.

Dvije vrste automatizacije

Postoji značajna razlika između automatizacije koja pomaže i automatizacije koja se kumulira. Većina ljudi tretira ih kao istu stvar. Nisu.

Automatizacija koja pomaže štedi vam vrijeme na specifičnom zadatku. Premješta podatke iz A u B. Šalje obavijest. Popunjava predložak. Zamjenjuje ručni korak okidačem. Ovo je korisno. Ali je i krhko.

Automatizacija koja se kumulira radi nešto drugačije. Postaje pouzdanija s vremenom. Sama obrađuje vlastite pogreške. Obavještava vas kada nešto nije u redu. Ne ovisi o jednoj osobi koja se sjeća da postoji. Nije prečac — to je infrastruktura.

Razlika nije u logici. Isto pravilo usmjeravanja upita može biti oboje. Razlika je u onome što okružuje logiku.

Zašto se izolirana automatizacija kvari

Većina automatizacija izgrađena je kao točka-do-točke veza. Obrazac se pošalje, Zapier se aktivira, podaci slete u tablicu. Jednostavno. Elegantno. I potpuno ovisno o tome da svaka karika u lancu ostane točno onakva kakva je bila kad ste je gradili.

Ali alati se mijenjaju. API-ji se ažuriraju. Netko preimenuje stupac. Netko restrukturira tablicu. Netko otkaže pretplatu na alat za posredovanje. Netko napusti tvrtku i odnese institucionalno znanje o tome zašto ovaj Zapier uopće postoji.

Izolirana automatizacija nema pamćenje. Ne zna zašto je izgrađena. Ne zna tko ju je izgradio. Ne zna što učiniti kad se nešto uzvodno promijeni. Jednostavno otkaže — tiho, često tjednima, ponekad i duže.

Google Sheets formula koja izračunava proviziju? Kvari se kad netko umetne redak iznad referentnog raspona. Automatski odgovor na email? Nastavlja slati stare cijene nakon ažuriranja jer nitko nije pomislio provjeriti. Zapier lanac koji sinkronizira kontakte između dviju platformi? Prestaje kad API ključ istekne.

Ništa od ovoga nisu složeni kvarovi. To su predvidljivi kvarovi. I u tome je poanta.

Kako izgleda automatizacija koja se kumulira

Automatizacija koja se kumulira ima četiri svojstva koja izoliranoj automatizaciji nedostaju.

Rukovanje pogreškama. Što se dogodi kad je API nedostupan? Kad se format podataka promijeni? Kad je ulaz neispravan? Kumulativna automatizacija ima odgovore na ta pitanja ugrađene u svoju strukturu. Pokušava ponovno. Ima rezervni plan. Stavlja loše podatke u karantenu umjesto da ih propušta.

Nadzor. Zna li netko kad otkaže? Ne na kraju. Ne kad se korisnik požali. Odmah. Kumulativna automatizacija sama objavljuje vlastite pogreške — kroz upozorenja, nadzorne ploče ili zapise koje netko zaista čita.

Dokumentacija. Razumije li itko osim osobe koja ju je izgradila što radi? Bi li novi zaposlenik mogao shvatiti zašto ova automatizacija postoji, što povezuje i što učiniti kad se pokvari? Ako je odgovor ne, automatizacija ima životni vijek jednak trajanju zaposlenja te osobe.

Vlasništvo nad održavanjem. Je li netko odgovoran za njezin rad? Ne kao sporedni zadatak. Ne kao “tko primijeti.” Kao eksplicitni dio nečije uloge. Automatizacija bez vlasnika je automatizacija s rokom trajanja.

Ova četiri svojstva ne čine automatizaciju složenijom za korištenje. Čine je manje krhkom. To je razlika između nečega što radi danas i nečega što radi sljedeće godine.

Pitanje arhitekture

Prije automatizacije bilo čega, postavite pet pitanja:

Je li ovo ponovljiv proces s jasnim ulazima i izlazima? Ako je odgovor “uglavnom” ili “obično,” niste spremni za automatizaciju. Spremni ste za standardizaciju.

Posjeduje li netko održavanje? Ako nitko nije odgovoran za nastavak rada ove automatizacije, neće raditi. Ne zato što je loše izgrađena — zato što ništa bez vlasnika ne preživljava kontakt s promjenjivim okruženjem.

Hoće li ovo još raditi za šest mjeseci? Koje bi promjene mogle to pokvariti? Migracija alata? Ažuriranje cijena? Restrukturiranje tima? Ako možete navesti tri vjerojatna scenarija koji bi to pokvarili, a nemate plan za nijedan od njih, gradite nešto privremeno.

Ima li ovo rukovanje pogreškama? Ne “što se dogodi kad radi” — što se dogodi kad ne radi?

Je li ovo dokumentirano? Ne u glavi graditelja. Negdje gdje bi kolega mogao pronaći.

Ako na svih pet možete odgovoriti potvrdno, gradite infrastrukturu. Ako ne možete, gradite prečac. Prečaci štede vrijeme jednom. Infrastruktura štedi vrijeme zauvijek.

Ponovna izgradnja

Tim koji je slavio Zapier tijek? Ponovno su ga izgradili. Ista logika — mapiranje teritorija, veličina tvrtke, interes za proizvod. Isti ishod — upiti usmjereni pravom predstavniku.

Ali drugačija arhitektura. Premjestili su ga u sustav s rukovanjem pogreškama koji označava neispravne prijave umjesto da ih tiho odbacuje. Dodali su nadzor koji šalje poruku na Slack kanal kad usmjeravanje zakaže. Dokumentirali su logiku mapiranja u zajedničkom wikiju. Dodijelili su tromjesečni pregled za provjeru jesu li podaci o teritorijima ažurni.

Ista automatizacija. Drugačiji temelj.

Radi više od godinu dana. Ne zato što je sofisticiranija. Zato što je podržana.

Ne više automatizacije — bolja arhitektura. To je razlika između nečega što pomogne jednom i nečega što se kumulira.

---

Povezano

• Usluga: Operativni sustavi i backend arhitektura — Backend arhitektura, automatizacijski cjevovodi i AI tijekovi rada.
• Članak: Izgradnja internih alata nasuprot kupnji gotovih — Kada prilagođeno pobjeđuje, a kada je gotovo dovoljno.
• Članak: Isplati li se automatizacija za male tvrtke? — Iskreni izračun koji većina prodavača automatizacije neće napraviti.