Your first automation in one hour, with no code
Not a theory lesson. Pick one task you repeat every week and we will turn it into something that runs itself before your coffee goes cold.
Most people who want to start automating start with the tool, spend a week comparing platforms, and automate nothing.
Start with the task. Pick one, and we will take it all the way.
Step zero: choosing the right task
This decides your success more than anything that follows. A good first task meets four conditions.
It repeats, at least weekly. Less than that and you will not feel the difference.
Its steps are stable, done in the same order every time.
Its inputs are digital, arriving in an email, a form or a file, not in a phone call.
Failure is cheap. If it goes wrong, nothing collapses and no customer is upset.
Good candidates: turning registration forms into spreadsheet rows with a notification, summarising a weekly inbox, renaming and filing incoming documents, tracking mentions of your name.
Step one: draw it on paper before opening any tool
Every automation, however complicated it looks, is three parts.
| Part | The question | Example |
|---|---|---|
| Trigger | What starts it? | An email arrives containing "training request" |
| Processing | What happens to the data? | Extract name, organisation and date |
| Destination | Where does the result go? | A new spreadsheet row and a phone notification |
Write one sentence for each. If you cannot, the task is not ready to automate yet, and that is useful information rather than failure.
Step two: where does the AI go?
Do not put a language model in every step. The rule:
Use a simple condition when the decision is unambiguous: does the subject contain a word? Is the amount above a thousand?
Use the model when the decision needs language understanding: what is this message about? Is its tone angry? Extract the organisation name from this free text.
Confusing the two is the most common mistake I see. Filtering with a language model is slow, expensive and unpredictable, when a simple condition does it in a fraction of a second for nothing.
Step three: the prompt that makes output usable
The usual problem with a model inside an automation is that the output arrives in a different shape each time, breaking the next step.
Three things make this work: a closed list of values for every categorical field, null instead of guessing, and a strictly specified output format.
Step four: test on twenty old cases
Do not point it at live input. Take twenty messages that arrived last month and run them through.
Look at what it got wrong. Usually the errors are not in the model but in your definition of the task: a case you had not considered, or a category that could mean two things.
The honest part: where automations really fail
Not in the building. Building is enjoyable, quick, and feels like progress.
Failure arrives three months later, when the format of incoming messages changes, or the platform updates, or something breaks silently and nobody notices for a fortnight.
So make your first automation tell you when it fails. An error notification matters more than the feature itself, because a broken silent automation is worse than none at all.
In closing
Automation is not a technical project. It is a habit: notice a repetition, describe it, remove it. The first takes an hour; the tenth takes twenty minutes.
Start today with one step only: write on paper a task you repeat every week, and one sentence each for the trigger, the processing and the destination. That page is ninety percent of the work.
And if you want to build one together on a real task from your own work, that is what we do hands on in the agents and automation course.
Common questions
- What makes a good first automation?
- A task that repeats at least weekly, with stable steps, digital inputs, and cheap failure that will not upset a customer. Avoid your most important task first, because that is when you are still learning where things break.
- Do I need to learn to code?
- Not for your first ten automations. Connection platforms are entirely sufficient. Code becomes useful when you need complex logic or integration with an internal system that offers no ready interface.
- When should I use a language model versus a simple condition?
- A simple condition when the decision is unambiguous, like a keyword being present or an amount exceeding a threshold. A model when the decision needs language understanding, like identifying a message's subject or pulling a name from free text.
- How do I stop model output breaking the next step?
- Demand a strict output format like JSON, with a closed list of values for every categorical field, plus an explicit instruction to use null rather than guessing. Those three together solve most breakage.
- Why do automations fail months after working fine?
- Because their inputs change silently: message formats, platform updates, a new field. Make your first automation send a notification on failure, because a silently broken automation is worse than none.
No comments yet
Leave a comment