The automation you should build first

Every automation conversation we have starts the same way: someone describes an elaborate multi-step workflow they want built, and it turns out to be the third or fourth most valuable thing they could automate. The most valuable one is almost always something boring they have stopped noticing, because they have been doing it manually for so long it no longer registers as a task — it just registers as "part of the job."

The test: twice a week, ten minutes

The automation worth building first is whatever passes this test: something a person does at least twice a week, that takes at least ten minutes each time, and produces the same kind of output every time. That threshold is not arbitrary — below it, the automation usually costs more to build and maintain than the time it saves over a year. Above it, the maths flips fast.

Do the arithmetic before building anything: ten minutes, twice a week, is roughly seventeen hours a year. At even a modest hourly value for that person's time, that is real money — and it is recurring, not one-off, which most cost comparisons forget to account for.

Where it actually hides

The highest-value candidates are rarely the tasks anyone complains about. Complaints go to the annoying-but-rare problems. The expensive tasks are the ones nobody mentions because they have become invisible through repetition:

• Re-typing the same data into a second system. An order lands in one place and gets manually copied into inventory, or accounting, or a spreadsheet nobody else can see.
• Answering the same question by hand, every time. "Where is my order" or "what is the status of my project" answered individually instead of surfaced automatically.
• Manually checking whether something needs attention. Logging into three dashboards each morning to see if anything broke overnight, instead of being told the moment it does.
• Formatting the same report from the same raw data. A weekly or monthly number-crunch that follows an identical process every single time.

The trap: automating a bad process

Automation makes a good process faster and a bad process fail faster and more confusingly. Before automating anything, write down the current process honestly, including the workaround steps nobody talks about — the manual double-check someone does because the system has been wrong before, the spreadsheet that exists because nobody trusts the "real" source of data. Automating around that workaround without understanding why it exists is how you end up with an automation nobody trusts either.

Build it to fail loudly

The single biggest difference between an automation that earns trust and one that gets quietly abandoned is what happens when it breaks. A workflow that fails silently — stops syncing, stops sending, stops updating — and tells nobody will eventually cost more than the manual process it replaced, because the failure goes unnoticed until a customer points it out. Every automation we build logs what it did and raises a real alert on failure, on the first day, not as an afterthought once something has already gone wrong.

Start with one, not five

The businesses that get real value from automation build one workflow, watch it run for a few weeks, fix what it revealed about the underlying process, and then move to the next candidate. The ones that struggle usually tried to automate five things simultaneously, none of which got the scrutiny needed to actually work. Pick the one that passes the twice-a-week, ten-minute test, and start there.