Lead-Qualifizierung mit n8n: Kategorien, Scoring und Follow-up

Was ist automatisierte Lead-Qualifizierung?

Kurzantwort: Für einen überschaubaren Einstieg kann ein n8n-Hauptworkflow genügen. Er nimmt Anfragen an, prüft Pflichtdaten, ordnet sie nach Regeln ein und bereitet die CRM-Übergabe vor. Zusätzliche Workflows werden sinnvoll, wenn beispielsweise Nachverfolgung oder Fehlerbehandlung unabhängig laufen sollen. Eine feste Anzahl gibt es nicht.

Lead-Qualifizierung bedeutet, eine Anfrage strukturiert aufzunehmen, ihre bekannten Merkmale zu ordnen und den nächsten sinnvollen Schritt festzulegen. Ein Lead ist dabei eine Anfrage oder ein Kontakt mit einem erkennbaren Anliegen. Eine Kategorie beschreibt eine fachliche Route, zum Beispiel needs_review, warm oder needs_data. Ein Score ist eine priorisierende Einschätzung. Er ersetzt keine Prüfung und ist keine Zusage.

Ein Workflow beschreibt die technische Verarbeitung. Ein Prozessschritt beschreibt, was darin geschieht: Lead-Erfassung, Vorprüfung, Bewertung, CRM-Übergabe oder Follow-up können Schritte desselben Ablaufs sein. Diese Begriffe sollten im Projekt nicht vermischt werden. Die erste Anschlussfrage lautet deshalb: Welche Entscheidung soll nach der Qualifizierung tatsächlich möglich sein, und welcher Teil bleibt bei einem Menschen?

Ein guter Ablauf macht fehlende Angaben sichtbar, speichert seine Begründung und hält Außenwirkungen zurück, bis sie geprüft sind. Er soll Ordnung in Anfragen bringen, ohne eine scheinbar genaue Zahl mit einer sicheren Entscheidung zu verwechseln.

Wie viele Workflows braucht die Lead-Kategorisierung?

Sechs beschriebene Schritte sind nicht automatisch sechs n8n-Workflows. Wenn ein gemeinsamer Eingang, dieselben Berechtigungen und eine zusammenhängende Fehlerbehandlung ausreichen, kann ein Hauptworkflow die Anfrage annehmen, prüfen, routen und an das CRM übergeben. Kategorien sind dabei Ausgänge oder fachliche Labels. Sie sind keine eigenen Workflows.

Eine Aufteilung wird sinnvoll, wenn sich Verantwortliche, Wartezeiten, Berechtigungen, Fehlergrenzen oder Außenwirkungen unterscheiden. Dann könnte ein System beispielsweise einen Ablauf für Intake und Vorprüfung, einen für Bewertung und Routing, einen für die CRM-Übergabe und einen freigegebenen Follow-up-Ablauf besitzen. Diese Aufteilung ist eine Architekturentscheidung, keine feste n8n-Regel.

Für die Entscheidung helfen drei Fragen: Gibt es denselben Trigger? Kann derselbe Verantwortliche Fehler und Wiederholungen bearbeiten? Entsteht eine eigene Außenwirkung oder Wartephase? Wenn Eingang, Zuständigkeit und Wiederholungslogik zusammenpassen, bleibt ein gemeinsamer Ablauf übersichtlich. Eine getrennte Freigabe oder unabhängige Wiederholung kann für ein Modul sprechen. Eine solche Aufteilung ersetzt allerdings keine Prüfung der Zugriffsrechte. Die Zahl ergibt sich aus diesen Grenzen, nicht aus der Zahl der Pfeile in einem Diagramm.

Welche Daten und Kategorien braucht der Einstieg?

Am Anfang steht ein kleiner Eingabevertrag. Sinnvolle Felder sind lead_id, Quelle, Eingangszeitpunkt, Anfrageart, gewünschter Zeitraum, bekannte Unternehmensdaten, Kontaktweg und ein dokumentierter Einwilligungsstatus. Ein unbekannter Wert bleibt unknown. Er wird nicht durch eine Vermutung ersetzt, nur damit die nächste Verzweigung einen Wert erhält.

