An Unsubscribe in One System Is Not an Unsubscribe
Most businesses now hold customer contact details in four or five places: the online store, the point of sale, the CRM, the email platform and often a loyalty or booking system. Marketing consent is captured in some of them and withdrawn in others, and unless something deliberately carries that state between them, a customer who unsubscribes on Monday can be emailed again on Thursday from a different system.
This is one of the few integration problems with a legal edge rather than only a commercial one. Under the Spam Act 2003 you need consent, you need to honour a withdrawal promptly, and you need to be able to show where the consent came from. This page covers how to design consent and suppression to move properly between systems, and what to do about the records you already hold whose origin nobody can explain.
Realistic ROI
Four Things That Break Consent When Data Moves
Every one of these is common, and every one of them produces the same visible symptom: somebody receives a message they asked not to receive.
Consent is captured in more places than anyone tracks
A tick box at online checkout, a form on a landing page, a staff member entering details at the counter, a competition entry, a booking form, a paper form at a trade show. Each of these produces a customer record with a consent state, and often in a different system. Businesses can usually name two of these sources and are surprised by the rest. Until you have written down every capture point, you cannot design the flow, and you certainly cannot answer a question about where a particular subscriber came from.
Withdrawal usually only travels one way
The email platform handles unsubscribes properly, because that is its job, and it stops sending. What it often does not do is tell the CRM, the store and the point of sale. Those systems keep their old consent flag, and the next time someone builds an audience from the CRM or exports a list for a campaign, the unsubscribed customer is back in it. The person experiences this as being ignored, and they are not wrong. Suppression has to propagate to every system that holds the record, not only to the one that was sending.
Consent without its origin is hard to defend
A flag saying yes is not evidence. What you want alongside it is where it was captured, when, what the person was actually told, and by which method. When a complaint arrives, that record is the difference between a straightforward answer and an uncomfortable reconstruction. It also matters operationally: consent given for order updates from a booking form is not consent for a weekly promotional newsletter, and a system that stores a single boolean cannot tell those apart.
Timing is a compliance question, not a preference
The Spam Act requires an unsubscribe request to be honoured within five business days. A nightly one way synchronisation sounds adequate and is not, because a withdrawal recorded on the Thursday before a long weekend, in a system that only pushes to one destination, can miss the window before anybody notices. Consent withdrawal should propagate quickly and in every direction, and the design should be able to demonstrate how long it takes rather than assume it is fine.
What a Consent Design Has to Cover
Six pieces. The first two are usually where businesses find the problems they did not know they had.
Map every capture point
Every place a customer’s contact details and consent can enter the business: web checkout, web forms, the counter, the booking system, competitions, trade shows, imported lists and anything staff key in manually. For each one, record what the customer was told, what they agreed to, and which system holds the result. This exercise routinely turns up two or three sources nobody was tracking, and those are usually the ones generating complaints.
Decide the consent record
Rather than one yes or no, store the state, the source, the timestamp, the method and the scope of what was agreed to. That lets you distinguish transactional messages a customer will always receive from promotional ones they opted into, and lets you answer where a subscriber came from without archaeology. It also makes it possible to run a re-permission approach on the records whose origin you cannot establish, rather than either keeping them or deleting them on a guess.
Name the authority
One system is declared the authority on consent state, and every other system reads from it rather than maintaining its own view. In most Australian businesses the CRM or the customer data layer is the sensible choice rather than the email platform, because the email platform only knows about the channel it sends on. Whatever is chosen, the important thing is that the others stop being independent sources of truth that quietly disagree.
Propagate suppression everywhere, quickly
A withdrawal recorded anywhere reaches every system that holds that person, within minutes rather than overnight, including systems that do not send but do export. Matching matters here: the same person may exist under two email addresses or a different phone format, and a suppression that only matches one of them leaves the other live. Where matching is uncertain, the safe behaviour is to suppress both and let a person resolve the identity afterwards.
Separate transactional from promotional
Order confirmations, dispatch notices, appointment reminders and account notices are not the same category as a promotional campaign, and a customer who opts out of marketing should still receive the messages relating to what they bought. Systems that treat these as one setting either keep marketing to people who declined it or stop sending order updates to people who need them. Define the boundary explicitly, and where a message sits close to the line, treat it as promotional.
Handle deletion and access requests
Under the Australian Privacy Principles a person can ask what you hold about them and ask for it to be corrected, and there are circumstances where information must be destroyed or de-identified. That obligation covers every system in the chain, not only the one they contacted. Keep a written map of which systems hold personal information and a defined process for actioning a request across all of them, including any suppression record that must be retained precisely so they are not contacted again.
Consent Situations and How They Should Behave
| Task | Traditional | Handled Properly | Notes |
|---|---|---|---|
| Unsubscribe from an email | Stops in that platform only | Propagated to every system | Within minutes, in all directions, including systems that only export lists. |
| Consent captured at the counter | Stays in the point of sale | Flows with the source recorded | Staff need a consistent script, because what was said is part of the record. |
| Same person, two email addresses | One suppressed, one still live | Matched, both suppressed | When matching is uncertain, suppress both and resolve identity afterwards. |
| Order confirmation after opting out | Blocked along with marketing | Still sent | Transactional and promotional need to be separate settings, not one switch. |
| Competition entry list | Added to the newsletter | Scope recorded and respected | What people agreed to at entry is what governs. Record it at capture time. |
| Records with unknown origin | Kept and mailed anyway | Re-permission or retire | A short re-permission approach is safer than assuming, and usually improves engagement. |
| Customer asks what you hold | Checked in one system | Answered across the map | Requires knowing which systems hold personal information before the request arrives. |
| New system added to the stack | Another independent consent flag | Reads the authority | The moment a new system is added is when this design either holds or quietly breaks. |
Where Consent Data Goes Wrong
Suppression only flows to the sending platform
This is the most common arrangement and it fails predictably. The email platform stops sending, the CRM and the store keep their old flag, and the next audience built or list exported from either of those brings the person back. Design suppression as a state that reaches every system holding that record, including ones that never send but do export, and test it by unsubscribing a real test record and then checking every system rather than assuming.
A nightly one way sync was considered fast enough
The Spam Act allows five business days to action an unsubscribe, which sounds generous until a Thursday afternoon withdrawal meets a long weekend, a failed overnight job and a Tuesday campaign send. Propagate withdrawals quickly rather than on a daily cycle, monitor the delay so you can state it rather than hope, and alert when a propagation fails. This is a case where near real time is genuinely justified rather than an expensive default.
Consent was stored as a single true or false
A boolean cannot tell you what somebody agreed to, when, or where, so it cannot distinguish a newsletter subscriber from a competition entrant from a customer who only wanted order updates. It also cannot support a re-permission approach because you have no way to identify the records at risk. Store the state, source, timestamp, method and scope from the beginning. Retrofitting provenance onto an existing list is not possible, which means the records you hold now will always be the ones you cannot explain.
Matching failures left live records behind
The same person is often in your systems more than once, under a work and a personal email or with a phone number stored in two formats. A suppression matched on exact email alone will silently miss the duplicate, and the customer will keep receiving messages and reasonably conclude they were ignored. Match on normalised email and normalised phone, suppress every candidate match rather than only the confident one, and put identity resolution in a queue for a person afterwards.
Purchased or scraped lists entered the stack
Address lists bought from a third party or harvested from websites are a poor fit for Australian requirements, because consent has to be yours and you have to be able to substantiate it, and the Spam Act deals specifically with address harvesting. Beyond the compliance exposure, these lists damage sending reputation and depress engagement for the legitimate part of your database. If historical records of this kind are already in your systems, isolate them, run a re-permission approach, and retire the ones that do not respond.
Nobody knows which systems hold personal information
When an access, correction or deletion request arrives, you need to answer across every system, including the ones added last year by a department that did not tell anybody. Keep a written map of which systems hold what personal information, where each stores its data, how long it retains records and what has access. Under the Australian Privacy Principles this is the basis of several obligations, and the map is also what makes a data breach assessment possible in the hours it needs to happen rather than the weeks it otherwise takes.
How Yes AI Handles Consent Data
A capture point audit before anything is built
We map every place contact details and consent enter your business, what customers are told at each one, and which system holds the result. Businesses are routinely surprised by two or three sources, and those are usually the ones generating the complaints.
Suppression that propagates in every direction
A withdrawal anywhere reaches every system holding that person within minutes, with the propagation delay measured so you can state it rather than assume it. Built on a managed cloud automation layer we operate, with record level logs showing what was suppressed and when.
Consent stored with its provenance
State, source, timestamp, method and scope rather than a single flag, so you can answer where a subscriber came from and distinguish what they actually agreed to. This is the piece that cannot be added retrospectively, which is why we insist on it at the start.
We work with your legal adviser, not around them
We build what your adviser confirms is required and we will tell you when something looks like a question for them rather than for us. What we bring is knowing where integrations typically break consent, so the right questions get asked while they are still cheap to answer.
From Scattered Flags to Consent You Can Explain
Five steps. The audit is usually a week, and a typical build is four to eight weeks depending on how many systems hold customer records.
Audit every capture and every holder
Where consent is captured, what customers are told, which systems hold contact details, which of them can send, which can export, and how each currently learns about a withdrawal. The output is a written map that is useful well beyond this project.
Design the consent record and name the authority
State, source, timestamp, method and scope, with one system declared authoritative and the others reading from it. Transactional and promotional separated explicitly so an opt out does not stop an order confirmation.
Build fast, multi directional suppression
A withdrawal anywhere propagates everywhere within minutes, with matching on normalised email and phone, candidate matches suppressed rather than skipped, and identity resolution queued for a person afterwards.
Deal with the historical records honestly
Identify records whose origin cannot be established, run a re-permission approach on them, and retire the ones that do not respond. This usually shrinks the database and improves engagement, which makes the conversation with marketing easier than expected.
Monitor, test and keep the map current
Propagation delay measured and alerted on, a periodic live test where a real record is unsubscribed and every system checked, the system map updated whenever a new tool is added, and a defined process for access and deletion requests across all of them.
Related Reading
SaaS Integration Explained
The six patterns and the decisions behind them.
Single Customer View
Matching one person across every system you run.
Klaviyo Integration
Connecting the email platform to the rest of the stack.
Data Privacy in Australia
What the Privacy Act expects of connected systems.
Writing the Specification
Where consent and privacy decisions belong in the document.
Custom API Integration
When the connector you need does not exist yet.
FAQ
Make an Unsubscribe Mean What the Customer Thinks It Means
Book a consent data review. We map every capture point and every system holding customer records, test what actually happens when someone unsubscribes, and show you where the gaps are. The map is yours either way.
All discussions held in confidence. Australian-based consultants.