When does a spreadsheet beat an automation?

Should I automate this or just keep it in a spreadsheet?

Keep it in a spreadsheet until the process stops changing. Automation pays off when a job is stable, frequent and boring. If you are still arguing about the steps, a spreadsheet is faster to change, cheaper to run and honest about the fact that a human is in the loop.

This is the question I get asked most often, usually in a slightly embarrassed tone, as if using a spreadsheet in 2026 is an admission of failure. It is not. Some of the best run small businesses I have worked with move a surprising amount of work through Google Sheets on purpose.

What follows is the test I actually apply before I quote anyone for automation work, and the reasons I have talked people out of building things they wanted to pay me for.

What does an automation actually cost you?

More than the build. Every automation carries a running bill, a maintenance bill and an attention bill. The running bill is metered by the platform, the maintenance bill arrives whenever an upstream tool changes, and the attention bill is the time you spend checking that it still works.

The running bill is the easiest one to reason about because vendors document it. Zapier's own help documentation defines a task as any successful action that runs in Zapier, and says only successful actions count toward your task usage. That sounds simple until you count the actions in a workflow you were picturing as one step.

Some steps also cost more than one. Zapier's documentation states that in Zapier Lead Router each successful lead routed counts as five tasks, and that in Zapier MCP each successful tool call counts as two tasks, with failed tool calls not counting. Even a setting can change the bill. Zapier says a search action set to proceed if nothing is found uses one task, while the same search set not to proceed uses none.

I am not picking on Zapier here. I like Zapier, and I run client work on it. I am using it because it publishes this clearly. The point is that the unit you are billed in is rarely the unit you think in, and your mental model of cost will be wrong until you go and read the vendor's own page. Check the current rates on the vendor's documentation before you design anything, because these details change. I worked through the whole cost picture, including the parts that never appear on an invoice, in what a small automation stack actually costs to run.

Why is volume the wrong reason to automate?

Because volume tells you the job is tiring, not that it is ready. A process you run two hundred times a month but redefine every fortnight will break two hundred times a month. Stability is the real signal. Volume just tells you how much the instability will hurt.

I have watched this play out on lead handling more than once. A founder is drowning in form submissions, so they ask for routing. Then they change how they qualify leads, then they add a second product, then sales asks for a different owner on enterprise enquiries. Each change is reasonable. Together they mean the routing logic was never true for more than three weeks.

The spreadsheet version of that job is ugly and it works. Someone eyeballs the sheet each morning and assigns owners. It costs half an hour a day and zero rework. When the qualification rules finally settle, the automation you build will be right the first time, because the sheet has been quietly documenting the real rules the whole time.

What makes a spreadsheet a genuinely good answer?

A spreadsheet is a good answer when the process needs judgement, changes often, involves fewer than a few dozen items a day, or has no clear owner yet. It is also the fastest way to discover what the process really is, because anyone can see the whole thing at once.

That last property is underrated. An automation hides its logic inside a tool that most of your team cannot open. A sheet shows every row, every exception and every place someone typed a note in the wrong column. That visibility is how you learn which exceptions are rare enough to ignore and which ones are the actual business.

Spreadsheets are also honest about failure. When a formula breaks, someone sees a wall of errors. When an automation breaks quietly, nobody sees anything, and you find out three weeks later when a customer asks why nobody called them back. I have written before about what tends to break first as an automation scales, and silence is almost always part of the story.

When does a spreadsheet stop being enough?

When the cost of a mistake exceeds the cost of building properly, when the same data has to live in two systems, or when the person doing the manual step becomes a single point of failure. Those three thresholds are worth more than any volume number.

The two systems case is the clearest. The moment a record has to exist accurately in both a spreadsheet and a CRM, you have created a reconciliation job that humans lose at. That is genuinely what sync tooling is for, and it is where I stop arguing and start building.

For Ajust I built exactly that kind of system on Airtable with WhaleSync doing the syncing, and it has carried real volume: more than 25,000 cases delivered, more than 400,000 people helped and more than 50,000 hours saved. That workload was never going to survive in a sheet. It had a stable shape, high volume, and a cost of error measured in people not getting help.

For Kismet Health the job was CRM plumbing into HubSpot through Zapier. Again the process was settled before I touched it. That is the pattern in both cases, and it is the pattern I look for.

How do you test the boundary without committing?

Run the process by hand for four weeks and write down every exception. If the exception list stops growing, automate. If it is still growing, you have just saved yourself an expensive rebuild.

This is a cheap experiment and almost nobody runs it. Four weeks of notes in a column called "weird cases" will tell you more about whether a workflow is automatable than any amount of diagramming. It also gives you the specification for free, because the exceptions become your branching logic.

A halfway option exists too. Automate the mechanical half and leave the judgement half manual. Let a workflow gather, format and stage the data, then have a human approve it. That keeps the tedious part automated and the risky part accountable, and it is how I build most first versions.

What does the hidden maintenance bill look like?

It looks like nothing for months, then a morning gone. Upstream tools rename fields, APIs deprecate endpoints, someone changes a form, a plan limit shifts. None of that shows up in your build estimate, and all of it lands on whoever owns the automation.

I price fixed fee, most projects between one thousand and ten thousand dollars, which means I carry the consequences of my own design decisions rather than billing hours against them. That structure changed how I build. Anything fragile is my problem later, so I now ask a blunt question during scoping: if this breaks in six months, who notices, and how?

If the honest answer is "nobody", the automation should not exist yet. Either the job is not important enough to automate, or it is important enough that it needs monitoring you have not budgeted for. Both answers point back to the spreadsheet for now.

Which jobs should almost never be automated?

Anything where a wrong output is worse than no output. Pricing decisions, anything touching money owed, anything that emails a customer something irreversible, and anything where the rules are really a person's judgement that nobody has written down.

The judgement case is the sneaky one. A senior person often cannot articulate the rule they are applying, so what gets automated is a simplified version that is right most of the time. Most of the time is fine for sorting inbound email and catastrophic for deciding who gets a refund.

There is a related trap with AI in the loop. An automation that used to fail loudly starts producing plausible output instead, which is much harder to spot. I have written about where a simple automation beats an AI agent, and the honest summary is that determinism is a feature when the output matters.

What is my own rule for this?

Automate when a process is stable for a month, costs more than an hour a week, and has a named owner who would notice it break. If any of those three is missing, it stays manual, and I say so even when building it would have been billable.

Across more than 70 projects for more than 25 clients over more than six years, the automations that survived all had those three properties on day one. The ones that got quietly switched off were usually built for a process that was still being invented.

My own practice follows the same rule, and the split is not glamorous. Plenty of what I do weekly is still manual on purpose, which I have described in more detail in what I automate versus what I still do by hand.

What should you do next?

Pick the process you most want to automate and do nothing to it for four weeks except write down the exceptions. Then look at the list. If it is short and stable, build. If it is long and growing, you have found a process problem that no amount of tooling will fix.

While you wait, go and read the pricing and usage documentation for whichever platform you were planning to use, and count the actual steps in the workflow you imagined. Most people are surprised, and it is much cheaper to be surprised before the build than after.

If you want a second opinion on whether something is ready to automate, or you want someone to tell you honestly that it is not, reach out. I would rather talk you out of a build than deliver one you switch off in March.