Guide

How to QA an email against the copy deck

The copy deck is the contract. Legal read it, the client signed it, and the email must say what it says — no more, no less. Most teams “check the copy” by reading the email top to bottom with the deck open beside it. That catches the big misses and reliably ships the small ones. Here’s the comparison done properly.

Both directions, always

One direction asks: is every deck line in the email? The other asks: is every email line in the deck? Teams run the first and skip the second, which is how unapproved copy ships — a leftover module from the cloned template, a developer’s placeholder headline, a stale legal paragraph. If a sentence in the email has no source in the deck, that’s a finding even when the sentence is fine.

Respect the deck’s own structure

A production copy deck isn’t prose — it’s sectioned: preheader, headline, body blocks, example modules, step lists, CTA labels, legal. Compare section to module, not wall-of-text to wall-of-text. Two structural gotchas break naive diffs:

• Version numbering is campaign-wide. Decks commonly label the launch email Version 1 and the reminder Version 2. A comparison that asks the reminder for “version 1” silently reads launch copy and floods the report with false differences.
• “Same as launch” is an instruction, not text. When a reminder section says it, the comparison must pull the launch section’s copy — not flag the literal words “same as launch” as missing from the email.

The parts everyone skips

• Alt text. Decks declare alt text per image. The email’s alt must say what the deck says — “Gift box icon” is not “Gift box bursting open with points”, and a rating scale with alt="1" through "5" is an accessibility finding hiding in plain sight. Verdicts here should be binary: matches, or differs with both strings shown.
• The links table. Decks list every link’s label and destination. Match by destination when you can; when click-tracking hides the URL, follow the wrapper to where it actually lands. A correctly-labeled link to the wrong page is the miss that label-checking can never catch.
• Placeholders and tokens. %%FirstName%% and friends should compare as wildcards, not as literal mismatches — but a token present in the email and absent from the deck (or vice versa) is real.

What “different” should mean

Case, whitespace, punctuation, and smart-quote substitutions are build noise; a QA comparison should read through them. A changed word, a dropped clause, a different number, a missing sentence — those are the campaign. The worst output a comparison can produce is “73% similar, verify manually”: it does the reading AND leaves you the homework. A useful verdict is binary, with the evidence side by side.

Done by hand vs done by machine

This comparison is the core of what SendLint automates: attach the .docx deck once per campaign, and every analysis reads the right language column and the right version, honors same-as-launch markers, verifies alt text and link destinations, and reports binary verdicts with both strings shown. Your read-through becomes a review of findings instead of a hunt for them.