Lead-Qualifizierung automatisieren: wie n8n eingehende Anfragen bewertet und einsortiert

n8n kann eingehende Anfragen beim Eintreffen automatisch erfassen, anhand festgelegter Kriterien bewerten und in eine von mehreren Bearbeitungsstufen einsortieren – von der sofortigen Übergabe an den Vertrieb bis zur automatisierten Nachfass-Sequenz. Wie fein diese Einsortierung ausfällt, entscheidet nicht die Technik, sondern eine Matrix, die Sie vorab für Ihren eigenen Vertrieb festlegen.

Dieser Beitrag zeigt zuerst den technischen Aufbau eines solchen Workflows, dann ein Entscheidungswerkzeug mit drei getrennt bewerteten Kriterien statt einer einzigen, ungetrennten Einschätzung, ob eine Anfrage heiß, warm oder kalt ist – und eine Regel, die verhindert, dass ein eigentlich wertvoller Lead unbemerkt in der kalten Schublade verschwindet.

Wie ein n8n-Workflow eingehende Anfragen erfasst und einordnet

Der Aufbau besteht aus fünf Schritten: Anfrage erfassen, Freitext strukturieren, mit CRM-Daten abgleichen, nach der Matrix bewerten, in die passende Stufe einsortieren. Unser Pillar-Guide zur n8n-Einführung im Mittelstand beschreibt den allgemeinen Aufbau von Trigger bis Fehlerbehandlung im Detail; dieser Beitrag konzentriert sich auf den fachlichen Teil dieses einen Anwendungsfalls.

1. Anfrage erfassen

Läuft das Kontaktformular bereits über n8n, fängt der Form-Trigger-Node die Eingabe ab. Laut Dokumentation lassen sich Feldtypen wie Text, E-Mail, Dropdown oder Textarea frei definieren, und die Antwort an die Besucherin oder den Besucher erfolgt entweder sofort bei Absenden oder erst, wenn der gesamte Workflow durchgelaufen ist. Läuft das Formular stattdessen über die bestehende Website, übernimmt ein Webhook-Node dieselbe Aufgabe – er akzeptiert laut Dokumentation POST-Anfragen bis zu einer maximalen Payload-Größe von 16 MB, was für ein Formular mit Freitext und ohne Dateianhang weit ausreicht.

2. Freitext strukturieren

Ein Nachrichtenfeld wie „Ihr Anliegen“ liegt zunächst nur als unstrukturierter Text vor. Der Information-Extractor-Node liest dieses Feld und ordnet es einem vorab definierten Schema zu – laut Dokumentation entweder über eine Liste benannter Attribute mit Beschreibung, über ein JSON-Beispiel, dessen Feldnamen und Typen übernommen werden, oder über ein manuell geschriebenes JSON-Schema. Für die Lead-Qualifizierung eignen sich Attribute wie „genannte Frist“, „Hinweis auf Unternehmensgröße“ oder „Hinweis auf Budget-Rahmen“ – jeweils mit einer kurzen Beschreibung, wonach gesucht werden soll.

3. Mit CRM-Daten abgleichen

Ein HTTP-Request-Node fragt parallel das CRM nach einem bestehenden Kontakt mit derselben E-Mail-Domain ab – laut Dokumentation lässt sich damit jede REST-API abfragen, für unterstützte Dienste empfiehlt n8n einen vordefinierten Credential-Typ. Der Merge-Node führt beide Ergebnisse anschließend zusammen: Im Modus „Combine“ mit „Matching Fields“ auf das E-Mail-Feld lassen sich laut Dokumentation Formulardaten und CRM-Treffer zu einem Datensatz vereinen, und die Option „Output Type“ steuert, ob auch Formulareinträge ohne CRM-Treffer erhalten bleiben – im Fall einer neuen Anfrage ohne bestehenden Kontakt ist genau das nötig.

4. Nach der Matrix bewerten

Ein Code-Node berechnet aus den drei Kriterien der Matrix unten eine Punktsumme. Da jede Anfrage einzeln bewertet wird, läuft der Node im Modus „Run Once for Each Item“, bei dem der Code laut Dokumentation für jedes Eingabe-Item separat ausgeführt wird:

const summe =
  $json.reaktionsgeschwindigkeit + // 0, 1 oder 2
  $json.datenvollstaendigkeit + // 0, 1 oder 2
  $json.vertriebswert; // 0, 1 oder 2

return { json: { ...$json, matrixSumme: summe } };

