Frequency-cap queue delay vs drop: hold the message until the cap frees vs discard it

A frequency-cap queue delay holds a suppressed send for a configurable window (often hours–days) and delivers it when day/week/month caps and DND/time-gap allow; drop discards the send if it cannot go out immediately under those rules.

What is the difference between FC queue-delay and drop?

Frequency capping protects the person—not the send pipe. When someone has hit today’s cap and a journey wants to send a nurture email or promo SMS, engines usually do one of two things:

1. Queue-delay: park the send, re-check caps and quiet hours until a TTL, then deliver if allowed.
2. Drop: kill that send attempt. It will not come back unless another step or trigger fires later.

Do not confuse this with rate limiting vs frequency capping: rate limits protect infrastructure; FC protects the relationship.

Decision table: nurture vs flash sale

See also SMS quiet hours vs quiet days.

Iranian store example on Kavenegar

Caps: max 2 promo SMS/day, 3/week. Black Friday journey plans three messages.

• Under Drop, if the shopper already got two morning promos from parallel campaigns, the noon third dies—even if the cap frees at evening.
• Under Queue with 18h TTL, the third may land evening/night (respecting quiet hours) and still hit the sale window.

Practical TTL: shorter than discount-code life and shorter than inventory window—often 6–12h for flash, 24–48h for steady nurture.

Engagement-tiered policy

A flat cap for everyone can be blunt. Some teams raise caps for highly engaged users and tighten for cold ones—see engagement-tiered frequency vs flat cap. Queue beside a tiered cap means “wait for a VIP slot”; drop for cold contacts means “this promo isn’t worth the annoyance if there’s no slot.”

Truthful Leadara mapping

With Leadara journeys and email/SMS (Kavenegar/Nikaline) you design frequency and quiet windows into campaigns and keep sensitive sends on a separate transactional-style path. Before scale, decide explicitly: when capped, queue or drop. Leadara AI Chat is an internal team dashboard assistant, not a customer-facing live-chat bot. Don’t invent WhatsApp unless public docs list it.

When to queue vs drop

1. Delayed value still high → Queue with explicit TTL;
2. Message only meaningful in a short window → Drop or very short queue;
3. Receipt/OTP-like → outside nurture FC;
4. Parallel journeys hitting one person → unify caps/priority first, then queue policy.

Configuration steps

1. Write separate day/week/month caps for email and SMS;
2. Lock Tehran quiet hours;
3. Put queue TTL or drop policy in each send-step brief;
4. QA with under-cap and at-cap profiles;
5. Review queued / delivered / dropped after the campaign;
6. Never give long queues to short-lived discount codes;
7. Turn Ignore FC on only for truly transactional cases—and verify whether it also bypasses time-gap.

Common mistakes

• Queue without TTL → next week’s message for yesterday’s sale;
• Drop with no alternate branch → silence;
• One cap shared blindly across email and SMS;
• Assuming queue is always “kinder” (not for flash sales);
• Ignore FC on all nurture.

FAQ

How long should I queue a Black Friday SMS under FC?

Shorter than code and stock life—often 6–12 hours; after that, drop is better than an irrelevant ping.

Does Ignore FC also skip the time-gap?

Platform-dependent. Write it in the brief and QA it; don’t assume every lock opens.

What happens when queue TTL expires?

Usually that send drops. Whether the journey advances depends on your design—state it explicitly.

Is queue policy the same for email and SMS?

Prefer channel-specific rules; SMS quiet hours are stricter.

What if two journeys queue at once?

Define shared caps and priority or they’ll both fire when the cap frees and feel spammy.

Does drop exit the journey?

Not necessarily—only that send is lost. Later steps may continue unless you exit separately.

Cart recovery: queue or drop?

Short queue aligned to code life; for flash inventory, honest drop beats a late message.

How do I summarize for leadership?

“Under FC we either queue with a TTL or drop; short TTL for Black Friday, longer for weekly nurture.”

Next step

For one real nurture and one flash journey, write separate Queue/Drop + TTL policies, test under/over cap profiles, and lock Tehran quiet hours before you scale.

Pre-campaign checklist

Before Black Friday or a big seasonal push, align with the channel team:

1. Separate daily/weekly caps for SMS and email written down?
2. Tehran quiet hours identical across promo paths?
3. Every send step has Queue+TTL or Drop in the brief?
4. Receipt/OTP-like messages kept off nurture FC?
5. Priority clear when parallel journeys hit one segment?
6. Who reads queued/dropped after the first 24 hours?
7. Is discount-code life shorter than queue TTL? (It must not be.)

If any answer is “we don’t know,” delay scale. A late irrelevant message costs more than an honest drop—especially when flash stock is gone.

Shared language with support and warehouse

Support should know “I didn’t get the discount SMS” may mean FC drop, not a Kavenegar outage. One internal line: “When the cap is full, nurture either queues or drops; transactional is separate.” Warehouse should know late messages can show expired codes—so align queue TTL with code life.

Dashboard metrics

• queued → delivered vs queued → expired
• mean queue time to send
• complaints/unsubs after queued vs immediate sends
• Ignore FC count per week (should stay near zero for nurture)

Related reading

• Rate limiting vs frequency capping: throttle the pipe vs protect the person
• SMS quiet hours vs quiet days: clock window vs banned calendar days
• Engagement-tiered frequency policy vs flat cap: different limits per engagement segment vs one number for everyone