Ausnahmemanagement im Kundensupport: Richtlinienausnahmen gewähren, dokumentieren und daraus lernen

Kurzfassung

Ausnahmemanagement im Support besteht aus drei Aufgaben: festlegen, wer welche Richtlinie lockern darf, jede Ausnahme einheitlich festhalten und die Einträge auswerten, damit wiederkehrende Ausnahmen zu Regeln werden. Die meisten Teams erledigen die erste Aufgabe nur halbherzig und überspringen die beiden anderen. Deshalb bekommt derselbe Kunde von einem Mitarbeiter ein Ja und vom nächsten ein Nein.

Mein Plädoyer: Eine Ausnahme, die du meistens gewährst, ist bereits deine Richtlinie, sie ist nur nicht aufgeschrieben. Und gefunden wird sie nicht in einer internen Notiz, sondern in einem Pflicht-Dropdown, über das dein Helpdesk Berichte erstellen kann. Achte aber auf die Fallstricke: Das „Pflichtfeld zum Lösen“ in Zendesk lässt sich durch Trigger, Automatisierungen und Zusammenführungen umgehen, und der Ticketfelder-Bericht von Gorgias zählt nur Dropdown-Felder.

Ich arbeite täglich in der eesel-Support-Queue, und bei Ausnahmen brauchen sowohl Mitarbeiter als auch KI die klarsten Regeln. In einem Test mit echtem Ticketaufkommen in einem Ecommerce-Zendesk-Postfach waren 96,4 % der Entwürfe von eesel bei Garantieanfragen für die Mitarbeiter nützlich. Genau dafür ist der KI-Teammate von eesel gebaut: Er wendet die Ausnahmen an, die du aufgeschrieben hast, hält alles, was Geld kostet, für die richtige Person zurück und übergibt den Rest mit einer Notiz an dein Team.

Was als Support-Ausnahme zählt

Eine Ausnahme liegt immer dann vor, wenn ein Mitarbeiter einem Kunden etwas gibt, das die schriftliche Richtlinie nicht vorsieht. Manche sind winzig, andere kosten echtes Geld, aber alle haben eines gemeinsam: Sie beruhen auf einer Ermessensentscheidung, sodass zwei Mitarbeiter beim selben Ticket unterschiedlich entscheiden können.

Hier sind die, die mir in der Queue am häufigsten begegnen, mit der Richtlinie, die sie lockern:

Die letzte Spalte ist wichtiger, als sie aussieht. Die meisten Teams haben eine Matrix für Erstattungsfreigaben oder zumindest ein Betragslimit für Erstattungen. Für den Rest der Tabelle gibt es nur selten dieselbe Klarheit, weshalb über Gebührenerlasse und Kulanzgutschriften nach Laune entschieden wird.

Warum unverwaltete Ausnahmen mehr kosten als die Ausnahmen selbst

Die Kosten einer Ausnahme sind nicht nur die 10-$-Gutschrift. Teuer wird es, wenn Ausnahmen uneinheitlich, unsichtbar und nicht auswertbar sind.

Kunden lernen, sich einen anderen Mitarbeiter zu suchen. Hängt die Antwort davon ab, wer abhebt, ist es klug, einfach noch einmal zu fragen. Das sagen Leute ganz offen:

"I've learned to play customer service roulette.

Don't get the answer I'm looking for?

Hang up and call back."

sirspacey, Hacker News

Ausnahmen verstecken sich in anderen Kategorien. Wenn Mitarbeiter keinen offiziellen Weg haben, etwas zu gewähren, finden sie einen inoffiziellen. Ein Kommentator beschrieb, wie das bei Banken und Kartenanbietern läuft:

"If you're not yelling at them, you can often get what you want via some other method (which only they know) - like them reclassifying the problem to something else they have leeway for."

bombcar, Hacker News

Das umklassifizierte Ticket taucht dann in deinen Berichten als etwas auf, das es nicht war. Dein Ticket-Tagging stimmt nicht mehr, und die Ausnahme ist unsichtbar.

