Alle Artikel

/ Skalierung  ·  Funnel-Architektur

Wenn der Bewerbungsfunnel200.000+ Anfragen schluckt.

Anatomie einer Pipeline, die nicht kippt, auch wenn Marketing am Montag dreht. Warum Standard-CRMs an dieser Last brechen — und was wir stattdessen bauen.

9 Min. Lesedauer12. Mai 2026Case-Hintergrund: Omid

Ein Bewerbungsfunnel sieht nach Frontend aus. Drei Schritte, schicker Progress-Bar, fertig. Stimmt — solange Sie 50 Bewerbungen pro Tag bekommen. Bei 2 500 am Tag wird daraus ein Verteilungs-Problem, eine Compliance-Frage und ein Backend-Albtraum. Spätestens dann zerlegt es jedes Standard-CRM.

Dieser Text beschreibt, was wir gebaut haben, um genau das zu verhindern — am Beispiel eines Funnels, der inzwischen über 200.000 Anfragen verarbeitet hat, ohne dass jemand im Team „Backlog" sagen muss.

/ Im Einsatz

200.000+
Bewerbungen verarbeitet
< 200 ms
Antwortzeit pro Funnel-Schritt
6 Stufen
vom Eingang bis zur Auswahl
0 manuell
Sortierschritte für Standardfälle

Warum Standard-CRMs hier verlieren

Wer das Wort „CRM" hört, denkt an Salesforce, HubSpot, Pipedrive. Alle drei sind exzellent — für Vertriebs-Pipelines mit hunderten Leads im Monat. Bei einem Bewerbungsfunnel mit Massen-Inflow brechen sie an drei Stellen:

  • API-Limits. Standard-CRMs versuchen, jede Bewerbung einzeln zu persistieren. Das geht gut bis irgendwann das Daily-Quota schreit. Spätestens bei einem Marketing-Push fängt die Pipeline an zu droppen.
  • Workflows als Trigger. „Wenn Status = neu, dann E-Mail." Schön — bis 5 000 Trigger gleichzeitig laufen wollen. Die Workflow-Engine ist nicht für Echtzeit-Massenverarbeitung gebaut.
  • Datenmodell. Ein Bewerbungsprozess ist kein linearer Sales-Funnel. Er hat Verzweigungen, Ausschlusskriterien, Quoten pro Standort, Compliance-Pflichten. Das in ein Sales-CRM zu pressen erzeugt technische Schulden bei jedem Release.
Ein Funnel mit Massenlast ist kein Marketing-Tool. Er ist eine Hochlast-API mit Conversion-Layer obendrauf."

Die Architektur, die nicht kippt

Was wir stattdessen bauen, ist immer dieselbe Form mit unterschiedlichen Geschmäckern. Drei Layer, klar getrennt, jeder mit eigenem Skalierungs-Verhalten:

/ Anatomie der Pipeline

/ Layer 1

Funnel-Frontend

Edge-cached statische Seite + Lightweight-API

Stateless. Schreibt nur in eine Queue. Antwortet jedem Bewerber sofort, auch wenn der Hintergrund 30 Sekunden später noch kaut.

/ Layer 2

Worker-Pool

Background-Jobs mit Idempotenz-Key

Validierung, Anti-Spam, Score-Berechnung. Skaliert horizontal — wenn 5 000 Anfragen reinkommen, drehen wir die Worker auf 50 statt 5.

/ Layer 3

CRM & BI

Postgres + Read-Replicas + analytisches Schema

Hier sitzt das CRM-Modell, in dem die Recruiter arbeiten. Schreibrate kontrolliert über Worker, nicht über User-Traffic.

Der Trick ist die Entkopplung von User-Traffic und Datenbankschreiben. Der Bewerber wartet nie auf das CRM. Die Recruiter sehen die Bewerbung ein paar Sekunden später — Konsistenz statt Echtzeit.

Conversion ist Architektur

