Tenantübergreifender Cooldown.

Die Prämisse, die wir uns selbst wünschen würden

Die meisten Outreach-Tools behandeln Leads als Privatbesitz: meine Liste, deine Liste, ihre Liste. Wenn zwei Kunden unabhängig auf denselben Prospect landen, ist das Problem des Prospects. Die meisten Tools wissen davon nicht einmal, weil es keinen gemeinsamen Pool gibt — jeder Tenant trägt seinen eigenen deduplizierten Kontaktgraphen, und das System sieht schlicht nicht über Tenants hinweg.

Wir haben einen gemeinsamen Pool. Die tenantübergreifende PublicLead-Collection hält jeden Lead, den irgendein Discovery-Lauf eines Kunden je entdeckt hat, dedupliziert nach kanonischer Firmen-Domain. Jeder Tenant bekommt darüber ein projektbezogenes Overlay — sein Kontakt, seine Anreicherung, sein State — sodass zwei Kunden unabhängig am selben Lead arbeiten können, ohne die Pipeline des anderen zu sehen. Das ist die Architektur. Cooldown ist, was wir damit machen.

Die Frage, die wir uns beim Design gestellt haben, war dieselbe Frage, die wir uns über jede Default-on-Schutzmaßnahme im Produkt stellen: würden wir es wollen, wenn wir auf der Empfänger-Seite wären? Wenn mich zwei Outbound-Tools am selben Mittwoch für Cold-E-Mails einreihen, würde ich dem zweiten verzeihen, weil er vom ersten nichts wusste? Nein. Ich würde beide markieren. Also haben wir das gebaut, was wir uns gebaut wünschen würden.

Was Cooldown tatsächlich tut

Wenn eine Kampagne eine Ausgangsmail an einen Lead schickt, wird der PublicLead-Datensatz mit einem cooldownUntil-Zeitstempel auf sieben Tage in der Zukunft versehen, und die Organisations-ID des sendenden Tenants wird als cooldownByOrgId festgehalten. Jeder andere Tenant, dessen Discovery-Lauf diesen Lead anschließend entdeckt, bekommt den Lead nicht in sein Overlay aufgenommen, bevor der Cooldown abgelaufen ist. Der Lead ist für diese sieben Tage still vor ihm versteckt.

Der Cooldown verlängert sich auf dreißig Tage in dem Moment, in dem der Lead antwortet. Eine Antwort bedeutet, dass das Gespräch lebt — der erste Tenant hat einen Thread laufen, der Empfänger hat signalisiert, mit dieser Firma reden zu wollen. Drei Tage in dieses Gespräch hinein einen Cold- Opener von einer zweiten, unverwandten Firma fallen zu lassen, liest sich noch schlechter als der Doppel-Schlag in derselben Woche; der Empfänger hat jetzt zwei unbeendete Gespräche im Posteingang von zwei Fremden. Dreißig Tage ist der Cooldown, der das erste Gespräch (positiv, negativ oder verblassend) zu Ende kommen lässt, bevor jemand anderes es versucht.

Der Cooldown des sendenden Tenants sperrt ihn nicht aus seinem eigenen Lead. Follow-ups in derselben Konversation laufen ungestört weiter — das Lock ist über Organisations-ID an andere Tenants gekoppelt, nicht global an den PublicLead. Sendungen desselben Tenants gehen ungehindert durch den Cooldown.

Die Zahl war absichtlich sieben

Drei war zu kurz. Ein höflicher Drei-Tage-Cooldown setzt immer noch zwei Cold-Opener in dieselbe Woche eines Empfängers — und das ist das Ergebnis, das wir verhindern wollten. Vierzehn war zu lang — die meisten Cold-Opener bekommen entweder innerhalb einer Woche eine Antwort oder verblassen, und nach vierzehn Tagen Stille hat der erste Tenant fast sicher weitergemacht; einen zweiten Tenant für einen abgestandenen Lead weiter warten zu lassen, verbrennt dessen Pipeline ohne Nutzen für den Empfänger.