Zugesagte Ausnahmen verschwinden. Am schlimmsten ist eine Ausnahme, die vereinbart, aber nie festgehalten wurde. Ein Kunde auf r/Comcast_Xfinity beschrieb, wie er telefonisch mit dem Support eine Lösung erarbeitet hatte: "they said they would note this on my account. I reached back out after a week to confirm the notes on the account an there is no record of the solution offered" (cali1302, Reddit). Jetzt muss der nächste Mitarbeiter wählen: ein Versprechen einhalten, das er nicht sehen kann, oder den Kunden der Lüge bezichtigen.

Kleine Ablehnungen werden zu großen Präzedenzfällen. Das bekannteste Beispiel ist der Fall des Air-Canada-Chatbots, bei dem eine abgelehnte Trauerfall-Erstattung vor einem Tribunal landete. Ein Hacker-News-Kommentator fasste es so zusammen: Es "should've been well within some second-tier customer service manager's discretionary refund budget. Instead they've got a precedent-setting ruling that makes the chatbot a huge liability" (ceejayoz, Hacker News).

Der Kreislauf des Ausnahmemanagements im Support

Jede Ausnahme sollte dieselben fünf Schritte durchlaufen. Den letzten Pfeil, von der monatlichen Auswertung zurück zur schriftlichen Richtlinie, überspringen die meisten Teams. Ohne ihn gewährst du dieselbe Ausnahme jeden Monat 40-mal und merkst nie, dass sie längst eine Regel sein müsste.

Der Rest dieses Leitfadens geht den Kreislauf der Reihe nach durch: wer entscheidet, wie du es dokumentierst, welche Tools Einzelausnahmen bereits abbilden, wie du auswertest und wie du deinem KI-Agenten dieselben Regeln mitgibst, nach denen deine Mitarbeiter arbeiten.

Schritt 1: Festlegen, wer was gewähren darf

Sortiere Ausnahmen zunächst nach zwei Fragen: Wessen Schuld ist es, und wie viel kostet es? Diese beiden Antworten verraten dir viel besser als ein einzelnes Betragslimit, wer entscheiden sollte.

Das Feld unten links machen die Leute am häufigsten falsch. Wenn eine Lieferung durch dich zu spät kam und die Lösung weniger kostet als die Zeit für die Genehmigung, sollte es gar keine Ausnahme sein. Ein Einzelhandelsmitarbeiter hat das Lohnkosten-Argument gut auf den Punkt gebracht:

"Especially on clothes that have a ridiculously high margin, it's costs more money in payroll wasting that time than just giving them a BOGO."

Rhewin, Reddit r/TalesFromRetail

Für alles andere gibst du jeder Rolle ein schriftliches Ermessensbudget. Banken arbeiten bereits so. Wie ein Kommentator schrieb: "most banks/credit cards let the first-level hit the 'refund one fee' button, and the higher up you get, the more discretion they have" (bombcar, Hacker News). Das Budget sollte drei Dinge festhalten:

1. Was die Rolle allein gewähren darf. Zum Beispiel: ein Gebührenerlass pro Kunde und Jahr, Kulanzgutschriften bis 15 $, Rückgaben bis zu 7 Tage nach Fristablauf.
2. Was sie gar nicht gewähren darf. Ausnahmen vom Endverkauf, Vertragsgutschriften, alles, was eine offene Rückbuchung betrifft.
3. Wen man für den Rest fragt. Eine namentlich genannte Person und eine Vertretung, nicht „der Leads-Kanal“. Wenn du eine Auffrischung zum Routing brauchst, hilft meine Anleitung zum Ticket-Eskalationsprozess.

Noch etwas gehört aufgeschrieben: wofür die Ausnahme da ist. Sonst driftet das Ermessen zu dem, der am hartnäckigsten drängt. Ein Mitarbeiter auf r/talesfromcallcenters beschrieb Vorgesetzte, die "pick to be nice to rude people and give hard stops to really nice people" (Asha990, Reddit). Ein Satz wie „Kulanzgutschriften sind für Servicefehler auf unserer Seite, nicht für Hartnäckigkeit“ klärt vieles, bevor der Streit beginnt.

Schritt 2: Jede Ausnahme in einem Feld erfassen, nicht in einer Notiz

Hier ist der Teil, den fast jeder Ausnahme-Leitfaden überspringt. Eine Notiz im Ticket („einmalige Kulanzerstattung gewährt“) ist besser als nichts, aber Notizen kann man nicht zählen. Um Ausnahmen auszuwerten, brauchst du strukturierte Daten, und im Helpdesk heißt das benutzerdefinierte Ticketfelder.