Die drei Eingabewerte selbst stammen aus einem vorgeschalteten Edit-Fields-Node: Er übersetzt die Attribute aus Schritt 2 und 3 nach einer festen, vorab definierten Regel in Punktwerte – laut Dokumentation lassen sich im Manual-Mapping-Modus sowohl neue Felder setzen als auch bestehende überschreiben, und die Option „Keep Only Set Fields“ reduziert den Datensatz auf das, was der nächste Schritt tatsächlich braucht.

5. Einsortieren und weiterleiten

Ein Switch-Node ordnet jede Anfrage anhand der Punktsumme und einer vorgeschalteten Regel für den Vertriebswert (siehe Rückfallregel unten) einer von drei Ausgaben zu. Laut Dokumentation prüft der Node im Rules-Modus die Regeln der Reihe nach und leitet ein Item an die erste zutreffende Regel weiter, solange „Send data to all matching outputs“ nicht aktiviert ist – genau das Verhalten, das die Rückfallregel braucht, wenn sie vor der reinen Summenregel geprüft wird. Für Fälle, die keine Regel trifft, lässt sich laut Dokumentation ein „Extra Output“ als Fallback definieren, statt die Anfrage stillschweigend zu verwerfen.

Die drei Ausgänge schreiben die Einstufung anschließend ins CRM: Für Pipedrive legt der Pipedrive-Node laut Dokumentation über die Ressource „Lead“ oder „Deal“ einen neuen Datensatz an oder aktualisiert einen bestehenden. Bei „Heiß“ folgt zusätzlich eine Slack-Nachricht an die zuständige Vertriebsperson – der Slack-Node ruft dafür über die Operation „Send“ laut Dokumentation die Slack-API-Methode chat.postMessage auf. Für die „kalt“ eingestuften Anfragen läuft zusätzlich ein zweiter, zeitgesteuerter Workflow: Ein Schedule-Trigger-Node, laut Dokumentation auf die Intervall-Einheit „Weeks“ mit festem Wochentag und fester Uhrzeit einstellbar, ruft sie für die periodische Stichprobe ab (siehe unten).

Die Matrix: drei getrennte Kriterien statt einer einzigen Einschätzung

Eine einfache Einteilung in Heiß, Warm und Kalt aus dem Bauch heraus verdichtet drei unterschiedliche Fragen in eine einzige Einschätzung: wie dringend, wie gut dokumentiert und wie passend eine Anfrage ist. Getrennt betrachtet lassen sich diese drei Fragen gezielter beantworten – und genau diese Trennung macht die Rückfallregel weiter unten erst möglich.

Die drei Kriterien

Kriterium	Hoch (2 Punkte)	Mittel (1 Punkt)	Niedrig (0 Punkte)
Reaktionsgeschwindigkeits-Bedarf (wie dringend eine Reaktion sein muss)	Anfrage nennt eine konkrete Frist, einen akuten Vorfall oder eine laufende Ausschreibung	reguläre Projektanfrage ohne genannte Frist	reine Informationsanfrage ohne erkennbaren Zeitdruck
Datenvollständigkeit (was der Workflow über die Anfrage weiß)	Firma, Ansprechperson mit Funktion, konkretes Anliegen und ein Hinweis auf Budget- oder Projektrahmen erkennbar	Firma und Anliegen erkennbar, aber Funktion der Ansprechperson oder Rahmen fehlen	nur Name und eine generische Nachricht ohne erkennbaren Firmenbezug
Vertriebswert (wie gut die Anfrage zum eigenen Zielkundenprofil passt)	Branche, Unternehmensgröße oder Funktion der Ansprechperson entsprechen dem Zielkundenprofil, oder laut CRM besteht bereits eine Kundenbeziehung	teilweise passend oder aus dem Text nicht eindeutig bestimmbar	erkennbar außerhalb des Zielkundenprofils (z. B. Bewerbung, Mitbewerber-Domain, Studierende)

Die Ausprägungen sind bewusst so formuliert, dass sie sich direkt auf den eigenen Vertrieb übertragen lassen: Ersetzen Sie „Zielkundenprofil“ durch die Branchen und Größenklassen, die Ihr Unternehmen tatsächlich bedient, und „konkrete Frist“ durch die Formulierungen, die in Ihren eingehenden Anfragen typischerweise auf Dringlichkeit hindeuten.

Von der Punktsumme zur Stufe

Punktsumme	Stufe	Weiterleitung
5–6	Heiß	sofortige Übergabe an den Vertrieb, Slack-Benachrichtigung
3–4	Warm	reguläre Pipeline, Bearbeitung nach Priorität
0–2	Kalt	automatisierte Nachfass-Sequenz, abgesichert durch Rückfallregel und Stichprobe

