What is a direct mail preflight checklist?
A direct mail preflight checklist is the final review control before a postcard or letter batch is released. It checks the data, creative, postal-layout assumptions, approval state, tracking fields, seed records, and audit evidence that explain why the send was allowed to move forward.
Preflight is broader than a design proof. The proof shows what the recipient may see. The preflight record shows what the team reviewed, which exceptions were accepted, and which source records or batch IDs were tied to the release decision.
Why does preflight matter before postcards reach production?
Direct mail becomes hard to unwind once a batch is released. Preflight catches preventable errors while the team can still pause, correct, suppress, or re-approve the send: stale addresses, duplicate households, missing fallback copy, wrong tracking fields, or an unreviewed proof version.
The goal is not to make a postal, delivery, or response promise. The goal is to create a clean operator checkpoint: this audience was checked, this proof was reviewed, these records were excluded, these exceptions were accepted, and this batch is ready for the next state.
What should be checked before the audience is approved?
Audience preflight should verify the source system, import date, segment rule, required fields, address cleanup state, suppression results, duplicate handling, householding rule if used, and the final count that will appear in the proof or approval queue.
| Audience check | Evidence to keep |
|---|---|
| Source and segment | Source system, list import ID, segment rule, campaign ID, and the person or workflow that created the audience. |
| Address readiness | Required address fields, standardization status, exception counts, and unresolved rows that should not move forward. |
| Suppression | Suppression list version, reason codes, exclusion counts, and approved overrides if any exception is allowed. |
| Duplicate handling | Match key, duplicate groups, survivor rule, householding rule if used, and before/after recipient counts. |
| Final audience count | Approved recipient count that will be compared against the proof, batch record, and release log. |
What should be checked before creative is approved?
Creative preflight should confirm the current proof version, final size, front and back artwork, address-side layout, variable fields, fallback copy, URLs, QR codes, phone numbers, and any campaign-specific identifiers that appear on the mailpiece.
USPS Postal Explorer publishes mailpiece design resources, and the Domestic Mail Manual includes physical standards for commercial mailpieces. Those sources are useful references when the team checks size, address-side layout, barcode space, and whether a design needs further review.
Operator rule: treat the proof as an internal review artifact. Do not treat the proof as a postal acceptance record or as proof that a campaign will be delivered, tracked, or answered.
What should be checked before the batch is released?
Release preflight should connect the final audience, approved proof, batch count, seed records, tracking fields, and approval decision in one record. The reviewer should be able to answer what changed, who approved it, and which batch moved forward.
| Release item | Preflight question |
|---|---|
| Batch identity | Does the batch ID match the approved audience count, proof version, and campaign ID? |
| Tracking fields | Are campaign IDs, QR URLs, phone numbers, coupon codes, or Intelligent Mail barcode fields present only where intended? |
| Seed records | Are internal test recipients or seed records included for review without being mistaken for response evidence? |
| Exceptions | Were rejected rows, override decisions, and accepted risks recorded before release? |
| Approval | Is there a named owner, timestamp, release decision, and state change from draft or review to approved? |
How is preflight different from a print proof?
A print proof checks the visible mailpiece and sample recipient rendering. A preflight checklist checks the whole release package: source list, suppression, dedupe, proof version, approval owner, batch ID, tracking fields, seed records, and exception decisions.
Teams often need both. The proof helps reviewers catch creative and variable-data problems. The preflight checklist helps operations confirm that the proof is connected to the right audience, count, workflow state, and release evidence.
What does a simple preflight workflow look like?
A practical preflight workflow moves through four checks: audience readiness, creative readiness, batch readiness, and release evidence. Each check should produce a small record that can be reviewed later if a returned mailpiece, bad personalization field, or tracking gap appears.
| Stage | Pass condition | Adjacent guide |
|---|---|---|
| Audience readiness | Address review, suppression, dedupe, householding, and final counts are complete. | List hygiene |
| Creative readiness | Proof version, variable fields, fallback copy, address side, and CTA paths are reviewed. | Print proof |
| Approval readiness | Reviewer, owner, proof version, audience count, and exceptions are visible before release. | Approval queue |
| Batch readiness | Batch ID, seed records, tracking fields, counts, and release decision are tied together. | Mail batch |
What should the preflight record preserve?
The preflight record should preserve the final count, source list, proof version, suppression version, duplicate rule, householding rule if used, seed records, tracking fields, approver, timestamp, release state, and exception notes. It should be useful without relying on a teammate’s memory.
This is where preflight supports later measurement and troubleshooting. If a team sees a returned piece, a tracking mismatch, or an unexpected response source, the record should make it clear which batch was sent and what was approved.
FAQ
What should a direct mail preflight checklist include?
A direct mail preflight checklist should confirm the audience source, suppression results, address review, duplicate rules, creative proof, variable-data rendering, approval owner, batch counts, tracking fields, seed records, and release decision before the job moves into production.
Is preflight the same as a print proof?
No. A print proof checks the visible mailpiece and sample data. Preflight checks the whole release package: audience inputs, suppression, dedupe, proof approval, batch metadata, tracking fields, seed records, exception decisions, and the audit record.
When should a direct mail preflight check happen?
Preflight should happen after the audience, proof, and approval inputs are ready, but before a batch is released. The goal is to catch data, creative, tracking, and release-control issues while the send can still be paused or corrected.