Ich würde vier Felder einrichten, von denen drei nur erscheinen, wenn das erste auf Ja steht:

• Ausnahme gewährt: ein Dropdown mit Nein und Ja. Mach es beim Schließen des Tickets zum Pflichtfeld.
• Ausnahmetyp: ein Dropdown mit den Typen aus der Tabelle oben.
• Ausnahmegrund: ein Dropdown mit Gründen (Kurierverzögerung, beschädigter Artikel, unser Fehler, Umstände des Kunden) plus einer Option „Sonstiges“.
• Wert und Genehmiger: ein Zahlenfeld für die Kosten und ein Dropdown mit den Namen der Genehmiger.

Dropdowns schlagen Freitext aus einem einfachen Grund. Laut Zendesks eigener Dokumentation können Textfeldwerte "inkonsistent sein oder Rechtschreibfehler enthalten", was sie "für Berichtszwecke weniger nützlich" macht (Zendesk). Freshdesk rät dasselbe: "favor dropdowns over text fields where possible" (Freshdesk).

Was die einzelnen Helpdesks unterstützen

Jeder große Helpdesk kann irgendeine Version davon, aber Tarifbeschränkungen und Limits unterscheiden sich stark. Das sagt die Dokumentation heute:

In Zendesk ist der Teil „nur bei Ja anzeigen“ ein bedingtes Feld. Im Bedingungseditor kannst du die abhängigen Felder außerdem je Status zu Pflichtfeldern machen, sodass der Ausnahmetyp erst beim Lösen des Tickets verpflichtend wird:

Gorgias macht dasselbe mit Feldbedingungen, in jedem Helpdesk-Tarif:

Vier Fallstricke im Kleingedruckten

Das sind die Details, die ein Ausnahmeprotokoll sechs Wochen nach der Einrichtung stillschweigend kaputt machen:

1. Zendesks Pflichtfeld hat Lücken. Die Einstellung steht bei jedem Feld, aber laut Zendesk-Dokumentation können Pflichtfelder "durch Trigger und Automatisierungen umgangen werden" und werden "auch umgangen, wenn ein Agent ein Ticket zusammenführt" (Zendesk). Der vorgeschlagene Workaround ist ein okay_to_close-Tag, auf das deine Schließ-Automatisierung wartet.
2. Gorgias wertet nur Dropdowns aus. Der Ticketfelder-Bericht "erfasst nur benutzerdefinierte Ticketfelder vom Typ Dropdown", Zahl-, Text- und Ja/Nein-Felder tauchen also nicht auf (Gorgias). Mach Ausnahme gewährt deshalb zu einem Dropdown, nicht zu einem Ja/Nein-Feld. Gorgias weist außerdem darauf hin, dass sein AI Agent "ein Ticket schließen kann, ohne ein erforderliches Ticketfeld auszufüllen" (Gorgias).
3. Help Scout prüft beim Antworten, nicht beim Schließen. Erforderliche benutzerdefinierte Felder müssen "beim Senden einer Antwort" ausgefüllt sein, und die Felddaten werden nicht mitgenommen, wenn die Unterhaltung in ein anderes Postfach verschoben wird (Help Scout).
4. Ein gelöschtes Feld löscht deine Historie. Freshdesk sagt, das Entfernen eines Felds "blendet es in Analytics aus", und Help Scout sagt, das Löschen entfernt die Daten "für immer". Archiviere alte Ausnahmetypen, statt sie zu löschen.

Ein Bonus für Zendesk-Teams ab Suite Professional: Das Dataset „Updates history“ in Explore kann Änderungen an Feldwerten im Zeitverlauf nachverfolgen (Zendesk) und beantwortet damit „wer hat das wann auf Ja gesetzt“. Mein Explore-Rezept für benutzerdefinierte Felder führt durch den Bericht.

Schritt 3: Tools nutzen, die Einzelausnahmen bereits abbilden

Dein Helpdesk hält die Ausnahme fest. Die Aktion selbst passiert aber oft in einem anderen Tool: der Retouren-App, dem Shop-Admin, dem Abrechnungssystem. Mehrere davon haben einen richtigen Ausnahmemechanismus eingebaut, und den zu nutzen ist besser, als wenn ein Mitarbeiter die Regeln umgeht.

