For Australian businesses whose customer data lives in several systems

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.

Book a Consent Data Review (03) 9003 0111

Realistic ROI

4 to 6 systems

Typically hold customer contact details

Each one a place consent can be captured or withdrawn independently

5 business days

Is the window the Spam Act allows for an unsubscribe

Which a nightly one way sync can quietly exceed across a long weekend

Consent has an origin

And you should be able to state it

Where, when and what the person agreed to, kept as a record

One way is not enough

Suppression has to travel in every direction

The system that sends is rarely the only system that collects

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.

Complete list

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.

Not a single flag

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.

One owner

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.

All directions

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.

Clear boundary

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.

Across every system

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.

FAQ

How quickly does an unsubscribe have to take effect?

The Spam Act 2003 requires an unsubscribe request to be honoured within five business days, and the unsubscribe facility itself has to work and stay functional. In practice you should aim well inside that, because the risk is not the limit itself but the combination of things that eats it: a withdrawal recorded late on a Thursday, a public holiday, a synchronisation job that fails silently overnight, and a campaign scheduled for Tuesday morning. Propagating within minutes and monitoring the delay means you can state your actual performance rather than hoping the window covered you.

Our email platform handles unsubscribes. Is that not enough?

It is enough to stop that platform sending, and that is usually where the protection ends. The CRM, the online store, the point of sale and any loyalty system typically keep their own consent flag, and the next audience built or list exported from one of those brings the person back into a campaign. The customer sees a business that ignored their request. Suppression needs to be a state that travels to every system holding that person, including ones that never send but are used to build lists, which is the case people most often overlook.

What should we record when someone opts in?

More than a yes. Record where the consent was captured, the exact time, the method, and the scope of what the person agreed to, alongside the state itself. That combination lets you answer a complaint without reconstruction, distinguish someone who wanted order updates from someone who wanted a weekly newsletter, and identify at risk records later if you ever need to run a re-permission exercise. The important point is that provenance cannot be added retrospectively, so whatever you are not capturing today becomes a permanent gap in the records you hold.

Can we still send order confirmations to someone who opted out of marketing?

Generally yes, because transactional messages relating to a purchase or account are a different category to promotional messages, and a customer who declined marketing usually still needs their dispatch notice. The practical requirement is that your systems treat these as separate settings rather than one switch, which many do not by default. It also means being disciplined about the boundary: a dispatch notice with three product recommendations underneath it is closer to promotional than transactional, and where a message sits near the line the safer treatment is to consider it marketing.

We have an old list and nobody knows where it came from. What should we do?

Do not simply keep mailing it and hope. Isolate those records so they are identifiable, then run a short re-permission approach asking people to confirm they want to keep hearing from you, and retire the ones that do not respond. It feels like throwing away a database and in practice it usually improves results, because unengaged and unwilling recipients depress deliverability for everybody else on your list. It also converts an unquantifiable exposure into a smaller list you can actually stand behind, which is worth more than the vanity number.

How does this interact with the Privacy Act?

They cover different ground and both apply. The Spam Act governs sending commercial electronic messages, meaning consent, identification of the sender and a working unsubscribe. The Privacy Act 1988 and the Australian Privacy Principles govern how you collect, hold, use, disclose and secure personal information, including obligations around direct marketing and a person’s ability to ask what you hold and have it corrected. Integrations sit right in the middle because they copy personal information into more systems, so the practical requirement is a written map of who holds what and a process that can action a request across all of it.

What happens to consent when we add a new system?

This is the moment a working design either holds or quietly breaks, and it is worth having a rule. Any new system that will hold customer contact details must read consent from the declared authority rather than maintaining its own flag, must be added to the suppression propagation, and must be added to the map of systems holding personal information. Make that a required step in whatever process you use to adopt new software. Most consent failures we see did not originate in a bad design, they originated in a good design that a new tool was never connected to.

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.