Warum wir LeadGrid als eine API für zwei Pipelines gebaut haben
Die meisten Growth-Teams betreiben ein CRM und ein ATS für dieselbe Bewegung. Hier erfährst du, was zusammenbricht, wenn du Sales und Recruitment auf einem Datenmodell abbildest — und warum wir es von Anfang an programmierbar gemacht haben.
Jedes Growth-Team, mit dem ich je gearbeitet habe, führt dieselbe Bewegung zweimal aus. Sales hat ein CRM. Recruitment hat ein ATS. Dieselbe Pipeline-Form — Aufnahme, Qualifizierung, Weiterbewegen, Abschluss — aber auf zwei Stacks, die nicht miteinander reden.
Wir haben LeadGrid gebaut, weil diese Trennung eine Entscheidung ist, keine Notwendigkeit.
Das Datenmodell ist dasselbe
Ein Lead und ein Kandidat sind beides Menschen, die Phasen durchlaufen. Gib ihnen einen Namen, eine Phase, eine Deadline, einen Verantwortlichen und ein paar Notizen — und du hast beide beschrieben. Die Verben sind identisch: erstellen, zuweisen, weiterschieben, kommentieren, abschließen.
Die Branche hat zwei Produktkategorien darum herum gebaut, weil es profitabel war — nicht weil die zugrunde liegende Arbeit unterschiedlich ist. Teams zahlen am Ende zwei Anbieter, integrieren zwei APIs, schulen auf zwei UIs und gleichen zwei Wahrheitsquellen ab — um dieselbe Sache zweimal zu verfolgen.
Was zusammenbricht, wenn du vereinheitlichst
Eine Plattform für beide Pipelines zu betreiben, bringt drei konkrete Vorteile:
- Übergaben fallen nicht mehr durch den Rost. Sales verspricht Lieferung. Recruitment findet die Menschen, die liefern. Wenn beide dasselbe Grid sehen, passieren Eskalationen bevor der Kandidat abspringt oder der Deal verloren geht.
- Tooling-Kosten halbieren sich. Ein Workspace, eine Abrechnungszeile, ein Berechtigungsmodell. Sales und Recruitment hören auf, darum zu streiten, welches Tool die Wahrheitsquelle ist — es ist dasselbe.
- Reporting wird ehrlich. Time-to-hire und Time-to-close leben in derselben Datenbank. Du kannst endlich die Frage beantworten: „Haben wir diesen Deal verloren, weil wir die Person nicht hatten?" — ohne ein Spreadsheet.
API-first, nicht API-als-Nachgedanke
Die andere bewusste Entscheidung: Jede Aktion, die die UI ausführt, ist ein REST-Aufruf. Dossier erstellen, Phase verschieben, Notiz hinzufügen, Mitglied zuweisen — alles skriptbar, alles dokumentiert unter /docs/api.
Das klingt nach Mindeststandard, und das sollte es auch sein — aber die meisten CRMs behalten ihre besten Features für höhere Tiers zurück, wickeln die API in Rate-Limits ein, die Dich in Professional Services treiben sollen, oder verweigern die Dokumentation von Webhooks. Wir wollten das Gegenteil: Die API ist das Produkt, die UI ist ein praktischer Weg, es zu nutzen.
Die praktische Konsequenz: Deine Automationen interessiert es nicht, ob etwas ein Lead oder ein Kandidat ist. Du schreibst eine Integration einmal, und sie funktioniert über beide Pipelines. Claude, n8n, Zapier, Dein eigenes Backend — gleiche Endpoint-Struktur, gleiche Auth, gleiches Webhook-Schema.
Kostenlos für immer im Free-Plan
Noch eine letzte Sache. LeadGrid ist kostenlos für immer im Free-Plan — kein 14-Tage-Test, keine zeitlich begrenzte Aktion. Du kannst ein echtes Team darauf betreiben, echte Pipelines bauen und uns keinen einzigen Cent zahlen. Bezahlte Pläne schalten mehr Seats, aktive Dossiers, Flows und API-Durchsatz frei, wenn Du die kostenlosen Limits übertriffst.
Wir haben lieber, dass Du auf der Plattform baust, als dass Du auf einen ablaufenden Countdown starrst.