Guide

Consent at send time: why campaign-time checks are not enough

A campaign approved on Monday can include someone who opted out on Tuesday. If your system checks consent only once, it will eventually contact the wrong person.

The gap between approval and action

Most outreach tools check eligibility when an audience is built or a campaign is launched. For simple email blasts sent immediately, that may be close enough. For sequences that run over days, or AI agents that place calls over weeks, it is not.

Between approval and action, things change: people withdraw consent, numbers are added to suppression lists, quiet hours start, frequency caps are reached, a provider rate limit is hit, or an operator decides to pause everything. A system that remembers only the launch-time answer will act on stale information.

What an execution-time check does

An execution-time check runs immediately before each outbound action and asks the same questions every time:

  • Is there valid consent or another recorded basis for this person, channel and purpose?
  • Is the contact on a suppression list for this channel, tenant or globally?
  • Is it inside permitted hours for the recipient’s location?
  • Have frequency or volume caps been reached?
  • Is the campaign, agent, provider or tenant switched off?
  • Are provider limits satisfied?

If any answer is no, the action is blocked and the reason is stored with the attempt.

Why store the decision

Blocking is only half the value. Storing the inputs and result of each check gives you evidence: why a message was sent, why another was suppressed, which consent record applied. When a complaint arrives or an auditor asks, you can answer from data rather than memory.

One opt-in is not every opt-in

Consent is specific. Agreeing to receive appointment reminders by SMS does not authorize marketing calls. Consent in one country may not meet requirements in another. Good systems store consent per channel, purpose and jurisdiction, with evidence, timestamp and expiry, and they never infer one from another.

Designing for failure

The policy check itself can fail: a database is unreachable, a cache is stale. The safe default for outbound activity is to block. A short pause in outreach is far cheaper than a message sent to someone who asked not to receive it. Inbound handling, where the customer initiated contact, can continue on last-known policy with an alert.

Questions to ask any vendor

  1. Is eligibility re-checked at the moment of each send, or only at launch?
  2. Where is the decision and its inputs recorded?
  3. How fast does an opt-out reach every channel?
  4. What happens if the policy service is down?
  5. Can I stop all outbound activity in one step, and how quickly does it take effect?

Software cannot make outreach lawful by itself. Rules differ by country, channel and use case. Review your policy configuration with your own counsel.

Frequently asked questions

Does this slow down sending?

The check is designed to be fast and runs in the path of each action. Throughput is bounded mainly by provider rate limits.

What about transactional messages?

Different rules often apply to service messages, but the same machinery can enforce channel, contact-window and suppression rules. Define the policy for each message purpose with your counsel.

Want to see these controls in a working platform?

Book a 30-minute walkthrough and we will show you each control, and where it ends.