When a plain rule beats a model

The question to ask of any repetitive task

Does this need judgement, or does it need doing?

If the same thing happens every time (an invoice raised when a job is marked complete, a reminder 24 hours before an appointment, a backup at midnight, a file copied when a form is submitted) that is a rule. Rules are cheap, instant, deterministic, auditable, and they cannot invent anything.

Putting a model in a rule’s place adds cost, latency, variation and a new failure mode, in exchange for nothing. This is the single most common way small businesses waste money on AI, and it is usually because the automation was sold as AI.

The tools, with honest pricing

Zapier: the easiest, connects to nearly everything, free tier is small and paid tiers become expensive at volume.

Make: similar, generally cheaper per operation, slightly steeper to learn.

n8n: open source and free if you host it yourself, roughly USD 5 a month on a small server. More work to set up, no per-task charge, and your data stays where you put it.

Google Apps Script: free, built into Google Workspace, runs on a schedule. If your business lives in Sheets and Gmail, this does an enormous amount for nothing.

Whatever your software already does. Most accounting, booking and shop platforms have automation rules built in and switched off. Check before adding a vendor; this is the third time this course has said so, and it remains the most frequently skipped step.

A worked division

A joinery workshop’s enquiry-to-invoice flow:

• Enquiry arrives → rule: create a record, notify the owner.
• Classify the enquiry → model: this is meaning, and rules cannot do it.
• Quote request → rule: create a quote from the template.
• Draft the covering note → model: varying text.
• Quote accepted → rule: create the job, order materials, diary the start date.
• Job complete → rule: raise the invoice, send it, schedule reminders.
• Payment late → rule to detect, model to draft the chaser at the right firmness.
• Customer complains → model to draft, person to send.

Two model steps, six rule steps. That is a healthy ratio, and it is roughly what a working small-business automation looks like once the enthusiasm has settled.

Where an AI step belongs in a workflow

Three places, and they share a shape: the input varies, the output is checked, and nothing irreversible happens automatically.

Classification: routing by meaning. Extraction: pulling fields out of a document into structured data. Drafting: producing text a person will read before it goes.

If an AI step in your workflow does something else (decides, sends, pays, publishes) look at it again. That is where module two’s warning about hostile input becomes concrete, because an automated path that acts is a path somebody else’s text can drive.

Build it so it tells you when it breaks

Automations fail silently, which is their characteristic failure. A vendor changes an interface, a token expires, a folder is renamed, and the reminders stop going out. Nobody notices for three weeks, because nothing produces an error where a person would see it.

Two cheap defences. Have the automation send you a weekly summary of what it did: a line saying “47 reminders sent” is enough to notice when it says nothing. And check anything money-related monthly against the source system.

The order of operations

Do the rules first. They are cheaper, they work reliably, and they usually deliver more time back than the model steps do.

Then add one model step, and only where the input varies. Businesses that do it the other way round end up with an expensive, occasionally creative system doing a job that a scheduled message did perfectly.

Start with one, and write down what it does

The failure pattern with automation tools is building six flows in an enthusiastic weekend, none documented, and discovering four months later that nobody knows what happens when a form is submitted.

One automation. Write down in plain words what triggers it, what it does, and what to check if it looks wrong. Keep that beside the prompt library from module two: same file, same discipline.

Then live with it for a fortnight before building the second. The side effects of the first will teach you what the second should be, and they are never the ones you predicted.

Know how to turn it off

Before you switch anything on, know how to switch it off, and make sure somebody else knows too.

The bad afternoon in automation is the loop: a rule that creates a record that triggers a rule that creates a record. It is easy to build accidentally, it sends four hundred emails before anybody notices, and the only useful skill in that moment is knowing where the off switch is.