The word means two things depending on context, and the confusion is worth clearing up. In some tools, "scenario" is simply the name given to a Workflow. In everyday language, an automation scenario means the use case itself, before anything is built.
That second sense is the interesting one, because it is where an automation project succeeds or fails. Most abandoned automations did not fail technically: they automated the wrong thing.
Definition
An automation scenario is the complete description of a case to automate: the starting event, the steps, the expected result, and above all the situations where things do not go as planned.
It is the document you write before opening any tool. In three lines or one page, it does not matter, but beforehand.
A well-written scenario answers four questions: what triggers it, what should happen, what is the visible result, and what do we do when it fails. The fourth is the one people skip, and the one that costs.
Choosing what deserves automating
Not every repetitive task is worth it. The grid is simple: multiply frequency by unit time, and compare against build time plus supervision.
| Good candidate | Bad candidate |
|---|---|
| Repeated several times a week | Three times a year |
| Always the same steps | Every case is different |
| No judgement required | Needs a human decision |
| An error is visible and fixable | An error reaches the customer |
| The tools expose an API | Something has to be retyped by hand |
That last line eliminates more projects than all the others. An automated chain with a manual step in the middle is not an automation, it is an extra source of delay.
Writing a scenario in practice
Describe the normal case first, one sentence per step, in the language of your trade rather than of the tool. If you cannot write it in plain words, you will not be able to build it.
Then list what can go wrong. Missing data, service down, duplicate, absurd amount. For each: stop, ignore, or alert.
Define the observable result. How will you know tomorrow morning that it worked last night? If the answer is "I do not know", a step is missing.
Quantify the expected gain. Twenty minutes a week is seventeen hours a year. That tells you whether a day of building is justified.
A scenario that starts with "and then the AI handles the rest" is not a scenario. Every step must be describable, including those handed to a model, otherwise you will never know whether the result is correct.
Frequently asked questions
Do you really have to write before building?
For a two-step case, no. As soon as the case has conditions or touches money or customers, yes, and writing takes ten minutes against several hours of fixing later.
Which scenario do you start with when everything looks automatable?
The one that annoys you most, not the one worth most. Motivation matters more than arithmetic at the start, and a first success makes the second far easier.
When do you need an agent rather than a workflow?
When you cannot write the list of steps in advance because they depend on what you find along the way. In every other case an AI agent costs more for a less predictable result.
How do you structure this work from the start?
By treating scenario writing as the first step of building rather than as paperwork. Our n8n course requires that step before every build, including the simplest cases.