When to Automate, and When to Leave It Alone
The bias you should expect me to have
I build automations. Report pipelines that assemble themselves overnight, approval workflows that route a request to the right person without anyone forwarding an email, scheduled data pulls that land in a spreadsheet before the team is awake. I spent about ten years running finance and operations in higher education, much of it building systems like these, and that work is the service I now offer other teams. You would expect someone in that business to tell you to automate everything you can reach.
I am going to tell you something closer to the opposite. Most processes should not be automated yet, and a few should never be. An automation is not free once it is built. It carries a maintenance cost, a monitoring cost, and a risk cost, all three invisible right up until the moment they are not. Here is the framework I use before I write a single line of code.
This is general educational information, not formal accounting, tax, or legal advice. I work non-attest, alongside your CPA, not in place of them.
Do it by hand first, more than once
You cannot automate a process you cannot write down. That sounds obvious, but nearly every automation request I have seen starts with a process that exists only in someone's head, and the version in the head is always cleaner than the version in the world.
Doing the task manually a few times is how you find the difference. The first pass through a monthly report feels simple: export, filter, total, send. The third pass is where the exceptions live. One vendor is spelled two different ways in the source system. A department code changed midyear, so half the history now maps to a bucket that no longer exists. None of that shows up in the one-sentence version of the task. All of it shows up in the doing.
My rule, for myself and for any team I work with: nobody automates a report they have not personally produced by hand at least twice. This is not hazing. The manual reps are the requirements document. Every exception you hit by hand becomes a branch the automation handles correctly. Every exception you never hit becomes a silent wrong number six months from now.
The rule of three-ish
The second gate is recurrence. Automate a task after it has repeated enough times to prove its shape is stable. My threshold is roughly three: once is an event, twice might be coincidence, three times with the same inputs, steps, and output format means the shape has settled.
The "ish" matters because frequency changes the math. A daily data pull earns automation after its first stable week, because you will run it two hundred more times this year. A quarterly report needs a full year of history before you know its shape at all, because "quarterly" often turns out to mean "different every quarter." I once watched a team script a reporting task after its first run, only to find the second run needed different columns, a different recipient, and a different cutoff date. They did not automate a process. They automated a memory of one Tuesday.
If the shape is still moving, keep doing it by hand and keep notes. The notes are cheaper than the rewrite.
The carrying cost nobody prices in
Here is the part the productivity content skips: an automation is not something you finish. It is something you now own.
Automations break silently, and most often when an upstream format changes. The source system adds a column to its export and your script starts reading a price where a quantity used to be. The pipeline does not crash. It runs on schedule, produces a clean-looking file, and delivers a confident, wrong report. A person doing the same task by hand would have paused at the weird column and asked a question. The script does not pause. Pausing is the one thing you built it not to do.
That is why every automation I ship gets an alert wired in on day one: notify someone when the job fails, and again when the output drifts outside a sane range, a row count far from its usual band, a total of exactly zero, a file that is not dated today. The alert needs a named owner, one person whose job includes noticing it. An automation nobody monitors is worse than the manual step it replaced, because the manual step at least had a human looking at the data while it happened.
Price this honestly before you build. The script might take a day to write. Owning it costs an hour or two a quarter forever, plus one bad afternoon a year when something upstream moves. For a task that saves ten minutes a month, that trade can lose.
Some steps should stay manual on purpose
Not everything slow is broken. Some manual steps are controls wearing work clothes.
A person signing off on a payment is a feature, not friction. When I built an approval-workflow system for a research center, the tempting move was to auto-approve the small routine requests and save everyone the clicks. We did not, because the pause is the point. A human looking at a payment before it goes out is the cheapest fraud control there is. Script it away and you have removed a control, not a bottleneck. The right target for automation is everything around the decision: route the request to the correct approver, prefill the details, surface the history, make the yes or no take five seconds. Never automate the yes.
The same goes for judgment steps. Writing the variance narrative, deciding whether an odd transaction is an error or a real event, choosing what a leader needs to see this month. Automate the gathering. Keep the judging.
The question to ask before you build
One more filter, and it is the uncomfortable one: sometimes the build is procrastination that feels like progress. Building is interesting. The task it replaces is boring. It is easy to spend six hours scripting something that takes twenty minutes and runs twice a year, and to feel productive the entire time. If the process runs twice a year, the spreadsheet is fine. Work that rare does not earn a pipeline, it earns a checklist.
The diagnostic I run before any build: Does it recur monthly or more often? Has its shape held steady for about three cycles? Can I write every step and every exception down? Would anyone notice within a day if it silently broke? And is there a judgment call or an approval buried in the middle that needs to stay human? Five yeses, automate it and wire the alert. Anything less, leave it alone for now. Sorting a team's task list into those two piles is a big part of what I do in a Financial Operations Assessment, and the honest answer is that most of the list lands in the second pile.
The goal was never automation. The goal is a process you trust. Sometimes that is a script with an alarm on it. Sometimes it is a person, pausing on purpose.