Conversion-Optimierung wird oft als Design-Disziplin verkauft — bessere Texte, weniger Felder, klarere Buttons. Stimmt alles, aber der größte Hebel liegt im Backend.

Wenn der nächste Funnel-Schritt 1,8 Sekunden zum Laden braucht, verlieren Sie pro Sekunde Wartezeit ca. 7 % der Bewerbenden. Bei sechs Schritten ist das katastrophal. Sub-200ms Antwortzeit ist nicht Polish — es ist Pflichtprogramm.

Das gilt auch für Heatmap-Insights. Wir messen pro Funnel-Schritt:

  • Time-on-step (Median + 95-Perzentil)
  • Klick-Pfade (welche Buttons werden vor dem Submit getestet?)
  • Drop-off-Quote relativ zum vorherigen Schritt
  • Validierungsfehler-Häufigkeit pro Feld

Diese Daten landen täglich in einem BI-Dashboard, das genau drei Personen lesen — und nach dem Lesen Felder umsortieren oder entfernen. Conversion-Optimierung ist ein dauerhafter Prozess, kein einmaliger A/B-Test.

Click-Heatmap der OMID-Funnel-Startseite: Die beiden primären CTAs sind die mit Abstand am häufigsten geklickten Elemente.

/ Heatmap-Auszug — Funnel-Startseite

Was hier rot leuchtet, ist nicht das Logo, nicht das Portraitfoto, nicht der Status-Banner — sondern die beiden primären CTAs. Genau so soll es aussehen.

Die nummerierten Marker zeigen die Top-Klick-Hotspots in absteigender Reihenfolge. Position 1: „Jetzt starten" (Auto verkaufen). Position 5: „Jetzt starten" (Expressverkauf). Position 6: Hamburger-Menü. Soziale Icons und alles oberhalb der CTAs werden de facto nicht angeklickt — was bei einem Funnel mit klarer Conversion-Intention genau die richtige Verteilung ist.

Solche Heatmaps gehören bei uns nicht zum Endprodukt, sondern zum laufenden Optimierungsprozess. Pro Sprint wird mindestens ein Element auf Basis der Daten verschoben, vergrößert, entfernt oder neu beschriftet.

Click-Heatmap der OMID-Funnel-Startseite, anonymisierter Auszug. Erstellt mit einem Standard-Heatmap-Tool über mehrere tausend Sessions aggregiert. Heller = mehr Klicks.

Die DSGVO-Falle, die niemand bedenkt

Bewerbungsdaten sind besonders schützenswerte Daten. Das hat zwei Konsequenzen, die in vielen Projekten zu spät erkannt werden:

/ Risiko

Standard-Cloud-Tools speichern oft außerhalb der EU. Bewerbungsdaten in einem US-CRM ohne saubere SCCs sind Art. 28-DSGVO-Wackelware.

/ Lösung

Hosting in deutschen Rechenzentren, dokumentierte Löschfristen pro Bewerbungsstatus, automatische Anonymisierung nach Ablauf. Bewerber-Auskunfts-Self-Service als API-Endpoint.

Die zweite Konsequenz: automatisches Scoring ist gefährlich. Sobald ein Algorithmus über die Vorauswahl von Bewerbenden entscheidet, sind Sie im Geltungsbereich von Art. 22 DSGVO (automatisierte Einzelfallentscheidungen). Wir bauen Scoring ausschließlich als Sortier-Hilfe, nie als Filter — Menschen entscheiden, Maschinen ranken.

/ Fazit

Ein Funnel, der nicht kippt, sieht für den Bewerbenden langweilig aus: drei Schritte, kurze Wartezeit, freundliche Bestätigung. Die ganze Architektur dahinter merkt er nie.

Genau das ist das Ziel. Wenn Sie ähnliche Lasten erwarten oder ein Standard-Tool gerade die Grenzen seines Designs erreicht, sprechen wir gerne.