Ein Eingang über einen Webhook kann einen Workflow starten und zwischen Test- und Produktionsadresse unterscheiden. Die n8n-Dokumentation zum Webhook-Node beschreibt außerdem dokumentierte Authentifizierungsoptionen. Vor dem Test klären wir daher: Welche URL wird verwendet, wie wird ein Request identifiziert, und welche Daten dürfen den ersten Schritt passieren?

Die erste Regel sollte prüfen, ob Mindestdaten vorhanden sind, ob eine Kontaktaufnahme vorgesehen ist und ob ein Duplikat bekannt ist. Fehlt etwas Wesentliches, führt der Weg zu needs_data oder needs_review. Eine Regel braucht immer eine verständliche Begründung und eine Route für den Fall, dass keine Bedingung passt.

Wie werden feste Regeln und KI-Scoring kombiniert?

Ein nachvollziehbares Scoring beginnt mit festen Regeln. Ein bekannter Zeitraum, ein klar beschriebenes Anliegen oder eine vollständige Anfrage können jeweils Punkte erhalten. Die genaue Gewichtung ist eine lokale Entscheidung und kein allgemeiner Branchenstandard. Jede Regel bekommt eine Version, damit später erkennbar bleibt, nach welcher Fassung der Wert entstand.

Eine KI kann aus Freitext einen Themenvorschlag oder eine Begründung ableiten. Sie sollte dabei nicht unbemerkt fehlende Angaben ergänzen. Speichern Sie deshalb neben score auch die Begründung, verwendete Eingabefelder und Regelversion. Eine vom Modell gemeldete Konfidenz ist dabei nur ein zusätzliches Signal; ihre Verlässlichkeit muss an geprüften Beispielen ermittelt werden. Ein niedriger oder nicht begründbarer Wert führt zu einer Prüfung, nicht automatisch zu einer Absage. Ein Modellvorschlag und eine deterministische Grenze haben unterschiedliche Aufgaben: Der Vorschlag hilft beim Ordnen, die Regel begrenzt die erlaubte Aktion.

Die Anschlussfragen lauten: Welche Merkmale sind fachlich relevant? Was passiert bei widersprüchlichen Angaben? Ab welchem Zustand ist eine menschliche Prüfung erforderlich? Ein brauchbarer Test enthält auch unvollständige und widersprüchliche Anfragen. Die erwartete Kategorie wird vorher festgelegt und anschließend mit dem Ergebnis verglichen.

Drei Beispielanfragen mit nachvollziehbarer Entscheidung

Die folgenden drei Fälle sind fiktive Planungsbeispiele. Sie enthalten keine echten Kundendaten und beschreiben keine bereits getestete JOOSN-Integration.

Wir verwenden bewusst eine kleine, vollständig sichtbare Beispielregel: Passende Leistung genannt = 40 Punkte; Anliegen konkret beschrieben = 30 Punkte; gewünschter Zeitraum bekannt = 30 Punkte. Fehlende Angaben ergeben für das jeweilige Merkmal 0 Punkte. Die Gewichte sind frei gewählte Testwerte, kein Branchenstandard. Kontaktstatus und Versandfreigabe werden unabhängig vom Score geprüft.

• Anfrage A – noch Angaben klären: „Wir brauchen eine neue Unternehmenswebsite.“ Die Leistung passt, ein konkretes Ziel und der Zeitraum fehlen. Ergebnis: 40 + 0 + 0 = 40 Punkte, Kategorie Angaben klären. Eine verantwortliche Person prüft, welche Rückfragen benötigt werden. Es startet keine E-Mail-Sequenz.
• Anfrage B – fachliche Prüfung vorbereiten: „Unsere Website-Anfragen sollen in das vorhandene CRM übernommen und nach Leistung verteilt werden. Der gewünschte Start ist in sechs Wochen.“ Alle drei Kriterien sind erfüllt. Ergebnis: 40 + 30 + 30 = 100 Punkte, Kategorie Fachlich prüfen. Das Team erhält die Anfrage und die Punktebegründung. Der Score bedeutet weder Kaufabsicht noch eine Angebots- oder Versandfreigabe.
• Anfrage C – Unsicherheit sichtbar halten: „Bitte Angebot senden.“ Leistung, konkretes Anliegen und Zeitraum sind unbekannt. Ergebnis: 0 Punkte, Kategorie Manuell prüfen. Auch der Kontaktstatus ist nicht geklärt. Das System erfindet keine fehlenden Angaben und erzeugt keinen externen Versand.