Loop ist das klarste Vorbild. Die Funktion Listings existiert, um "Rückgabeausnahmen und -beschränkungen zu verwalten", und eine Bestellung auf die Allowlist zu setzen "übersteuert jeden bestehenden Blocklist-Eintrag, als Final Sale markierte Produkte oder die Rückgabefrist der Bestellung" (Loop). Noch besser gefällt mir Loops eigene Best Practice: die Bestellung auf die Allowlist setzen, die Rückgabe für den Kunden einreichen und den Allowlist-Eintrag sofort wieder entfernen. Eine temporäre Ausnahme, die hinter sich aufräumt, ist genau das, was du willst. Loop verweist Käufer nach Fristablauf außerdem an den Support: "contact your support team directly for any exceptions" (Loop). Diese Tickets landen also in deiner Queue, ob du sie einplanst oder nicht.

Loop Workflows machen aus wiederkehrenden Ausnahmen Regeln. Wenn die Auswertung in Schritt 4 ergibt, dass eine Ausnahme zur Richtlinie werden sollte, können Workflows sie automatisch anwenden, mit Aktionen wie Bypass final sale, Set return window und Set handling fee, um bestehende Gebühren zu "übersteuern, zu ergänzen oder zu erlassen" (Loop Workflows). Mehr dazu habe ich in meinem Leitfaden zur Retouren-Automatisierung behandelt.

Shopify-Regeln können Ausnahmen abbilden, die du schon kennst. Mit Überschreibungen der Rückgabefrist kannst du Ausverkaufsartikeln 14 Tage und Möbeln 90 Tage geben, und Final-Sale-Artikel werden als "Ausnahmen von deinen Standard-Rückgaberegeln" beschrieben (Shopify). Was ich in Shopifys Dokumentation nicht finden konnte, ist ein Schalter, der eine einzelne Bestellung zulässt, obwohl die Regeln Nein sagen. Der dokumentierte Weg ist eine von Mitarbeitern im Admin angelegte Rückgabe, bei der Gebühren je Rückgabe bearbeitet werden können.

Stripes Guthaben ist eine Kulanzgutschrift mit eingebautem Prüfpfad. Jedes Kundenguthaben wird "aus einem Ledger berechnet, einer unveränderlichen Liste von Soll- und Haben-Transaktionen" (Stripe). Jede Anpassung kann eine interne Notiz tragen, die der Kunde nie sieht, und Einträge lassen sich nicht löschen, nur stornieren. Wenn Kulanzgutschriften bei deinem SaaS-Produkt irgendwo anders liegen, sind sie schwerer zu prüfen als nötig.

Schritt 4: Das Protokoll auswerten und wiederkehrende Ausnahmen befördern

Hier zahlt sich Ausnahmemanagement aus. Ziehe einmal im Monat alle Tickets mit Ausnahme gewährt auf Ja und gruppiere sie nach Typ und Grund. Für jede Gruppe stellst du eine Frage: Ist das eine echte Ausnahme oder eine ungeschriebene Regel?

Aus Kundensicht wirken ungeprüfte Ausnahmen willkürlich. Ein Kommentator schrieb, nachdem ihm ein Vorgesetzter geholfen hatte: "There's no particular rhyme or reason for why extraordinary relief is sometimes granted though, it seems completely random!" (gnicholas, Hacker News). Aus Teamsicht ist es noch schlimmer: Du verbrauchst Zeit der Genehmiger für Entscheidungen, die du jedes Mal gleich triffst.

Nimm einen Ausnahmetyp vom letzten Monat und trage seine Zahlen hier ein:

Die Schwellenwerte im Widget (10 Anfragen im Monat, 80 % gewährt) sind mein Ausgangspunkt, kein Branchenstandard. Passe sie an dein Volumen an. Entscheidend ist, dass die Auswertung bei einer von vier Entscheidungen endet und jede Entscheidung etwas verändert:

