When a spreadsheet beats an automation

We built a Zapier workflow last year to move new newsletter sign-ups from a form into a CRM, tag them by source, and post a summary to Slack every morning. It worked. It also took about ninety minutes to build, another forty to fix twice in the following two months when the form provider changed a field name, and it was moving, on a good week, eleven records. Eleven. We could have typed eleven rows into a spreadsheet in about four minutes a day and never touched an API key.

We are not about to argue that automation is bad. Most of what this site covers assumes the opposite, and we have written at length about how to make a workflow survive past its first month without collapsing quietly. But that piece assumed you had already decided to build the thing. This one is about the decision before it, which almost nobody makes on purpose. People build automations for the way they feel — the drag, the connectors, the small satisfaction of a scenario going green — and rarely for the arithmetic, which says no more often than the no-code industry would like.

Three numbers decide it, and none of them is difficulty

The question people ask before automating something is usually "can I?" That is almost always yes. The question that actually matters is different, and it has three parts.

Volume. How many times does this run per week, and how long does each run take by hand? A task that happens eleven times a week at thirty seconds each costs five and a half minutes. The same task at four hundred times a week costs three and a half hours — a different conversation entirely. Automation has a fixed setup cost regardless of volume, so its economics only work once volume is high enough to amortise that cost inside a reasonable number of weeks. Below that line you are paying an hour of engineering to save five minutes.

Stability. Does the underlying process change shape from month to month, or has it stayed the same for a year? An automation encodes the process as it exists on the day you build it. If the form gets a new field, or leads from the trade show now need a different tag, the automation does not adapt — it breaks, or worse, keeps running and silently produces the wrong thing. A spreadsheet adapts because a person looks at it every run. That is a mechanical point, not a romantic one about human judgement: manual steps re-validate themselves on every execution; automated steps validate themselves never, unless you specifically built the validation, which is its own cost.

Stakes. What does a wrong result cost, and who notices? Tagging a newsletter sign-up wrong costs nothing — worst case, the wrong segment of a marketing email. A refund calculation done wrong costs real money and trust, quietly, because the automation reports success whether the number was right or not. High-volume, low-stakes tasks are the best automation candidates there are. Low-volume, high-stakes tasks are the worst, because the process fails rarely enough that nobody remembers how to check it manually when it does.

Combined loosely, the three give a shape rather than a formula: automate what happens often, stays the same, and is cheap to get wrong. Leave everything else alone until one of the numbers moves. If the arithmetic says yes, start from automations worth building first rather than whatever a colleague mentioned last.

The maintenance line everyone leaves out of the payback calculation

Every automation pitch, including ours, compares build time against time saved per run. That comparison is missing a term, and it is usually the largest one: the hours spent finding out the thing broke, fixing it, and re-verifying the backlog it silently mangled unnoticed.

We covered the specific failure modes in automation that survives a month — schema drift, auth expiry, rate limits, a colleague renaming a field — and the point here is not which one hits you, it is that one of them will, on a timescale measured in weeks rather than years. A realistic payback calculation is not "build time versus time saved." It is "build time plus expected maintenance time versus time saved," and that second term turns a lot of confident yes decisions into honest no ones.

Put a number on it. A workflow that takes ninety minutes to build and costs, say, thirty minutes a month to fix — optimistic for anything touching more than one external service — needs to save at least an hour a month to pay for itself in the first year, and considerably more to pay for the reliability layer that piece describes. Below that, the spreadsheet was never the compromise option. It was the correct one.

Work that looks automatable and is actually a decision wearing a process costume

The clearest false positives are judgement tasks described in the vocabulary of a process, which makes them sound mechanical when they are not.

Categorising support tickets by urgency looks like a rule: if the word "refund" appears, tag it high priority. It is actually triage, a skill that degrades the moment you encode it as keyword matching, because the tickets that matter most rarely use the expected words. Approving expense reports under a threshold looks like a number comparison. It is actually a check for whether the category, the vendor and the amount make sense together, which nobody has fully specified because until now a person did it by feel.

The tell is the size of the exception list. Adding a fourth, fifth and sixth "unless" means you are not building a rule engine — you are transcribing a decision someone already knows how to make into a format that cannot ask a follow-up question.

The middle ground nobody markets, because there is nothing to sell

Between "type it in every time" and "wire up a platform" there is a wide middle that gets skipped because no vendor has a product named after it.

A template with the formulas already built, so entering raw numbers produces the finished output. A checklist that turns a fifteen-step process into fifteen checkboxes, which does not save the time of doing the steps but reliably saves the time of remembering them and catches the one that got skipped. A keyboard shortcut for the five-line message you type identically forty times a week, which gets most of the speed of automation with none of the API surface that can break. None of these show up in a "best automation tools" roundup, because none are a product — they are habits, and habits do not go stale.

The choice between a proper database-backed workflow and staying in this middle ground turns on the same question we cover in choosing a no-code database: whether more than one person needs to see the same live data at once. If not, a spreadsheet usually beats the database for the same reason it beats the automation — fewer moving parts that can silently disagree with reality.

Two we deleted, and what replaced them

The first was a Make scenario that pulled weekly analytics numbers into a report every Monday. It worked for five months, then the analytics platform changed its API response shape and the scenario started writing zeroes into three of twelve fields — not an error, just wrong numbers in a report people trusted. We deleted it and replaced it with a ten-minute Friday habit: open the dashboard, copy twelve numbers into a sheet with the formulas already built. That is well under the maintenance time the automation was actually costing us, and the person doing it now notices immediately if a number looks wrong, because they are the one typing it.

The second was an n8n workflow reconciling two payment exports, built because doing it by hand felt tedious. It saved perhaps fifteen minutes a week, right up until a currency field arrived in a different format from one source and the workflow matched records that were not actually the same transaction. Nobody caught it for three weeks because the run history showed green. We replaced it with a spreadsheet formula that does the same match and highlights anything it cannot match confidently in red, so exceptions surface instead of disappearing into a silent success flag — about twelve minutes on the Friday it runs, close to what the automation saved, minus the three weeks it cost us the one time it was wrong.

Neither replacement is more sophisticated than the automation it replaced. Both are more honest about their own limits, which is the property that mattered.

Revisit the decision when the numbers actually move

None of this is an argument against automating anything, and treating it as one is the overcorrection to avoid. The three thresholds are meant to be re-checked, not set once. If volume genuinely doubles — the newsletter goes from eleven sign-ups a week to two hundred — the arithmetic that said no six months ago says yes now. If a second team starts depending on a spreadsheet you built for yourself, the stakes term has changed even though volume has not, and that is worth automating regardless of how little time it saves, because a silent wrong number now lands on someone who cannot see how the sheet works.

The useful discipline is neither "spreadsheets are better" nor "automate everything you can." It is noticing which number moved, and re-running the arithmetic — rather than defending the tool you already built or reaching for a new one out of habit.