Two questions do most of the deciding on whether a repetitive task is worth automating, and neither one is "can this be automated." Nearly anything can, given enough patience. The questions that matter are how often the task actually runs, and what it costs you on the day it breaks without telling anyone.
This is for knowledge workers who already have a couple of automations running, or a browser tab full of half-built ones, and want a rule for which to keep building.
The verdict
Automate the boring copy-paste between two systems you already trust. Leave anything that needs judgment as a reminder, not a trigger.
A trigger fires on its own when some event happens — a form is submitted, a file lands in a folder — and does the work without a person in the loop. A reminder puts the task in front of you and lets you decide. The middle option is easy to skip past, and it deserves more consideration than it usually gets.
Question 1: how often does it actually run
An automation charges you twice. Once to build it, and then quietly forever, because it is now a thing you maintain. Connections expire. Someone renames a field. A vendor deprecates an API version — the interface one app uses to talk to another. None of that announces itself.
A handoff you perform several times a day pays that maintenance back, because you feel the benefit continuously and you notice breakage the same day. A handoff that comes around a few times a year does not. By the time it runs again, you have forgotten how you built it, and you are debugging a thing you no longer understand under the deadline that made you build it.
Be honest about frequency, and count real runs rather than the ones you imagine. A task that felt constant last month may have run a handful of times.
Question 2: what does a silent failure cost
A loud failure is fine. The automation errors, you see the error, you fix it or you do the task by hand. A failure you notice immediately is usually cheap to absorb, because you can still do the task by hand that day.
A silent failure is the expensive one: the automation reports success and does nothing, or does half of it. Rows stop arriving in the tracker and the tracker still looks normal because it was never full. The cost is not the one missed run. It is the whole interval between the break and the moment you notice — every decision made from data that stopped updating.
So ask: if this stopped working today and said nothing, when would I find out, and what would be wrong by then?
Many times a day
Cost of a silent failure. Low, and you'd notice quickly
What to do. Build it. This is where automation pays.
Many times a day
Cost of a silent failure. High, or invisible for a long stretch
What to do. Build it, but build the alarm first — the automation is not done until failure is visible.
A few times a year
Cost of a silent failure. Low
What to do. Skip it. A checklist has less to maintain than a workflow, and nothing to break silently.
A few times a year
Cost of a silent failure. High
What to do. Do it by hand from a written procedure. This quadrant is where automation can quietly cost more than it saves.
That last row is the counterintuitive one. Rare and important feels like the thing to protect with automation. It is the hardest quadrant to justify: you get little practice, the tooling has had months to drift, and the consequences land where they hurt most.
Three handoffs that usually qualify
Moving the same field between two systems, with no interpretation. Form response into a tracker row. New client in the CRM into a folder structure. Ticket closed in one tool, status updated in the other. If you can describe the rule without using the word "usually," it is a good candidate — you are not automating a decision, you are automating typing.
Filing by a rule you can say out loud. Receipts into a folder by month. Attachments out of email and into the project directory. The rule has to be stateable: "PDFs from this sender go here." If the rule turns into "unless it's the one from the accountant, then it goes elsewhere," you have found a judgment call wearing a filing costume.
Creating the same scaffold every time. The project checklist, the recurring agenda, the folder tree with the same five subfolders. Generation tends to fail more visibly than interpretation: a scaffold that comes out wrong is usually apparent when you open it — provided you do open it.
What these three share: the inputs are already structured, both systems are ones you use daily, and a mistake is visible rather than buried.
Two that usually don't
Anything that decides on your behalf. Auto-replies, auto-assigning work, auto-categorizing by keyword. These fail in a way that is worse than not running: they produce a confident wrong answer, and downstream everything treats it as a real one. A misfiled attachment is an annoyance. A misrouted request that someone assumes was handled is a problem with a delay fuse on it. Make these a reminder — surface the item, suggest the category, let a person confirm.
The rare, high-stakes run. Quarterly invoicing, annual renewals, offboarding someone. Low frequency means the automation gets no practice and no early warning; high stakes mean the failure is expensive. A written procedure you follow by hand beats a workflow you have not watched run since the last quarter.
If you build it, make it fail loudly
The build is not finished when the happy path works.
- Write results where you already look. An automation that logs to a dashboard you open twice a year is an automation with no alarm on it.
- Make it safe to run twice. Idempotent means running it a second time leaves you in the same state as running it once — no duplicate rows, no double emails. This is what lets you re-run after a failure without cleaning up first.
- Give it an owner. If nobody's name is on it, the first breakage becomes permanent and the team routes around it by hand.
- Prefer a visible artifact. Something that creates a row, a file, or a message can be checked. Something that only edits an existing field can rot unnoticed.
Who should skip this
If your repetitive work is genuinely varied — different clients, different formats, different exceptions each time — you are looking at a documentation problem, not an automation problem. Write the procedure down and stop there.
If the two systems don't talk to each other without a fragile workaround, the workaround is the whole project, and it will break on someone else's release schedule. Do it by hand until one of the vendors makes it easy.
And if you enjoy the task, or it is the five minutes where you actually look at your own data, keep it. Noticing that the numbers look odd is work, even when it does not feel like it.
The next action
Over one working week, keep a running note of each time you copy something from one app into another by hand. At the end, look for the line that appears most in that note, and check it against the second question: if it broke silently, would you know that day? Automate that one. For the rest, a reminder or a checklist is usually enough until the frequency changes.