Most automation advice focuses on tools. But the harder question — and the one that determines whether an automation actually saves you time — is which task to automate first. Pick the wrong one and you've built something nobody uses. Pick the right one and the payoff is immediate and obvious.

After 13 years working in operations before moving into software, I've seen both outcomes. Here's the framework I use.

The four things worth automating

Not every repetitive task is a good automation target. The best candidates share most of these traits:

  1. It happens on a schedule or a trigger. Daily, weekly, or "every time X happens" — regularity makes automation straightforward. One-off tasks rarely justify the build time.
  2. The input is consistent. If the task always starts with the same type of data — a form submission, a CSV, an email in a specific format — automation is clean. If the input varies wildly, the edge cases will eat you.
  3. The output is well-defined. A report, a reply, a logged entry, a notification. Vague outputs produce vague automations.
  4. Someone is currently doing it manually. If it takes a real person 20–60 minutes per cycle, that's your target. That time can usually be cut to near zero.

Score your candidates

When evaluating a task, I mentally score it on two axes:

Time saved per cycle

How long does it take a human right now? 5 minutes is low priority. 2 hours is urgent.

Frequency

Daily beats weekly beats monthly. Multiply time × frequency to get the real annual cost.

Error risk

Manual data entry, copy-paste tasks, and anything going into a customer-facing system carry high error risk. Automation eliminates it.

Build complexity

Simpler is better, especially for a first project. A 2-hour build that saves 30 min/week pays off in a month.

The sweet spot: high frequency + meaningful time per cycle + low build complexity. That combination usually produces the fastest visible return.

The tasks I see most often

Across restaurants, retail, property management, and service businesses, the same categories keep coming up:

Why automations fail (and how to avoid it)

Most failed automations have one of three problems:

1. Too much ambition in v1. The goal was to automate the entire workflow instead of one step. Build the smallest thing that saves real time, get it running reliably, then extend it.

2. The output doesn't get used. A daily report that nobody reads is a waste. Before building, confirm where the output will go and who will act on it. If the answer is unclear, the task might not be worth automating.

3. No error handling. Manual tasks fail gracefully — a human notices something is wrong and deals with it. Automations fail silently unless you build in logging and alerts. Even a simple email or log file that records failures is enough to make an automation maintainable long-term.

The one-week rule: if an automation doesn't save someone visible time within the first week, something is wrong — either the task wasn't the right target, or the output isn't being used. Fix it before moving on to the next thing.

Where to start

Ask whoever runs daily operations one question: "What's the task you dread most because of how long it takes?"

That answer is usually your best starting point. It's concrete, it has a clear owner, and there's immediate motivation to see it automated. Build that first. Everything else gets easier once there's a working example in the room.


If you have a workflow you're trying to automate and aren't sure where to start, get in touch. A 20-minute conversation usually clarifies the right first step.

All posts
← Back to Notes