Outreach planning · Practical guide

Outbound audience exclusion rules: define who must stay out before import

Define exclusion reasons before assembling the sending audience. Different reasons need different handling, but none should disappear merely because a contact is imported again.

Reviewed · Examples are illustrative

Who this helps: Business owners and operators planning audience, offer, ownership and review decisions.

Define the decision

An opt-out, an active customer and an unverified company identity are not the same state. A durable policy explains which records are prohibited from prospecting, which belong in another relationship workflow and which need more research. That distinction supports both consistent operations and useful reporting.

Work through the procedure

  1. List exclusion reasons with their scope, owner and source of truth.
  2. Separate durable stop requests from temporary holds requiring review.
  3. Reconcile the proposed audience against current exclusions before enrollment.
  4. Define how newly received exclusions propagate to pending work and future imports.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Exclusion matrix
Recipient opt-out: preserve across prospecting work
Active customer: route to the relationship owner
Open negotiation: coordinate with the opportunity owner
Ambiguous company identity: hold until verified
Unsupported service geography: exclude for this offer
Each row has a different reason, even if all are absent from today's campaign.

Read the result

The matrix allows an operator to explain why someone was excluded without erasing the underlying relationship. Temporary holds can be revisited through an explicit decision; stop requests should not be treated as expired research tasks. Keep campaign-specific fit exclusions separate from broader recipient preferences.

Check before moving on

  1. Check the actual matching scope, including exact domain behavior.
  2. Do not delete history as a substitute for preserving suppression.
  3. Reconcile exclusions after list merges and ownership changes.

Limits and next action

This is a policy-design method, not a claim of automatic cross-workspace suppression in Zintara. Verify the implemented owner and domain scope. Applicable legal obligations may require additional handling beyond this operational checklist.

Source: Zintara product context; procedures and examples are editorial guidance

Source references

Worked examples are illustrative. Editorial procedures are suggested methods, not measured performance claims or promises of additional product features.

Related guides

Explore the Zintara workflow