_Before learning to build an automation, learn to recognize which process deserves one._
Overview
People who hear about automation for the first time usually imagine two wrong things at once: that you need to know how to code, and that the goal is to automate "everything" as soon as possible. Neither is true, and together they explain why so many people give up before they even start. Automation, in the sense this course uses the word, is simply teaching a system to repeat on its own a sequence of steps you currently repeat manually — and it's only worth it when the process behind it is already good enough to be worth repeating. This chapter installs the mental model that supports the entire course: before any tool, before any workflow, there's the question "is this worth automating right now?" — and knowing how to answer it is the most valuable skill you'll leave here with.
Key Concepts
Every automation, no matter how sophisticated it looks on the outside, is built on the same skeleton: a trigger (the event that sets everything off — a submitted form, a received email, an approaching date), one or more conditions (rules that decide what to do depending on the case) and an action (what actually happens — sending a message, creating a row in a spreadsheet, moving a card). Once you understand that's all there is, the word "automation" stops sounding like something reserved for programmers and starts sounding like what it is: a way to describe, in clear steps, something you already do.
This leads straight to the most overlooked point for beginners: automating a bad process doesn't fix the process, it just makes the mistake happen faster and with fewer people noticing. If your current way of responding to a customer is inconsistent — sometimes you forget a detail, sometimes it takes days — encoding that same process into a tool won't bring consistency on its own; it will just formalize the inconsistency into a system no one is watching closely. The right order is: first make the manual process good enough to trust, then automate.
The third concept is the practical selection criterion, and it has three simple variables: frequency (how regularly this happens — daily, weekly, once a month?), time spent (how many minutes, added up over the month, does this consume?) and cost of error (what happens when someone forgets or messes up this step — an angry customer, or just a minor annoyance?). Processes with high frequency, high total time and low cost of error are the best candidates to start with. Processes that require case-by-case human judgment — negotiating a discount, deciding whether a customer deserves an exception — should stay manual for now, even if they're frequent: automation doesn't replace judgment, it only executes rules.
Execution Flow
- List everything you do repeatedly. Over three or four days, jot down every task you notice yourself redoing — without filtering yet, just observing.
- Identify the trigger for each item on the list. Ask: what sets off this task? An email arriving, a date on the calendar, a customer filling something out?
- Measure frequency and approximate time. How many times a week does this happen, and how many minutes does each occurrence take — multiply to see the real monthly impact.
- Assess whether it requires judgment or is mechanical. If the answer changes depending on your personal judgment each time, mark it as "don't automate yet".
- Classify each item as manual, semi-automatable or automatable. This initial classification, even rough, is already more structure than 90% of people have before they start.
Applied Scenarios
A hairdresser who confirms appointments over WhatsApp manually, one message at a time, is a classic example of a frequent process, low risk of serious error and highly mechanical — a great automation candidate, because the trigger (appointment made) and the action (confirmation message) are always the same, with no judgment involved. The same hairdresser deciding whether to make an exception to fit in a late client, on the other hand, is a judgment call — not a candidate, at least not at this stage of the course.
A second scenario: a consultancy that receives, every month, the same email question about how the hiring process works. High frequency, low risk (it's a standard response), mechanical — another good candidate, different from the first example but with the same scoring profile. Negotiating the final contract value with each client, even though it's frequent, involves judgment and context that changes case by case: it stays out for now, even though it consumes real time every month.
Common Mistakes
- Trying to automate a process that isn't even clear in your own head, expecting the tool to "fix" the mess.
- Confusing "happens often" with "worth automating", ignoring the cost of error and whether it requires judgment.
- Wanting to automate everything at once, without picking one specific first candidate to validate the method.
- Ignoring tasks with low individual volume but high aggregate volume — five 5-minute tasks a day add up to more than it seems.
- Treating "requires judgment" and "can never automate" as synonyms, when it's really just "don't automate yet, not without automating first".
Pro Tip: When listing your repetitive tasks, actually time each one at least once with your phone — mental estimates usually miss by a factor of two or three, up or down, and that measurement becomes the foundation for the rest of the course.
Practical Exercise
Over the next two days, keep a notepad (paper or digital) open and write down every repetitive task you perform manually — the trigger that set it off, how long it took, and whether it involved any judgment call. At the end of the second day, reread the list and star the three tasks that appear most often or consume the most time combined.
Implementation Checklist
- I can explain what a trigger, condition and action are without using technical jargon.
- I understand why automating a bad process only amplifies the problem.
- I can estimate the frequency, time and cost of error of a specific task.
- I can tell apart a mechanical task from one that requires case-by-case human judgment.
- I have a real (not hypothetical) list of repetitive tasks from my daily routine.
Chapter Summary
- Automation is teaching a system to repeat a sequence of trigger, condition and action that you already do manually.
- Automating a bad process formalizes the error, it doesn't fix it — fix the manual process before encoding it.
- The practical selection criterion combines three variables: frequency, time consumed and cost of error.
- Tasks that require case-by-case human judgment stay out of automation for now, even if they're frequent.
- The next chapter shows how to prepare the ground before choosing which process to automate first.
---