There are few things more frustrating than returning to an old topic, campaign, or workflow after several months to discover that you barely remember how or why you built it a certain way. Customer journey workflows and decisions can often intertwine with the domains of multiple teams and roles, and depending on your governance structure, things can get messy.
Older customer journeys can contain rules that nobody remembers choosing, and that's a problem.
Why did you decide to wait three days, specifically, before the next email in the workflow is triggered? Who decided that some customers should be suppressed after clicking a specific link, or not clicking a specific link? Why does one response trigger a human handoff while another continues through automated workflows?
Nobody knows. Someone set it up three team leads ago.
If you're lucky, change history may tell you who edited it and when, but in an enterprise organization you're probably digging through a haystack to find the elusive needle. And even if you find your needle, it doesn't necessarily point north and tell you why the rule exists.
That becomes a problem when journeys change hands, campaigns evolve, regional teams adapt global programs, agencies enter and leave, or curious stakeholders start poking about and asking questions.
And the decisions we make in our customer journey logic matter. PwC's 2025 U.S. Customer Experience Survey found that 70% of executives say customer expectations are evolving faster than their companies can adapt. At the same time, 29% of consumers said they had stopped using or buying from a brand because of poor customer experience, either online or in person. The details inside a journey, including timing, frequency, eligibility, suppression, and what happens next, are part of the experience an organization creates.
For consequential journey changes, I think teams should preserve the reasoning in a simple Customer-Treatment Change Record.
This is not a compliance framework or an established industry standard. It is a proposed release record for changes that materially alter the customer experience. It answers four basic questions: What changed? What will customers experience differently? Why are we making the change? What would make us reconsider it?
Let's take a look at onboarding at a household energy provider, for example.
Each time the company gets a new customer, they receive a welcome email. Seven days later, if they have not submitted a meter reading, the system sends a reminder.
A year after launch, the company introduces a new online account and rewrites the onboarding sequence around it. Someone decides seven days is now too long and changes the delay to three. The change is tested, approved, and published.
Another year passes. The original campaign manager has left. The agency that helped redesign the onboarding program is gone. The welcome message has been rewritten several times by three different junior marketing managers.
The three-day wait is still there, and while nothing is technically wrong, the automation is doing exactly what it was told to do. What has disappeared is the reason it was told to do it.
That distinction has a precedent outside marketing.
Software architects use Architecture Decision Records, usually shortened to ADRs, to preserve significant technical decisions and the reasoning behind them. Martin Fowler describes an ADR as a short document containing the decision, its context, and its important consequences. One of its main purposes is historical: allowing someone months or years later to understand why a system ended up working the way it does. Martin Fowler: Architecture Decision Record
The practice is broader than software. The UK's Health and Safety Executive uses a Key Decision Log during investigations. Its guidance makes an important distinction: the log is not supposed to record everything that happened. It records decisions that materially affected the course of the investigation and the reasons for making them. The HSE specifically points to staff changes as one reason that history becomes useful. A successor should be able to understand the thinking that preceded them. HSE: Key Decision Log guidance
That is essentially the problem here.
The Customer-Treatment Change Record is a marketing application of the same idea. The name is proposed. The underlying discipline of recording consequential decisions and their rationale is established.
The energy-provider example does not need a document describing every branch in the onboarding journey.
It needs a few lines explaining the decision that changed it.
Changed rule: The meter-reading reminder now follows the welcome message after three days instead of seven.
Customer effect: New customers who have not submitted a reading will hear from us four days sooner.
Reason: The redesigned online account allows customers to complete setup immediately, and testing of the new onboarding sequence supported an earlier reminder.
Scope: New-customer onboarding.
Approved by: Lifecycle lead.
Effective date: [date]
Review condition: Reconsider if the onboarding sequence, account setup process or audience definition materially changes.
That record tells a future owner something the number “3” cannot. It also establishes the right threshold for documentation: a corrected typo does not need one, and neither does a new hero image.
EY's 2025 Future Consumer Index surveyed 20,235 consumers across 26 countries and found that 88% felt brand messaging did not resonate with their needs and values. That research is broader than journey automation, but it illustrates the size of the relevance problem confronting customer communication. EY: 2025 Future Consumer Index
A customer of our energy company who has already submitted the meter reading but receives another request has encountered one operational version of that mismatch. Perhaps the suppression rule did not receive the new account status quickly enough, or perhaps somebody changed the entry criteria without reconsidering the exit condition.
What matters to the customer is that the company appears not to know what just happened, and that's not a great look.
This is part of the wider argument in our earlier Perspective on real-world customer engagement: communications become an experience through their relationship with one another and with what the customer is actually doing
Suppose the three-day reminder was chosen because the welcome message explicitly told customers, “You can submit your first meter reading now.” Six months later, that sentence disappears during a content refresh, but the automation workflow still waits three days.
Is that still smart? Maybe, but it wasn't deliberate.
Looking only at the current configuration provides very little help. Looking at the old decision record reveals that the timing and the message were connected.
The rules can survive after the circumstances behind them disappear.
This is why plain language matters. “Suppress when status = X” explains what the software does. “Customers who have completed registration should not receive another registration reminder” explains the decision.
Months later, the second sentence is the useful one.
There is a temptation to solve this with another calendar, as if you don't have enough of those already. Sometimes that is useful, but does not address the more interesting problem.
If its timing was chosen around a particular message, rewriting that message is a reason to look at the timing again. If a suppression rule depends on a customer status, changing how that status is defined is a reason to reopen it. If a handoff was created around a particular organizational structure, a reorganization should put the decision back under scrutiny.
The record therefore needs something more useful than “review again in six months.” It needs the assumption that would cause the decision to be reconsidered.
That idea also has a close parallel in Architecture Decision Records. Fowler recommends retaining old decisions rather than silently rewriting them when circumstances change. A new decision supersedes the earlier one, leaving a visible history of what was decided and when it stopped applying.
Customer journey history can work the same way.
The point is not to preserve an old rule forever. It is to preserve enough context to understand why it existed before replacing it.
This question becomes harder as more journey decisions originate with AI-assisted systems.
Gartner predicted in January 2026 that 60% of brands will use agentic AI for streamlined one-to-one interactions by 2028. More pertinent to this argument, Gartner advised marketers preparing for that shift to put strong data governance in place and track customer journey changes weekly. Gartner: Agentic AI and one-to-one customer interactions
Consider what happens when an optimization system recommends changing the energy-provider journey from three days to two because the shorter interval produces more completed meter readings.
Was the improvement large enough to justify contacting customers sooner? Did complaints arise? Was the test conducted on the same audience that will now receive the new treatment? Does the change still make sense if the welcome message changes next month?
Once the setting reads “2 days,” most of that context is invisible.
NIST's guidance on human-AI interaction offers a useful parallel. It suggests that organizations may benefit from collecting data about how frequently people override AI outputs and, importantly, their rationale for doing so. NIST: AI Risk Management and Human-AI Interaction
The interesting part is the rationale.
Whether a two-day interval was first proposed by a campaign manager, an analyst or an AI system matters less six months later than whether somebody can explain why the organization decided to put it into production.
Entirely's CEO Tobias Ackermann has made a similar argument about agentic marketing more broadly: consequential actions need identifiable approval and retained reasoning, rather than disappearing into a stream of automated execution. Enterprise Marketing Needs an Operating System, Not More Agents
A Customer-Treatment Change Record gives that reasoning somewhere to live at the level where customers actually encounter it.
The practical test is an inherited journey.
Give someone a program that has been live for two years. It has changed owners twice, received a regional variation, gone through a content refresh, and picked up a few exceptions along the way.
The new owner can probably trace the branches and read the conditions.
Can they explain why the important decisions remain?
Why three days? Why this suppression rule? Why does this response leave automation? Which of those decisions still reflect the current experience, and which merely survived the last redesign?
If the answer requires finding the right former colleague on LinkedIn, searching an agency archive, or excavating an old message thread, the organization has kept the automation and lost part of the decision that created it.
Rules change all the time, and they will continue to do so, but the reasoning behind them should be easier to understand and to inherit.