Sieben deckt den modalen Fall ab: die meisten Erst-Berührungs- Sequenzen landen ihren zweiten oder dritten Touch innerhalb einer Woche, danach gibt es entweder eine Antwort (der Cooldown wird dreißig) oder eben nicht (der Lead wird kalt und wird entweder später durch Trigger-Signale hot-geboostet oder verfällt aus jedem aktiven Queue). Sieben ist die kleinste Zahl, die den Fehlerfall nicht durchlässt, den sie verhindern soll.

Dreißig für den Antwort-Zweig war noch bewusster. Eine Antwort startet meistens ein Gespräch, das ein bis drei Wochen läuft. Wir wollten den Long-Tail von „wir haben geantwortet, aber es bewegt sich langsam" abdecken — was empirisch innerhalb von dreißig Tagen für alles, was wir gemessen haben, abklingt.

Warum still, nicht offenbart

Dem zweiten Tenant wird nicht gesagt „dieser Lead wird gerade von einem anderen Kunden kontaktiert". Der Lead ist aus seinem Overlay versteckt; der Discovery-Lauf zeigt eine Zählung versteckter Leads an („12 Leads werden bereits von einem anderen Kunden kontaktiert"), und das war's. Keine identifizierenden Informationen darüber, wer den Lead sonst kontaktiert. Keine Domain, keine Kampagne, kein Hinweis.

Der Grund ist geradeaus: diese Informationen zu zeigen würde die Pipeline-Form eines Kunden an einen anderen leaken. Wenn du eine Discovery-Probe für „B2B-SaaS-Firmen in Berlin, die SDRs suchen" gefahren hast und wir dir zeigen würden, welche dieser Firmen im Cooldown sind, würdest du den ICP eines anderen Kunden lesen. Das ist eine Datenschutz-Linie, die wir auch um den Preis der Transparenz über den Cooldown nicht überschreiten.

Der Trade-off ist real: der zweite Tenant kann nicht unterscheiden, ob eine hohe Zahl versteckter Leads daher rührt, dass der Lead-Pool klein ist, oder daher, dass sein ICP sich mit dem eines anderen Tenants überschneidet. Wir haben entschieden, dass der richtige Weg, mit dieser Mehrdeutigkeit umzugehen, ist, die Zählung ohne Identität zu zeigen — und dem zweiten Tenant genug Discovery-Breite zu geben, dass die Cooldown-Löcher ein Rundungsfehler sind, kein strukturelles Problem.

Was es jeden Tenant kostet

Konkret: ein Tenant, dessen ICP sich stark mit dem eines anderen aktiven Tenants überschneidet, wird einige Leads still aus seinem Discovery-Output fallen sehen. Wir zeigen dir nicht, welche Leads — wir zeigen dir die Zählung. Über einen Hundert-Lead-Discovery-Batch in einer typischen Vertical ist die versteckte Zahl meist klein (einstellig in den meisten Kategorien, die wir gemessen haben). In dichten Überlappungs-Kategorien kann sie größer sein.

Die Kosten sind nicht gleich auf alle Kunden verteilt. Ein Tenant, dessen Discovery in einer Vertical sitzt, auf die viele andere Kunden auch zielen, sieht mehr versteckte Leads als ein Tenant in einer einzigartigen Nische. Wir bepreisen das nicht — jeder Kunde zahlt dasselbe Pro-Lead- Cap, unabhängig davon, in welcher Discovery-Slice er arbeitet — und wir erstatten versteckte Leads nicht auf das Cap an, weil sie nie der Pipeline des Tenants hinzugefügt wurden.

Was wir stattdessen schulden, ist Breite. Der Discovery- Layer arbeitet hart daran, Leads zu finden, die andere Kunden nicht schon entdeckt haben — andere Geos, andere Absence-Proben, andere Source-Adapter. Der Cooldown ist die Rückendeckung; Breite ist der Front-Stop. Die meisten Kunden stoßen die meiste Zeit gar nicht in den Cooldown rein, weil sie an Leads arbeiten, die noch niemand berührt hat.

Wie die Alternative aussah

