Angebote und Follow-ups automatisieren: was n8n aus CRM-Daten selbst erledigen kann

n8n kann aus CRM-Daten einen Angebotsentwurf erzeugen und eine Erinnerung ansetzen, wenn ein Angebot nach einer festgelegten Frist unbeantwortet bleibt – aber nur, wenn der Preis vorab feststeht. Ob eine Angebotsart das erfüllt, entscheidet nicht die Technik, sondern eine Festlegung, die Sie einmal treffen: Ist es eine Standardleistung mit bekanntem Preis, oder braucht die Kalkulation eine individuelle Einschätzung?

Dieser Beitrag zeigt zuerst, wie ein solcher Workflow technisch aufgebaut ist, dann das Entscheidungswerkzeug, mit dem Sie selbst festlegen, welche Angebotsart in welchen Pfad gehört.

Wie ein n8n-Workflow Angebot und Follow-up aus CRM-Daten baut

Der Aufbau besteht aus sechs Schritten: Auslöser erkennen, Daten holen, Preis berechnen, Entwurf freigeben lassen, Angebot verschicken, Follow-up terminieren.

1. Auslöser erkennen

Unterstützt Ihr CRM beim Wechsel einer Deal-Phase einen ausgehenden Webhook, fängt der Webhook-Node ihn ab. Für den Response-Modus bietet sich „Immediately“ an: Laut Dokumentation liefert der Node dann sofort den Antwortcode samt der Meldung, dass der Workflow gestartet wurde, statt dass das CRM auf das Ende der gesamten Verarbeitung warten muss. Die maximale Payload-Größe liegt laut Dokumentation bei 16 MB – relevant wird das erst, wenn das CRM zusätzlich große Anhänge mitschickt, nicht für das reine Deal-Objekt als JSON.

2. Daten aus dem CRM holen

Der HTTP-Request-Node ruft die vollständigen Deal-, Kontakt- und Positionsdaten über die REST-API des CRM ab – laut Dokumentation lassen sich damit „Daten aus jeder App oder jedem Dienst mit REST-API“ abfragen. Für unterstützte Dienste empfiehlt n8n den vordefinierten Credential-Typ, für alles andere stehen generische Verfahren wie Header Auth oder OAuth2 zur Verfügung. Umfasst ein Angebot viele Positionen und liefert die API sie nur seitenweise zurück, holt die Pagination-Option laut Dokumentation alle Seiten nacheinander ab.

3. Preis nach fester Logik berechnen

Für Positionen mit Preislisten-Bezug übernimmt ein Code-Node die Rechnung – Stückzahl mal hinterlegter Preislisten-Satz, nicht eine Schätzung durch ein Sprachmodell. Da jede Position einzeln durchgerechnet werden muss, 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, statt einmal für die gesamte Liste. Das ist zugleich die technische Grenze dieses Schritts: Der Code-Node kann nur rechnen, was als Formel hinterlegt ist. Fehlt im CRM der Preislisten-Satz zu einer Position, liefert die Rechnung keinen sinnvollen Wert – ein vorgeschalteter Prüfschritt sollte diesen Fall abfangen, bevor er in ein Angebot läuft.

4. Entwurf freigeben lassen

Für alle Angebote, die laut der Matrix unten einen Prüfschritt brauchen, pausiert der Workflow über den Slack-Node mit der Operation „Send and Wait for Response“, Response Type „Approval“. Laut Dokumentation liefert die Antwort unter anderem das Feld approved sowie Zeitpunkt und Identität der antwortenden Person zurück. Bei Zustimmung läuft der Workflow zum Versand weiter, bei Ablehnung zurück an die Person, die das Angebot kalkuliert hat. Unser Beitrag zu automatisierten Kundenservice-Antworten nutzt denselben Baustein für eine vergleichbare Einordnung nach Fehlerkosten statt nach technischer Machbarkeit.

5. Angebot zusammenstellen und verschicken

