Twelve automations worth building before any of the clever ones

The automation people build first is almost never the one that lasts. It is the impressive one — the multi-branch scenario that reads an inbox, classifies the message, drafts a reply and files it three systems deep — and it is usually dead within a fortnight, not because the platform failed but because a branch nobody tested caught an edge case and quietly did the wrong thing, and by the time anyone noticed, trust in the whole thing was gone. Meanwhile the plain one from the same week — new form submission copied into a sheet — is still running two years later, and nobody has thought about it since the day it was built.

We have watched this pattern often enough on this site to write it down as a rule: the automations that survive are not the clever ones, they are the low-stakes ones. This is a list of twelve we would build again, in roughly the order we would build them, chosen for exactly that property rather than for how much time any single one saves.

What earned a place on this list

Three criteria, applied strictly. Repetitive — it happens on a schedule or a trigger you did not have to think up, not a one-off task dressed up as a process. Rule-based — the correct output follows from the input without judgement, the distinction we went into at length in when a spreadsheet beats an automation. And harmless when it fires wrongly — if the trigger double-fires or the mapping drops a field, the worst outcome is a duplicate Slack message or a blank row, not a wrong invoice or a contact who gets deleted. That third criterion did more filtering than the other two combined. A lot of genuinely repetitive, genuinely rule-based tasks did not make the list because a bad run costs more than the good runs are worth.

None of these need the reliability layer we described in automation that survives a month — the heartbeat check, the shared-channel alert, the dedup key. That is the point of starting here. Build these first, watch a couple of them fail over a month, and you will know from direct experience which of your tools' failure modes to actually worry about before you build anything where the answer matters.

The twelve

Automation	Trigger	Weekly time saved	Failure mode
Form submission to spreadsheet row	New form response	5–10 min	Blank cell if a field is renamed upstream; visible immediately
New calendar event posted to a channel	Calendar event created	5 min	Duplicate post if the calendar sync double-fires
Invoice or subscription due date reminder	Days-before-date schedule	5 min	Reminder fires on the wrong day if a date field is text, not a date type
Starred or saved item weekly digest	Weekly schedule	10–15 min	Digest arrives empty if the source app changes its "starred" API field
New contact added to a mailing list	New CRM record	5 min	Contact added twice if the same lead form is submitted twice
File dropped in one folder copied to a backup location	New file in watched folder	10 min	Copy silently skipped if the file type filter is too narrow
Website or endpoint uptime check	Scheduled ping	0 min saved, pure insurance	False alarm on a slow response mistaken for downtime
New repository issue posted to a channel	New issue created	5 min	Duplicate post on issue edit if the trigger is not scoped to "created" only
Weekly numbers pulled into a running log	Weekly schedule	15–20 min	Wrong numbers written silently if the source dashboard changes its layout
Birthday or renewal-date reminder from a contact list	Daily schedule, date match	5 min	Missed reminder if the date format differs between source and check
New email attachment saved to cloud storage	New email matching a filter	10 min	Wrong file saved if the filter matches on subject line only
Social post cross-published to a second, low-stakes channel	New post published	5 min	Post arrives with broken formatting on the second platform

None of these is dramatic, and that is deliberate. The most valuable one on the list by time saved is the weekly numbers pull, and it is also the one with the worst failure mode — a wrong number that looks right — which is exactly why we flagged it with a caution rather than a recommendation: we replaced ours with a ten-minute Friday habit after it silently wrote zeroes into three fields for most of a month. It stays on the list because the underlying pattern is genuinely useful; the lesson is to add a sanity check — a cell that flags any number that dropped to zero week over week — the same day you build it, not after it breaks.

The uptime check earns its place with an unusual entry in the time-saved column: none, by design. Its job is not to save time, it is to be the second, independent thing that tells you when something else has stopped working, which is the exact gap we described in the piece on error handling in no-code automations. Build it early and point it at whatever automation on this list you would be most annoyed to lose without noticing.

What is worth building on a free plan

Nine of the twelve. The three that tend to outgrow a free tier are the uptime check, if your platform's free plan polls too infrequently to be useful — hourly is fine, but some free tiers throttle to a schedule too coarse to catch a short outage — the weekly numbers pull, if the source dashboard sits behind an integration only offered on a paid connector, and the file backup, if your provider's free operation count is low enough that a busy week of uploads runs you out of runs before the month is over. The other nine are single-trigger, single-action workflows with no branching logic, which is exactly the shape every major platform's free tier is built to support without complaint. If you are starting from nothing, there is no reason to pay for anything until you have outgrown the free allowance on one of these, and you will know you have because the platform will tell you, not because we are guessing at a number here.

Three we left off on purpose

Support ticket triage by keyword. It looks like a rule — if the message contains "refund," tag it urgent — and it is actually judgement wearing a process costume, the exact trap we described in the spreadsheet piece. The tickets that most need the urgent tag are the ones that do not use the expected words, so the automation is wrong precisely where it matters most.

Auto-replying to inbound email. The trigger is repetitive and the action is rule-based, but it fails the third criterion badly: a misfire here is not a blank cell, it is a reply sent to the wrong person, or the right person receiving the wrong canned answer to a message that actually needed a human. The cost of being wrong is far larger than the time the automation saves when it is right.

Full CRM-to-invoicing sync. Tempting because it looks like the newsletter-to-CRM example we opened with, just scaled up. But invoicing is the one place on this list where a duplicate or a dropped record is not an annoyance, it is a wrong bill sent to a real client. That is a low-volume, high-stakes task, the exact combination the spreadsheet piece flags as the worst candidate for automation, and it deserves the full reliability treatment or a human, not a spot on a starter list.

Where to actually start

Pick the form-submission-to-spreadsheet automation first, even if it is not the one that would save you the most time. It is the shortest to build, the easiest to verify by eye — open the sheet, count the rows — and the failure mode is the most forgiving one on the list. Get that one running for a week and watch what actually happens to it: does the trigger fire when you expect, does a field ever arrive empty, do you check it daily or forget it exists after day three. That week teaches you more about your specific platform's real behaviour than any comparison article will, ours included.

From there, add the uptime check or the digest, whichever failure would annoy you more to discover late. Add one automation every week or two rather than five in a weekend, because the limiting resource here is not build time, it is your attention across the automations you already have running — and an automation nobody is watching is not meaningfully different from no automation at all.