Automation

Most of the time people say they want AI at work, what they want is this. The complaint is rarely that a task is intellectually hard; it is that it is repetitive, easy to forget and eats an hour a day that nobody costed. Automation addresses exactly that, and often without needing a model at all. Knowing the distinction saves money in both directions: it stops you paying for intelligence where a rule would do, and it stops you writing a hundred brittle rules for a job that genuinely needs judgement at one step.

Every automation has the same three parts. A trigger says when to run: a form submitted, a file added, a message received, a time of day. Actions say what to do. Conditions decide which actions apply to this particular case. Understanding those three is enough to read almost any automation anyone shows you, whatever platform it was built on.

The steps are fixed in advance, and that is the defining property. The same input produces the same output every time, which makes the behaviour predictable, testable and explainable to an auditor. It also means anything the designer did not anticipate is handled badly or not at all, so the quality of an automation is largely the quality of the thinking that went into its edge cases.

Systems are joined either by a purpose-built connector or by a general interface. A connector is the pre-built path between two named products, which is why platforms advertise how many they have. Where none exists for the pair you need, the same joining is done through a general programming interface, or by having the sending system push a message the moment something happens.

AI enters as one step among many rather than as a replacement for the pattern. The trigger, the routing and the recording stay ordinary automation; a model is called where the work needs language or judgement, classifying an incoming message, drafting a reply, extracting fields from a document. This hybrid is what most working systems look like, and it is more reliable than making everything a decision.

What happens when a step fails is the part people skip and then regret. A well-built automation retries where retrying is safe, records what it did, and tells somebody when it cannot proceed. A poorly built one fails silently, and the first sign is a customer asking why nobody replied for a fortnight. Failure handling is the difference between a demonstration and something you can rely on.

Running twice is a specific hazard worth designing against. Retries, duplicate triggers and a person pressing the button again can all cause the same case to be processed more than once, which is harmless for a draft and expensive for a payment or an email. The usual defence is recording an identifier for each case handled and skipping anything already seen.

The economics are unusual and worth stating plainly. Automation costs most of what it will ever cost before it runs at all, in the thinking and building, and almost nothing per run afterwards. That makes it a poor fit for tasks done twice and an excellent one for tasks done daily, and it means the honest question is not whether a task could be automated but whether you do it often enough to repay the build.

• Connect a form to a spreadsheet and a chat channel so a new submission lands in both without anyone copying anything, which is the trigger-and-actions pattern at its simplest.

  Zapier

• Build the same kind of flow on a self-hostable platform, where the steps run on infrastructure you control and the data does not pass through anyone else's servers.

  n8n

• Route incoming records through a multi-step scenario with branching conditions, which is where the conditions half of the pattern starts doing the real work.

  Make

• Trigger a sequence from a change to a customer record, so the automation reacts to the state of your data rather than to a clock.

  Attio

Do I need to be technical to build an automation?

Not for common cases. Platforms present triggers, actions and conditions as things you pick rather than code, and the standard patterns of moving records between systems are well covered. Technical help becomes worthwhile when you need an unusual connection, careful failure handling or something that must not run twice.

Where should I start?

With a task you do at least weekly, that follows the same shape each time, and whose failure would be obvious rather than silent. Copying data between two systems is the classic first automation because it is frequent, unambiguous and easy to check. Avoid starting with anything that sends money or messages to customers.

What happens when an automation breaks?

That depends entirely on how it was built. Good ones retry where it is safe, log every run and alert someone when they cannot proceed. Poor ones fail silently and are discovered weeks later. When comparing platforms, look at what they show you after a failure rather than at how many connectors they list.

Should the automation use AI at every step?

No. Use it where the work needs language or judgement, such as classifying a message or drafting a reply, and leave the routing, recording and moving to ordinary steps. Models are slower, dearer and less predictable than a rule, so they earn their place only where a rule genuinely cannot do the job.

Who should own an automation once it is built?

A named person in the team whose work it affects, rather than whoever built it. Automations break when the systems around them change, so ownership means watching for failures and knowing what the thing is for. An unowned automation quietly stops working and nobody notices until the work it was doing is missed.

How do I stop an automation running twice on the same thing?

Record an identifier for each case as it is handled and skip anything already seen. Retries, duplicate triggers and a person pressing the button again all cause repeats, which is harmless for a draft and expensive for a payment or a customer email. Most platforms provide a way to do this.

• Automation is a trigger, some actions and the conditions deciding which apply.
• Steps are fixed in advance, which buys predictability and costs adaptability.
• Most of it needs no AI at all; a model is worth adding only at steps needing language or judgement.
• Failure handling and running-twice protection are what separate a demonstration from something reliable.
• Cost is nearly all upfront, so frequency and stability decide whether a build repays itself.

• Zapier

  The trigger-and-actions pattern, with thousands of pre-built connections to pick from.

• Make

  Multi-step scenarios with branching, where the conditions half does the work.

• n8n

  Self-hostable, so the whole sequence can run on infrastructure you control.

• Attio

  Triggers from changes to customer records rather than from a clock.