One email that protects your agency: documenting consent decisions in writing
Consent projects go wrong in the handover, not the build. The banner works, the blocking rules are right, and then six months later the client changes a theme, adds a plugin, or hires a new marketing person who installs a pixel. Something breaks. The client points at you. And the only thing standing between your agency and the liability is what you wrote down when the project shipped.
Most agencies document the build. Very few document the decisions. The build is the configuration. The decisions are who chose what, what was rejected, and what the client was warned about. When consent breaks later, the decisions are what matter, and they are the part nobody wrote down.
What actually protects an agency
It is not a longer contract. Contracts set the frame, but they rarely capture the specific judgment calls of a consent project: that the client declined the reject-all button redesign, that they insisted on keeping a non-compliant analytics setup for historical data, that they were told the chat widget sets cookies before consent and chose to keep it anyway.
What protects you is a contemporaneous written record that the client made those calls with the tradeoffs explained. An email sent the week the project shipped, listing the decisions and the warnings, is worth more than any clause added to the master agreement afterward. Courts and clients both trust records made at the time over reconstructions made during a dispute.
The email to send at every handover
Write it the day the project goes live, while the details are fresh. Address it to the client's decision maker, not just the day-to-day contact. Keep it short and specific. It should cover five things.
First, what was implemented: the consent tool, the blocking approach, the banner configuration. Second, the choices the client made against your recommendation, stated plainly. Third, the known gaps: third-party tools that set cookies before consent, embeds that bypass the banner, anything on the known-issues list. Fourth, what changes will break the setup: theme updates, new plugins, new marketing tools, each named. Fifth, what you recommend going forward: a recheck cadence, who to call before adding tracking tools, and the fact that consent is maintenance, not a one-time project.
Ask for a reply confirming they received and understood it. A one-line "confirmed" from the client turns your record into their record too.
Why email beats the project doc
The handover document lives in a shared drive nobody opens again. The email lives in both inboxes, timestamped, with the client's own reply attached. When the dispute comes, you are not searching for a PDF. You are forwarding a thread.
Email also forces brevity. Handover docs bloat into thirty pages that bury the three decisions that matter. The email format disciplines you to name the decisions, the warnings, and the breakage risks in language a non-technical client can actually understand. That clarity is itself protective: it is much harder for a client to claim they were never warned when the warning was a five-bullet email they confirmed.
The decisions worth documenting every time
Some calls recur across nearly every consent project. The client who wants the banner to default to accept. The client who will not remove a non-compliant tool because "legal said it was fine" without putting that in writing. The client who declines ongoing monitoring to save the retainer fee. Each of these is a liability fork, and each deserves its own bullet in the email.
Also document what you do not control. The client's hosting, their tag manager access, their marketing team's autonomy to add scripts: name the boundaries. "We configured consent on the current site. Changes made by your team or other vendors after handover are outside this scope." That sentence has saved more agencies than any insurance policy.
Making it a system, not a favor
The agencies that do this well do not rely on individual project managers remembering to write the email. They make it a checklist item in the handover process, with a template and a named owner. The template lists the five sections. The owner fills in the project specifics. The project does not close until the email is sent and confirmed.
That sounds like process overhead. It is about ten minutes per project. Compare that to the cost of one liability dispute where the client claims the agency never warned them about the thing that is now a regulatory complaint. Ten minutes is cheap.
The bottom line
Your consent work is only as defensible as its paper trail. The build will drift the moment it leaves your hands. The email you send at handover is the record of what you built, what the client chose, and what you warned them about. Write it the day you ship, keep it short, get the confirmation reply, and make it a checklist item so it happens every time. Future-you, mid-dispute, will be grateful.
Common questions
Is an email really enough, legally?
It is evidence, not a legal shield by itself. It shows what was communicated and when, which is usually the contested point. Pair it with a solid contract, but do not mistake the contract for the record of project-specific decisions.
What if the client will not reply to confirm?
Send it anyway and note the non-response in your project file. A sent, unanswered warning still beats no warning. Follow up once, then move on; you cannot force a reply, but you can prove you asked.
Should this be a separate email or part of the handover doc?
Separate email, always. It can reference the handover doc, but the decisions and warnings need to live in the thread, timestamped and confirmed, not buried in a document.