Consent is a data model, not a checkbox

Most systems store consent as a single field: marketing_opt_in: true. Then a complaint arrives and someone asks when it was given, for what, on which channel and how — and the answer is a shrug.

Consent here means a person's permission for you to contact them for a given purpose. Handling it well is a legal duty in most places, and it is also good business.

1. When? Consent ages. Expectations about refreshing or re-confirming old permission vary by country and by industry code, but "they ticked a box in 2017" rarely ends a complaint well.
2. For what? Agreeing to delivery updates is not agreeing to weekend promotions. If both read the same field, you cannot honour the difference even if you want to.
3. On which channel? Permission to email is not permission to text or to message on WhatsApp. This is the most common modelling error in the category.
4. How? A ticked box at checkout, a texted keyword and a verbal yes on a call carry different weight as evidence. "The field was true" is not evidence.
5. Was it withdrawn? Under the EU's GDPR (Article 7), withdrawing consent must be as easy as giving it, and many other regimes have similar expectations. Withdrawal must take effect everywhere — including in a campaign that is already queued.

Not a field on the contact. An append-only ledger — a log you only ever add to — of grants and withdrawals. Your current permission is then a query over the ledger ("latest event for this person, channel and purpose"), not a stored value.

A few rows for one customer might look like this:

This sounds like extra work. It is much less work than reconstructing history from application logs the first time someone asks.

Worth separating, because mixing them up costs you reachable customers.

• Consent is whether you may contact someone at all for a purpose. A legal question with a yes or no answer.
• Preference is how they would like to be contacted — which channel, how often, about what. A product question with many answers.

A system with only consent offers one control: off. A system with preferences offers "less often", "only order updates", "by email instead" — and many people who would have chosen off will choose one of those. That is the commercial case for the ledger, and it usually pays off sooner than the compliance case.

The import with no history. A list arrives from an acquisition, a partner or a spreadsheet, and every row is written as "imported" and nothing else. Record the source file, the date and who vouched for it. Weak provenance is still a fact; a blank field is a gap you cannot close later.

The withdrawal that reaches only one system. Someone unsubscribes in the email tool; the SMS platform never hears. This failure generates complaints, and it is architectural: if suppression lists live in each vendor rather than centrally, every vendor is a place a withdrawal can fail to arrive. Keep one central suppression list that every sending system checks.

The consent that outlives its purpose. Permission for delivery updates gets read, two years later, as permission to market. Nobody decided that; the data model simply could not tell the difference.

You may need to prove the basis for a message sent years ago, so consent records often need to outlive the customer relationship. That sits awkwardly with deletion duties. A common resolution: treat the consent event as a record of what happened, keep only the minimum needed to evidence it, delete the rest with the contact, and document the reasoning. Take local legal advice on retention periods.

Since 2 August 2026, Article 50 of the EU AI Act requires that people be told, clearly and at the first interaction, when they are dealing with an AI system rather than a person. If an automated agent handles part of your conversations with people in the EU, that disclosure belongs in the same part of your architecture as consent — recorded per conversation, with evidence — and is worth doing everywhere. See AI Act Article 50 for messaging.

• Can I see consent and opt-out events per contact, per channel and per purpose, with timestamps?
• When someone replies STOP, how quickly is it reflected, and can I receive it by webhook to update my own ledger?
• Can I export the full consent history if I leave?

• Sender registration around the world — the next step in this track.
• Consent architecture — the deeper design.
• Omnichannel is an identity problem — why consent belongs to each identifier.