Zwei Beispiele zeigen, wie die drei Kriterien zusammenwirken: Eine Anfrage mit dem Betreff „Angebot für die Automatisierung des Bestellwesens bis Ende des Quartals“, abgesendet von einer Person mit der Funktion „Leiter Einkauf“ bei einem Unternehmen aus dem Zielkundenprofil, erreicht bei Reaktionsgeschwindigkeit und Vertriebswert die Stufe Hoch, bei Datenvollständigkeit mangels eines eigenständigen Budget- oder Projektrahmen-Hinweises die Stufe Mittel – Summe 5, Stufe Heiß. Eine kurze Nachricht „Ich interessiere mich für KI, bitte Infos“ ohne Firmenbezug und ohne erkennbare Funktion der absendenden Person erreicht dagegen bei Reaktionsgeschwindigkeit und Datenvollständigkeit die Stufe Niedrig, bei Vertriebswert mangels jedes Hinweises auf das Zielkundenprofil die Stufe Mittel – Summe 1, Stufe Kalt.

Die Rückfallregel gegen Fehlklassifikation

Die reine Punktsumme kann eine Anfrage falsch einordnen: Eine kurze, unpersönliche Nachricht von der E-Mail-Domain eines erkennbar guten Zielkunden erreicht bei Reaktionsgeschwindigkeit und Datenvollständigkeit jeweils 0 Punkte, bei Vertriebswert aber 2 Punkte – macht in Summe 2 Punkte und würde nach der reinen Summenregel in der Kalt-Stufe landen, obwohl der Vertriebswert allein schon die Stufe Hoch erreicht. Genau dieser Fall – ein eigentlich wertvoller Lead, der an Dringlichkeit und Datenlage scheitert – ist der Grund für eine zweite Regel: Erreicht Vertriebswert allein die Stufe Hoch und würde die Anfrage nach der reinen Summenregel in der Kalt-Stufe landen, hebt der Switch-Node die Einstufung auf mindestens Warm an. Diese kombinierte Regel wird vor der einfachen Kalt-Regel geprüft; da der Switch-Node im Rules-Modus die erste zutreffende Regel verwendet, hat sie damit Vorrang – ein Lead, der bereits ohne sie bei Warm oder Heiß landet (wie im Beispiel oben mit Summe 5), bleibt davon unberührt.

Die periodische Stichprobe

Die Rückfallregel fängt nur den Fall ab, den sie vorhersieht: einen hohen Vertriebswert bei gleichzeitig niedriger Dringlichkeit und Datenlage. Für alle übrigen Fehlklassifikationen – etwa eine falsch extrahierte Angabe aus Schritt 2 oder ein Zielkundenprofil, das die tatsächliche Marktlage nicht mehr trifft – bleibt eine zweite, unabhängige Absicherung sinnvoll: ein wöchentlicher Schedule-Trigger, der die in der vergangenen Woche als „kalt“ eingestuften Anfragen aus dem CRM abruft und einer Person zur Sichtprüfung vorlegt. Welchen Anteil der Kalt-Stufe Sie dabei tatsächlich ansehen, legen Sie nach dem eigenen Anfragenaufkommen fest – bei wenigen Anfragen pro Woche ist eine vollständige Durchsicht praktikabel, bei einem höheren Aufkommen reicht eine Teilmenge. Entscheidend ist, dass die Prüfung regelmäßig stattfindet, nicht ihr Umfang im Einzelnen.

Wo die Automatisierung an ihre Grenze stößt

Die Einstufung ist nur so gut wie die Matrix, die ihr zugrunde liegt: Ein veraltetes Zielkundenprofil oder zu eng formulierte Dringlichkeits-Kriterien schlagen sich in jeder einzelnen Bewertung nieder, ohne dass der Workflow das selbst bemerkt. Die Matrix braucht deshalb eine im Vertrieb verankerte, in Abständen überprüfte Festlegung – nicht nur eine einmalige Einrichtung.

Die Freitext-Extraktion aus Schritt 2 ist eine weitere Fehlerquelle: Der Information-Extractor-Node kann eine genannte Frist oder einen Größenhinweis übersehen oder falsch zuordnen, insbesondere bei mehrdeutig formulierten Anfragen. Da die Extraktion nur eines von drei Kriterien speist und die Rückfallregel unabhängig davon greift, bleibt der Schaden eines einzelnen Fehlers begrenzt – ein Grund mehr, die drei Kriterien tatsächlich getrennt zu halten, statt sie vorschnell zu einer einzigen KI-Bewertung zusammenzufassen.

