Ein n8n-Flow, der neue Ashby-Bewerbungen abhört, den Kandidaten-Datensatz plus das Must-Have-Rubric der Stelle abruft, Claude bittet, die Bewerbung gegen das Rubric mit aus dem Lebenslauf zitierter Evidenz zu bewerten, und das Ergebnis in einen von drei Slack-Kanälen routet: #review-needed (die meisten), #fast-track (oberstes Dezil, nach Gesamtscore und Aktualität), oder #surfaced-not-rejected (unter dem Schwellenwert, aber sichtbar gehalten — der Flow lehnt niemals automatisch ab). Ersetzt die tägliche Posteingangs-Sortier-Stunde des Recruiters durch eine geordnete Slack-Queue, die 12–15 Minuten zum Durchgehen braucht.
Wann einsetzen
- Sie erhalten ≥30 eingehende Bewerbungen pro Stelle pro Woche, und der Recruiter verbringt täglich mehr als eine Stunde damit, Lebensläufe zu lesen, die größtenteils nicht passen.
- Die Stelle hat ein schriftliches Rubric mit Verhaltensankern pro Dimension (Skill-Match, Level, Standort/Arbeitsgenehmigung, Antwort-Wahrscheinlichkeit). Die Rubric-Vorlage liegt im
_README.mddes Bundles. Ohne sie bewertet der Flow gegen Bauchgefühl. - Sie verwenden Ashby oder ein anderes ATS, das einen Per-Bewerbung-Webhook liefert. Greenhouse, Lever, Workable qualifizieren alle; der Intake-Node des Flows tauscht sauber aus. Nur-Polling-ATS-Plattformen funktionieren, aber mit einer 5-Minuten-Untergrenze bei der Latenz.
- Ein Recruiter geht die
#review-needed-Queue mindestens täglich durch und bearbeitet jeden Eintrag. Der Flow verschiebt Kandidaten nicht in eine Stage im ATS.
Wann NICHT einsetzen
- Auto-Ablehnung im Loop. Der Flow rankt und routet; er lehnt niemals ab. Eine
reject-Aktion an einen Score-Schwellenwert zu verdrahten, macht das zu automatisierter Entscheidungsfindung — das löst NYC Local Law 144 Bias-Audit-Pflichten innerhalb eines Jahres nach dem Go-Live aus, und EU-KI-Act-Annex-III-Hochrisikosystem-Pflichten für jeden EU-ansässigen Kandidaten. Der dritte Bucket des Flows (#surfaced-not-rejected) existiert genau deshalb, damit der Recruiter sieht, wer abgelehnt worden wäre, und überschreiben kann. - Demografische Daten als Scoring-Input. Der Flow verweigert, nach Name, Foto, Schulname als eigenständigem Signal, Adresse, aus dem Abschlussjahr inferiertem Alter, Geschlechtspronomen, Beschäftigungslücken-Strafen oder „Cultural Fit” ohne Verhaltensanker zu bewerten. Die Fairness-Checkliste im
_README.mddes Bundles läuft als Preflight auf dem Rubric. - Das Urteilsvermögen des Recruiters bei Grenzfällen ersetzen. Gesamtscore innerhalb von 15 % des Cutoffs wird nach
#review-neededgeroutet, nicht in einen der Enden. Das ist ein absichtliches Ermessens-Puffer-Band. - Rollen, bei denen Sie weniger als 10 Bewerbungen pro Woche erhalten. Manuelle Triage ist schneller als ein Rubric und eine Slack-Queue zu abstimmen. Die Setup-Kosten des Flows (60 Minuten plus Rubric-Erstellung) amortisieren sich bei der 30-App-pro-Woche-Marke, nicht bei der 5-pro-Woche-Marke.
- Vertrauliche / Executive-Rollen. Andere Einwilligungs-Haltung. Andere Audit-Kette. Anderes Routing — diese gehen direkt zu einem namentlichen Recruiter, nicht in einen gemeinsamen Slack-Kanal.
Einrichtung
- Flow importieren. Legen Sie
apps/web/public/artifacts/inbound-applicant-triage-n8n/inbound-applicant-triage-n8n.jsonin Ihre n8n-Instanz. Jeder Node trägtnotesInFlow: true, sodass die In-Canvas-Notizen die Entscheidungen erklären. - Credentials verdrahten. Der Flow braucht drei:
PLACEHOLDER_ASHBY_CRED_ID(Ashby-API-Key, nur Lese-Scope),PLACEHOLDER_ANTHROPIC_CRED_ID(Claude-API-Key),PLACEHOLDER_SLACK_CRED_ID(Slack-Bot-Token mitchat:writefür die drei Kanäle). Jeder Abschnitt in_README.mdzeigt, wo der Wert zu finden ist. - Rubric verfassen. Pro Stelle eine JSON-Datei unter
n8n/data/rubrics/<role-slug>.jsonmit den vier Dimensionen (Skill, Level, Standort, Antwort-Wahrscheinlichkeit) und Verhaltensankern pro Dimension schreiben. Der Flow schlägt das Rubric nachrole_slugaus dem Ashby-Bewerbungs-Payload nach. Kein Rubric für eine Stelle → der Flow stoppt mit einemmissing_rubric-Log-Eintrag statt gegen Defaults zu bewerten. - Routing-Schwellenwerte konfigurieren. Im
Route by Aggregate-IF-Node:aggregate >= 16routet nach#fast-track,12–15nach#review-needed, alles unter 12 nach#surfaced-not-rejected. Nach einer Woche Dry-Run einstellen. - Dry-Run auf einer geschlossenen Rolle. Die letzte Woche Bewerbungen für eine manuell gesourcte Stelle wiederholen. Den
#fast-track-Bucket des Flows mit Ihrer tatsächlichen Screen-Pass-Liste vergleichen. Rubric-Anker einstellen, wenn sie abweichen — die Anker, nicht das Modell, sind normalerweise falsch. - Trigger aktivieren. Den Ashby-Webhook von
disabledaufenablednur nach einem guten Dry-Run umschalten. Webhook-Traffic in der Produktion ist schwieriger zu debuggen als wiedergegebene Historie.
Was der Flow macht
Acht Nodes, in Reihenfolge. Der Flow hält Fairness-Preflights und deterministische Filter vor dem LLM-Call, weil das Modell auf einem kontaminierten Payload frei loszulassen schnelles, zuversichtliches, unbrauchbares Scoring produziert.
- Ashby-Webhook — empfängt
application.created-Events. Die Webhook-Signatur wird im nächsten Schritt verifiziert; ein nicht verifiziertes Payload wird verworfen. - Signatur verifizieren — HMAC-SHA256 gegen das konfigurierte Webhook-Secret. Nicht übereinstimmende Signatur → log + halt. Die Signaturprüfung ist nicht optional, weil Ashby-Webhooks aus dem offenen Internet erreichbar sind.
- Bewerbung + Rubric abrufen — zieht den vollständigen Kandidaten + Bewerbungs-Datensatz aus
/candidate.info(Ashby ist POST-only, sogar für Lesevorgänge — siehe_README.mddes Bundles), und lädt die Rubric-Datei der Stelle. Stoppt beimissing_rubricstatt auf einen Standard zurückzufallen. - Fairness-Preflight — führt das Rubric durch eine Checkliste von Protected-Class-Proxies. Schulrangfolge-Scoring, namensbasierte Filterung, Beschäftigungslücken-Strafen, Foto-Präsenz, „Cultural Fit” ohne Anker → stoppen und dem Rubric-Autor aufzeigen. Die Entscheidung, vor dem LLM-Call zu scheitern, ist absichtlich: Ein biasiertes Rubric in eine Scoring-API geladen hinterlässt einen Log-Eintrag, der bereits als automatisierte Verarbeitung unter DSGVO Art. 22 zählt.
- Deterministischer Vorfilter — prüft die Arbeitsgenehmigung gegen die Standortanforderung der Stelle, entfernt Bewerbungen aus der kürzlich-abgelehnten Liste (6-Monatsstille-Periode), bestätigt, dass die Bewerbung die erforderlichen Dokumente hat (Lebenslauf, optionales Anschreiben). Diese Filter sind auditierbar und das LLM verhandelt sie nicht erneut.
- Claude Score — sendet Rubric + Lebenslauf + Bewerbungsformulardaten an Claude. Gibt ein JSON-Objekt mit Per-Dimensions-Scores 1–5, einem wörtlichen Evidenz-String pro Dimension über 1 und einem Aggregat zurück. Scores ohne Evidenz-String werden standardmäßig auf 1 gesetzt. Die Evidenz-Anforderung ist das, was das Modell im Lebenslaufstext verankert statt aus Namen oder Schule zu inferieren.
- Route by Aggregate — IF-Node. Drei Branches nach Score-Band wie in Setup-Schritt 4 gesetzt.
- Slack Notify + Audit Append — postet in den entsprechenden Slack-Kanal mit einem Link zurück zur Ashby-Kandidaten-Seite, den Per-Dimensions-Evidenz-Auszügen und einem
view-rubric-Link. Fügt eine JSONL-Zeile anaudit/<YYYY-MM>.jsonlan mitapplication_id,role_slug,rubric_sha256, Per-Dimensions-Scores, Aggregat, Route, Modell. Keine PII. Das Audit-Log ist das, was einen NYC LL 144- oder EU-KI-Act-Inquiry überstehbar macht.
Kostenrealität
Pro 100 bewerteten Bewerbungen, auf Claude Sonnet 4.5:
- Anthropic-API-Token — typischerweise 8–12k Input-Token pro Bewerbung (Rubric ~1k + Lebenslauf + Formulardaten) und 400–700 Output-Token (bewertetes JSON + Evidenz). Zu Sonnet-4.5-Listenpreisen landet das bei ungefähr 0,05–0,08 $ pro Bewerbung. Ein Team, das 1.000 eingehende Bewerbungen pro Woche bewertet, läuft 50–80 $ pro Woche in Modellkosten.
- n8n-Kosten — Self-hosted n8n ist in einem Container kostenlos. n8n Clouds Starter-Plan deckt ~5k Workflow-Ausführungen pro Monat für 20 $; mittlere-Volumen-Teams (>5k/Woche) brauchen Pro oder Self-hosted.
- Ashby-API-Kontingent — nur Leseanrufe. Der Flow macht 1
/candidate.infopro Bewerbung; weit innerhalb von Ashbys 100-Req/min-Standard. - Recruiter-Zeit — das ist der Gewinn. 100 Bewerbungen manuell lesen ist ~8 Stunden; die Slack-
#review-needed-Queue mit vorab-stagierter Evidenz und Links durchgehen ist ~20–30 Minuten. Die Fast-Track-Queue braucht weitere 5–10 Minuten für höherwertigen Outreach. - Setup-Zeit — 60 Minuten für den Flow selbst, plus 30–60 Minuten pro Stelle für das Rubric. Das Rubric ist die bindenden Kosten; Wiederverwendung über Rollenfamilien amortisiert sie.
Erfolgsmetrik
Drei Zahlen pro Stelle pro Monat im ATS verfolgen:
- Recruiter-Screen-Pass-Rate aus
#fast-track— sollte ≥75 % auf einem kalibrierten Rubric sein. Darunter ist das Rubric oder der Schwellenwert locker; straffen Sie die Anker, bevor Sie den Schwellenwert erhöhen. - Recruiter-Screen-Pass-Rate aus
#review-needed— sollte 25–40 % sein. Wenn sie unter 20 % fällt, ist das Ermessens-Puffer-Band zu breit und Sie lesen zu viele. Wenn sie über 50 % steigt, ist der Fast-Track-Cutoff zu hoch und qualifizierte Kandidaten werden verpasst. - Zeit von Bewerbung bis erstem Recruiter-Kontakt — sollte von Tagen auf unter 4 Stunden sinken. Das ist die Kandidatenerfahrungs-Metrik und das, was den Flow gegenüber dem TA-Leiter verteidigbar macht.
Vergleich mit Alternativen
- vs. Ashbys natives Scoring (oder Greenhouse Predictive Hire) — ATS-natives Scoring ist für die binäre „Match-Wahrscheinlichkeit”-Frage in Ordnung, aber der Score ist eine Black Box und das Rubric gehört nicht Ihnen. Wählen Sie den Flow, wenn Sie einen Per-Dimensions-Score mit wörtlicher Evidenz benötigen (verteidigbar unter NYC LL 144), ein Rubric, das Sie versionskontrollieren, oder ein Modell, das Sie austauschen können. Wählen Sie ATS-nativ, wenn Ihr Team das Rubric nicht pflegen wird.
- vs. Eightfold / Findem Inbound-Matching — das sind tiefere Produkte: Sie re-scoren gegen Ihre historischen Einstellungen, sie handhaben Outbound, sie besitzen einen Kandidaten-Graphen. Wählen Sie sie, wenn das Budget das Plattform-Spiel trägt und Sie ein verwaltetes Produkt wollen. Wählen Sie den Flow, wenn Sie das Rubric und das Audit-Log in Ihrem Repo wollen und der Rest Ihres Stacks bereits verdrahtet ist.
- vs. DIY-Python-Script, das die Ashby-API pollt — gleiche Scoring-Qualität, wenn Sie den Prompt sorgfältig aufbauen, aber Sie bauen auch die Webhook-Signatur-Verifizierung, den Fairness-Preflight, den Rubric-Loader, das Audit-Log, das Slack-Routing und die n8n-Debugger-UX selbst. Das Bundle liefert sie.
- vs. Status quo (Recruiter liest alles) — manuell ist richtig bei weniger als 10 Apps/Woche pro Stelle, wo ein Rubric Overhead ist und der Kopf des Recruiters bereits kalibriert ist. Der Flow verdient seine Setup-Kosten bei Rollen, die skalieren.
Watch-outs
- Bias-Amplifikation. Guard: Der Fairness-Preflight in Schritt 4 stoppt den Flow, wenn das Rubric Protected-Class-Proxies enthält. Das Audit-Log erfasst
rubric_sha256pro bewerteter Bewerbung, sodass das bei einem bestimmten Datum verwendete Rubric unter EU-KI-Act- oder NYC Local Law 144-Prüfung reproduzierbar ist. - Webhook-Replay / Doppel-Scoring. Guard: Die Ashby-Webhook-Signatur enthält
application.created.id. Das Audit-Log des Flows ist aufapplication_idals Schlüssel; Zweitankunft wird erkannt und ohne Neubewertung übersprungen. - Modell-Output-Drift bei Rubric-Bearbeitungen. Guard:
rubric_sha256im Audit-Log macht Rubric-Änderungen zwischen zwei Runs sichtbar. Wenn ein Gesamtscore für eine neu bewertete Bewerbung abweicht, liegt der Unterschied im Rubric-Hash, nicht in Modell-Nicht-Determinismus. - Auto-Route-to-Rejection-Drift. Guard: Der Flow hat keinen
reject-Branch. Der dritte Bucket ist#surfaced-not-rejected, und die Slack-Nachricht enthält einen „promote to review”-Button, der die Bewerbung nach#review-neededre-routet. Der Recruiter ist die alleinige Ablehnungsautorität. - Lebenslauf-PII in Slack-Nachricht. Guard: Die Slack-Nachricht enthält nur den Vornamen des Kandidaten, den aktuellen Titel und die Per-Dimensions-Evidenz-Auszüge (max. 200 Zeichen jeweils). Vollständiger Lebenslaufsinhalt bleibt im ATS. Slack-Kanäle haben kürzere Aufbewahrung als Ashby; der Flow macht Slack nicht zu einer Kandidaten-Datenbank.
- Nicht-auf-EU-Kandidaten-getestetes Risiko. Guard: Der
Verify Signature-Node des Flows prüft auch den angegebenen Standort der Bewerbung. Bewerbungen mit EU-ansässigen Standortcodes werden unabhängig vom Score nach#review-neededgeroutet, und die Slack-Nachricht flaggtEU-Kandidat — bestätigen, dass KI-Screening-Hinweis zugestellt wurde. KI-Screening von EU-Ansässigen ohne Hinweis ist eine EU-KI-Act-Hochrisikosystem-Verletzung.
Stack
Das Artefakt-Bundle liegt unter apps/web/public/artifacts/inbound-applicant-triage-n8n/ und enthält:
inbound-applicant-triage-n8n.json— der n8n-Flow-Export (jeder Node konfiguriert, keine Stub-Parameter)_README.md— Credential-Setup, Rubric-Format, Fairness-Checkliste, Dry-Run-Prozedur
Tools, die der Workflow voraussetzt: Ashby (das ATS — wechseln Sie zu Greenhouse oder Lever, indem Sie den Intake-Node ersetzen), Claude (das Scoring-Modell), n8n (die Orchestrierung), Slack (die Recruiter-Queue-Oberfläche). Für den parallelen Sourcing-Flow siehe den Kandidaten-Sourcing-Claude-Skill; für den Per-Loop-Interview-Aufbau siehe den Interview-Loop-Builder.
Verwandte Konzepte: KI-Screening-Bias, Kandidatenerfahrung, Recruiting-Funnel-Metriken, Strukturiertes Interviewen.