Bewerbungsfunnel und CRM für Omid

Der erste Hinweis ist selten ein Ausfall. Es ist eine Übersichtsliste, die spürbar länger lädt, und eine Bewerberin, die zweimal im System steht, weil sie den Weg einmal am Handy und einmal am Laptop angefangen hat. Wer täglich mit Bewerbungseingängen arbeitet, kennt den Punkt, an dem das Werkzeug den Ablauf bremst, statt ihn zu tragen.

Omid führt Bewerbungen vom Erstkontakt bis zur finalen Auswahl. Über die Vorgeschichte veröffentlichen wir nur, was freigegeben ist. Das Muster dahinter ist verbreitet genug, um es zu beschreiben: Ein Bewerbungsprozess wird für den Zulauf gebaut, den es am Tag der Einführung gibt, und trägt die Menge, die sich danach ansammelt, irgendwann nicht mehr.

Der Unterschied zwischen ein paar tausend und mehreren hunderttausend Datensätzen ist selten eine Frage der Serverleistung.

Was sich bei sechsstelligen Beständen ändert

• 01Das Datenmodell: Ein überschriebenes Statusfeld reicht, solange niemand fragt, wer wann entschieden hat. Bei sechsstelligen Mengen fragt jemand.
• 02Antwortzeiten: Abfragen ohne Index und Auswertungen über den Gesamtbestand fallen von Millisekunden auf mehrere Sekunden. Das trifft jeden Klick, auch außerhalb des Monatsberichts.
• 03Dubletten: In einem kleinen Bestand fallen Doppelungen beim Durchsehen auf. In einem sechsstelligen findet man sie nur, wenn das System danach sucht.
• 04Löschfristen: Aufbewahrungspflichten und Speicherbegrenzung lassen sich über eine gepflegte Liste nicht mehr steuern. Sie müssen am Datensatz hängen und automatisch ablaufen.

Gebaut wurde ein zusammenhängendes System aus zwei Teilen: dem Bewerbungsfunnel, den Bewerber sehen, und dem CRM, in dem die Auswahl stattfindet. Beide arbeiten auf demselben Datenbestand. Ein Lead entsteht im ersten Schritt des Funnels und behält seine Identität bis zur finalen Entscheidung.

Der Funnel

Der Funnel ist mehrstufig und speichert Zwischenstände. Wer abbricht, verliert die bereits eingegebenen Angaben nicht und setzt beim nächsten Aufruf an der erreichten Stelle fort. Geprüft wird jede Eingabe auf dem Server; die Prüfung im Browser ist Komfort und zählt für die Datenqualität nichts. Die Herkunft eines Eingangs steht am Datensatz, damit spätere Auswertungen auf Daten und nicht auf Vermutungen beruhen.

Das Datenmodell

Jede Statusänderung wird als Ereignis geschrieben. Der aktuelle Stand ergibt sich daraus, der Verlauf bleibt erhalten, und die Frage nach dem Zeitpunkt einer Entscheidung lässt sich beantworten, ohne Protokolldateien zu durchsuchen. Neben den Rohangaben liegen normalisierte Felder für E-Mail und Telefonnummer. Indizes liegen auf den Feldern, nach denen im Alltag tatsächlich gefiltert wird: Status, Eingangszeitpunkt, Herkunft, Zuständigkeit.

Dublettenerkennung

Eindeutige Treffer über die normalisierten Schlüssel werden zusammengeführt, bevor jemand den Datensatz zum ersten Mal öffnet. Unsichere Treffer werden nicht automatisch verschmolzen, sondern landen in einer Prüfliste. Diese Trennung ist Absicht: Eine falsch zusammengeführte Bewerbung kostet mehr Aufwand als eine, die zweimal in der Liste steht, weil sich die Zusammenführung im laufenden Betrieb nur mühsam rückgängig machen lässt.

Antwortzeiten

Listen werden serverseitig gefiltert und seitenweise geladen. Kennzahlen für Übersichten sind vorberechnet. Exporte und Massenaktionen laufen als Hintergrundjob mit Statusanzeige, damit ein Export über den Gesamtbestand keinen Arbeitsplatz blockiert. Ausgelegt sind diese Wege auf den Bestand, der sich über Jahre ansammelt.

Löschfristen

Jeder Datensatz trägt eine Aufbewahrungsfrist, die sich aus seinem Zustand ergibt. Läuft sie ab, wird der Datensatz gelöscht oder auf einen anonymen Rest reduziert, der noch für Statistik taugt und keine Person mehr erkennen lässt. Eine ausdrückliche Einwilligung zur längeren Speicherung setzt eine eigene, ebenfalls befristete Frist. Jeder Lauf wird protokolliert, sodass eine Auskunfts- oder Löschanfrage belegbar beantwortet werden kann.

Welche Fristen gelten, entscheidet der Kunde mit seiner rechtlichen Beratung. Das System setzt die festgelegten Fristen um und macht ihren Vollzug nachweisbar.

Über 200.000 Leads sind über den Funnel eingegangen und im CRM bis zur finalen Auswahl bearbeitet worden. Der gesamte Weg liegt in einem System, vom ersten Formularschritt bis zur Entscheidung, und der Bearbeitungsstand einer Bewerbung steht an einer Stelle.

Durchlaufzeiten und Konversionsraten sind nicht zur Veröffentlichung freigegeben und stehen deshalb hier nicht. Ob die Auswahl selbst bessere Ergebnisse liefert, lässt sich aus Systemdaten ohnehin nicht ablesen. Belegt sind die verarbeitete Menge und der durchgängige Weg der Daten.

Wer Bewerbungsfunnel-Software sucht, findet am Markt fertige Bewerbermanagementsysteme, die für viele Häuser ausreichen. Ein eigenes System lohnt sich erst, wenn mehrere der folgenden Punkte zusammenkommen.

• 01Der Zulauf kommt kontinuierlich über eigene Kanäle und erreicht Mengen, bei denen niemand mehr jeden Eingang einzeln sichtet.
• 02Die Auswahl läuft über mehrere Stufen mit unterschiedlichen Zuständigkeiten.
• 03Der Prozess weicht so weit von der Norm ab, dass Standardsoftware ihn nur mit Umwegen abbildet.
• 04Aufbewahrung und Löschung müssen belegbar sein, nicht nur behauptet.
• 05Die Auswertung soll auf den eigenen Rohdaten laufen und nicht auf dem, was ein Anbieter exportiert.

Bei wenigen hundert Bewerbungen im Jahr ist Standardsoftware schneller am Ziel und im Betrieb günstiger. Solange der Auswahlprozess selbst noch jedes Quartal anders aussieht, ist es ebenfalls zu früh: Ein System legt einen Ablauf zu einem gewissen Grad fest, und wer im Haus niemanden benannt hat, der über Fristen, Felder und Statusstufen entscheidet, verschiebt diese Entscheidungen in die Entwicklung, wo sie nicht hingehören.

Für ein System dieses Zuschnitts, also Funnel, CRM, Rollen und Auswertung auf einem Datenmodell, liegt der Rahmen erfahrungsgemäß in diesem Band. Was ein konkretes Vorhaben kostet, hängt an der Zahl der Schnittstellen und an der Tiefe der Auswahlstrecke.

Bei Personendaten in dieser Menge zählt, wer das System später noch ändern kann. Der Code gehört dem Kunden ab Tag eins, betrieben wird in Deutschland oder der EU.

• Alle Projekte