Outreach Engine

Problem

Outreach in jedem größeren Maßstab bedeutet heute Miete: ein SaaS-Werkzeug mit Preis pro Kontakt, einem Scoring, das niemand einsehen kann, und Adressdaten auf fremder Infrastruktur. Wer systematisch hunderte Organisationen bearbeiten will, mietet sich damit eine Meinung darüber, wen er als Nächstes anschreibt.

Die zweite Falle ist der Betrieb. Eine Pipeline mit fünf Stufen bricht selten laut: ein Feed verschiebt sich, ein Kontakt läuft ins Leere, eine Antwort versinkt im Postfach. Die Zustellung ist der einfache Teil. Die Frage ist, ob man drei Wochen später noch weiß, woran man gerade ist.

Architektur

Der Kern ist eine Pipeline aus fünf Stufen: Ingestion, Matching, Anreicherung, Zustellung, Triage. Jede Stufe liest aus SQLite und schreibt nach SQLite, im WAL-Modus, dazu ein FTS5-Volltextindex mit Trigram-Tokenisierung. Zwischen den Stufen sitzt kein Message Broker, und auch kein Cloud-Dienst.

Das Ranking beginnt mit einem Gate: Ein taxonomischer Filter über die Kategorien des Datenbestands lässt nur passende Records durch. Was überlebt, durchläuft das Reranking: ein gemischter Score aus BM25 und Cosinus-Ähnlichkeit über Embeddings ordnet den Bestand neu. 37.059 bewertete Paare liegen in der Datenbank, nach Organisation gruppierbar und je Paar mit Begründung abrufbar.

Die Zustellung arbeitet mit 55 Formulierungsvarianten. Die Auswahl fällt per Hash über die Datensatz-ID (FNV-1a), deterministisch und reproduzierbar, ohne Modellaufruf. Der Versand läuft über einen selbst geschriebenen SMTP-Client mit Jitter zwischen den Nachrichten. Jede Nachricht wird als .eml archiviert und per IMAP APPEND in den Gesendet-Ordner gelegt.

Das Ganze ist eine Node-CLI in TypeScript mit null Laufzeit-Abhängigkeiten: SMTP, IMAP, ZIP, DOCX und XLSX sind selbst geschrieben, die Tests laufen offline. Installieren, konfigurieren, laufen lassen: kein Container, kein Dashboard, kein Abo.

Daten & Zahlen (gemessen)

Stand 6. Oktober 2026: 20.180 Datensätze im Bestand, dazu 5.153 Organisationen und 48.967 geokodierte Adressen über 2.335 Städte. Die Datenbank bringt 628 MB mit, darin stecken zwei Wochen Ingestion in 222 Läufen.

Der Betrieb hat stattgefunden: 100 Zustellungen in den ersten 48 Stunden, 173 angereicherte Kontakte, 30 Antworten vom IMAP-Leser in vier Intentions sortiert (Bestätigung, Einladung, Absage, Pool). Keiner dieser Werte ist eine Schätzung: alle stehen in derselben SQLite-Datei, die die Pipeline selbst füllt.

Datenhoheit & Auditierbarkeit

Der Bestand bleibt auf dem eigenen Rechner. Was die Maschine verlässt, ist der Textbaustein für die Embeddings, und nur solange ein API-Schlüssel gesetzt ist. Ohne Schlüssel läuft das Ranking allein über den Volltextindex weiter. Kein zweiter Dienst sieht auch nur einen Datensatz.

Jede ausgehende Nachricht ist rekonstruierbar: Archivkopie auf der Platte, Append im Gesendet-Ordner, Ledger-Eintrag mit validierten Statusübergängen. Der IMAP-Leser sortiert eingehende Antworten in Ordner und schreibt jede Einordnung nachvollziehbar weg. Der Jahresexport als Excel-Datei braucht keine Bibliothek, weil der XLSX-Schreiber selbst gebaut ist.

Ein Vorgang, der sich nicht rekonstruieren lässt, hat nicht stattgefunden. Deshalb ist Auditierbarkeit hier kein Feature, sondern die Voraussetzung.

Was Firmen daraus ziehen können

Die fünf Stufen sind der klassische SDR-Funnel: Zielprofil definieren, Kandidaten ranken, Kontakte anreichern, den ersten Kontakt personalisiert zustellen, Antworten triagieren. Genau diesen Funnel mieten Firmen heute, in der Regel pro Kontakt und Monat.

Der Unterschied dieser Bauart: Die Maschine ist an keinen Quelltyp gebunden. Solange eine Quelle strukturiert ist, läuft dieselbe Architektur darüber, vom eigenen Bestand bis zum offenen Datenfeed. Bewiesen hat sie sich im persönlichen Maßstab. Die Architektur ist der Punkt, nicht das Dashboard.