Automating the boring parts, without code

Automation sounds like a developer word. The thing it describes is ordinary: something happens, and something else happens as a result, without you being the connection between them.

A form response arrives, and a row appears in a spreadsheet. A meeting ends, and the notes land in a shared folder. A customer signs, and three people get told.

You have almost certainly used one already. An out-of-office reply is automation.

The two words you need

Trigger: the thing that starts it. A new email with a certain label. A form submission. A specific time on a Monday.

Action: what happens next. Create the row. Send the message. File the document.

Every no-code automation tool is a way of connecting triggers to actions without writing anything. Zapier and Make are the general-purpose ones. Most tools you already pay for have simpler versions built in, and those are usually where to start.

Start inside tools you already have

Before signing up for anything new, check what is already sitting there unused:

• Email filters and rules. Twenty minutes on filters in Gmail or Outlook removes more daily friction than most paid automation. Auto-labelling and skipping the inbox for recurring reports is the highest-return automation available to almost everyone.
• Calendar defaults. Default meeting length, buffers between calls, a working-hours window that stops evening bookings.
• Templates and snippets. If you type something more than twice a week, it should be a saved snippet.
• Recurring tasks. Anything you re-create by hand every month.

None of that needs a new tool or a new bill.

The three jobs worth automating first

1. Moving information between two places you already use. Form to spreadsheet, spreadsheet to task list, meeting to notes folder. Highest value, lowest risk, because a mistake means a duplicate row rather than a wrong message to a customer.

2. Reminding people, including yourself. A weekly nudge for the report nobody remembers. A notification when a deal has not moved in fourteen days. Automation is very good at remembering, which is exactly the thing humans are worst at.

3. First drafts of repeated writing. A template that fills itself with the details you already captured, and you edit before it goes anywhere. Note the last part. Anything that writes and sends without a human looking is where automation goes wrong in public.

The maths, honestly

The usual pitch is that a task taking five minutes a day is twenty hours a year. True, and incomplete, because it ignores three costs: building it, fixing it when a tool changes, and being the only person who understands it.

My rule after several disappointing attempts: automate it when it is frequent, identical every time, and low-stakes if it breaks. Fail any one of those and do it by hand.

• Frequent but different every time: not automatable, you will spend longer handling exceptions.
• Identical but rare: not worth the build.
• Frequent, identical, and high-stakes: automate the preparation, keep a person on the send.

Where it goes wrong

Silent failure. The automation stops and nothing tells you. Weeks later you find the spreadsheet has been empty since March. Anything that matters needs a check on it, even a monthly glance.

The invisible dependency. You leave the team and nobody knows the Monday report is a machine, or how to fix it. Write down what it does and where it lives, in one paragraph, somewhere a colleague would find it.

Automating a bad process. A slow approval chain running automatically is a faster bad process. Fix the process first, then remove yourself from it.

A first automation worth building this week

Take the report or update you assemble by hand every week. Do not automate the writing. Automate the gathering: get the numbers, links or responses to collect themselves in one place, on a schedule, so that when you sit down to write, the ingredients are already there.

That is the version that keeps paying. The judgement stays yours, and the fetching stops being your job.