Für dieses Beispiel gilt: vollständig beschriebene passende Anfragen gehen in die fachliche Prüfung; erkennbare passende Anfragen mit Lücken in die Klärung; unklare Anfragen in die manuelle Prüfung. Bei widersprüchlichen Angaben hat die manuelle Prüfung Vorrang. Andere Betriebe brauchen andere Kategorien und Regeln.

So kann ein Hauptworkflow in n8n aussehen

Ein überschaubarer Hauptablauf kann so aussehen: Der Webhook nimmt den Datensatz an. Eine Vorprüfung kontrolliert Pflichtfelder, Einwilligungsstatus und Duplikat-Schlüssel. Danach wird ein regelbasierter Wert berechnet; eine KI darf ergänzend einen Themenvorschlag liefern. Die Anfrage wird einer Kategorie zugeordnet, an das CRM übergeben und intern zur Prüfung angezeigt.

Für die Vorprüfung eignet sich eine dokumentierte Bedingungsverzweigung. Der n8n-If-Node unterstützt unter anderem Existenz-, Leer- und Vergleichsbedingungen. Für mehrere Kategorien kann der n8n-Switch-Node mehrere Ausgänge und einen Fallback abbilden. Der Fallback ist entscheidend: Ein unbekannter Wert darf nicht stillschweigend in eine beliebige Route fallen.

Der Hauptablauf kann zunächst ausreichen. Wenn Bewertung, CRM-Schreibvorgang oder Follow-up andere Fehler- und Freigabegrenzen brauchen, werden daraus Module. In beiden Fällen müssen lead_id, execution_id und workflow_version die Übergabe nachvollziehbar machen. Ein erster Test läuft mit fiktiven oder freigegebenen anonymisierten Anfragen, bevor echte Folgeaktionen zugelassen werden.

Wie verhindern wir doppelte oder falsche Aktionen?

Interne Sortierung und externe Wirkung gehören auseinander. Ein CRM-Feld zu aktualisieren ist eine andere Aktion als eine E-Mail zu senden oder einen verbindlichen Status zu ändern. Für eine externe Nachricht braucht der Ablauf einen sichtbaren Entwurf, einen Freigabestatus und einen Nachweis des tatsächlichen Ergebnisses. Ein Lead-Score allein löst weder ein Newsletterabo noch einen ungeprüften Werbeversand aus.

Für einfache Freigaben beschreibt die n8n-Gmail-Dokumentation eine Operation, die sendet und auf Zustimmung oder Ablehnung wartet. Dabei wird zunächst die Freigabeanfrage an die prüfende Person gesendet. Die spätere Kundennachricht bleibt eine eigene Aktion mit genau festgelegtem Empfänger und Inhalt. Ablehnung, Ablauf und Änderung eines Entwurfs brauchen eigene Zustände.

Bei einer wiederholten Zustellung muss der Vorgang anhand von lead_id, einer externen Ereignis-ID oder einer anderen eindeutigen Kennung erkannt werden. Die HubSpot Contacts API beschreibt Kontakt-Properties und das Arbeiten mit eindeutigen Kennungen. Welche Kennung und welches CRM-Objekt verwendet werden, muss im Erstgespräch festgelegt werden. Fehler erhalten error_code, retry_count und crm_write_status=failed; ein Timeout ist kein stillschweigender Erfolg.

Wann darf ein Follow-up weiterlaufen und wann stoppt es?

