Mein Handwerker-Kunde spart 18 Stunden pro Woche — das ganze n8n-Setup offengelegt

Der Anruf Anfang Januar

Anfang Januar 2026 rief mich jemand an den ich von einer Empfehlung kannte. Klempnerbetrieb aus NRW, drei Monteure, der Chef selbst plus Frau im Büro. "Dennis, wir bekommen 30-40 Anfragen pro Woche über unsere Webseite und WhatsApp. Meine Frau schreibt jetzt nur noch Angebote, sonst nix. Mein Sohn studiert Informatik, der hat gesagt wir sollen dich fragen."

Das war der Einstieg. Vier Monate später läuft das Setup stabil, macht 85 Prozent der Angebots-Arbeit automatisch, und spart der Ehefrau grob 18 Stunden pro Woche. Die gewonnene Zeit nutzt sie für Rechnungen und Mahnwesen — Sachen die vorher liegen geblieben sind.

Dieser Artikel ist der komplette Workflow. Kein geschöntes Case-Study, sondern echte Zahlen inklusive der Punkte wo ich Scheiße gebaut habe.

Das Ausgangsszenario

Die Anfragen kamen aus drei Kanälen: E-Mail über die Firmen-Webseite, WhatsApp-Business (der Klempner hat eine offizielle Nummer für Kundenanfragen), und vereinzelt telefonische Anfragen die intern per Notiz ins E-Mail-System kamen.

Jede Anfrage brauchte vorher grob 25-40 Minuten Bearbeitung durch die Ehefrau: Anfrage lesen, Leistungsumfang einschätzen, Material-Liste, Stundenaufwand, Angebots-PDF erstellen, verschicken, CRM-Eintrag machen. Bei 35 Anfragen pro Woche waren das 15-20 Stunden reine Angebots-Arbeit.

Der Workflow im Überblick

Ich beschreib 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 hat sein eigenes n8n-Node. Der komplette Workflow hat 23 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. Ich brauche 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 n8n's eingebautem Twilio-Trigger. Telefon-Notizen sind manuell in ein Formular eingetragen und laufen als Webhook-Call rein.

Fun fact: Die Ehefrau hat am Anfang gesagt "das kann ich nicht, ich kenn mich mit sowas nicht aus." Nach einer Woche hat sie das Formular öfter benutzt als ich vermutet hätte. Die UX war einfacher als Angebots-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 sind etwa 0.02 Cent pro Extraktion. Bei 35 Anfragen pro Woche rund 2,8 Cent für diesen Schritt.

Das Ergebnis ist strukturierte Daten die im nächsten Schritt direkt gegen unsere Preis-Datenbank matchen.

Schritt 3 — Preis-Datenbank-Match

Der Klempner hat seit Jahren eine Excel-Tabelle mit Durchschnittspreisen für verschiedene Auftragstypen. Die habe ich in eine SQLite-DB überführt. 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 vom Klempner und schreibt einen Angebots-Text.

Der Prompt enthält zwei Beispiel-Angebote von der Ehefrau die sie in ihrem üblichen Stil geschrieben hat — 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 seit Tag 1 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. Die Ehefrau 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.

Anfangs hatte ich keinen Review-Schritt eingebaut. Das war Fehler Nummer 1. Siehe 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 — das hab ich vom ersten Tag an eingebaut — ein Cron-Job läuft täglich der 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 es schiefging — die drei Momente

Fall 1 — das fehlende Review in Woche 2

Ein Kunde fragte nach einer "sanitären Renovierung unseres Altbaus." Claude hat das als sanitaer-neuanlage klassifiziert, die Standard-Pauschale genommen, und rausgeschickt. Das Angebot lag bei 800 Euro. Die tatsächliche Arbeit hätte vier- bis fünftausend gekostet.

Der Kunde war happy, hat zugesagt, und erst beim Vor-Ort-Termin stellte sich raus dass das unmöglich so machbar ist. Peinlich. Der Kunde hat verstanden und wir haben nachverhandelt — aber das war mein Weckruf dass die Heuristiken nicht reichen. Seitdem gibt's den Review-Schritt für alle Angebote über drei Tausend Euro.

Fall 2 — das DSGVO-Problem mit Google

Ich hatte initial Google Gemini als LLM konfiguriert. Nach vier Wochen fiel dem Klempner's Steuerberater auf, dass Gemini-API-Calls mit personenbezogenen Daten (Kunden-Adressen!) ohne ordentlichen AV-Vertrag liefen.

Wir mussten schnell zu Claude über AWS Bedrock EU (Frankfurt) wechseln. Das war eine Woche Mehrarbeit und hat mir eine Lektion beigebracht: DSGVO-Prüfung vor der ersten API-Integration, nicht erst wenn der Steuerberater pingt.

Fall 3 — die Pseudo-Duplikate

WhatsApp und E-Mail-Anfragen kamen manchmal vom selben Kunden — der schrieb über beide Kanäle weil er unsicher war. Mein Workflow hat beide als separate Anfragen behandelt und zwei Angebote generiert. Die wurden an unterschiedliche Preise raus.

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.

Die Zahlen

Nach drei Monaten stabiler Laufzeit:

| Metrik | Vorher | Jetzt | |---|---|---| | Bearbeitungszeit pro Angebot (Durchschnitt) | 32 min | 4 min (Review-only) | | Reaktionszeit (Anfrage → Angebot raus) | 1-2 Tage | 45 Minuten | | 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 € | ~4,50 € | | Conversion-Rate (Angebot → Auftrag) | 28 % | 31 % |

Die Conversion ist sogar leicht gestiegen, weil die schnellere Reaktionszeit dem Kunden "die sind dran" signalisiert.

Was das gekostet hat — ehrlich

• Setup von mir: etwa 35 Arbeitsstunden über vier Monate (inklusive Iterationen und Bug-Fixes)
• Running Costs: Hetzner-VM (8 €/Monat), Claude Haiku API (~18 €/Monat), WhatsApp-Business (~20 €/Monat inkl Twilio)
• Einmalige Setup-Kosten: Projektpauschale (vierstellig, übliches B2B-Segment)

Break-even für den Klempner: etwa Monat 3. Ab dann gewonnene Zeit ist purer Profit.

Was ich heute anders machen würde

Wenn ich jetzt von Null anfangen würde:

• Review-Schritt ab Tag 1. Nicht nachträglich einbauen.
• DSGVO-Check vor der ersten API-Integration. AV-Vertrag-Template im Voraus, nicht nachträglich.
• Weniger Zwischenschritte. Der Workflow hat 23 Nodes. Man kommt mit 14-15 aus wenn man beim Design konsequent ist.
• Monitoring vom ersten Tag an. Ich hab erst nach zwei Monaten Grafana-Dashboards dazugebaut. Hätte ich früher gewusst wie oft Claude mal "kein JSON" zurückgibt, hätte ich sofort Error-Handling robuster gebaut.

Wer profitiert von sowas?

Das Setup passt für jeden Dienstleister-Betrieb mit wiederkehrenden Angebots-Strukturen. Handwerk, Reinigung, Haustechnik, kleine Bau-Unternehmen. Voraussetzung: Du hast seit Jahren einen halbwegs konsistenten Preis-Katalog. Wenn jedes Angebot individuell durchverhandelt wird, funktioniert das nicht.

Mein Kunde zahlt inzwischen monatliche Wartung statt neue Projekt-Aufträge. Das Setup läuft, braucht ab und zu Tuning, und ist stabil.

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.