Engagement-tiered frequency policy vs flat cap: different limits per engagement segment vs one number for everyone

A flat cap applies the same max messages/window to every profile; an engagement-tiered frequency policy assigns different limits to segments and shares that policy across campaigns that use it.

What is an engagement-tiered frequency policy vs a flat cap?

Flat cap is one number for everyone: “max 3 emails per 7 days” whether the person opens everything or ghosts you. An engagement-tiered frequency policy groups profiles by engagement (hot / warm / cold, or VIP openers vs dormant) and assigns different caps per tier—then reuses that named policy across multiple campaigns and journeys so you do not reinvent limits in every flow.

Flat caps are simple and fair-looking. Tiered policies are how you protect inbox trust without starving your best customers of useful messages—or blasting cold users at the same intensity as VIPs.

How does each model work?

Flat cap

1. You pick channel + window + max count (e.g. SMS ≤ 2 / 48h).
2. Every profile shares that ceiling.
3. When a send would exceed the cap, it is skipped, delayed, or dropped per your product rules.
4. Campaigns that do not opt into the cap ignore it unless the cap is global.

Engagement-tiered frequency policy

1. You define engagement segments (opens/clicks last 30d, RFM-ish activity, or explicit VIP flags).
2. Each tier gets its own max/window (VIP email 8/7d, warm 4/7d, cold 1/14d).
3. The policy is a shared object: several campaigns and journeys reference the same policy.
4. When engagement changes, the profile’s effective cap changes with the segment—without editing every flow.

Compare this to rate limiting vs frequency capping: rate limiting throttles the pipe; frequency capping protects the person. Tiered policy is a smarter person-level cap. Also separate from smart-sending window vs flow frequency filter—that post is account-wide recent-send skip vs local flow rules; this one is one shared limit vs limits that vary by engagement tier.

Concrete examples

Fashion ecommerce — VIP vs dormant

VIP openers (open rate high last 30d) tolerate 5–7 fashion emails/week during launches. Dormant buyers should get 1 nurture / 14d plus transactional only. A flat “3/week for all” either annoys dormant inboxes or leaves VIP launch revenue on the table.

B2B SaaS — trial vs paid power users

Trial users: low email cap, high signal-to-noise. Power users who click product tips weekly: higher educational cap. Flat caps force the same ceiling and usually under-educate the people who actually want tips.

Marketplace — SMS during peak season

SMS flat cap of 2/48h is a good safety floor. Tiered policy can still allow VIP buyers one extra logistics SMS while freezing promo SMS for cold profiles—without rewriting every journey.

When to choose which

1. Early-stage / one campaign → flat cap is fine.
2. Multiple journeys fighting the same inbox → named tiered policy.
3. You already have reliable engagement segments → tiered.
4. Engagement data is noisy or delayed → fix segments before tiering; a bad tier is worse than a flat cap.
5. Enrollment volume control is a different knob—see every event vs once within a window.

Leadara mapping (events, segments, journeys, email/SMS)

Build with Leadara primitives only:

• Events: opens, clicks, deliveries (and suppressions) feed engagement segments—do not invent vanity events.
• Segments: hot / warm / cold (or VIP / regular / dormant) with clear refresh rules.
• Journeys / campaigns: attach the same frequency policy object where supported; avoid per-flow copy-paste numbers that drift.
• Email / SMS: separate caps per channel; SMS tiers should be stricter than email tiers.

Common mistakes

• Calling a per-flow “max 2” a policy when three other flows still send uncapped.
• Tiers based on lifetime opens with no recency window.
• Same numeric cap for email and SMS.
• Moving someone to “cold” and still running aggressive winback + promo + digest the same week.
• Editing tier thresholds mid-campaign without a changelog.
• Confusing pipe rate limits with person frequency policy.

One-line takeaway

Flat cap = one max/window for every profile; engagement-tiered policy = different limits per engagement segment, shared across the campaigns that opt in.

Next step