Ein Follow-up beginnt erst, wenn die fachliche Route und die zulässige Außenwirkung feststehen. Der n8n-Wait-Node kann eine Ausführung zeit- oder ereignisbasiert pausieren und später fortsetzen. Die konkrete Frist richtet sich nach dem vereinbarten Ablauf. Eine pauschale Drei-Tage-Sequenz ist für unterschiedliche Anfragen nicht automatisch passend.

Jede Wartephase braucht eine Zeitzone, einen Status und ein Ende. Der Ablauf stoppt bei einer Antwort, einem Bounce, einer Abmeldung, einer manuellen Sperre, fehlender Einwilligung oder einem bereits erledigten Anliegen. Vor einer Wiederholung wird geprüft, ob inzwischen ein neues Ereignis eingegangen ist. Eine erneute Ausführung darf nicht einfach dieselbe Nachricht senden.

Die Anschlussfrage lautet: Welches Ereignis beendet den automatischen Versuch und übergibt an einen Menschen? Ohne diese Antwort ist ein Follow-up nur eine Warteschleife. Im Datensatz sollten deshalb Status der Nachverfolgung, nächster Termin und Abbruchgrund getrennt stehen.

Woran messen wir die Qualität und den geschäftlichen Nutzen?

Technische Qualität, fachliche Qualität und Geschäftsergebnis sind drei verschiedene Ebenen. Technisch lassen sich Ausführungsstatus, Fehler, Wiederholungen, Wartezeiten, Fallbacks, Duplikatunterdrückung und bestätigte CRM-Übergaben zählen. Fachlich lassen sich Referenzkategorie, fehlende Felder, Konfidenz und menschliche Überschreibungen vergleichen. Geschäftlich können später beantwortete Anfragen oder qualifizierte Erstgespräche erfasst werden, sofern diese Ereignisse sauber definiert sind.

Der n8n-Evaluation-Node unterstützt Evaluationsdaten und numerische Metriken für AI-Workflows. Dafür braucht es einen freigegebenen Testdatensatz mit erwarteten Kategorien und Stoppsignalen. Aus einem Testlauf folgt keine bestimmte Zeitersparnis, Umsatzwirkung oder Erfolgsquote. Für eine spätere Nutzenbewertung erfassen wir vor und nach der Umstellung dieselben Vorgänge über gleich lange Zeiträume: zum Beispiel Bearbeitungszeit je vollständiger Anfrage, Zahl notwendiger Rückfragen und qualifizierte Erstgespräche. Änderungen am Anfrageaufkommen müssen bei der Bewertung berücksichtigt werden.

Was klären wir im JOOSN-Erstgespräch?

Für ein erstes JOOSN-Gespräch sollten sechs Punkte geklärt werden: Welche Eingänge gibt es? Welche CRM-Objekte sollen entstehen oder aktualisiert werden? Welche Felder sind Pflicht? Wer darf Kategorie und Score ändern? Welche Außenwirkungen brauchen eine Freigabe? Welche Ereignisse stoppen ein Follow-up? Zusätzlich sollte feststehen, welcher Nachweis für eine erfolgreiche interne Übergabe genügt.

Das Ergebnis kann eine kleine Version lead-routing-v0.1 sein: ein Hauptworkflow mit klarer Vorprüfung, wenigen fachlichen Kategorien, einer Route zur manuellen Prüfung, einer bestätigten CRM-Übergabe und einem Testdatensatz. Erst danach wird entschieden, ob Bewertung, Freigabe oder Follow-up als eigenes Modul getrennt werden müssen. Welche externen Aktionen später zulässig sind, wird gesondert festgelegt.

Bringen Sie dazu eine anonymisierte Beispielanfrage, Ihre bisherigen Kategorien und das verwendete CRM mit. JOOSN kann daraus mit Ihnen den kleinsten sinnvollen Testumfang und die noch offenen Entscheidungen ableiten. Den konkreten Leistungsrahmen finden Sie unter KI-Automatisierung für Unternehmen.