Der Test startet, ohne dass jemand klickt.

Eine manuelle Einladung fühlt sich nach dreißig Sekunden an und kostet realistisch drei bis fünf Minuten: Bewerbermanagement öffnen, Adresse kopieren, ins Testsystem wechseln, Test auswählen, versenden, zurückwechseln, Notiz hinterlassen. Der Wechsel zwischen zwei Oberflächen macht dabei den größeren Teil aus, nicht das Versenden selbst.

Bei zehn Einladungen im Monat reden wir also über unter eine Stunde. Dafür baut niemand eine Schnittstelle. Bei achtzig sind es fünf bis sieben Stunden, jeden Monat, und die Rechnung dreht sich. Der zweite Grund wiegt oft schwerer als die Zeit: Beim manuellen Weg bleiben Kandidaten liegen. Jemand ist im Urlaub, die Vertretung kennt den Ablauf nicht, und drei Bewerber warten zwei Wochen auf einen Link, den sie nie bekommen. Das fällt niemandem auf, weil es keinen Fehler erzeugt — nur eine Absage von der anderen Seite.

Prüfen Sie vor dem Projekt außerdem, ob der Engpass überhaupt beim Versand liegt. Wenn die Einladungen zügig rausgehen, die Ergebnisse aber vier Tage unbearbeitet liegen, lösen Sie mit einer Schnittstelle das falsche Problem. Welche Kennzahl das zeigt, steht in Recruiting-KPIs.

Im Bewerbermanagement hinterlegen Sie eine Adresse und wählen aus, bei welchem Ereignis sie aufgerufen werden soll — meistens der Wechsel in einen Status wie „Im Assessment“. Sobald ein Recruiter diesen Status setzt, schickt das System einen Datensatz mit Name, E-Mail-Adresse und Stelle an diese Adresse. Der empfangende Dienst legt daraufhin eine Einladung für den hinterlegten Test an und verschickt sie an den Kandidaten.

Drei Dinge sollten dabei von Anfang an geregelt sein. Erstens die Zuordnung Test zu Stelle: Entweder ein Test für alle Vorgänge, die über diesen Weg kommen, oder eine Zuordnung anhand der Stellenkategorie — dann brauchen Sie allerdings die Logik dazwischen. Zweitens die Absicherung: Der Endpunkt muss prüfen, dass der Aufruf wirklich aus Ihrem System kommt, in der Regel über einen Schlüssel oder eine Signatur im Aufruf. Drittens der Umgang mit Wiederholungen: Viele Systeme rufen bei einem Fehler mehrfach an, und ohne Duplikatsprüfung verschicken Sie dann drei Einladungen für denselben Vorgang.

Die technischen Einzelheiten für trønso — Endpunkte, Authentifizierung per Schlüssel, Signaturprüfung und die Struktur der Nutzdaten — stehen in der Dokumentation und der API-Übersicht.

Die Versuchung ist groß, alles zurückzuschreiben, was die Schnittstelle hergibt. Tun Sie es nicht. Für die Arbeit im Recruiting reichen drei Angaben am Bewerberdatensatz: der Status, das Gesamtergebnis und ein Link auf die Detailansicht. Alles Weitere schauen die zwei bis drei Personen an, die es wirklich brauchen, und zwar dort, wo es ohnehin liegt.

Der Grund ist nicht nur Übersichtlichkeit. Jedes Feld, das Sie zurückspielen, erzeugt eine zweite Kopie derselben Kandidatendaten an einem anderen Ort — mit eigener Zugriffsberechtigung, eigener Aufbewahrung und eigener Löschung. Wer Freitextantworten und Protokolldaten automatisch ins ATS schreibt, muss sie später auch dort wieder herausbekommen, und in vielen Systemen ist das mühsamer als gedacht. Legen Sie die Feldliste deshalb gemeinsam mit den Datenschutzverantwortlichen Ihres Hauses fest, bevor gebaut wird, nicht danach.

Praktisch bewährt sich außerdem, den Status feiner zu führen als nur „bestanden / nicht bestanden“. Die Unterscheidung zwischen „eingeladen, aber nie begonnen“ und „begonnen und abgebrochen“ sagt etwas über Ihr Verfahren aus: Häufen sich die ersten, stimmt etwas mit der Einladungsmail nicht. Häufen sich die zweiten, ist der Test zu lang.