Bei Zustimmung übernimmt der Send-Email-Node den Versand. Laut Dokumentation verschickt der Node E-Mails über einen SMTP-Server und benötigt dafür ein SMTP-Account-Credential. Für das Feld „Email Format“ bietet er laut Dokumentation drei Optionen – Text, HTML oder beides –, für ein Angebot mit Positionsliste, Gesamtsumme und Anrede ist HTML die naheliegende Wahl. Betreff und Body füllt der Workflow dabei mit den Daten aus den vorherigen Nodes: Kundenname und Positionen aus Schritt 2, den berechneten Preis aus Schritt 3 – dieselbe Mechanik, mit der n8n laut Dokumentation Parameterwerte dynamisch aus Daten vorheriger Nodes setzt.

Für ein PDF-Dokument zum Anhängen hat n8n keinen eingebauten Node: Der Convert-to-File-Node, der dafür am ehesten in Frage käme, deckt laut Dokumentation CSV, HTML, ICS, JSON, ODS, RTF, Text File und XLS/XLSX ab – PDF gehört nicht dazu. Nur Community-Nodes von Drittanbietern decken das ab – eine zusätzliche externe Integration, kein Bestandteil der Standard-Installation. Der Send-Email-Node selbst kann laut Dokumentation zwar Anhänge verschicken, über „den Namen der Binär-Properties, die als Anhang hinzugefügt werden sollen“ – das setzt aber voraus, dass die Anhangsdatei bereits als Binärdaten vorliegt, etwa aus einer vorgeschalteten Vorlage. Für Standardleistungen reicht das Angebot ohne PDF: Positionen, Preis und Zahlungsziel stehen direkt und vollständig in der HTML-Mail. Wer zwingend ein PDF braucht, bindet dafür bewusst einen Community-Node oder einen externen PDF-Dienst ein – das ist eine eigene Abwägung zwischen Aufwand und Nutzen, kein Standardbaustein dieses Workflows.

6. Follow-up-Erinnerung terminieren

Nach dem Versand pausiert ein Wait-Node den Workflow – entweder für eine feste Zeitspanne über „After Time Interval“ oder bis zu einem festen Zeitpunkt über „At Specified Time“. Danach ruft der Workflow den Deal-Status erneut per HTTP-Request-Node ab: Hat sich der Status im CRM nicht geändert, löst er eine Erinnerung aus, etwa eine Slack-Nachricht an die zuständige Person. Eine Einschränkung aus der Dokumentation lohnt sich hier genau zu lesen: „Die n8n-Serverzeit gilt unabhängig von der Zeitzoneneinstellung“ – eine für Montag 9 Uhr geplante Erinnerung löst nach der Zeitzone aus, in der die n8n-Instanz läuft, nicht nach der des Empfängers. Prüfen Sie das einmal beim Einrichten, nicht erst, wenn die erste Erinnerung nachts verschickt wird.

Die Matrix: Welche Angebote sind automatisierbar

Die Einordnung richtet sich nicht danach, ob sich ein Angebotsdokument technisch erzeugen lässt – das lässt sich für fast jede Angebotsart irgendwie bauen –, sondern danach, ob der Preis bereits feststeht oder eine Person vor dem Versand noch etwas klären muss. Das ist eine Festlegung, die Sie für Ihr Unternehmen einmal treffen und dann in der Verdrahtung der Workflow-Pfade umsetzen, nicht eine Eigenschaft, die der Workflow selbst erkennt.

