Most double opt-in implementations I audit are a confirmation email and a hope. Someone built the send, nobody modelled the states, and nobody can answer the one question that actually matters when a complaint arrives: on what date did this person consent, to what wording, and can you show me?
What this package fixes
- Consent modelled as a state — pending, confirmed, expired, withdrawn — not as a boolean nobody can audit.
- The exact wording each person agreed to, stored with a timestamp and a source.
- Withdrawal that propagates everywhere, including into journeys already in flight.
- A confirmation flow that actually converts, rather than losing a third of signups to a badly worded email.
- Documentation your legal team or a Datenschutzbeauftragter can read without you in the room.
Why this goes wrong so often
Double opt-in looks simple, which is exactly the trap. Four failures show up again and again:
1. "Confirmed" is a checkbox, not a state
Someone signs up. A flag flips. But there is no distinction between we sent the confirmation and they never clicked and they never asked in the first place. Those are legally different situations and they need different handling. A boolean cannot express the difference, so the org quietly mails people who never confirmed.
2. The wording is not stored
You can prove someone ticked a box. You cannot prove what the box said, because the form has been edited four times since. Under DSGVO the burden of proof for consent sits with you, and “we have a timestamp” is only half an answer.
3. Withdrawal does not reach everywhere
Someone unsubscribes on Tuesday. A journey they entered on Monday has a three-day wait and sends on Thursday. Whether that send happens depends entirely on whether the send step re-checks consent or trusts the entry-time evaluation. This single scenario is the most common way a technically compliant organisation sends a non-compliant email.
4. The confirmation email is an afterthought
It arrives from a no-reply address, has a subject line like “Please confirm”, and gets ignored. Confirmation rates of 50–60% are common and are treated as normal. They are not normal — they are a badly designed email, and every unconfirmed signup is acquisition spend you already paid for and cannot use.
The test
Pick a contact who signed up eight months ago. Can you produce, in under five minutes: the date they consented, the exact wording shown to them, the IP or source, and whether they have withdrawn since? If any of those four takes longer than five minutes, this package pays for itself the first time someone asks.
What you get
| Deliverable | What it means in practice |
|---|---|
| Consent data model | States, transitions and the fields that hold them, built in Account Engagement or Data 360 depending on your platform |
| DOI flow | Signup → pending → confirmation send → confirmed, with an expiry rule for people who never click |
| Wording archive | Each consent record stores the version of the text the person actually saw |
| Withdrawal propagation | One authoritative store, re-checked at send time — including mid-journey |
| Confirmation email rebuilt | Written to be opened and clicked, not just to exist |
| Preference centre review | So it writes back to the same store rather than holding a second opinion |
| Documentation pack | A written description of the model, in German if you need it, for your legal file |
How it runs
- Days 1–2 — audit. What exists today, where consent is stored, which capture points write to it, and which of the four failures above you have. You get the findings whether or not you continue.
- Days 3–4 — model. The state machine, agreed with you before anything is built. This is the part that determines whether it holds up.
- Days 5–8 — build. Flows, fields, forms, confirmation email, suppression rules.
- Days 9–10 — test and document. Including the mid-journey withdrawal case, which is the one everyone skips.
Worth knowing before you buy
I am not a lawyer and this is not legal advice. What I build is the technical implementation of the consent model your legal counsel specifies — and, where you have no specification, a sensible default based on how DSGVO is commonly interpreted for B2B marketing. If your Datenschutzbeauftragter wants something different, we build what they want.
Best for
- Organisations marketing into Germany, Austria or Switzerland where DOI is the expected standard
- Teams who inherited a Salesforce marketing setup and have never audited how consent is stored
- Anyone who has had a complaint, a warning letter, or an uncomfortable question from legal
- Teams about to migrate — because migrating a broken consent model just relocates the problem
Price and duration
From €2,900. One to two weeks. Fixed scope, fixed price, agreed before work starts. Priced on outcome rather than on days.
If the audit in days 1–2 finds your consent model is already sound, I will tell you and we stop there — you pay for the audit only.
Sound like your org?
Thirty minutes, free, no slides. Bring your questions about scope, timing or whether this package is even the right one — you will get straight answers.