Vom Web-Formular zum PDF-Angebot: der n8n-Workflow Schritt für Schritt

Der Aufbau im Überblick

Der gesamte Ablauf lässt sich in sechs Blöcke gliedern. Jeder Block hat eine klar abgegrenzte Aufgabe, und genau diese Trennung macht den Workflow später wartbar. Wer alles in einen großen Verarbeitungsschritt packt, hat beim ersten Fehler keine Chance, die Ursache zu finden.

Die Preistabelle: das eigentliche Fundament

Die häufigste Frage bei solchen Projekten lautet, welches Sprachmodell man nehmen sollte. Die praktisch wichtigere Frage lautet, wie die Preistabelle aufgebaut ist. Denn davon hängt ab, ob der Workflow überhaupt etwas Belastbares berechnen kann.

Eine brauchbare Tabelle hat pro Zeile eine Leistungsposition und mindestens diese Spalten: eine eindeutige Positions-ID, mit der der Workflow sie referenziert; die Bezeichnung, wie sie im Angebot erscheinen soll; die Einheit (Stück, Quadratmeter, Stunde, Pauschale); den Einheitspreis; die Leistungsart, unter der die Position ausgewählt wird; und eine Spalte für Bedingungen, die steuert, wann die Position automatisch gesetzt wird — etwa „nur bei Baujahr vor 1990" oder „nur wenn Bestandsanlage vorhanden".

Dazu kommen zwei separate kleine Tabellen. Eine für Zuschläge: Anfahrt nach PLZ-Zone, Altbauzuschlag, Zuschlag für schwierige Zugänglichkeit, Expresszuschlag bei kurzfristigen Terminen. Und eine für Pakete, die häufige Positionskombinationen bündeln, damit der Workflow nicht bei jeder Anfrage dreißig Einzelpositionen zusammensuchen muss.

Wo diese Tabellen liegen, ist zweitrangig. Für kleinere Betriebe ist eine Google-Tabelle völlig ausreichend und hat den Vorteil, dass die Pflege ohne technische Kenntnisse funktioniert. Wer strengere Anforderungen an den Datenschutz hat, legt eine CSV oder eine kleine PostgreSQL-Tabelle auf denselben Server, auf dem n8n läuft. Wichtig ist nur die Regel: eine Quelle, aus der alles liest.

Die Rollenteilung zwischen Code und Sprachmodell

Es ist verlockend, dem Sprachmodell die gesamte Anfrage zu geben und es das Angebot schreiben zu lassen. Das funktioniert im Test verblüffend gut und im Betrieb nicht. Der Grund ist, dass Sprachmodelle Zahlen als Text behandeln. Bei einer Position mit drei Nachkommastellen und einem Zuschlag von 12,5 Prozent auf eine Teilsumme entstehen Abweichungen, die einzeln klein sind und in der Summe die Vertrauenswürdigkeit des ganzen Entwurfs zerstören.

Die tragfähige Aufteilung sieht so aus: Der Code entscheidet und rechnet. Welche Positionen kommen in das Angebot? Welche Menge hat jede? Welcher Zuschlag greift? Wie hoch ist die Zwischensumme, die Umsatzsteuer, die Endsumme? Das alles ist Regellogik und gehört in einen Code-Knoten oder in eine Kette aus n8n-Knoten. Es ist prüfbar, reproduzierbar und liefert bei gleicher Eingabe immer dasselbe Ergebnis.

Das Modell formuliert. Es bekommt die fertige Positionsliste, die Angaben aus dem Fragebogen und einen System-Prompt, der Tonalität und Struktur des Betriebs beschreibt. Daraus entsteht ein Anschreiben, das auf die konkrete Anfrage eingeht statt aus Textbausteinen zu bestehen, sowie ausformulierte Leistungsbeschreibungen und Hinweise auf Rahmenbedingungen. Der Prompt enthält die ausdrückliche Anweisung, keine Zahlen zu verändern oder zu ergänzen.

Eine dritte, oft übersehene Rolle des Modells ist die Plausibilitätsprüfung. Am Ende bekommt es die Anfrage und den erzeugten Entwurf mit der Frage, ob beides zusammenpasst und ob etwas Wichtiges zu fehlen scheint. Die Antwort geht nicht in das Angebot, sondern in die Benachrichtigung an die prüfende Person — als Hinweis, worauf besonders zu schauen ist. Das ist ein billiger Zusatzschritt mit erstaunlich hohem Nutzen.

Welches Modell dafür sinnvoll ist, hängt vom Volumen ab; die Unterschiede zwischen den Tiers sind erheblich und im Artikel zur Modellauswahl für KMU aufgeschlüsselt.

Fehlerbehandlung: der Teil, den alle weglassen

Ein Workflow, der im Testbetrieb funktioniert, ist noch kein produktives System. Der Unterschied liegt fast vollständig in der Fehlerbehandlung — und die wird beim ersten Aufbau regelmäßig übersprungen, weil sie keinen sichtbaren Nutzen hat, solange nichts schiefgeht.

Der Error-Workflow

n8n erlaubt es, jedem Workflow einen Error-Workflow zuzuweisen, der bei jedem Abbruch ausgelöst wird. Dieser sollte drei Dinge tun: die eingegangenen Rohdaten sichern, damit die Anfrage nicht verloren ist; eine Benachrichtigung mit dem konkreten Fehler an die zuständige Person schicken; und dem Interessenten eine neutrale Eingangsbestätigung senden, damit er nicht im Ungewissen bleibt. Der schlimmste denkbare Fall ist eine Anfrage, die still verschwindet — kein Kunde, keine Fehlermeldung, kein Wissen darüber, dass es sie je gab.

Timeouts und Wiederholungen

API-Aufrufe an Sprachmodelle oder an Lexoffice können langsam sein oder scheitern. Jeder externe Aufruf braucht deshalb ein Zeitlimit und eine begrenzte Zahl automatischer Wiederholungen mit wachsendem Abstand. Ohne Begrenzung hängt der Workflow, ohne Wiederholung scheitert er an einer vorübergehenden Störung, die zwei Sekunden später vorbei gewesen wäre.

Doppelte Absendungen

Nutzer klicken zweimal auf Absenden. Ohne Schutz erzeugt das zwei Angebotsentwürfe für dieselbe Anfrage — im besten Fall peinlich, im schlechtesten gehen beide raus. Ein einfacher Abgleich auf E-Mail-Adresse plus Zeitfenster von einigen Minuten löst das Problem zuverlässig.

Kalibrieren statt sofort produktiv schalten

Ein neu gebauter Workflow gehört nicht direkt in den Betrieb, sondern in einen Parallelbetrieb. Vier bis sechs Wochen lang läuft er mit, erzeugt seine Entwürfe — und die Angebote werden weiterhin manuell geschrieben. Danach wird verglichen: Wo lag der Entwurf richtig, wo daneben, und warum?

Der Fragebogen selbst — welche Fragen er stellen sollte und in welcher Reihenfolge — ist im Artikel zum Angebotskonfigurator für Handwerksbetriebe beschrieben. Beides gehört zusammen: Ein perfekter Workflow hinter einem zu groben Fragebogen liefert grobe Entwürfe.

Häufige Fragen