Angebotsart	Preisgrundlage	Pfad	Begründung
Verlängerung eines laufenden Vertrags ohne Konditionsänderung	unverändert aus dem Vorvertrag	automatisierbar	Preis und Leistung stehen bereits fest; der Workflow übernimmt nur, was im CRM ohnehin hinterlegt ist.
Nachbestellung eines bereits kalkulierten Standardpakets (z. B. zusätzliche Lizenzplätze zum Stückpreis der Preisliste)	Preisliste × Stückzahl	automatisierbar	Die Berechnung ist eine feste Formel, keine Einschätzung.
Standardwartungsvertrag zum Listenpreis ohne individuelle Leistungsanpassung	Preisliste	automatisierbar	Leistungsumfang ist vordefiniert, keine Verhandlung vorgesehen.
Vertragsverlängerung mit geänderter Menge oder geändertem Preis	Preisliste, aber mit Abweichung	Prüfschritt nötig	Prüffrage: Deckt eine hinterlegte Regel die Abweichung (z. B. eine Mengenstaffel), oder entscheidet das eine Person im Einzelfall? Nur im ersten Fall lässt sich das in die feste Formel aufnehmen.
Angebot mit Rabatt außerhalb der Preisliste	Preisliste plus individuelle Abweichung	Prüfschritt nötig	Dieselbe Prüffrage wie oben: Erst wenn die Abweichung selbst als Regel hinterlegt ist, kann der automatisierte Pfad sie übernehmen.
Projektangebot mit kundenspezifischem Aufwand (z. B. individuelle Integration)	Schätzung durch eine Fachperson	Prüfschritt nötig	Der Aufwand steht nicht im CRM, sondern im Wissen der Person, die ihn einschätzt; dem Code-Node fehlt dafür die Datengrundlage.
Erstangebot für eine Leistung ohne Referenzpreis im CRM	kein hinterlegter Preis	Prüfschritt nötig	Ohne historischen Preis fehlt der festen Formel die Grundlage, mit der sie rechnen könnte.

Zwei Zeilen zeigen, warum die Einordnung an der Preisgrundlage hängt und nicht am Vertragstyp: Eine unveränderte Vertragsverlängerung und eine Vertragsverlängerung mit geänderter Menge sind auf den ersten Blick dieselbe Angebotsart, landen in der Matrix aber in entgegengesetzten Pfaden. Eine Einordnung, die nur grob nach Dokumenttyp statt nach der tatsächlichen Preisgrundlage unterscheidet, vermischt genau diese beiden Fälle.

Wo die Automatisierung an ihre Grenze stößt

Drei Einschränkungen gelten unabhängig vom gewählten Pfad. Erstens die Datenaktualität: Die feste Formel im Code-Node rechnet mit dem Preislisten-Satz, der im CRM hinterlegt ist – ändert sich die Preisliste, ohne dass der hinterlegte Wert aktualisiert wird, rechnet der Workflow mit einem veralteten Preis, ohne dass das auffällt. Der CRM-Datensatz muss also selbst gepflegt sein; der Workflow prüft ihn nicht gegen eine zweite Quelle.

Zweitens die Follow-up-Logik selbst: Sie prüft nur, ob sich der Deal-Status im CRM geändert hat, nicht, ob die Kundin oder der Kunde das Angebot tatsächlich gelesen hat. Wer das genauer wissen will, braucht eine zusätzliche Integration mit Öffnungs- oder Klick-Tracking, die dieser Aufbau nicht abdeckt.

Drittens die Freigabe-Pause: Für den Fall, dass niemand auf die Slack-Anfrage antwortet, nennt die n8n-Dokumentation keine automatische Zeitbegrenzung. Prüfen Sie deshalb vor dem produktiven Einsatz, wie Sie eine ausstehende Freigabe selbst im Blick behalten – etwa durch eine eigene Erinnerung an die freigebende Person oder einen regelmäßigen manuellen Blick auf offene Freigaben; ohne eine solche Absicherung bleibt ein vergessenes Angebot unbemerkt in der Warteposition stehen. Unser Beitrag zum Zusammenführen mehrerer Systeme im Reporting beschreibt ein verwandtes Risiko: eine erfolgreiche, aber leere Antwort, die ein Workflow stillschweigend als vollständig behandelt.