• Zur Richtlinie machen. Aktualisiere die schriftliche Richtlinie und das Help Center, passe deine Makros an und informiere Mitarbeiter und KI-Agent am selben Tag. Meine Anleitung zum Change Management für Support-Richtlinien behandelt die Einführung.
• Im Ermessen des Mitarbeiters belassen. Lass es im Budget, aber erfasse es weiter.
• An eine benannte Freigabeperson geben. Hohe Kosten oder ein Muster, bei dem du ein zweites Paar Augen willst.
• Das Nein vorformulieren. Wenn du eine Anfrage zu 80 % ablehnst, bringen die 20 % Ja den Kunden bei, weiter zu fragen. Wie ein Einzelhandelsmitarbeiter sagte: "They are getting something out of it, so it continues" (Cheshire1871, Reddit).

Die Auswertung speist außerdem zwei weitere Kreisläufe. Mitarbeiter, deren Ausnahmequote weit vom Teamdurchschnitt abweicht, sind ein Coaching-Gespräch, und hier kommen Support-QA-Kalibrierung und Agent-Feedback ins Spiel. Und ein Ausschlag bei einem Grund, etwa Kurierverzögerungen, ist ein operatives Problem, das der Support stillschweigend mitbezahlt. Melde es zusammen mit der übrigen Support-Ticketanalyse.

Schritt 5: Deinem KI-Agenten schriftliche Ausnahmeregeln geben

KI-Agenten machen Ausnahmemanagement dringender, nicht weniger dringend. Ein Mensch kann die Stimmung lesen und eine Regel unauffällig lockern. Ein KI-Agent befolgt entweder die Regeln, die du geschrieben hast, oder er improvisiert, und beide Fehlerarten zeigen sich öffentlich.

Die erste Sorge ist, dass Kunden die KI zu Ausnahmen überreden:

"People will find out how to convince the LLM you do meet the requirements for a refund.

