Cross-tenant cooldown.

The premise we'd want ourselves

Most outreach tools treat leads as private property: my list, your list, their list. If two customers independently land on the same prospect, that's the prospect's problem. Most tools don't even know about it, because there's no shared pool — each tenant carries its own deduped contact graph, and the system simply doesn't see across tenants.

We have a shared pool. The cross-tenant PublicLead collection holds every lead any customer's discovery run has ever surfaced, deduplicated by canonical company domain. Each tenant gets a per-project overlay on top — their contact, their enrichment, their state — so two customers can independently work the same lead without seeing each other's pipeline. That's the architecture. Cooldown is what we do with it.

The question we asked, designing it, was the same question we ask about every default-on safety in the product: would we want it if we were on the receiving end? If two outbound tools queued me up for cold emails the same Wednesday, would I forgive the second one because they didn't know about the first? No. I'd flag both. So we built the thing we'd want built.

What cooldown actually does

When a campaign sends an outbound email to a lead, the PublicLead record gets a cooldownUntil timestamp set to seven days from now, with the sending tenant's organization ID recorded as cooldownByOrgId. Any other tenant whose discovery run subsequently surfaces this lead will not have the lead added to their overlay until the cooldown expires. The lead is, silently, hidden from them for those seven days.

The cooldown extends to thirty days the moment the lead replies. A reply means the conversation is live — the first tenant has a thread going, the recipient has signaled they're willing to talk to that company. Dropping a cold opener from a second, unrelated company three days into that conversation reads even worse than the same-week double-tap; the recipient now has two unfinished conversations in their inbox from two strangers. Thirty days is the cooldown that lets the first conversation conclude (positive, negative, or fade) before anyone else can try.

The sending tenant's cooldown doesn't lock them out of their own lead. Follow-ups within the same conversation continue uninterrupted — the lock is keyed to other tenants by org-id, not to the PublicLead globally. Same-tenant sends pass through the cooldown unchanged.

The number was deliberately seven

Three was too short. A polite three-day cooldown still puts two cold openers in the same recipient's week, which is the outcome we were trying to prevent. Fourteen was too long — most cold openers either get a reply or fade within a week or so, and after fourteen days of silence the first tenant has almost certainly moved on; making a second tenant wait further for a stale lead burns their pipeline for no recipient benefit.

Seven covers the modal case: most first-touch sequences land their second or third touch within a week, after which either there's a reply (the cooldown becomes thirty) or there's not (the lead goes cold and either gets hot- boosted later by trigger signals or expires from anyone's active queue). Seven is the smallest number that doesn't leak the failure case it was built to prevent.

Thirty for the reply branch was even more deliberate. A reply usually starts a conversation that runs for one to three weeks. We wanted to cover the long tail of "we replied but it's still moving slowly," which empirically settles inside thirty days for everything we've measured.

Why silent, not surfaced

The second tenant doesn't get told "this lead is currently being contacted by another customer." The lead is hidden from their overlay; the discovery run surfaces a count of hidden leads ("12 leads already being contacted by another customer") and that's it. No identifying information about who else is contacting the lead. No domain, no campaign, no hint.

The reason is straightforward: surfacing that information would leak one customer's pipeline shape to another. If you ran a discovery probe for "B2B SaaS companies hiring SDRs in Berlin," and we showed you which of those companies were in cooldown, you'd be reading another customer's ICP. That's a privacy line we're not willing to cross even at the cost of transparency on the cooldown.

The trade-off is real: the second tenant can't tell whether a hidden-lead count is high because the lead pool is small or because their ICP overlaps with another tenant's. We've decided the right way to handle that ambiguity is to surface the count without the identity, and to give the second tenant enough discovery breadth that the cooldown holes are a rounding error, not a structural problem.

What it costs each tenant

Concretely: a tenant whose ICP overlaps heavily with another active tenant's will see some leads silently dropped from their discovery output. We don't show you which leads — we show you the count. Over a hundred-lead discovery batch in a typical vertical, the hidden count is usually small (single digits in most categories we've measured). In dense overlap categories, it can be larger.

The cost isn't equal across customers. A tenant whose discovery sits in a vertical many other customers also target sees more hidden leads than a tenant in a unique niche. We don't price for this — every customer pays the same per-lead cap regardless of which discovery slice they're working — and we don't refund hidden leads against the cap because they were never added to the tenant's pipeline to begin with.

What we owe instead is breadth. The discovery layer works hard to find leads other customers haven't already surfaced — different geos, different absence probes, different source adapters. The cooldown is the back-stop; breadth is the front-stop. Most customers most of the time aren't bumping into the cooldown at all because they're working leads no one else has touched yet.

What the alternative looked like

We considered, briefly, the per-tenant model that every other tool ships: no shared pool, no cooldown, every tenant lives in its own deduped silo. The argument for it is simplicity — less infrastructure, no cross-tenant state to reason about, easier to explain to a customer "your leads are your leads."

The argument against it was the recipient's experience. We're building a tool that's going to send a lot of emails. If we shipped it without cooldown, in steady state, we'd be running double-taps and triple-taps on some non-trivial number of leads simply because our customers' ICPs overlap. The recipients of those double-taps wouldn't know they were getting hit twice by the same software vendor. They'd just know the category was somehow worse than the others. We'd be building exactly the experience we set out to fix.

So we picked the architecturally heavier option, and ate the per-tenant cost in hidden leads, in exchange for not being the system that burns recipients. It's a trust-loop call. We made it the same way we make the others: would we want it ourselves?

What it's not

Cooldown is not a suppression list. A lead in cooldown for tenant B might be perfectly contactable by tenant B in twelve days. Suppression — the per-tenant list of leads who've unsubscribed, bounced, asked to be removed, or otherwise told the tenant to stop — is a separate mechanism that doesn't expire.

Cooldown is also not deduplication. If tenant A discovers a lead and never sends to it (DISCOVERY_ONLY mode, or pauses before reaching it), tenant B sees the lead immediately. The cooldown clock only starts ticking on a successful outbound send. Hidden leads from another tenant's discovery without sends don't exist; the pool is shared but the cooldown gate fires on send, not on surface.

If you're evaluating outbound tools

You're the founder shopping the category. You've read the comparison pages. You've watched the demos. The question worth asking on any tool you're considering: what does your system do when two of your customers land on the same lead?

Most tools will tell you the question doesn't apply because each tenant has its own list. Read that as: the system will, in steady state, double-tap the same recipient with cold openers from two different customers, because it has no machinery to prevent it. That's not a deal-breaker for every buyer — high-volume shops sending to massive lists have effectively zero overlap, and the model works. For a founder sending a few hundred emails a month from their own domain to a tight ICP that other founders in their category are probably also targeting, the math is different.

Cooldown isn't a feature you can demo. It's a structural choice that shows up only in the absence of a failure case you wouldn't have noticed. The 14-day trial exposes the hidden-lead count on every discovery run, so you can see what the cooldown holds back for your specific ICP, even if we won't show you whose pipeline it sits in.

— Tobias Duelli, founder · tobias@overwise.com