How many times have you automated something you never ended up using? For me, the last time — 8 hours on a bot. Status — abandoned.
Automation Is a Time Investment
Automation should save time. The logic is simple: spend time now to save it later. But does this always make sense?
Essentially, automation is an investment with ROI. Spend 30 hours on a system that saves an hour per day — payback in a month. That's good.
Spend 8 hours on a bot that saves a minute per day — payback in 8 months. That's questionable.
The formula is simple:
Payback = Time to automate / Savings per use
The problem is, we often don't calculate this before starting. We get excited about technology, the process, the possibilities — and spend hours on something that will never pay back.
How to determine the payback threshold? Depends on how stable the process is. If the process will live a year, then a month payback sounds good. Six months — already doubtful. Anything over a year — doesn't work.
My Case Analysis: 8 Hours on a Bot
What I built: a Telegram bot on n8n. You send audio → Whisper transcribes → AI agent decides action → saves to note in Obsidian.
Technically, it was a fully working system: n8n with Telegram Node, authorization via chat ID, Whisper for voice-to-text transcription, ChatGPT Assistant with tools for action determination, Obsidian integration for note creation.
The first version worked through Git — pulled the repository, created a note, and committed back. The second version required a home hub for direct Obsidian integration. I spent a ton of time on infrastructure.
ROI calculation: 8 hours to create — that's 480 minutes. Time savings — from 2 minutes to 1 minute per note. Payback: 480 divided by 1 = 480 notes. With my two notes per day, that's 240 days, or 8 months.
Result: not using it. Hub is off. Process changed.
What went wrong? I didn't calculate ROI before starting. If I had — I would've killed this idea immediately. 8 months payback for an experimental process is unreasonable.
What Can Be Automated
You can only automate a stable process.
A stable process is one that has repeated at least 10 times and will repeat 10 more. It has clear steps, predictable results, no constant changes.
If the process is unstable, you're freezing chaos. With each new use, the condition changes, and automation becomes invalid.
Examples? Production deployment via CI/CD pipeline — that's a stable process. Data backup, calendar synchronization, invoice generation — also stable. They repeat regularly and don't change.
But if you're still experimenting with the approach, steps change every time, or you're not sure you'll be doing this in a month — that's an unstable process. Too early to automate.
Exception: monkey job. Very routine work — transferring data from one table to another. If you can quickly automate it and it pays back in at least 10 executions — worth it.
Nothing stays stable forever. Any process will eventually change. So look at the process "lifetime" — like customer lifetime in SaaS. Payback must fit within this term.
When Automation Makes Sense
Three situations when automation makes sense.
First — high frequency. You do it daily or multiple times a day. Even if savings are small — 5 minutes, but daily — that's significant. Plus, context switching costs more than the action itself.
Second — substantial savings. The process takes 30+ minutes and can be reduced to 5. Here, the ROI will be fast even at low frequency. Even if you do it once a week, the savings are noticeable.
Third — errors are costly. Critical business processes. For example, I wrote about how we almost lost a customer due to a payment automation failure — the customer paid, but the system didn't register the transaction. They should immediately see access and receive an invoice. If something doesn't work, you lose a customer. Here, automation isn't about time savings, but about reliability.
Conclusion
Before starting any automation:
1. Calculate ROI. How much time will you spend creating it? How much will you save per use? When will it pay back?
2. Make sure the process is stable. Has it repeated at least 10 times? Are steps clear? Will it live at least six months?
3. Create the process manually first. Write it on paper, go through it a few times. Only then automate.
Don't automate for the sake of automation. Look for automations with maximum ROI.
Sometimes it's better to do something manually 100 times than spend 20 hours on a system that will pay back in a year. Or never.
Sometimes the best automation is the decision not to automate.
