What is a direct mail send rule?
A direct mail send rule is the decision logic that decides whether a customer event, list record, or workflow state is allowed to become a mailed piece. It turns a possible send into an approved, held, or rejected send decision.
The rule matters because automated direct mail can move faster than manual review. A clear send rule gives operators a repeatable way to stop incomplete records, suppressed recipients, duplicate sends, unapproved proofs, and missing campaign metadata before a batch moves forward.
How is a send rule different from a trigger?
A trigger is the event that asks for mail. A send rule is the review logic that decides whether the request is eligible. For example, a new lead can trigger a postcard, but the send rule still needs to check address readiness, suppression, proof approval, and duplicate-send history.
This difference keeps automation safer. A trigger says, "something happened." A send rule says, "this record is ready enough to release or should be held for review." For more context on trigger events, see the triggered postcards guide.
What inputs should a direct mail send rule check?
A send rule should check the event, audience record, postal address fields, suppression results, duplicate-send window, proof version, campaign ID, batch rules, and tracking fields. The rule should save both the decision and the reason code.
| Input | Question the rule answers | Safe decision |
|---|---|---|
| Trigger event | Did a real event ask for mail? | Proceed only when the event type is allowed for the campaign. |
| Audience record | Is the recipient or household eligible? | Hold if source, segment, or required identifiers are missing. |
| Address fields | Is the mailing address ready for review? | Hold incomplete, ambiguous, or exception records. |
| Suppression result | Should the recipient be excluded? | Reject or hold when an active suppression rule matches. |
| Duplicate window | Was this person or household recently mailed? | Hold when the duplicate-send rule requires review. |
| Proof version | Is the creative approved? | Hold until the approved proof and variable fields are known. |
| Campaign metadata | Can the send be tracked later? | Hold when campaign ID, batch ID, or response path is missing. |
What should stop a send rule?
A send rule should stop or hold a mailpiece when required fields are missing, the address is not ready for review, a suppression rule matches, a duplicate-send window is active, the proof is not approved, or required campaign and batch identifiers are missing.
Those stops should be explicit. "Do not send" is not enough for a useful operations record. The system should capture the reason, the source of the decision, the reviewer if a human override occurs, and the next state for the record.
How do postal and address checks fit into the rule?
Postal and address checks should be upstream inputs to the send rule. USPS Publication 28 covers postal addressing standards, the Domestic Mail Manual includes addressing standards, and USPS mailpiece-design resources help teams review physical layout before release.
These resources do not replace internal review. They help teams define address-readiness and layout-readiness checks before a campaign reaches a batch. The send rule should record whether the address, proof, and response fields were complete enough for the workflow to continue.
Operator rule: postal resources support readiness checks. They do not prove delivery, recipient exposure, response causality, or campaign lift.
How should a send rule save its decision?
A useful send-rule decision should save the rule version, input record, trigger event, eligibility result, reason code, hold or reject state, override details, campaign ID, batch ID, proof version, and timestamp. That record makes later audits and response review possible.
| Record field | Why it matters |
|---|---|
| Rule version | Shows which logic made the decision. |
| Input record ID | Connects the decision back to the original audience or event record. |
| Decision state | Separates approved, held, rejected, and manually overridden records. |
| Reason code | Explains why the rule acted. |
| Proof version | Shows which creative version was eligible for release. |
| Campaign and batch IDs | Keep later tracking and attribution tied to the send decision. |
| Reviewer notes | Capture manual exceptions without hiding them. |
How should teams handle manual overrides?
Manual overrides should be rare, named, and visible. When a reviewer releases a held record, the workflow should save who changed the state, what rule was bypassed, why the override was allowed, and whether the exception should change the rule later.
This keeps automation from turning into a black box. If the same override happens repeatedly, the team may need a better rule. If an override is a one-off exception, the audit record should make that clear during review.
How does a send rule connect to duplicate-send prevention?
Duplicate-send prevention is one check inside a broader send rule. The send rule decides whether the current request can proceed; the duplicate-send check asks whether the same person, household, or address has already been mailed inside the review window.
For the duplicate-specific workflow, see the duplicate-send prevention rule guide. The send-rule record should preserve the match key, window, prior batch reference, and exception state when a duplicate check changes the decision.
What should a Sendvo-style workflow keep visible?
A Sendvo-style workflow should keep the send rule close to the campaign record: trigger event, audience source, address-readiness state, suppression result, proof approval, duplicate-send decision, batch ID, tracking fields, and final release state.
Sendvo is in beta, so product language should stay capability-framed. The operational pattern is stable: the rule should make a repeatable decision, save the evidence, and keep the campaign ready for later tracking and measurement review.
FAQ
What is a direct mail send rule?
A direct mail send rule is the decision logic that decides whether a customer event, list record, or workflow state is allowed to become a mailed piece. It should check eligibility, address readiness, suppression, duplicate windows, proof approval, campaign metadata, and audit records before release.
Is a send rule the same as a trigger?
No. A trigger is the event or condition that asks for mail, such as a new lead or abandoned cart. A send rule is the review logic that decides whether that triggered request is safe, complete, and eligible to release.
What should stop a direct mail send rule?
A send rule should stop or hold a mailpiece when required fields are missing, the address is not ready for review, a suppression rule matches, a duplicate-send window is active, the proof is not approved, or required campaign and batch identifiers are missing.