# Lifecycle Frequency Caps: Coordinate Messages Across Journeys Canonical URL: https://www.martechdevs.com/blog/lifecycle-frequency-caps By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo) Data Engineer and Co-founder, martechdevs Published: 2025-02-13 Last updated: 2026-09-17 Lifecycle frequency caps limit how much eligible communication a person receives, but they do not decide which message deserves the next available slot. Combine caps with message priority, expiry, channel permission and current customer state. Check how your platform counts time and handles blocked messages, because a skipped send, delayed send and completed journey can mean different things. A customer can qualify for onboarding, a webinar invitation, a product announcement and a renewal reminder on the same morning. Each campaign owner can follow their own calendar and still create a poor combined experience. The solution is a shared communication policy across journeys. In [CRM and lifecycle implementation](https://www.martechdevs.com/crm-lifecycle), that policy should sit beside the eligibility rules, so a new automation joins an existing operating system rather than adding another uncoordinated stream. ## Which controls solve which problems? A frequency cap limits counted sends to a person during a defined window. A throughput limit controls how quickly a system sends messages overall. Quiet hours restrict the time of day. Consent or subscription preferences determine whether a message is permitted. Journey eligibility determines whether it is relevant. These controls can interact, but none replaces the others. Sending more slowly does not necessarily reduce the total received by one person. Being below a cap does not establish permission. Waiting until morning does not make an expired offer useful. Braze documents both delivery-speed controls and frequency caps as distinct mechanisms. It also notes that a frequency-capped Canvas message can be skipped while the person continues to the next step. [Braze delivery controls](https://www.braze.com/docs/user_guide/messaging/messaging_fundamentals/frequency_capping). That distinction changes reporting. A person who reached the end of a journey may never have received an intermediate message. When a later step assumes “you saw our setup instructions,” verify the prior delivery or rewrite the follow-up so it stands on its own. ## How should you define the policy? Begin with the customer's experience, then map it to supported platform settings. Specify the audience identity, included channels, counted event, time window, exclusions and blocked-message behaviour. Write each rule so two operators would reach the same decision. An illustrative SaaS policy might say: - At most two optional lifecycle messages in any rolling 24 hours. - At most five optional lifecycle messages in any rolling seven days. - At most one promotional SMS in any rolling 24 hours, also subject to the shared cap. - User-requested security or account actions follow their own delivery and abuse controls. - A blocked promotion expires at the end of its useful offer period. - A blocked setup reminder is reconsidered only while the underlying setup task remains incomplete. These numbers are an example for testing, not universal best practice. A travel service with time-sensitive trip updates and an infrequently used B2B application need different policies. Document the reason for the starting limits, then change them using customer and business outcomes. Separate “ignores the marketing cap” from “does not count toward any measure.” A service message might need immediate delivery while still being visible in a complete communication history. That history can help the team avoid piling an optional promotion onto an already busy account. ## Does one day mean a calendar day or 24 hours? This detail can produce visibly different behaviour. Braze documents calendar-day frequency calculations using the user's time zone. Customer.io describes relative windows calculated from message timestamps. Those are different implementations of a daily limit. [Braze cap timing](https://www.braze.com/docs/user_guide/messaging/messaging_fundamentals/frequency_capping), [Customer.io message-limit windows](https://docs.customer.io/messaging/send/message-limits/overview/). For an illustrative one-message daily rule, a send at 23:50 followed by another at 00:10 can fit two different calendar days. It does not fit a rolling 24-hour limit. Neither calculation is inherently wrong; the mistake is configuring one while promising the other. Test boundaries using the actual customer's time zone, including the fallback when that value is missing. If your desired policy requires a rolling interval but the selected native control uses calendar days, add an appropriate eligibility rule or revise the policy explicitly. Do not assume the word “daily” guarantees the behaviour. Use longer windows alongside short ones when the business needs both pacing and cumulative restraint. A daily rule alone can still permit a message every day. A weekly rule alone can permit a burst at the start of the week. The intended combination should be tested as a whole. ## Do channel caps coordinate the whole experience? Not necessarily. Klaviyo documents independent Smart Sending windows for email, SMS and push. A recent email therefore does not by itself consume the SMS window. Messages skipped by Smart Sending are not automatically rescheduled. [Klaviyo Smart Sending](https://help.klaviyo.com/hc/en-us/articles/115002779311). If the business wants a cross-channel budget, confirm that the chosen platform and configuration support one. Customer.io supports shared limits for selected channels, but limits must be assigned to workflows or messages; creating the limit alone does not cover the workspace's communication. [Setting up message limits](https://docs.customer.io/messaging/send/message-limits/set-up-message-limits/). A channel fallback also needs a policy. Failing to deliver an email should not automatically justify an SMS if the customer has not permitted it or if the message is no longer useful. Decide whether the fallback represents the same business communication and how it affects the shared count. Review identity across channels. If the same person has two profiles, each can appear under its own limit. If several people share a phone number, treating each CRM record independently can overstate the number of distinct recipients. The [single customer view](https://www.martechdevs.com/blog/single-customer-view) is therefore part of frequency control, not just reporting. ## Which message should win when several are eligible? A cap commonly blocks a message after capacity has been consumed. It does not necessarily reserve capacity for the most valuable later message. A low-priority newsletter sent first can occupy the slot a useful activation reminder needs. Create a priority policy based on customer tasks. For example, an instruction needed to finish a setup action can outrank a general feature announcement. A scheduled account review can replace a generic adoption nudge for the same person. A recently opened support escalation can temporarily exclude an unrelated promotion. Avoid making revenue alone the priority score. An upsell opportunity can be commercially attractive and still be a poor message while the account is struggling with a service problem. Define the customer benefit and contraindications for each priority class. For a small programme, priority can be implemented through coordinated schedules and explicit exclusions. For a large programme, it may require a central eligibility service or shared queue. Choose the smallest mechanism that can consistently enforce the rules. A separate orchestration service introduces engineering and reliability work of its own. This is also why [customer journey mapping](https://www.martechdevs.com/blog/identify-key-customer-journeys) should identify competing messages. Journey diagrams drawn one at a time rarely expose the collision experienced by a person who qualifies for several. ## What should happen to a blocked message? Give each message one of three treatments: discard it, reconsider it later or escalate the underlying task through another approved route. The choice depends on whether the message still has value after waiting. A one-day promotion may be discarded when its window closes. An onboarding instruction may be reconsidered tomorrow if setup is still incomplete. A billing issue may require a separate service policy and account owner. The [dunning workflow guide](https://www.martechdevs.com/blog/saas-dunning-workflows) explains why payment-state checks matter more than blindly retrying a reminder. Do not assume leaving a journey cancels every queued retry. Customer.io explicitly documents that automatic retries for frequency-blocked messages can continue after the person exits the originating automation. For messages that become incorrect after a state change, review this behaviour before enabling auto-retry. [Retry configuration and exit behaviour](https://docs.customer.io/messaging/send/message-limits/set-up-message-limits/). A safer design for an expiring message may be to leave automatic retries off and arrange a later fresh eligibility decision, accepting that some messages will be skipped. If the platform cannot revalidate the necessary state at the required time, do not promise that every delayed message will remain accurate. Customer.io distinguishes messages awaiting a retry from those marked undeliverable and advises inspecting the reason because those statuses cover more than frequency caps. [Reviewing blocked messages](https://docs.customer.io/messaging/send/message-limits/review-message-limits/). Your report should preserve those explanations rather than call every missing send a deliverability problem. ## How would the policy handle a real collision? Consider a fictional customer who received an optional onboarding email yesterday at 14:00 and a webinar invitation today at 09:00. At 10:00 today, three more messages become candidates: a setup reminder, a feature announcement and an expiring promotion. Under the illustrative two-per-rolling-24-hours rule, no optional slot is available at 10:00. The oldest counted message leaves the window at 14:00. The coordinator should still check the seven-day limit and all other requirements before using that slot. At 13:00, the customer completes setup. At 14:05, the correct decision is to discard the setup reminder, then evaluate the remaining candidates. If the promotion has expired or is less useful than the feature announcement under the agreed policy, it should not be resurrected simply because capacity exists. Now imagine the newsletter system is separate from the lifecycle platform. If it sends another message at 12:00 without sharing its activity, the lifecycle platform's local counter no longer represents the full policy. Either bring the systems into the same decision path or state that the cap covers only a defined subset of communication. ![Remove inappropriate messages, rank useful candidates, check capacity and revalidate state before sending or reconsidering later.](https://www.martechdevs.com/assets/blog/lifecycle-frequency-caps.svg) The diagram describes a proposed coordination policy. Native product behaviour must be mapped and tested against it; it is not a claim that every platform supplies this exact queue automatically. ## How do you know the cap is helping? Measure the distribution of communication per person, not just average campaign volume. An average of two messages can hide a small group receiving twelve while most receive none. Inspect the busiest recipients and the journeys competing for their attention. Track candidate messages, blocked messages by reason, expired messages, actual sends and task completion. Compare complaint, opt-out and repeat-contact patterns alongside activation or renewal outcomes. A lower send count is useful only if it preserves the communication customers need. For an illustrative review, suppose 1,000 optional candidates produce 720 sends, 180 frequency blocks, 60 completed-task exclusions and 40 expired offers. The frequency block share is 18% of candidates. Combining all 280 unsent candidates into a “cap failure” would overstate the problem and hide two desirable exclusions. Inspect which message classes lose capacity. If high-value setup instructions are consistently blocked by broad announcements, the priority policy needs repair. Raising the cap may conceal that conflict while increasing total pressure. ## What should be in the release checklist? - [ ] The policy names its identity, channels, counted event and time windows. - [ ] A late-night boundary test matches the promised calendar or rolling behaviour. - [ ] Every included workflow actually uses the relevant limit. - [ ] Exemptions have a business reason and remain visible in communication reporting. - [ ] The chosen priority survives a collision between a broad campaign and a useful task reminder. - [ ] A completed task or expired offer cannot produce an unsuitable delayed message under the chosen retry design. - [ ] Operators can distinguish frequency blocks from permission, eligibility and delivery failures. - [ ] Separate sending systems are either coordinated or explicitly outside the policy's scope. Give one owner authority over exceptions. Without that, every campaign owner has an incentive to bypass the cap when their own launch feels important. Review exceptions with the same care as the rule itself. ## Frequently asked questions ### What is the best frequency cap for SaaS? There is no universal count that fits every product and customer task. Start with a policy grounded in your journey mix, customer expectations and observed message pressure. Evaluate useful task completion and negative feedback before changing it. ### Are quiet hours enough to prevent too many messages? Quiet hours control timing within the day, while frequency policy controls volume across a window. Several messages can accumulate for the same permitted time. Test the combination so morning delivery does not become a burst of unrelated messages. ### Should transactional messages ignore the cap? Classify them by their actual purpose and required delivery behaviour. Essential account actions may need separate rules, while promotional content should not obtain an exemption merely by being triggered by an event. Keep exempt communication visible in the overall customer history. ### Should blocked messages always be retried? Only when they remain useful and the implementation can respect current eligibility and expiry. A later fresh decision is often more appropriate than resending an old candidate. Test the product's actual retry and exit behaviour before relying on it. ### Does a cap replace preference management? No. Preferences determine what the person has agreed to receive, while caps limit eligible communication. Apply permission and relevance checks before using a capacity slot, and preserve their distinct reasons in reporting. ## Sources 1. [Braze rate limiting and frequency capping](https://www.braze.com/docs/user_guide/messaging/messaging_fundamentals/frequency_capping). Accessed 17 September 2026. 2. [Customer.io message frequency limits](https://docs.customer.io/messaging/send/message-limits/overview/). Accessed 17 September 2026. 3. [Customer.io limit and retry configuration](https://docs.customer.io/messaging/send/message-limits/set-up-message-limits/). Accessed 17 September 2026. 4. [Customer.io blocked-message review](https://docs.customer.io/messaging/send/message-limits/review-message-limits/). Accessed 17 September 2026. 5. [Klaviyo Smart Sending](https://help.klaviyo.com/hc/en-us/articles/115002779311). Accessed 17 September 2026.