Automation thinking: trigger, condition, action

The skill underneath every tool

Zapier, Make, n8n, GoHighLevel — the tools change every year. The thing that doesn't change is the shape of every automation ever built: trigger → condition → action. Something happens, a rule decides what kind of something it is, and the system does the next step without a human.

Clients don't pay for tool knowledge. They pay for someone who can look at a messy human process and see that shape inside it. This lesson teaches you to see it before you ever open a tool — because the number one amateur mistake is opening Zapier first and thinking second.

Trigger, condition, action

Trigger — the event that starts everything. A form gets submitted. An email arrives. A Stripe payment lands. A row gets added to a sheet. It's always a fact you can point at, never a vibe like "when we're busy."

Condition — the fork in the road. Is the budget above $1,000? Does the email contain "refund"? Is the lead from Texas? Conditions are yes/no questions a machine can answer from the data it received.

Action — what happens next. Create a CRM contact. Post to Slack. Send email #1 of a sequence. Add a row. Actions can chain: one trigger can fire five actions in order.

One automation, drawn

Here's a lead-routing flow you'll build for real in lesson 3 — a new lead arrives, and the system decides how urgently a human should see it:

Read it out loud: when a form is submitted, if budget is over $1,000, create the contact and ping Slack; otherwise create the contact and start the nurture emails. One sentence, one diagram, one automation. Every build you'll ever ship is this picture with more boxes.

When to automate — and when not to

The rough math seniors use: frequency × minutes × error cost. A 10-minute task done 40 times a month is nearly 7 hours — automate it. A 2-hour task done twice a year is not worth a build that needs maintenance. And a task where a mistake costs a client relationship (firing an employee, quoting custom prices) should keep a human in the loop no matter how often it repeats.

Map before you build

Professionals map the process on paper before touching a tool. The mapping ritual:

What this looks like with a real client

Dana's client Sarah, a Texas real-estate agent, said "I keep losing leads." Vague. Dana mapped it: leads arrive from a Facebook ad into an email inbox (trigger), Sarah reads them "when she can" (the gap), replies personally to serious ones (condition: pre-approved? timeline under 3 months?), and forgets the rest (missing action). The map exposed the actual fix: instant CRM entry for everyone, instant SMS to Sarah for hot leads, automatic nurture email for the rest. Sarah thought she needed "an AI." She needed a trigger, one condition, and three actions.

Do this now

Twenty minutes. Take the top task from your lesson 1 Automation Audit and map it in a doc titled Process Map — [task name]: (1) the trigger, stated as an observable event; (2) every step as a verb sentence; (3) each decision written as a yes/no question; (4) the apps and data involved at each step; (5) the finished one-liner: "When [trigger], if [condition], then [actions]."

Then write one honest sentence at the bottom: should this even be automated, using frequency × minutes × error cost? Saying "no, leave it manual" correctly is a senior skill — and this map becomes the build plan for your first real scenario in lesson 3.