Support-Tickets mit KI: erst messen, dann senden.

Support-Automatisierung wird häufig mit einer einzigen Zahl verkauft: der Automationsquote. Diese Zahl ist ohne Kontext wenig wert. Ein automatisch geschlossenes Ticket kann korrekt gelöst, unbemerkt falsch beantwortet oder nur verlagert worden sein.

Der Business Case braucht deshalb mehrere Perspektiven: Kosten pro Vorgang, Lösungsqualität, Durchlaufzeit, Wiedereröffnung, Eskalation und Betriebsaufwand. Erst zusammen zeigen sie, ob die Automatisierung tatsächlich Wert erzeugt.

Vor dem Agenten: die Support-Baseline

Eine repräsentative Stichprobe sollte mindestens nach Anfrageart, Sprache, Kundengruppe und Risikoklasse getrennt werden. Für jede Klasse werden dokumentiert:

• monatliches Volumen und saisonale Spitzen
• aktive Bearbeitungszeit und gesamte Lösungszeit
• Rückfragen, Übergaben und Wiedereröffnungen
• heutige Lizenz- und Dienstleisterkosten
• Fehlerfolgen, Kulanz und Eskalationsaufwand
• verfügbare Quellen und ausführbare Aktionen

Fünf Funktionsstufen – nicht alles auf einmal

1. Triage: Kategorie, Dringlichkeit und zuständiges Team vorschlagen.
2. Recherche: freigegebene Wissensquellen und Kundendaten abrufen.
3. Entwurf: Antwort mit Quellen und Unsicherheitskennzeichen vorbereiten.
4. Aktion: begrenzte Werkzeuge wie Statusabfrage oder Dokumentbereitstellung ausführen.
5. Versand: nur freigegebene Fallklassen ohne menschliche Prüfung abschließen.

Jede Stufe besitzt eigene Abnahmekriterien. Ein System kann wirtschaftlich wertvoll sein, obwohl der automatische Versand deaktiviert bleibt – etwa wenn Recherche- und Entwurfszeit deutlich sinken.

Illustrative Process P&L

Der Pilot gilt nur dann als wirtschaftlich, wenn die eingesparte Bearbeitungszeit nicht durch mehr Wiedereröffnungen, Kontrolle oder Systembetrieb aufgezehrt wird. Kapazitätsgewinn und tatsächlich vermiedene Ausgaben werden getrennt ausgewiesen.

Eine belastbare Referenzarchitektur

Ticket / E-Mail
  ↓
Datenschutz- und Risikofilter
  ↓
Klassifikation mit dokumentierter Confidence
  ↓
Freigegebene Wissens- und Systemzugriffe
  ↓
Entwurf + Quellen + ausgeführte Aktionen
  ↓
Policy Gate
  ├─ menschliche Freigabe
  ├─ sichere automatische Aktion
  └─ Eskalation / Stopp
  ↓
Outcome- und Kostenmessung

Das Sprachmodell ist nur eine Komponente. Identität, minimale Berechtigungen, Secret-Management, Protokollierung, Löschung, Fallback und Wiederanlauf bestimmen, ob das System produktionsfähig ist.

Welche Fälle zuerst geeignet sind

Guter Pilotumfang

• hohes Volumen und klar unterscheidbare Fallklasse
• verlässliche Wissensquelle oder Systemabfrage
• reversible Aktion mit begrenztem Fehlerfolgeschaden
• ausreichende historische Fälle für Test und Baseline

Nur mit enger Freigabe

• Kulanz, Rabatt, Beschwerde oder emotionaler Kontext
• rechtsverbindliche Aussagen und individuelle Vertragsauslegung
• Gesundheits-, Finanz- oder andere besonders sensible Informationen
• Aktionen mit schwer umkehrbarer Wirkung

Systemkosten vollständig rechnen

Zur TCO gehören nicht nur Token oder Server. Rechnen Sie auch Ticketsystem, Integrationen, Evaluation, menschliche Reviews, Monitoring, Security-Patches, Modellwechsel, Support und erwartete Störungszeit ein. Ein selbst gehostetes Open-Source-System kann günstiger und souveräner sein – wenn das Unternehmen den Betrieb beherrscht. Andernfalls verschiebt es Kosten lediglich von Lizenz zu Betrieb.

Ein kontrollierter Sechs-Wochen-Pfad

1. Baseline: Stichprobe, Fallklassen, TCO und Qualitätsmetriken.
2. Policy: erlaubte Quellen, Aktionen, Limits und Eskalationen.
3. Offline-Test: historische Tickets ohne Kundeneffekt auswerten.
4. Shadow Mode: Vorschläge parallel zur echten Bearbeitung messen.
5. Freigabebetrieb: Menschen prüfen Antworten definierter Klassen.
6. Entscheidung: Stop, Anpassung oder begrenzte automatische Freigabe.