Tensor LabsTENSORLABS

Give every contact a frequency budget

One budget per human, enforced where every message must pass

July 6, 20264 min read3 sectionsBy Ahmed Abdullah
Give every contact a frequency budget

Introduction

"Why did we email Sarah four times on Tuesday?" the founder asked, holding up a phone with the evidence, and the honest answer took twenty minutes because it required a diagram.

The onboarding sequence in the marketing platform had sent one. The CRM's sales cadence, working a renewal, sent another. The product itself fired a feature announcement, and a webinar tool nobody remembered buying closed the set. Four systems, four teams, four reasonable decisions. Sarah unsubscribed at 4:51 p.m., and the unsubscribe landed in only one of the four databases, which means three of them still think she is reachable.

This is the standard failure of a grown-up marketing stack, and it is a failure of architecture, not of taste. Braze, HubSpot, the CRM, the product's notification service: each one ships with its own frequency capping, and each one's cap governs only itself. Nobody sits above them. The customer experiences the sum, and the sum is spam assembled entirely from polite parts.

Every tool was considerate. Together they were a problem.

One decision point, one budget

The fix is a pattern the biggest consumer companies converged on years ago and mid-size stacks are only now adopting: a central message-decision service. No tool sends anything directly anymore. Instead, every system that wants to reach a human submits an intent, this contact, this message, this channel, this priority, and one service decides yes, no, or later.

The decision logic is where the intelligence concentrates, and its core is a frequency budget per person. Not a cap per tool, a budget per human across all channels, spent by whatever gets through. Three messages a week, say, with the allocation governed by priority tiers: transactional messages, receipts and resets, always pass and do not spend budget; lifecycle messages, onboarding and renewal, outrank promotions; promotions compete for whatever budget is left, and the loser waits for next week or dies quietly. Add per-channel quiet hours, a global suppression list that every tool respects because the gate enforces it, and a simple fatigue rule that pauses promotional sends to anyone who has ignored the last several.

The plumbing is deliberately dull. A queue of message intents on Kafka or even Postgres, a decision service that is mostly if-statements and a token bucket per contact in Redis, and the existing tools demoted from deciders to delivery arms via their APIs. The profile layer you likely already own, Segment or RudderStack, supplies the identity spine so the budget follows the person rather than the email address.

A frequency cap in one tool is a promise; a budget enforced at one gate is a policy.

Sending less, earning more

The counterintuitive result, reproduced at company after company, is that total conversions rise while volume falls. Deliverability improves because mailbox providers score sender reputation on engagement, and engagement rises the moment the ignored messages stop shipping. Unsubscribes drop, which preserves the audience you spent acquisition dollars building; every unsubscribe caused by message collision is marketing budget being set on fire by the coordination gap between tools. And marketing finally gets a lever it never had: change the budget, the tiers, or the quiet hours in one place and the whole stack obeys.

(The four teams, it turned out, had four separate spreadsheets for "send days." The gate replaced all of them, which was the only diplomatic way that spreadsheet war was ever going to end.)

We installed this gate at a company whose contacts averaged nine messages a week from five systems. Volume fell 40 percent in the first month; replies and click-throughs rose, unsubscribes halved, and the founder stopped screenshotting his own product's emails at the leadership team.

At TensorLabs we wire the decision service into the tools you already run rather than replacing them, which is why it is a weeks-scale project and not a migration. Your customers have been reading your whole stack's output as one voice all along. The budget is how the voice learns to stop interrupting itself.