Das Szenario
Nimm einen typischen Klempnerbetrieb aus NRW: drei Monteure, der Chef plus Ehefrau im Büro. 30-40 Anfragen pro Woche über Webseite und WhatsApp. Die Ehefrau schreibt irgendwann fast nur noch Angebote, sonst nichts. Genau dieser Betriebstyp ist der ideale Kandidat für Angebots-Automation.
Ein Setup wie das folgende kann grob 85 Prozent der Angebots-Arbeit automatisieren und dem Büro rund 18 Stunden pro Woche freimachen — Zeit, die dann in Rechnungen und Mahnwesen fließt, also in Sachen die sonst liegen bleiben.
Dieser Artikel ist der komplette Workflow — inklusive der Stellen, an denen so ein Setup typischerweise Scheiße baut, wenn man nicht aufpasst.
Hinweis zu den Zahlen: Die Werte in diesem Artikel (Zeitersparnis, Kosten, Conversion) sind realistische Größenordnungen für einen Betrieb dieser Größe, keine gemessenen Werte aus einem konkreten Kundenauftrag. Deine Zahlen hängen von Auftragsstruktur, Preis-Katalog und Anfragevolumen ab.
Das Ausgangsszenario
Die Anfragen kommen typischerweise aus drei Kanälen: E-Mail über die Firmen-Webseite, WhatsApp-Business (viele Betriebe haben eine offizielle Nummer für Kundenanfragen), und vereinzelt telefonische Anfragen die intern per Notiz ins E-Mail-System kommen.
Jede Anfrage braucht ohne Automation grob 25-40 Minuten Bearbeitung: Anfrage lesen, Leistungsumfang einschätzen, Material-Liste, Stundenaufwand, Angebots-PDF erstellen, verschicken, CRM-Eintrag machen. Bei 35 Anfragen pro Woche sind das 15-20 Stunden reine Angebots-Arbeit.
Der Workflow im Überblick
Erst die grobe Struktur, dann die Details.
E-Mail + WhatsApp-Webhook
↓
Input-Normalisierung
↓
Extract-Parameter (Claude Haiku)
↓
Check gegen Preis-Datenbank
↓
Angebots-Text generieren (Claude Haiku)
↓
PDF erstellen (Template-basiert)
↓
(bei Hoch-Risiko) → Review-Queue
(bei Normal) → Direkt rausschicken
↓
CRM-Eintrag + DSGVO-Löschfrist setzen
Jeder Schritt ist ein eigenes n8n-Node. So ein Workflow kommt schnell auf gut 20 Nodes — klingt viel, ist aber pro Node klein.
Schritt 1 — Input-Normalisierung
Das Problem: Eine E-Mail sieht anders aus als ein WhatsApp-Text anders als eine Telefon-Notiz. Man braucht eine einheitliche Datenstruktur.
Der erste Node extrahiert die Rohnachricht und normalisiert:
{
"source": "email|whatsapp|phone_note",
"received_at": "2026-04-15T14:22:10Z",
"customer": {
"name": "...",
"email": "...",
"phone": "...",
"address": "..."
},
"raw_request": "...",
"attachments": []
}
Bei E-Mails greift n8n die Gmail-API an, bei WhatsApp kommt der Webhook von n8ns eingebautem Twilio-Trigger. Telefon-Notizen werden manuell in ein Formular eingetragen und laufen als Webhook-Call rein.
Praxis-Beobachtung: So ein Eingabe-Formular wirkt zunächst abschreckend ("das kann ich nicht"), wird aber erfahrungsgemäß schnell akzeptiert — es ist einfacher als jedes Angebot von Hand zu schreiben.
Schritt 2 — Parameter-Extraktion mit Claude Haiku
Der interessante Teil. Hier übernimmt Claude Haiku die eigentliche Intelligenz.
Das Prompt:
"Aus folgender Kundenanfrage extrahiere bitte im JSON-Format:
- leistungsart (eine aus: [notdienst, rohrreinigung, sanitaer-reparatur, sanitaer-neuanlage, heizung-wartung, heizung-reparatur, sonstiges])
- dringlichkeit (eine aus: [sofort, heute, diese_woche, unbestimmt])
- umfang_stunden_geschaetzt (Ganzzahl, 1-40)
- material_grob (Freitext, maximal 200 Zeichen)
- besonderheiten (Freitext, zB. 'Altbau, 3. Stock, kein Aufzug') Wenn eine Info fehlt, gib null zurück."
Claude Haiku ist für diese Klasse Aufgabe perfekt. Schnell, billig, zuverlässig. Die Kosten liegen im Bereich von Bruchteilen eines Cents pro Extraktion — bei 35 Anfragen pro Woche also nur wenige Cent für diesen Schritt.
Das Ergebnis ist strukturierte Daten, die im nächsten Schritt direkt gegen die Preis-Datenbank matchen.
Schritt 3 — Preis-Datenbank-Match
Die meisten Betriebe haben seit Jahren eine Excel-Tabelle mit Durchschnittspreisen für verschiedene Auftragstypen. Die überführt man in eine SQLite-DB. Spalten: Auftragsart, Pauschale, Stundensatz, typische Material-Posten mit Durchschnittspreis.
Der n8n-Node nimmt die extrahierten Parameter, liest die passenden Preis-Zeilen aus der DB, rechnet aus:
# Pseudocode der Berechnung im n8n Function-Node
gesamt_netto = pauschale
gesamt_netto += umfang_stunden * stundensatz
for posten in material_grob_matched:
gesamt_netto += posten.durchschnittspreis * menge_geschaetzt
mwst = gesamt_netto * 0.19
gesamt_brutto = gesamt_netto + mwst
Wichtiger Punkt: Bei unklaren Fällen (Material komplett unbestimmt oder Umfang > 20 Stunden) markiert der Node den Auftrag als high_risk und der Workflow schlägt einen anderen Pfad ein.
Schritt 4 — Angebot-Text generieren
Zweites LLM-Prompt. Claude Haiku bekommt die Parameter plus die Preisberechnung plus das CI-Template des Betriebs und schreibt einen Angebots-Text.
Der Prompt enthält zwei Beispiel-Angebote im üblichen Stil des Betriebs — Few-Shot-Learning funktioniert perfekt für solche tonalen Aufgaben. Claude nimmt den gewohnten Ton auf.
Output-Format ist ein Markdown-Template das der PDF-Generator direkt fressen kann.
Schritt 5 — PDF-Generierung
Hier keine KI, nur Templating. WeasyPrint nimmt das Markdown plus ein CSS-Template mit dem Firmen-Logo und rendert ein PDF. Das ist Standard-Handwerk und läuft ohne Probleme.
Schritt 6 — Review oder direkter Versand
Der Switch-Node entscheidet:
- high_risk oder gesamt_brutto > 3000 € → Review-Queue in einer internen Mail-Inbox. Das Büro sieht das Angebot, kann einen Button klicken "so versenden" oder "anpassen."
- normal → PDF geht direkt per E-Mail an den Kunden mit einer höflichen Begleitung.
Der Review-Schritt ist kein Nice-to-have, sondern Pflicht — warum, zeigt Falle 1 unten.
Schritt 7 — CRM und DSGVO
Zum Schluss: Ein Eintrag in einem selbst-gebauten Mini-CRM (Postgres plus eine NocoDB-UI). Dort steht die Anfrage, das Angebot, der Kunden-Kontakt.
Und — von Tag 1 an — ein Cron-Job der täglich Anfragen älter als 6 Monate automatisch anonymisiert, wenn sie nicht zu einem Auftrag geführt haben. DSGVO-Relevanz. Die Verarbeitungsgrundlage ist "Anbahnung eines Vertrags" — und die ist nach Monaten ohne Reaktion erloschen.
Wo so ein Setup typischerweise schiefgeht — drei Fallen
Falle 1 — kein Review bei großen Angeboten
Ein Kunde fragt nach einer "sanitären Renovierung unseres Altbaus." Claude klassifiziert das als sanitaer-neuanlage, nimmt die Standard-Pauschale, schickt raus — Angebot 800 Euro, obwohl die echte Arbeit vier- bis fünftausend kostet. Der Kunde sagt zu, und erst beim Vor-Ort-Termin fliegt auf, dass das unmöglich so machbar ist.
Genau das ist der Grund für den Review-Schritt bei allen Angeboten über drei Tausend Euro. Automatische Heuristiken reichen für Standardfälle, aber nicht für die Ausreißer — und die Ausreißer sind teuer.
Falle 2 — DSGVO und der falsche LLM-Anbieter
Wer initial einen LLM ohne ordentlichen AV-Vertrag (Auftragsverarbeitung) mit personenbezogenen Daten (Kunden-Adressen!) füttert, hat ein Problem — spätestens wenn der Steuerberater draufschaut. Die saubere Lösung: ein Anbieter mit AV-Vertrag und EU-Verarbeitung (z.B. Claude über AWS Bedrock EU/Frankfurt).
Die Lektion: DSGVO-Prüfung vor der ersten API-Integration, nicht erst nachträglich. Ein AV-Vertrag-Template gehört an den Anfang, nicht ans Ende.
Falle 3 — Pseudo-Duplikate über mehrere Kanäle
WhatsApp- und E-Mail-Anfragen kommen manchmal vom selben Kunden — er schreibt über beide Kanäle, weil er unsicher ist. Ohne Schutz behandelt der Workflow beide als separate Anfragen und generiert zwei Angebote, womöglich zu unterschiedlichen Preisen.
Fix: ein Dedup-Node der die letzten 48 Stunden checkt, ob dieselbe E-Mail oder Telefon-Nummer schon ein Angebot hat. Bei Treffer wird die Anfrage der alten angehängt, statt ein neues Angebot zu generieren.
Realistische Größenordnung
Die folgende Tabelle ist eine illustrative Schätzung für einen Betrieb dieser Größe bei stabilem Betrieb — kein gemessener Einzelfall:
| Metrik | Ohne Automation | Mit Automation | |---|---|---| | Bearbeitungszeit pro Angebot (Durchschnitt) | ~32 min | ~4 min (Review-only) | | Reaktionszeit (Anfrage → Angebot raus) | 1-2 Tage | unter 1 Stunde | | Angebote die Review brauchen | 100 % | ~15 % | | Anfragen pro Woche | 35 | 35 | | Reine Angebots-Arbeit pro Woche | ~18 h | ~2 h | | API-Kosten pro Woche | 0 € | ~5 € | | Conversion-Rate (Angebot → Auftrag) | ~28 % | ~31 % |
Der Conversion-Effekt ist plausibel, weil eine schnellere Reaktionszeit dem Kunden "die sind dran" signalisiert — belastbar messen lässt er sich aber nur im echten Betrieb.
Was so ein Setup grob kostet
- Aufbau: grob 30-40 Arbeitsstunden über einige Wochen (inklusive Iterationen und Bug-Fixes)
- Running Costs: Hetzner-VM (~8 €/Monat), Claude Haiku API (~15-20 €/Monat), WhatsApp-Business (~20 €/Monat inkl. Twilio)
- Einmalige Setup-Kosten: übliches B2B-Projekt-Segment (vierstellig, je nach Umfang)
Break-even für einen Betrieb dieser Größe liegt realistisch bei einigen Monaten. Ab dann ist die gewonnene Zeit purer Gewinn.
Worauf man von Anfang an achten sollte
- Review-Schritt ab Tag 1. Nicht nachträglich einbauen.
- DSGVO-Check vor der ersten API-Integration. AV-Vertrag-Template im Voraus.
- Weniger Zwischenschritte. So ein Workflow kommt schnell auf 20+ Nodes. Mit konsequentem Design reichen oft 14-15.
- Monitoring vom ersten Tag an. Wer früh sieht, wie oft ein LLM mal "kein JSON" zurückgibt, baut das Error-Handling von Anfang an robust.
Wer profitiert von sowas?
Das Setup passt für jeden Dienstleister-Betrieb mit wiederkehrenden Angebots-Strukturen. Handwerk, Reinigung, Haustechnik, kleine Bau-Unternehmen. Voraussetzung: ein halbwegs konsistenter Preis-Katalog seit Jahren. Wenn jedes Angebot individuell durchverhandelt wird, funktioniert das nicht.
Weiterlesen
Für die technische Grundlage zu LLM-Workflows siehe Lokale LLMs Vergleich — wenn du komplett ohne Cloud arbeiten willst. Für DSGVO-Aspekte siehe ChatGPT-Alternativen.
Eigenes Automation-Projekt im Kopf oder schon im Bau? Zone "Business & Automation" im Discord. Wir besprechen sowas konkret, mit echten Zahlen, keine Verkaufs-Sprüche.
