Role
Marketing automation
How do you know all your journeys still do what they were meant to do? An error in automation does not shout. It simply sends the wrong thing, at the wrong time, to the wrong people - for several months.
Intro call
Four questions we would start with
How do you know a journey launched a year ago still runs correctly?
If you have no answer to that, you have one in reality - on the side of the recipients, who get messages that do not fit their situation and stop opening them.
What do you not know about your segments until somebody asks?
Usually: how many people are really in them, when they were last updated and whether they overlap. A segment built for one campaign then lives a life of its own.
How many people touch one journey before it goes live?
Marketing, somebody from data, sometimes a lawyer. With every handover the chance grows that the assumption at the start parts ways with what was built.
Who notices first that a send went to the wrong group?
With a good journey - the monitoring. With a typical one - a recipient who replies. And one in several hundred replies; the rest simply unsubscribe.
We take over the building and the checking, you keep the design
Building a journey from a description, tests before launch and continuous checking of the running automations can be taken off the desk. What we want to achieve and who we are talking to stay with a person.
- Every journey has a description in plain language. - Not only a diagram in the tool. A year later that is the difference between "we know what this does" and "we are afraid to switch it off".
- A test before launch is compulsory. - A preview of the entry population shows who would get what and when, before anyone gets anything for real.
- Consents are a condition, not a field. - A journey will not run for people with no basis for contact in that channel - and that is checked every time, not once at build.
Scope
What can be taken off marketing automation
Twenty-one example tasks. Each one has a human approval point. Below is a selection, and the scope we fit to your process.
Segments and their definitions
- A description of every segment in plain language, beside the technical definition
- Detecting segments that overlap
- Pointing out segments that are empty or long unchanged
- Checking that the people in a segment have a basis for contact in that channel
- How many journeys one person belongs to
Building a journey
- A draft journey from a description of the goal (designed and approved by: the specialist)
- Pointing out edge cases the diagram does not handle
- Checking for loops and conditions that will never be met
- The messages one person could receive in a single week
- Documentation of the journey produced along with it
Content and tests
- Content variants within a journey (approved by: the specialist)
- Checking the personalisation - what happens when a field is empty
- The list of people meeting the entry condition today, before the journey launches
- Launching on a control group before the full start (decision: the specialist)
- The list of things to check before launch
- A test send to a control group (decision to launch: the specialist)
Reviewing the running automations
- An alert at an unusual number of sends in a journey
- Detecting journeys with no activity for a long time
- Pointing out journeys with a rising number of unsubscribes
- A summary of every running automation with the date it was last reviewed
- Material for the quarterly review (decision to switch off: the specialist)
A day's work
Today
- A journey is built by clicking and is remembered only for the first month
- Before launch you test on yourself and two colleagues
- You learn about an error from recipients' reactions or from the unsubscribe report
- You do not know how many messages your most active client gets in a week
- There are several dozen segments and nobody knows which are still used
- Nobody switches off a journey from two years ago, because nobody knows what it does
With AI assistance
- A journey has a description somebody who did not build it can understand
- A simulation shows who would get what, before anyone gets anything
- An unusual number of sends reports itself, on the day it happens
- You can see how many messages add up on one person across every journey
- Segments have a description, a date and who uses them
- The quarterly review has a list; switching something off stops being an act of courage
- Catching silent errors
unusual behaviour in a journey is reported rather than discovered at a review
journeys are monitored, not sampled
- Time to launch
a new journey goes live sooner
building and testing stop being manual work from zero
- Clean segments
fewer overlapping and dead segments
each has a description, an owner and a review date
- Clarity for a successor
the automations can be taken over
a journey is described in plain language, not only drawn in a tool
We start with an inventory, not with new journeys.
- Step 1
A list of what is running
Every live automation with what it does and who is accountable for it. Usually the most uncomfortable document in the whole project and the most necessary.
- Step 2
Descriptions and switch-offs
Every journey gets a description in plain language. Some are switched off at this stage already, because they turn out to duplicate another or to have no reason to exist.
- Step 3
Tests before launch
A preview of the entry population and a start on a control group become compulsory for new journeys.
- Step 4
Monitoring what runs
Alerts and quarterly reviews. Only here, because they need the list from step 1 as a reference point.
Common questions
Questions that come up at the first meeting
What about the GDPR with automated sends?
The rules do not change: a basis for contact in the channel, the ability to withdraw consent, the scope of data used for personalisation. What changes is that checking the basis becomes a condition of launching a journey, rather than a field filled in at build and never checked again.
Do we still need an automation specialist after a rollout?
You need them more, because the number of journeys somebody has to understand grows. A journey built and forgotten is today the most common source of silent errors - and that is a problem of knowledge, not of hands. A specialist who does not spend time manually checking who got what keeps more machinery under control instead of being afraid to touch it.
Does this fall under the AI Act?
Automating communication is not in itself a high-risk use and the AI Act does not classify it as one. The limit worth remembering comes from the GDPR: profiling that affects the terms offered to a particular person falls under article 22, and that is a separate conversation, not a paragraph on a page. What the AI Act does require here applies to every rollout - AI literacy among the people who operate the journeys.
Still have a question that is not here? Book a call
Next step
How many journeys are running right now with no review for more than a year?
We will show you what work on automations looks like when every journey has a description and a silent error no longer gets a quarter to run.