Automation course · What automation is
What can be handed over, and what can't
Most people meet automation as a promise — "put your business on autopilot" — and bounce off it, because the promise is too big to act on. This course starts somewhere smaller and more useful: a single question you can ask about any task in your week, which tells you whether a machine can take it. Once you can answer that question quickly, the rest of the course is just plumbing.
The question is: does this task have a trigger, a rule, and a result I can describe? A trigger is the thing that starts it — a form is submitted, a payment lands, Friday arrives. A rule is what happens next, and it has to be stateable in plain words with no "it depends" hiding inside. A result is the thing that exists afterwards: a row added, a message sent, a file moved. If all three are clear, the task is a candidate. If any one of them turns mushy when you say it out loud, it is not — yet.
Notice what the question does not ask about: how important the task is, how much you dislike it, or how modern the tool is. Importance is a bad guide, because the most important tasks are usually the ones with judgement in the middle. The right first targets are small, boring, and frequent — the ones you do the same way every week without thinking, which is exactly why they survive being described in three parts.
A note on what the tools can do as of September 2026. The category has settled into two shapes. One is the connector service — you pick an app that starts things, an app that receives them, and a chain of steps in between; the vendors here are the ones you have heard of, and they compete on how many apps they speak to. The other is the assistant that writes and runs the steps for you from a description. The second shape is younger and moves fast, which is why this course teaches the first: the parts are visible, and when something breaks you can see which part broke.
There is a second filter, quieter but sharper: what happens if this runs wrong at three in the morning and nobody notices for a week? For "move the file into the archive folder", the honest answer is "nothing much". For "send the invoice", it is a phone call with a client. That answer does not forbid automating the invoice — it tells you the flow needs a human checkpoint in the middle, which is a design you will build in module four.
Maya runs a one-person ceramics studio, and her week has all three kinds. Packing orders is frequent, describable, and low-stakes if it hiccups — a candidate. Choosing which wholesale enquiry to pursue is frequent and high-stakes with judgement in the middle — never. Writing the monthly update to stockists sits between: the assembly can be handed over, the last read cannot. That middle case is the most common one in real work, and it is where this course spends most of its time.
Try it now: list five things you did more than once last week. For each, write the trigger, the rule, and the result in one line each — and mark the ones where a line came out mushy. The mushy lines are not failures; they are the exact places where your process is not yet decided, and no tool can decide it for you.