Frequency caps protect users from overlapping journeys. They also protect teams from misreading engagement caused by too many reminders. A cap should account for user, account, stream, and urgency.
User-level caps prevent one person from receiving too many messages. Account-level caps prevent several teammates from receiving the same account prompt after one shared event.
| cap | example |
|---|---|
| User cap | No more than one lifecycle prompt per day. |
| Account cap | No more than one admin prompt per account per week. |
| Stream cap | Billing notices do not count against marketing caps. |
| Priority override | Security and payment mail can bypass marketing caps. |
When two automations want to send on the same day, the system should know which one wins. Trial expiration usually beats feature education. Billing beats broadcast.
A cap delays or blocks a send. An exit rule removes the user from the journey when the target action is complete. Both are needed.
Suppressed sends are useful signal. They show where journeys overlap, where trigger rules are too broad, and where lifecycle programs need consolidation.
At an early stage the deciding factors are what the free tier actually covers, what the first paid invoice looks like, and how much of a founding engineer's week the setup costs. Feature depth that only matters at a million sends a month is noise until it is not.
Applied to email frequency capping, that means weighing free tier, best published rate per 1,000, entry price, and developer experience ahead of the rest, against a waitlist, a launch announcement, onboarding email, and the first transactional sends.