The boring automation that prints time

What "boring automation" means

A boring automation takes one recurring decision off your plate. Not a task: a decision. Tasks are easy to automate and usually were automated years ago. Decisions are the things that still pull a person into the loop: is this email urgent, who should handle this ticket, what did I miss in that thread, did that lead ever reply. Each one is small. Each one happens every day. Together they are the reason your afternoon disappears.

The automation that handles them is not impressive to look at. It reads something, decides something, writes something, and tells one person. It does not have a chat interface. Nobody puts it in a launch video. It is also, in our experience, the automation with the best return on effort by a wide margin, because the return compounds daily and the risk is near zero.

Four patterns that cover most of it

Triage. Something arrives; decide what it is and how urgent. Inbox mail, support tickets, pull requests, alerts, form submissions. The output is a label and a priority. A person still handles the item, but they open the right one first and ignore the ones that do not matter. We run this on inbound mail and on the alert stream from our own monitoring, and the value is not that the agent is smarter than us. It is that it is awake at six in the morning.

Routing. Something arrives; decide who owns it and put it in front of them. The difference from triage is that the output is an assignment, not a label. Leads to the right rep, bugs to the right repo, questions to the person who answered the last one like it. Routing eliminates the worst kind of latency: the hours a thing sits in a shared queue while everyone assumes someone else has it.

Summarization. Something long exists; produce the short version a person actually needs. The overnight thread, the week's commits, the forty-message channel, the three documents another team sent over. Done well, this is the automation people notice least and would miss most. Our own morning briefing is this pattern: what changed across every project since yesterday, in one page, before the first meeting.

Follow-up. Something was supposed to happen; check whether it did, and nudge if not. The reply that never came, the invoice that is overdue, the pull request with an approval and no merge, the ticket that has been "waiting on customer" for nine days. Follow-up is the pattern most often skipped because it feels like nagging. It is also the one that directly recovers revenue and closes loops that would otherwise quietly die.

The hidden ROI

If you measure boring automation by minutes saved per item, it looks modest. Thirty seconds to triage an email. A minute to route a ticket. The real return is in two things that do not show up on that ledger.

Fewer context switches. Every small decision costs more than the decision itself; it costs the attention it takes to stop what you were doing, load the context, decide, and get back. Removing twenty of those from a day does not save twenty minutes. It saves the hour of focus that the twenty interruptions would have fragmented.

Fewer dropped balls. The lead that never got a reply, the renewal nobody chased, the bug that sat unassigned for a week. None of those cost time. They cost money and trust, and they are invisible until they are expensive. A follow-up automation does not need to be smart to prevent them. It needs to be relentless, and relentless is what software is for.

The stack

Four pieces, all of which you probably already have.

A system of record. Notion, a spreadsheet, a database table. Somewhere the automation reads its inputs and writes its results, that a person can also open and edit. The automation must write its status back here. More on why below.

A notification channel. Slack, usually. The automation tells one person or one channel what it did and what it could not decide. Not a dashboard nobody opens; a message that arrives where people already are.

Email, as both an input and an output. Most of the recurring decisions in a small business arrive by email and many of the follow-ups leave by it.

One worker. A single scheduled process that runs the loop: read, decide, write, notify. A cron job, a cloud function, a small script on a server you already run. Not a platform. One worker per automation, with a log.

That is the whole thing. The language model sits inside the "decide" step and nowhere else. Everything around it is plumbing you have built before.

Where it goes wrong

We have shipped enough of these to have a short list.

Not writing status back. Our first content pipeline read "ready" entries from a calendar, published them, and crashed before marking them published. The next run read the same entries and published them again. The writeback step is not bookkeeping. It is what makes the automation safe to run twice, and an automation that is not safe to run twice will eventually run twice.

Starting with write access. A triage automation that labels is harmless. A triage automation that archives is not, until it has proven itself. Run every new automation in a read-and-recommend mode for a week before it is allowed to change anything. The recommendations are the test suite.

Notifying too much. An automation that posts every action to a channel trains people to mute the channel. Post exceptions and summaries: what it could not decide, and a daily count of what it did. Silence should mean "handled," not "broken," which means the automation also has to report its own failures loudly.

No owner. Automations drift. Inputs change shape, APIs rotate keys, the thing it was routing to gets renamed. Someone has to own each one, and the ownership has to include a recurring look at whether it is still right. Ten minutes a week per automation is enough.

Where to start

Pick the decision you make first every morning. Not the hardest one; the first one. For most people it is some version of "what came in overnight and what do I do about it." Build the triage for that, read-only, notifying one person, and run it for a week. If you still open the raw inbox first on day eight, the automation is not good enough yet. If you stop, you have your first one, and the second is easier.

If you would rather we found the first one for you, tell us what your week looks like. The recurring decision is usually obvious from the outside.