Automation platforms have made it easy to connect systems and move data around without writing code. That is a genuine improvement, and we use them regularly. It has also made it easy to automate a process that should never have existed in its current form.
The pattern
A team has a manual process with several steps, a few exceptions and some shared knowledge about how it really works. Someone builds an automation that reproduces those steps. The process now runs faster, and the errors it produced now arrive faster too.
Six months later there are a dozen scenarios, some of which fix problems created by others, and nobody is certain what the end-to-end flow actually does.
Why it happens
Automating the existing process feels safe. It does not require anyone to agree on a change, and it shows results quickly. Redesigning the process requires the harder conversation about what the operation is actually trying to achieve.
Start with the state, not the steps
The alternative is to define what the operational state should be and work backwards.
For a customer journey, that means deciding: at each stage, what should be true about the customer's record? What should have been sent? What should the next person see when they open it? Once that is defined, the automation has a target, and each scenario can be judged by whether it moves the record towards the right state.
This is a small shift in framing with a large effect. It turns automation from "do the steps faster" into "keep the operation in the state we designed".
Practical rules we follow
- One system of record per fact. If two systems both hold the appointment time, one of them is wrong at some point.
- Automate towards the record, not around it. Automation should update the system of record and let everything else read from there.
- Handle the exception path explicitly. If a scenario cannot complete, it should create a task for a person, with context, rather than silently stopping.
- Prefer fewer, larger workflows to many small ones that depend on each other.
- Write down what each scenario is for. If nobody can explain it, retire it.
Where the platforms fit
Tools like Make and n8n are excellent for the connective tissue between systems, especially when the systems have good APIs. They are less good as the place where the core workflow logic lives, because that logic becomes hard to see and hard to test.
Our approach is to keep the core journey in the operational system, expose it through the API, and use automation platforms for the edges: notifications, integrations with third parties, the occasional one-off.
The test
Before automating anything, ask what the process would look like if it were designed today with the systems you now have. If the answer is "the same", automate it. If the answer is "quite different", design that first. The automation will be simpler, and it will still be right in a year.
- Automation
- Workflow
- Process design
- Make
- n8n