Angenommene Angebote laufen technisch in dieselbe Richtung weiter wie andere abgeschlossene Vorgänge: Ist die Kalkulation geprüft und freigegeben, lässt sich die Übergabe an die Buchhaltung nach demselben Muster automatisieren, das unser Beitrag zur DATEV- und ERP-Anbindung mit n8n für Rechnungen beschreibt.

Für den Mittelstand heißt das

Legen Sie die Matrix fest, bevor der Workflow gebaut wird, nicht danach. Die umgekehrte Reihenfolge – erst den Workflow bauen und schauen, was er kann, dann im Nachhinein entscheiden, welche Angebotsart wie viel Prüfung braucht – führt dazu, dass die technisch am leichtesten zu automatisierende Angebotsart auch automatisiert wird, unabhängig davon, ob ihr Preis tatsächlich feststeht.

Starten Sie außerdem schmal: Nehmen Sie zunächst nur die Angebotsarten in den automatischen Pfad, bei denen der Preis zweifelsfrei aus dem CRM folgt, und lassen Sie alles andere über den Prüfschritt laufen – auch Grenzfälle, bei denen Sie unsicher sind. Grundlage für den Baukasten dieses Beitrags ist unser Pillar-Guide zur n8n-Einführung im Mittelstand; unser Beitrag zu den Kostenfaktoren einer KI-Automatisierung ordnet ein, wie sich der Aufwand für einen solchen Workflow zum laufenden Nutzen verhält.

FAQ

Welche Angebote kann n8n automatisch aus CRM-Daten erstellen?

Angebote, deren Preis bereits feststeht und sich aus im CRM hinterlegten Daten nach einer festen Formel berechnen lässt – etwa eine Vertragsverlängerung ohne Konditionsänderung oder eine Nachbestellung zum Preislisten-Stückpreis. Sobald der Preis eine individuelle Einschätzung braucht, etwa bei einem Rabatt außerhalb der Preisliste oder einem kundenspezifischen Projektaufwand, gehört ein Prüfschritt vor den Versand. Das Angebot selbst entsteht dabei als HTML-formatierte E-Mail mit Positionen und berechnetem Preis, nicht als PDF-Anhang – dafür hat n8n keinen eingebauten Node, sondern nur Community-Nodes von Drittanbietern.

Wie entscheidet die Matrix, ob ein Angebot automatisiert werden darf?

Nicht danach, ob sich ein Dokument technisch erzeugen lässt, sondern danach, ob der Preis vorab feststeht oder eine Person vor dem Versand noch etwas klären muss. Jede Angebotsart wird dafür einmal fest einer der beiden Gruppen zugeordnet, nicht im Einzelfall durch den Workflow entschieden.

Kann n8n den Angebotspreis selbst berechnen?

Für Standardleistungen ja, über einen Code-Node mit fester Formel wie Stückzahl mal Preislisten-Satz – das ist eine Rechenregel, keine Schätzung. Für eine individuelle Kalkulation fehlt dem Code-Node die Datengrundlage: Der Aufwand steht nicht im CRM, sondern im Wissen der Person, die ihn einschätzt.

Wie funktioniert die automatische Follow-up-Erinnerung zu einem offenen Angebot?

Ein Wait-Node pausiert den Workflow für eine festgelegte Zeitspanne oder bis zu einem bestimmten Zeitpunkt. Danach prüft der Workflow per API-Abruf, ob sich der Status des Angebots im CRM geändert hat, und löst bei weiterhin offenem Status eine Erinnerung aus. Die Wartezeit läuft dabei nach der Serverzeit der n8n-Instanz, nicht nach der Zeitzone des Empfängers.

Was passiert, wenn die CRM-Daten für ein Angebot unvollständig sind?

Der Workflow sollte das vor der automatischen Berechnung prüfen, etwa fehlt ein Preis oder eine Mengenangabe. Ohne diese Prüfung würde der Code-Node entweder mit einem leeren Wert rechnen oder abbrechen – beides ohne dass jemand es bemerkt, bevor das Angebot beim Kunden ankommt.