Wir haben das Per-Tenant-Modell, das jedes andere Tool ausliefert, kurz erwogen: kein Shared Pool, kein Cooldown, jeder Tenant lebt in seinem eigenen deduplizierten Silo. Das Argument dafür ist Einfachheit — weniger Infrastruktur, kein tenantübergreifender State zu reasonen, leichter einem Kunden zu erklären „deine Leads sind deine Leads".

Das Argument dagegen war die Empfänger-Erfahrung. Wir bauen ein Tool, das viele E-Mails versenden wird. Wenn wir es ohne Cooldown auslieferten, würden wir im eingeschwungenen Zustand auf eine nicht-triviale Zahl von Leads Doppel-Schläge und Dreifach-Schläge fahren — schlicht weil die ICPs unserer Kunden sich überschneiden. Die Empfänger dieser Doppel-Schläge wüssten nicht, dass sie zweimal vom selben Software-Anbieter getroffen werden. Sie wüssten nur, dass die Kategorie irgendwie schlechter ist als die anderen. Wir würden genau die Erfahrung bauen, gegen die wir antreten wollten.

Also haben wir die architektonisch schwerere Option gewählt und die Pro-Tenant-Kosten in versteckten Leads getragen — im Tausch dafür, nicht das System zu sein, das Empfänger verbrennt. Das ist eine Trust-Loop- Entscheidung. Wir treffen sie genauso wie die anderen: würden wir es uns selbst wünschen?

Was es nicht ist

Cooldown ist keine Suppression-Liste. Ein Lead im Cooldown für Tenant B kann in zwölf Tagen perfekt von Tenant B kontaktierbar sein. Suppression — die pro Tenant gepflegte Liste von Leads, die sich abgemeldet haben, gebounced sind, um Entfernung gebeten haben oder dem Tenant anderweitig gesagt haben, dass er aufhören soll — ist ein separater Mechanismus, der nicht abläuft.

Cooldown ist auch keine Deduplizierung. Wenn Tenant A einen Lead entdeckt und ihn nie kontaktiert (DISCOVERY_ONLY- Modus oder Pause vor dem Erreichen), sieht Tenant B den Lead sofort. Die Cooldown-Uhr startet nur bei einer erfolgreichen Ausgangs-Sendung. Versteckte Leads aus dem Discovery eines anderen Tenants ohne Sendungen gibt es nicht; der Pool ist geteilt, aber das Cooldown-Gate schaltet beim Senden, nicht beim Entdecken.

Wenn du Outbound-Tools evaluierst

Du bist der Gründer, der die Kategorie absucht. Du hast die Vergleichsseiten gelesen. Du hast die Demos gesehen. Die Frage, die es wert ist, jedem Tool zu stellen, das du in Erwägung ziehst: was tut dein System, wenn zwei deiner Kunden auf demselben Lead landen?

Die meisten Tools werden dir sagen, dass die Frage nicht gilt, weil jeder Tenant seine eigene Liste hat. Lies das als: das System wird im eingeschwungenen Zustand denselben Empfänger mit Cold-Openern von zwei verschiedenen Kunden doppel-tappen, weil es keine Maschinerie hat, das zu verhindern. Das ist kein Deal-Breaker für jeden Käufer — High-Volume-Shops, die an massive Listen senden, haben effektiv null Überlappung, und das Modell funktioniert. Für einen Gründer, der ein paar hundert E-Mails im Monat aus seiner eigenen Domain an einen engen ICP schickt, auf den andere Gründer in seiner Kategorie wahrscheinlich auch zielen, ist die Rechnung eine andere.

Cooldown ist kein Feature, das du demoen kannst. Es ist eine strukturelle Entscheidung, die nur in der Abwesenheit eines Fehlerfalls sichtbar wird, den du nicht bemerkt hättest. Die 14-Tage-Testphase zeigt die versteckte Lead-Zählung auf jedem Discovery- Lauf, damit du sehen kannst, was der Cooldown für deinen spezifischen ICP zurückhält — auch wenn wir dir nicht zeigen, in wessen Pipeline er sitzt.

— Tobias Duelli, Gründer · tobias@overwise.com