Wird die Anfrage in Schritt 3 zusätzlich um Firmendaten aus einer externen Anreicherungs-API ergänzt, verlassen dabei personenbezogene Daten die eigene n8n-Instanz in Richtung eines weiteren Anbieters. Wie sich das zwischen Self-Hosting und Cloud-Betrieb unterscheidet, ordnet unser Beitrag zu n8n, DSGVO und Hosting ein.

Für den Mittelstand heißt das

Legen Sie die Matrix fest, bevor der Workflow gebaut wird – gemeinsam mit der Person, die heute eingehende Anfragen von Hand sortiert. Diese Person trifft die drei Einstufungen ohnehin bereits informell; die Matrix macht nur explizit, wonach sie dabei tatsächlich entscheidet, und macht diese Entscheidung dadurch überprüf- und wiederholbar.

Starten Sie mit der reinen Punktregel und beobachten Sie über einige Wochen, wie oft die Rückfallregel tatsächlich greift. Greift sie selten, war die Grundeinteilung schon tragfähig; greift sie häufig, sagt das etwas über die Gewichtung der drei Kriterien zueinander aus – dann lohnt sich eine Anpassung der Punktewerte oder der Schwellen, bevor weitere Automatisierung draufgesetzt wird. Ist ein Lead einmal als „Heiß“ eingestuft und im CRM angelegt, zeigt unser Beitrag zu Angeboten und Follow-ups mit n8n, wie sich der nächste Schritt automatisieren lässt. Dasselbe Grundprinzip – einstufen nach Risiko beziehungsweise Wert statt nach technischer Machbarkeit – nutzt auch unser Beitrag zu automatisierten Kundenservice-Antworten für eingehende Mails.

FAQ

Wie entscheidet n8n, ob eine eingehende Anfrage heiß, warm oder kalt ist?

n8n selbst entscheidet das nicht – es wertet eine Matrix aus, die Sie vorab aus drei Kriterien festlegen: Reaktionsgeschwindigkeits-Bedarf, Datenvollständigkeit und Vertriebswert. Jedes Kriterium bekommt 0 bis 2 Punkte, ein Code-Node summiert sie, und ein Switch-Node ordnet die Summe einer von drei Stufen zu. Die fachliche Festlegung treffen Sie, der Workflow führt sie nur aus.

Was passiert, wenn ein eigentlich wertvoller Lead fälschlich als kalt eingestuft wird?

Zwei Absicherungen fangen diesen Fall ab. Erstens eine Rückfallregel: Erreicht das Kriterium Vertriebswert allein die Stufe Hoch und würde die Anfrage sonst in der Kalt-Stufe landen, hebt der Workflow die Einstufung auf mindestens Warm an. Zweitens eine periodische Stichprobe: Ein Schedule-Trigger-Node ruft wöchentlich die als „kalt“ eingestuften Anfragen ab und legt sie einer Person zur Sichtprüfung vor, unabhängig davon, ob die Rückfallregel gegriffen hat.

Kann n8n den Inhalt einer Anfrage aus einem Freitextfeld selbst verstehen?

Teilweise, über den Information-Extractor-Node: Er liest ein Freitextfeld und ordnet es einem vorab definierten Schema zu, etwa einem Hinweis auf die Firmengröße oder eine genannte Frist. Die Extraktion kann Hinweise falsch deuten oder übersehen – deshalb darf sie nie allein über die Kalt-Einstufung entscheiden, sondern nur als eines von drei Kriterien einfließen, abgesichert durch die Rückfallregel.

Welche CRM-Systeme lassen sich für die Lead-Qualifizierung mit n8n anbinden?

Für Pipedrive gibt es einen eigenen Node mit den Ressourcen Lead, Person und Deal. Für CRM-Systeme ohne eigenen n8n-Node, etwa viele Branchenlösungen, übernimmt der HTTP-Request-Node die Anbindung über die REST-API des Systems und ein dafür hinterlegtes Credential.

Worin unterscheidet sich diese Matrix von einer einfachen Hot/Warm/Cold-Einteilung?

Eine einfache Hot/Warm/Cold-Einteilung verdichtet Dringlichkeit, Datenlage und Passung zum Zielkunden in eine einzige Einschätzung. Die Matrix trennt diese drei Dimensionen und macht sichtbar, warum eine Anfrage in eine Stufe fällt – und erlaubt dadurch die Rückfallregel: Ohne die Trennung nach Vertriebswert ließe sich ein passender, aber datenarmer Lead gar nicht gezielt anheben.