Use it when
- The same activity consumes hours every week.
- The team relies on spreadsheets, messages and memory to manage delivery.
- Mistakes happen when work moves between people or systems.
Do not start here when
- The task is rare and completely different each time.
- Errors are costly and there is no human approval step.
- The real goal is merely to justify buying a new tool.
Choose a small, frequent routine
“Automate sales” is not a project. “Every morning, find leads with no reply for three days and prepare the next contact” is. The second sentence has a frequency, a condition and an observable output.
Prefer routines that happen several times a month, use accessible data and tolerate human review.
Map the process as it works today
Watch one real execution and record every handoff: who starts it, what they consult, what they decide, where they record it and who receives it. Do not draw the ideal process yet.
- Trigger: what starts the work?
- Inputs: which data is required and where is it?
- Decisions: which rules change the path?
- Output: what proves the task is done?
- Exceptions: when must a person take over?
Separate rules, judgment and action
A rule is verifiable. Judgment requires interpretation. An action changes the world by sending a message, updating a CRM or approving a payment.
Automate rules and preparation first. Keep sensitive judgment and irreversible actions behind approval. This makes the system easier to test and limits the impact of a bad answer.
Grant the smallest useful access
If the task is to summarize stalled deals, AI may only need to read a few CRM fields. It does not need permission to delete records or access the whole account. Test with synthetic data, then a small real sample with logs and a named reviewer.
Measure before and after
Record total time, wait time, rework and common errors before the test. Speed is not always the main result. A routine may be worthwhile because it reduces missed work, improves traceability or removes the need to check five systems.
Delivery Hero redesigned approval before automating account recovery
The n8n case describes roughly 800 account-recovery requests per month. The solution was not merely connecting APIs: approval moved from IT to the employee's direct manager, and only then were actions across Okta, Jira and Google automated.
Each recovery took an average of 35 minutes before the change.
The first workflow was deployed in about five hours.
Average lockout time fell from 35 to 20 minutes.
The company reports 200 hours saved per month; the data comes from a vendor case.
The gain came from changing one process decision and automating the stable slice. Copying only the connectors would have kept the approval bottleneck in place.
Prepare a process for a small, reversible pilot
Map one execution that actually happened. The goal is to find a stable slice, not to design an imaginary company.
1. Observe one occurrence
Record who started it, which data arrived, where it waited and how it ended.
A map of real work, including shortcuts.
2. Separate decision from action
Mark judgment calls apart from moving, copying, calculating or notifying.
A boundary between people, AI and deterministic automation.
3. Discover exceptions
Ask when the normal rule fails and who owns the case.
A deviation list before it becomes a production error.
4. Measure the baseline
Count volume, time, waiting, errors, rework and impact.
Current numbers for comparison with the pilot.
5. Automate one slice
Choose a frequent, reversible step with verifiable input and output.
A pilot with approval, logs and a manual fallback.
6. Expand with evidence
Compare results, corrections and incidents for one week.
A decision to keep, adjust, stop or expand.
Create the map before opening n8n
This context forces a record of current work. The complete pack in development will include a canvas, baseline sheet, risk matrix and pilot plan.
Map this process before recommending any automation. PROCESS [name and objective] CURRENT EXECUTION [real steps, people, systems and shortcuts] VOLUME AND FREQUENCY [how often it happens] OBSERVED PROBLEMS [delays, errors, rework, waiting or poor visibility] Return: 1. trigger, inputs, decisions, actions, output and exceptions; 2. the owner of every decision; 3. stable and variable steps; 4. controls that must not disappear; 5. a baseline for time, errors and rework; 6. the smallest automatable slice; 7. required human approval; 8. a rollback plan; 9. conditions to stop or expand the pilot. Mark implicit rules as "DISCOVER". Do not invent the ideal process before recording the real one.
The guide stays open. You pay for the shortcut.
Join the early list. We will use demand to decide which pack should be released first and what it must include.
- Current-process canvas
- Time and rework baseline
- Decision, action and exception matrix
- Reversible pilot plan
- Expansion and stop criteria
Verify at the source
Product capabilities and policies change. These are the official references reviewed for this guide.