Frequency caps don't cover your automated messages

If a customer got four messages from you in eleven minutes, the frequency cap in your email tool did not fail. It was never in the path. HubSpot, Klaviyo, and Braze all cap marketing sends, and all three exempt the transactional and API send paths, which is exactly how an automation sends. A cap that covers automated messages has to sit on the contact record, ahead of every sender, and it has to know which message matters more.

Why the cap you configured does not cover automated sends

Every major messaging platform has a frequency control. Every one of them is scoped to that platform's marketing channel, and every one of them ships an exemption. Checked September 2026:

Sender	What the cap counts	What is exempt	Does an automated send hit it?
HubSpot (Marketing Hub Enterprise)	Regular marketing emails, blog notification emails, and automated emails sent through workflows, counted per contact on a rolling window	Transactional emails, one-to-one emails, feedback survey emails, and emails from the conversations inbox. Any individual send can also clear the "apply send frequency cap" checkbox	Yes if the automation enrolls the contact in a HubSpot workflow. No if it calls the transactional API
Klaviyo (Smart Sending)	Marketing email on a 16 hour default window, SMS on a 24 hour default window	Transactional messages are never skipped, and receiving one does not reset the window for anything else	Only if the automation triggers a flow message with Smart Sending on. It is on by default for campaigns, and on for many pre-built flows but not all of them
Braze	Each campaign or Canvas component send, across push, email, SMS, webhook, WhatsApp, and LINE	In-app messages and Content Cards, any campaign with frequency capping toggled off, and any API campaign sending override_frequency_capping set to true	Usually no. API campaigns are the transactional pattern, and the override is one field in the request body
Twilio, SendGrid, Postmark, direct API	Nothing per recipient. The limits are throughput, measured in messages per second at the account and number level	Not applicable	No. There is no per-recipient frequency concept to hit
Zapier, Make, n8n	Nothing. Deduplication is per trigger record, not per recipient	Not applicable	No

Read the exempt column as a group and the pattern is obvious. The exemption is granted by send path, not by content. That is the right design for a password reset, and nobody would argue otherwise. The problem is that anything traveling down that path inherits the exemption, and automations travel down that path by default, because the automation platform holds an API credential and the API credential is the exempt route.

Nobody sat in a meeting and decided the review request should bypass the cap. The plumbing decided.

Is it transactional, or is it marketing wearing a transactional badge?

One question sorts this cleanly. If this message never arrived, would the customer have to contact you to get on with their day?

Yes means it must send: appointment confirmations, a reschedule notice, a technician-is-en-route text, a password reset, a receipt, a failed-payment warning. Cap those and you manufacture support calls.

No means it is cap-eligible, whatever triggered it. This is where the misclassification lives, and it is always the same short list:

• The review request that fires when a job is marked complete. Triggered by a record change, built in the automation platform, sent with the transactional credential, exempt.
• The second and third appointment reminder, when the first one already landed.
• The post-visit upsell for a maintenance plan.
• The satisfaction or NPS survey, which HubSpot exempts by name.
• The abandoned-booking nudge, which reads as helpful to the person who built it and as pestering to the person who deliberately closed the tab.

None of those are transactional. All of them get built like the ones that are, because the trigger is a record change and record-triggered sends live in the automation layer. If you are building follow-up and nurture sequences, decide this once, up front, instead of discovering it from a complaint. It is the same shape as consent state, where the answer is also one owner rather than a copy in every tool: see why opt-outs don't sync across your tools.

Where a real cap has to live

On the contact record, in whichever system is your record of record, checked by every sender before it sends. Not inside a messaging tool, because a messaging tool can only see its own sends on its own channels. Three fields do most of the work:

• last_contacted_at, a timestamp written on any outbound message on any channel.
• last_contact_tier, an integer priority for whichever message set that timestamp.
• contact_count_7d, a rolling counter, if you want a weekly ceiling on top of the cooldown.

Two implementation details matter more than the field names.

Write after the send, in the same run. Writing before you send produces a phantom suppression every time a send fails: the record says the customer was contacted and the customer received nothing. Writing in a separate scheduled job opens a window where two automations both read a stale value and both send. That is the ordinary overlapping-runs failure, and it applies here exactly as it does anywhere two workflows touch one field: overlapping runs on the same record.

Make one workflow the only writer. Airtable, Google Sheets, and most no-code tables have no row-level lock. Two automations reading last_contacted_at four seconds apart will both see an empty value and both send. The fix that survives contact with production is a single send workflow that every other automation calls with a payload of recipient, channel, tier, and body. It costs one extra hop and it removes the race, because there is now exactly one reader and one writer. That is the shape we build into most workflow automation systems that touch customers directly.

A counter alone suppresses the wrong message

Here is the part most people miss after they build the gate. A rule that says "contacted in the last four hours, skip" drops whichever message arrived second. Arrival order is arbitrary. The appointment reminder loses a coin flip to the review request, and the customer misses the appointment.

Give every message a tier, and have the gate compare tiers instead of only checking a timestamp:

1. Must-send. Never gated. Confirmations, reschedules, receipts, payment failures, anything a customer would call about.
2. Time-sensitive operational. Reminders, arrival windows, day-of updates. Gated only against tier 2 and below.
3. Relationship. Review requests, check-ins, satisfaction surveys.
4. Promotional. Offers, upsells, newsletters.

Tiers 3 and 4 should defer, not drop. Deferring means re-queueing with a delay and a maximum defer count, so a tier 4 message that never finds a window expires quietly instead of arriving nine days late and out of context. A dropped message is invisible. A deferred message with no expiry is worse, because it does show up eventually and it reads as bizarre.

The same record should carry the per-recipient send window, since the two controls answer the same question about one customer at slightly different scales. That half is covered in quiet hours and timezone handling.

Eleven minutes, four messages

A dispatcher moves an HVAC service call from Tuesday at 2:00 pm to Wednesday at 9:00 am. Here is the sequence, with every cap in the stack configured correctly:

• 9:02. The field app writes the new appointment time. The scheduling automation sends "Your appointment has been rescheduled to Wed 9:00 am" by SMS through Twilio. No frequency cap exists on that path.
• 9:04. The CRM sees appointment_date change, enrolls the contact in a confirm-your-appointment sequence, and sends an email. This one is a marketing email in HubSpot's terms, so the cap does apply. The contact has received no marketing email today, so it sends.
• 9:06. The calendar sync updates the Google Calendar event. Google emails its own invite-updated notification. That is not your sender, and no cap you own can reach it.
• 9:11. The reminder automation, which polls every 15 minutes for appointments inside the next 24 hours, matches the Wednesday 9:00 am slot for the first time and sends "Reminder: your appointment is tomorrow at 9:00 am."

Four messages, three of them restating one fact, from three systems plus one you do not control. Your tools counted one send each and reported no violations. The customer counted four. That gap is the whole problem: tools count sends per channel per tool, and customers count messages per person.

How to start

Spend twenty minutes on an inventory, and inventory senders rather than campaigns. List every credential in your stack that can put a message in front of a customer: each API key, each connected mailbox, each SMS number, each calendar, helpdesk, and e-signature tool that emails on your behalf. For each one, write down the send path and whether any cap sits in it. Most operators find between six and eleven senders and are surprised by at least two of them.

Then pick the busiest customer from last month and pull every message they received in one 24 hour period, in order, across all of those senders. That list is the argument for building the gate, and it is more persuasive than any policy document. If you want help mapping the senders and putting one gate in front of them, get in touch, or look at how we structure the messaging layer in customer acquisition systems.