Inbound-Mails klassifizieren (Sales / Support / Spam / eskalieren), Antwort-Drafts generieren, ins richtige CRM-Postfach routen — mit Approval-Queue für die unsicheren Fälle.
Kurz gesagt: Inbound-Mails klassifizieren (Sales / Support / Spam / eskalieren), Antwort-Draft generieren, ins CRM routen. Stack: Claude für Klassifikation und structured output, Webhook-Integration ins CRM (HubSpot, Pipedrive, Salesforce, Bexio, Microsoft Dynamics), Approval-Queue für unsichere Fälle. Anti-Hype: Wenn der Inbound unter rund 20 Mails/Tag liegt oder die Absender-Verteilung sehr stabil ist, ist klassisches Rule-Routing (Regex + Whitelist) oft günstiger und transparenter — und wir sagen das auch unseren Kunden so. Der Agent lohnt sich dort, wo Volumen UND Variabilität gleichzeitig wachsen.
In wachsenden Schweizer KMU landen Inbound-Mails häufig in einem einzigen geteilten Postfach — und eine Person (Office-Manager, Junior-Sales, gelegentlich der Founder selbst) entscheidet manuell: Sales-Lead, Support-Ticket, Spam, Vendor-Outreach, Eskalation. Bei zehn Mails am Tag funktioniert das. Bei fünfzig oder hundert wird die Triage zum Bottleneck. Latenz frisst Conversion: ein Sales-Lead, der vier Stunden auf eine erste Antwort wartet, ist häufig schon weg — er hat parallel drei andere Anbieter angeschrieben und nimmt den, der zuerst antwortet. Gleichzeitig liegen echte Support-Probleme stundenlang ungesehen im Postfach, während die triagierende Person manuell Cold-Outreach von Recruitern aussortiert.
Aber: nicht jeder Inbound braucht KI. Bei einem klar strukturierten Postfach mit erkennbaren Absender-Domänen und stabilen Subject-Patterns funktioniert klassisches Rule-Routing (Regex + Whitelist nach Domain + Subject-Filter) oft günstiger und transparenter als ein LLM-basierter Agent. Eine ehrliche Diagnose zuerst, dann die richtige Werkzeugwahl — manchmal ist die Antwort „dreissig Regeln pflegen statt Agent bauen". Der Agent verdient sich erst dann, wenn das Volumen und die Variabilität des Inbounds gleichzeitig hoch sind und Rule-Routing entweder zu viele Fehlklassifikationen oder zu viel Pflegeaufwand verursacht.
Die Pipeline ist linear. Inbound-Mail landet via IMAP-Connector oder Mail-Provider-Webhook (Microsoft Graph für M365, Gmail API für Google Workspace) beim Agent. Schritt eins: Klassifikation gegen einen kundenspezifischen Kategorie-Katalog — typischerweise Sales / Support / Vendor / Recruiter / Spam / Eskalation. Die Klassifikation passiert mit Claude und structured output, kein Freitext: ein JSON pro Mail mit Kategorie, Sub-Kategorie, Confidence-Score und einer kurzen Begründung. Schritt zwei: bei klassifizierten Sales- oder Support-Mails generiert der Agent einen Antwort-Draft (Calendar-Link für Demo-Requests, Bestätigung mit Ticket-ID für Support-Fälle, höfliche Absage für Vendor-Outreach). Schritt drei: das Routing — der Agent legt im CRM einen Lead, Contact oder Ticket an und schreibt das kontextuelle Briefing dazu (Original-Mail, Klassifikation, Confidence, vorgeschlagene Antwort).
Entscheidend ist das Confidence-Gate vor dem Versand: über einem konfigurierbaren Schwellwert geht der Draft (für bestimmte Kategorien, z.B. Demo-Request mit Calendar-Link) direkt raus oder in eine Approval-Queue mit Zwei-Klick-Freigabe. Unter dem Schwellwert eskaliert der Agent explizit — die triagierende Person sieht die Mail mit dem Klassifikations-Vorschlag und entscheidet selbst. Spam und Cold-Outreach werden immer autonom verarbeitet, Eskalations-Verdachtsfälle nie. Das CRM-Routing nutzt REST/Webhook und unterstützt HubSpot, Pipedrive, Salesforce, Bexio, Microsoft Dynamics, Close.io sowie Custom-CRMs über Standard-REST.
Wichtig: Das Confidence-Gate ist die ethische Linie. Wer es zu locker setzt, riskiert peinliche Auto-Sends an echte Kunden. Wir empfehlen den Start mit Approval-Queue für alle Kategorien ausser Spam — Auto-Send wird erst nach gemessener Akzeptanzrate für ausgewählte Kategorien aktiviert.
Ein B2B-SaaS-Anbieter — Komposit, kein realer Klient — mit rund 50 Inbound-Mails pro Tag und unklarer Eigentumsregelung im geteilten Postfach. Mischung aus Sales-Anfragen (Demo-Request, Pricing-Frage, Trial-Anmeldung), Support-Tickets (Bug-Report aus dem Produkt, Feature-Frage, Integrationshilfe), Vendor-Outbound (NDA-Anfragen, Sponsoring-Pitches), Recruiter-Cold-Outreach. Vor dem Agent bearbeitete die Office-Managerin das Postfach zweimal pro Tag — typischerweise 60 bis 90 Minuten am Stück, mit dem Resultat, dass Sales-Leads im Schnitt drei bis vier Stunden auf eine erste Antwort warteten. Nach dem Rollout klassifiziert der Agent jede eingehende Mail in unter 30 Sekunden; Demo-Requests bekommen automatisch einen Calendar-Link, Bug-Reports landen direkt im HubSpot-Support-Pipeline mit dem ausgefüllten Briefing, Recruiter-Mails werden höflich abgelehnt und archiviert. Die Office-Managerin reviewt einmal pro Tag die Approval-Queue (typisch zehn Minuten) und entscheidet bei den vom Agent als „unsicher" eskalierten Fällen.
Typischer Effekt: die erste Antwort an einen Sales-Lead geht in Minuten statt Stunden raus, das CRM bleibt sauber befüllt mit Klassifikation und Kontext, Routine-Inbound (Cold-Outreach, NDA-Anfragen, Standard-Sales-Fragen) bindet keine menschliche Aufmerksamkeit mehr. Wichtig: das spart Latenz und Mental Load, ersetzt aber nicht die Sales- oder Support-Person — die wird schneller und fokussierter. Die schwierigen Fälle (komplexer Enterprise-Lead, mehrdeutige Support-Anfrage, potenzielle Eskalation) landen weiterhin bei einem Menschen, jetzt aber mit kontextuellem Briefing statt aus dem rohen Postfach. Wie stark der Effekt ausfällt, hängt direktional vom Inbound-Volumen, der Verteilungs-Variabilität und der CRM-Disziplin ab — das ist ein Erfahrungswert aus Engagements, keine veröffentlichte Benchmark.
Konfigurierbar. Unsere Standard-Empfehlung: Start mit Approval-Queue für alle Kategorien ausser Spam — der Agent draftet, ein Mensch reviewt mit zwei Klicks. Nach vier bis sechs Wochen wird die Akzeptanzrate pro Kategorie gemessen: wenn über 85 % der Drafts ohne inhaltliche Änderung freigegeben werden, kann Auto-Send für diese Kategorie aktiviert werden — typisch zuerst für „Demo-Request → Calendar-Link senden" und ähnlich klar definierte Patterns. Die 85 %-Schwelle ist ein direktionaler Erfahrungswert, kein veröffentlichter Benchmark — der konkrete Wert hängt von Voice-Konsistenz, Tonalität und Geschäftskontext ab. Spam und Cold-Outreach werden immer autonom verarbeitet. Eskalations-Verdachtsfälle nie. Diese Linie ist nicht-verhandelbar.
Wenn das Inbound-Volumen unter rund 20 Mails pro Tag liegt, ist Rule-Routing (Regex + Whitelist nach Absender-Domain + Subject-Pattern) oft günstiger und transparenter als ein Agent. Die Pflege von 30 Regeln ist überschaubar; ein LLM einzusetzen, um 20 Mails pro Tag zu klassifizieren, ist Über-Engineering — die Token-Kosten dominieren, die Wartung kommt obendrauf. Wenn die Inbound-Verteilung sehr stabil ist (z.B. 80 % Support, 15 % Sales, 5 % Spam mit klar erkennbaren Absender-Patterns), reichen klassische Filter ebenfalls aus. Erst wenn Volumen UND Variabilität gleichzeitig wachsen — also der Inbound diverser wird und die Regel-Pflege überproportional zunimmt — lohnt sich der Agent. Wir sagen das auch unseren Kunden so, und schicken sie manchmal mit „kauf das nicht von uns" wieder weg. Das ist nicht Marketing, sondern saubere Diagnose.
REST/Webhook ist Standard. Unterstützt werden HubSpot, Pipedrive, Salesforce, Bexio, Microsoft Dynamics, Close.io sowie Custom-CRMs über Standard-REST. Der Agent erzeugt einen Lead, Contact oder Ticket im CRM mit kontextuellem Briefing: Original-Mail, Klassifikation, Confidence-Score, vorgeschlagener Antwort-Draft, Sub-Kategorie-Hinweise. Der zuständige Sales-Rep oder Support-Agent sieht das CRM-Item, prüft es und sendet die Antwort — oder löst direkt über die Approval-Queue eine Aktion aus. Wichtig: wir empfehlen, den Lead-Score initial nicht vom Agent setzen zu lassen — Score-Drift (der Agent stuft systematisch zu hoch oder zu tief ein, ohne dass es jemand bemerkt) ist ein häufiger Stolperstein und vergiftet langfristig die CRM-Disziplin. Score-Setzung bleibt zuerst beim Menschen; nach kalibrierter Akzeptanzrate kann das später schrittweise verschoben werden.
Dieser Use Case sitzt in der Praktik KI-Engineering und greift in benachbarte Customer-Operations-Use-Cases.
Praktik: LLM-Anwendungen in Produktion — Klassifikations-Pipelines, structured output, Evaluation, Guardrails, Plattformwahl.
Verträge gegen kundenspezifisches Regelwerk prüfen — Ampelsystem rot/gelb/grün pro Klausel, Erstreview in Minuten, Juristen-Eskalation bei den roten Fällen.
Support-Anfragen über DE / FR / IT / EN beantworten — gleicher Wissensstand, gleiche Tonalität, Eskalation bei komplexen Fällen.
Aus strukturiertem Anfrage-Input (Form, Mail-Klassifikation) Angebote draften — mit Preislogik und Review-Queue vor dem Versand.
Sales-/Support-Triage lohnt sich ab etwa 30 Mails pro Tag mit echter Verteilungs-Variabilität. Bei kleinem oder klar strukturiertem Inbound ist klassisches Rule-Routing meistens günstiger — und wir sagen Ihnen das ehrlich, bevor wir Zeit Ihrerseits binden. In einem unverbindlichen 30-Minuten-Discovery-Call schauen wir Ihren konkreten Inbound an und besprechen, ob ein Agent oder Regel-Pflege der bessere Weg ist.
Discovery-Call anfragen