Automations That Actually Save Time (And the Ones That Just Create Noise)

Which triggers are worth automating, and how to avoid notification spam, brittle chains and automations nobody remembers building.

Three months after the new system went live, the operations channel gets 140 automated messages a day. Nobody reads them. Last week a genuinely urgent alert about a failed shipment sat unread for two days, buried between “Record updated” and “Record updated.”

Automation is one of the main reasons to leave the spreadsheet behind. It is also the fastest way to make a good system unpleasant to live with. The difference comes down to choosing what to automate and building it so it keeps working.

What an automation actually is

Every automation has the same shape: when something happens, if certain conditions are true, do something. When a purchase request is submitted, if the amount is over a set limit, send it to the finance lead. When an order is marked shipped, email the customer the tracking number.

The “when” is the trigger. The “if” is the condition. The “do” is the action. Most no-code database platforms and internal app builders have this built in, and a separate automation platform can connect actions across different tools. If you can describe a task in that when-if-do sentence, you can probably automate it.

Whether you should is a different question.

Automations worth building

The best candidates share a few traits: they happen often, they follow a clear rule, and a human doing them by hand adds no judgement.

Handoffs between people. When a job moves from “Quoted” to “Approved,” assign it to the scheduling team and tell them. Handoffs are where work goes to die in a spreadsheet, because nobody notices the status changed.
Filling in the obvious. Set the due date to 14 days after creation. Copy the customer’s billing address onto a new invoice. Stamp who approved something and when.
Reminders on things that are stuck. If a request has sat in “Awaiting approval” for three working days, nudge the approver once. This is far more useful than notifying them on every change.
Moving data between systems. When a deal is won in your CRM, create a project record in your delivery tracker. Retyping data between tools is the purest form of wasted time.
Scheduled summaries. One message each morning listing today’s overdue items beats twenty messages spread across the day.

Do a quick sum before you build anything. Say a coordinator spends four minutes copying each won deal into the project tracker, and you win 60 deals a month. That is four hours a month, plus the typos. Worth automating. A task that happens twice a quarter and takes two minutes is not worth an automation you will have to maintain.

Anti-pattern one: notification spam

The most common failure is notifying people about everything because it’s easy. Every new record, every edit, every comment. The result is the 140-message channel, and people learn to ignore all of it, including the alerts that matter.

A useful rule: only notify someone if they need to do something, or if something has gone wrong. “A record was updated” fails both tests. “This request needs your approval” passes. “The overnight sync failed” passes.

Also be specific about who receives it. Notify the assigned person, not the whole team. If you find yourself sending a message to a group channel, ask who in that group is supposed to act on it.

Anti-pattern two: brittle chains

It starts innocently. Automation A creates a record, which triggers automation B to update a field, which triggers C to send an email, which triggers D to log it somewhere. Each step works. Then someone renames a field, step B silently fails, and C and D never run. Nobody notices for a fortnight.

Long chains are fragile because each link depends on the one before it, and failures rarely shout. Some ways to keep things sturdy:

Keep chains short. If one trigger can do three actions directly, that’s better than three automations triggering each other.
Make failures loud. Most tools can send an alert when an automation errors. Turn that on and send it to a named person.
Avoid loops. An automation that updates a record, which triggers itself again, can run hundreds of times in a minute. Add a condition so it only runs once.
Don’t build on fields people edit casually. If your automation depends on a free-text field matching exactly, someone will eventually type it differently.

Anti-pattern three: forgotten automations

Eighteen months in, there are 47 automations. Nine were built by someone who has since left. Four send emails to an address that no longer exists. One is still creating records in a table nobody uses.

Forgotten automations are the new hidden tab, the thing nobody dares delete. Prevent them with a simple register: a list, kept somewhere everyone can find, with one line per automation.

Name	What it does	Owner	Built	Last reviewed
Won deal to project	Creates project record when CRM deal is won	Dana	March	September
Stale approval nudge	Reminds approver after 3 working days	Leo	April	September

Give each automation a plain descriptive name in the tool itself, too. “Automation 12” helps nobody. Review the register twice a year and switch off anything nobody can explain.

Test before you trust

Before turning on any automation that sends messages to customers or changes many records, run it against a test record first. Check the result with your own eyes. Then watch the first week of real runs. Most problems show up in the first ten runs, and they are much cheaper to fix before they have touched three hundred records.

Where to start this week

List the handoffs in one process and pick the single most frequently missed one. Automate that first.
Audit your current notifications. For each one, ask “does the recipient need to act?” and switch off the ones that fail.
Start an automation register with owner and purpose for everything that already exists.
Turn on failure alerts and route them to a named person, not a shared channel.