Wie KI-Agenten Support-Tickets tatsächlich vollständig schließen

Die meisten "AI Customer Support"-Tools beantworten einfache Fragen und eskalieren alles andere. Das ist eine nützliche Abkürzung für FAQ-Traffic, lässt aber den Long Tail — die Tickets, die tatsächlich Stunden eures Teams verschlingen — unberührt. Dieser Artikel zeigt, wie die Wisnots-Agenten genau diese schwierigeren Tickets vollständig schließen: was "ein Ticket schließen" bedeutet, welchen Kontext der Agent liest, wo Shadow Mode hingehört und wie Policy-Durchsetzung Autonomie unter eurer Kontrolle hält.

Was "ein Ticket vollständig schließen" tatsächlich heißt

Ein Ticket ist geschlossen, wenn es geschlossen bleibt. Nicht wenn eine automatisierte Antwort verschickt wurde, nicht wenn das System es als gelöst markiert — wenn der Kunde nicht zurückschreibt. Das ist absichtlich eine harte Schwelle. Wisnots bepreist sie: Eine Klärung zählt nur, wenn das Ticket für das vereinbarte Fenster geschlossen bleibt (typischerweise 14 Tage). Wiedereröffnungen innerhalb des Fensters werden nicht berechnet.

Diese Schwelle prägt alles, was davor passiert. Ein Agent, der so richtig sein muss, dass der Kunde nicht zurückschreibt, kann nicht raten. Er muss den tatsächlichen Kontext lesen — nicht nur den sichtbaren Ticket-Betreff und -Text, sondern die Kundenhistorie, den relevanten Produktstatus, die anwendbare Policy und die bisherigen Lösungen eures Teams für ähnliche Tickets.

Die Integrationsschicht

Vollständige Ticket-Schließung braucht mehr als Helpdesk-Integration. Der Agent braucht dieselbe operative Sicht, die eure Senior-Agenten haben. Wisnots integriert vier Schichten:

1. Helpdesk — Zendesk, Freshdesk, Intercom, HubSpot oder Custom. Tickets, Kommentare, interne Notizen, Status, Tags.
2. CRM — Kundendatensatz, Account-Status, Tarif, Vertragskonditionen, Support-Berechtigungen.
3. Produktdaten — Billing, Subscription-Status, Feature Flags, jüngste Aktivität, kundenspezifische Error-Logs.
4. Knowledge Base — euer schriftliches Wissen, frühere Lösungsmuster, interne Runbooks.

Eine Antwort, die nicht aus allen vier zieht, ist die Art generischer KI-Antwort, die Wiedereröffnungen auslöst. Aus allen vier zu ziehen schließt das Ticket einmal.

Der Reasoning-Loop: 12+ Context-Checks vor jeder Antwort

Bevor eine Antwort entworfen wird, durchläuft der Agent Context-Checks: Wer ist dieser Kunde (CRM-Lookup), wie ist der Account-Status (Produktdaten), welche Tickets hat er kürzlich geöffnet (Helpdesk-Historie), was sagt die Policy (Regelwerk), was hat euer Team beim letzten ähnlichen Ticket gemacht (Lösungs-Historie), welche Sprache und welcher Ton, welche Anhänge, welches SLA-Fenster, welche Confidence-Schwelle für autonome Antwort, wie sähe Eskalation aus, welche Audit-Log-Anforderung. Die Liste ist nicht fix — sie wächst pro Ticket-Kategorie — aber sie verhindert kollektiv die "klingt plausibel, ist aber falsch"-Antwort, die Wiedereröffnungen verursacht.

Wenn ein Check fehlschlägt oder die Confidence unter der Schwelle liegt, eskaliert der Agent statt zu antworten.

Shadow Mode: wie das Team reviewt und freigibt

Am ersten Tag ist der Agent im Shadow Mode. Er entwirft Antworten für jedes Ticket — das Team reviewt jeden Entwurf, editiert oder verschickt ihn, und der Agent lernt aus Korrekturen. Keine autonomen Antworten, keine Überraschungen, kein Vertrauensvorschuss.

Wenn ihr bereit seid, Kategorien autonom zu schalten, setzt ihr Confidence-Schwellen pro Kategorie. Routine-Passwort-Resets könnten autonom bei 90% Confidence verschickt werden; Multi-System-Vertragsstreitigkeiten verschicken sich nie autonom, unabhängig von der Confidence. Die Schwellen sind eure, nicht unsere.

Simulation: 90 Tage Tickets als Prognose

Bevor ein einziges Produktions-Ticket durch den Agenten läuft, spielen wir 90 Tage eurer historischen Tickets durch den aktuellen Agenten + euer aktuelles Regelwerk. Das Ergebnis sind keine projizierten Metriken — es ist ein Pro-Ticket-Replay, das zeigt, was wir geantwortet hätten, was wir eskaliert hätten und was einen Policy-Check nicht bestanden hätte. Ihr seht die Closure-Rate, die Eskalations-Rate und die Kanten, an denen der Agent versagt — bevor ihr in Produktion deployt.

Wenn die Simulationsprognose eure Schwelle nicht trifft, geht ihr weg.

Policy-Durchsetzung: Confidence-Schwellen und Eskalationsketten

Confidence-Schwellen gaten autonomes Verschicken. Eskalationsketten bestimmen, wohin abgelehnte Antworten gehen: welcher Supervisor, welche Queue, mit welcher Vorbereitung. Beide sind pro Ticket-Kategorie, pro Kundensegment und pro Kanal konfigurierbar.

Jede Aktion — Context-Check, Entwurf, Versand, Eskalation, Schließung — wird mit Zeitstempeln geloggt, mit den Daten, die der Agent zum Entscheidungszeitpunkt sah, und dem Regelpfad, dem er folgte. Euer Audit-Team kann jede Entscheidung gegen die zum Zeitpunkt aktive Policy nachspielen.

Pricing: Bezahlung pro gelöstem Ticket

Das Pricing folgt der Schwelle: Bezahlung pro gelöstem Ticket. Ticket-Komplexitäts-Bänder setzen den Pro-Ticket-Preis (0,40 € bis 4,50 € im Standardbereich). Ein monatliches Cap schützt vor Volumen-Spikes. Tickets, die wir nicht lösen können, die innerhalb des vereinbarten Fensters wieder geöffnet werden oder die wir eskalieren, werden nicht berechnet.

Die Plattformgebühr deckt die Integrationen, die Policy-Engine, die Runtime, die Audit-Logs und das laufende Model-Tuning. Die Pro-Ticket-Gebühr deckt die Ergebnisse, die wir liefern.

In-Article FAQ

Wohin als Nächstes

Neugierig, ob eure Ticket-Landschaft passt? Der schnellste Weg zu sehen, ist die Simulation — 90 Tage eurer Tickets, durch den Agenten gespielt, mit einer Pro-Ticket-Aufschlüsselung dessen, was wir geschlossen hätten. Zwei Wochen vom Kickoff bis zu euren ersten Zahlen.