And if you check the requirements using something deterministic (last order was within last 2 weeks, customer has a high loyalty points score, they're subscribed to some premium service) then why do you need an agent at all?"

graypegg, Hacker News

Der umgekehrte Fehler ist genauso schlimm: ein Bot, der keine Ausnahme gewähren kann und den Kunden nicht zu jemandem durchlässt, der es kann. Ein Kunde beschrieb einen KI-Support-Chat, der immer wieder anbot, zum Ende des Abrechnungszeitraums zu kündigen: "I ask for human. It repeats. I ask for human again. It repeats. I disconnect" (kldg, Hacker News).

Die Antwort auf beides ist dieselbe wie bei Menschen. Schreibe die Ausnahmen, die die KI anwenden darf, als einfache Regeln auf, setze eine harte Grenze bei allem, was Geld bewegt, und sorge dafür, dass jede andere Ausnahmeanfrage mit Kontext bei einem Menschen landet. Das sind KI-Leitplanken für Richtlinien angewendet, und der Weg der KI-Eskalation ist die Hälfte davon.

Die wichtigsten KI-Tools für Helpdesks unterstützen dieses Vorgehen inzwischen:

Zendesks Procedure Builder ist ein gutes Bild dafür, wie „die Ausnahme aufschreiben“ für eine KI aussieht. Du beschreibst die Richtlinie in einfacher Sprache, und er baut eine verzweigte Karte mit einer Prüfung, bevor etwas Unumkehrbares passiert (Zendesk):

Zendesks Dokumentation ist auch ehrlich, was die Grenze angeht: Kontext in einer Procedure kann "exaktes KI-Verhalten nicht garantieren", und alles, was verzweigen muss, sollte einen Check-condition-Block nutzen (Zendesk). Das ist der richtige Instinkt. Formulierungen leiten die KI an, harte Grenzen für Geld gehören aber in die Aktionseinstellungen.

So würde ich Ausnahmeregeln mit eesel schreiben

In eesel kommen Ausnahmen in einfacher Sprache in die Anweisungen des Agenten, so wie du eine neue Kollegin einweisen würdest. Die Dokumentation liefert eine Vorlage „Cover exceptions and edge cases“ mit Zeilen wie „Schadensmeldungen unter 50 $: Fotoanfrage überspringen, Erstattung genehmigen“ und „Bestellungen der letzten Stunde: Stornierungen brauchen keine Freigabe“, dazu eine Regel, dass Kunden mit VIP-Tag immer eskaliert werden (eesel-Dokumentation). Die Eskalationsvorlage deckt die andere Hälfte ab: eine interne Notiz hinterlassen, die sagt „was der Kunde will, was du gefunden hast und was du geantwortet hättest“, und sie dann einer Person zuweisen.

Du kannst den Agenten auch so korrigieren, wie du einen Menschen korrigieren würdest. Ein Support-Admin, mit dem ich gearbeitet habe, brachte seinem Agenten eine Regel bei, die im Grunde eine Ausnahmerichtlinie ist: Eine Kündigungs- oder Erstattungsanfrage mit einem ungelösten Problem bekommt zuerst Fehlerbehebung:

"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."

Ein Support-Admin, der eine Richtlinie „erst Fehler beheben, dann kündigen“ in den Agenten einbaut

Bei allem, was Geld kostet, erzwingen die Aktionseinstellungen die Regel. Jede Aktion hat pro Agent eine von drei Einstellungen: Auto, Needs approval oder Disabled (eesel-Dokumentation). Du kannst eine Aktion auf Auto lassen und dem Agenten trotzdem sagen, dass er in bestimmten Situationen zuerst fragt. So wird aus einer schriftlichen Ausnahmerichtlinie eine echte Schranke. Wenn eine Freigabe nötig ist, sieht die genehmigende Person die genaue Aktion und den Betrag, und Freigaben laufen nach einem Timeout nie von selbst durch.

Die Seite Activity hält fest, wer was wann genehmigt hat, und dient damit als Ausnahmeprotokoll für alles, was die KI angefasst hat.

Häufige Fehler im Ausnahmemanagement

Diese würde ich zuerst beheben, grob in der Reihenfolge ihrer Kosten:

1. Ausnahmen in Notizen erfassen. Notizen kann man nicht zählen. Nutze ein Pflicht-Dropdown, und achte in Gorgias darauf, dass es ein Dropdown und kein Ja/Nein-Feld ist.
2. Kein Ermessensbudget. Ohne eines erfindet jeder Mitarbeiter sein eigenes, und Kunden lernen, einen zweiten Mitarbeiter zu fragen. Schreib auf, was jede Rolle gewähren darf.
3. Ausnahmen bei eigenem Verschulden wie Gefälligkeiten behandeln. Eine Gutschrift für verspätete Lieferung, die du jedes Mal gewährst, sollte eine Regel sein. Kunden darum bitten zu lassen, erzeugt nur Tickets und schadet dem CSAT.
4. Den Kreis nie schließen. Wenn die monatliche Auswertung weder Richtlinie, Help Center noch Makros verändert, ist sie nur ein Bericht. Jeder Ausnahmetyp sollte die Auswertung mit einer Entscheidung beenden.
5. Die KI improvisieren lassen. Ein KI-Agent ohne schriftliche Ausnahmeregeln sagt entweder zu allem Nein oder zum Falschen Ja. Gib ihm Regeln, eine Geldgrenze und einen sauberen Eskalationsweg.
6. Alte Felder löschen. Archiviere ausgemusterte Ausnahmetypen, damit die Daten vom letzten Jahr weiter in Berichten erscheinen.

Support-Ausnahmen mit eesel bearbeiten

Wenn dein Team mit Zendesk, Gorgias oder Freshdesk arbeitet, ist der KI-Helpdesk-Teammate von eesel der direkteste Weg, deine Ausnahmeregeln durchzusetzen. Er reiht sich in deine bestehende Queue ein, lernt aus deinen früheren Tickets, deinem Help Center und deinen Makros und befolgt die Ausnahmen, die du in einfacher Sprache schreibst. Alles, was Geld kostet, wartet auf die Freigabe der richtigen Person, im Dashboard oder in Slack, und alles außerhalb deiner Regeln geht mit einer Notiz an dein Team, was der Kunde will und was er gefunden hat.

Bevor er eine echte Ausnahme bearbeitet, kannst du eine Simulation auf deinen vergangenen Tickets laufen lassen und seine Antworten mit dem vergleichen, was dein Team tatsächlich gesendet hat. Die Preise gelten pro Ticket bei unbegrenzten Seats, sodass jede genehmigende Person Zugriff haben kann, und du kannst mit 100 kostenlosen Credits und ohne Karte starten. eesel testen.