List every live journey that can email or SMS the same person this month. If they do not share one frequency object, either wire a flat global floor today or define three engagement tiers and one named policy before the next launch.

FAQ

Is a tiered policy unfair?

It is intentionally unequal. Document why VIP gets more; fairness here means “appropriate to engagement,” not “identical counts.”

Do transactional messages count?

Usually exclude OTP/receipts from marketing caps—or use a separate transactional policy. Mixing them silently breaks trust metrics.

How often should tiers refresh?

Daily is common; weekly if events are sparse. Real-time is nice but not required for email.

Can flat and tiered coexist?

Yes: global flat floor (never more than N) plus tiered ceilings underneath. Floor protects; tiers allocate.

What if someone is hot on email and cold on SMS?

Cap per channel. Cross-channel “total messages” caps are optional extras.

Does this replace smart-sending windows?

No. Smart-sending skips based on recent send; frequency policy caps count in window. Use both.

How do we A/B a policy?

Hold out a small percent on the old flat cap; compare unsub, complaint, and revenue-per-recipient—not just open rate.

Step-by-step for growth

1. Pull 30-day open/click distributions; propose three tiers with plain names.
2. Draft caps per channel per tier; get brand + support sign-off.
3. Implement engagement segments in Leadara; verify membership counts.
4. Attach one shared policy to all promo journeys; leave transactional aside.
5. Monitor unsub and complaint by tier for two weeks.
6. Only then raise VIP caps—never raise cold first.

Programmer-shaped sketch

policy = {
  "vip":   {"email": (8, "7d"), "sms": (3, "7d")},
  "warm":  {"email": (4, "7d"), "sms": (2, "7d")},
  "cold":  {"email": (1, "14d"), "sms": (0, "7d")},
}
tier = engagement_segment(profile)
if count(profile, channel, window) >= policy[tier][channel].max:
  skip_or_delay(send)

Guards: exclude transactional; version threshold changes; one shared policy id in every promo journey.

Metrics

• Sends per profile per week by tier
• Unsub / spam complaint by tier
• Revenue per recipient by tier
• Share of skipped sends due to cap

PM language

Say “cold tier is 1 email / 14d shared across launch + digest,” not “the tool randomly blocks sends.”

Acceptance tests before you raise VIP caps

1. Pick ten VIP and ten cold profiles; count marketing email/SMS they would receive under the new policy for the next 14 days.
2. Confirm transactional receipt/OTP paths are excluded from the policy object.
3. Fire a launch campaign that opts into the policy and a digest that also opts in—same person must not exceed the tier ceiling across both.
4. Move one profile from warm → cold in the segment and verify the next promo is skipped or delayed.
5. Review support macros: agents should explain “you are on the lower-frequency tier because recent engagement dropped,” not “the system is broken.”

Reporting language for weekly growth review

Write one line in the doc: policy=engagement_tiered_v3, email vip=8/7d warm=4/7d cold=1/14d, sms vip=3/7d warm=2/7d cold=0, transactional=excluded. That single line prevents three Slack threads about “why didn’t my launch send.”

Channel checklist

• Email tiers: can creative quality absorb higher VIP volume, or will you just send more mediocre launches?
• SMS tiers: default cold to zero promo SMS unless they texted you first.
• Push (if you add it later): never copy email caps blindly—push fatigue arrives faster.
• Cross-channel total: optional; only add after per-channel tiers are stable.

Versus per-flow frequency filters alone

A filter inside one flow cannot see the digest, the winback, and the launch fighting the same inbox. Named shared policy is the coordination layer; per-flow filters remain useful for local pacing (e.g. “this abandoned-cart SMS at most once per cart”). Use both: shared policy for the person, local filter for the path.

Related reading

• Smart-sending window vs flow frequency filter: account-wide recent-send skip vs per-flow rules
• Rate limiting vs frequency capping: throttle the pipe vs protect the person
• Every event vs once within a window: fire on each signal or throttle enrollment