Eskalationsrichtlinie

Zweck

Dieser Skill definiert, wann ein Fall die Bearbeitungsbefugnis der First-Line-Betreuung übersteigt und formal an ein Spezialistenteam eskaliert werden muss. Er liefert Entscheidungskriterien, Routing-Regeln, Dringlichkeitsstufen und Handoff-Protokolle, damit kein Fall verloren geht und jede Eskalation mit den richtigen Informationen beim richtigen Team ankommt.

Eskalation ist kein Scheitern — sie ist korrekte Prozessausführung. Wende diese Richtlinie proaktiv an, bevor sich ein Fall verschlechtert, nicht reaktiv, nachdem der Schaden entstanden ist.

Eskalationsstufen

Jeder Fall, der sich nicht mit dokumentierten Knowledge-Base-Inhalten, Standard-Troubleshooting-Schritten oder freigegebenen Antwortvorlagen lösen lässt, muss eskaliert werden. Bestimme die richtige Stufe anhand der folgenden Kriterien.

1. Product-Team

Eskaliere, wenn:

• Ein bestätigter Bug oder unerwartetes Produktverhalten sich nicht per Workaround lösen lässt

• Eine Funktion fehlt, defekt ist oder von der dokumentierten Spezifikation abweicht

• Der Kunde eine Regression meldet (etwas, das vorher funktioniert hat, funktioniert nicht mehr)

• Eine Produktfrage sich nicht aus aktueller Dokumentation oder den Release Notes beantworten lässt

• Mehrere Kunden dasselbe Problem melden (Muster über 2+ Tickets erkennbar)

Nicht an Product eskalieren bei:

• Allgemeinen „Wie benutze ich das?"-Fragen (über KB oder Dokumentationslinks lösen)

• Feature-Wünschen ohne Auswirkung auf die aktive Nutzung (im Backlog erfassen, nicht eskalieren)

Anforderungen an den Handoff:

• Ticket-ID und vollständiger Konversationsverlauf

• Reproduzierbare Schritte oder Bildschirmaufnahme, falls vorhanden

• Betroffene(r) Account(s), Plan-Tier und Anzahl betroffener Nutzender

• Häufigkeit: erstmalig, sporadisch oder systematisch

2. Engineering-Team

Eskaliere, wenn:

• Infrastruktur, API oder Backend-System ausgefallen oder beeinträchtigt ist

• Datenverlust, Datenkorruption oder Dateninkonsistenz gemeldet oder vermutet wird

• Performance-Einbußen die Kernfunktionalität des Produkts betreffen (Ladefehler, Timeouts, Fehler)

• Eine Integration (Drittanbieter oder intern) nicht mehr funktioniert

• Ein technischer Fehler sich mit Standard-Debugging nicht reproduzieren lässt und eine Untersuchung auf Code-Ebene erfordert

• Sicherheitsnahe technische Probleme eine Ursachenanalyse erfordern (siehe auch Security unten)

Nicht an Engineering eskalieren bei:

• Kosmetischen UI-Problemen ohne funktionale Auswirkung (an Product weiterleiten)

• Konfigurationsfehlern, die Kunde oder Support-Agent selbst beheben können

Anforderungen an den Handoff:

• Fehlerlogs, Fehlercodes oder HTTP-Response-Codes

• Zeitstempel des ersten Auftretens (mit Zeitzone)

• Umgebungsdetails (Browser, OS, API-Version, Tenant-/Account-ID)

• Reproduktionsrate: durchgängig, sporadisch oder Einzelfall

3. Legal-Team

Eskaliere, wenn:

• Ein Kunde oder Nutzender eine formale Rechtsforderung, Aufforderung oder Drohung äußert (inklusive Unterlassungserklärung, Klageandrohung oder Beschwerde bei einer Aufsichtsbehörde)

• Ein Antrag auf Datenlöschung, Datenauskunft oder Datenübertragbarkeit eingeht (Betroffenenrechte nach DSGVO Art. 15–17)

• Vertragsbedingungen, SLA-Definitionen oder Haftungsklauseln vom Kunden bestritten werden

• Eine gerichtliche Anordnung, Vorladung oder behördliche Anfrage eingeht

• Fragen zu geistigem Eigentum aufkommen (Urheberrecht, Marke, Patent)

• Ein Kunde geltendes Recht oder eine Verordnung als Grundlage seiner Beschwerde anführt

• Ein Partner oder Lieferant einen Vertragsbruch geltend macht

Nicht an Legal eskalieren bei:

• Allgemeinen Datenschutzfragen von Kunden (über Datenschutzrichtlinien oder KB lösen)

• Internen Compliance-Fragen ohne rechtliches Forderungselement (an den Compliance Officer weiterleiten)

Anforderungen an den Handoff:

• Vollständige wortgetreue Kundenkommunikation (Rechtsforderungen nicht paraphrasieren)

• Referenz auf den relevanten Vertrag oder die Vereinbarung, falls zutreffend

• Datum und Kanal der Kommunikation

• Nach einer Legal-Eskalation nicht mehr gegenüber dem Kunden antworten, bis Legal die Antwort freigibt

4. Security-Team

Eskaliere, wenn:

• Ein Kunde unbefugten Zugriff auf sein Konto oder seine Daten meldet

• Verdächtige Login-Aktivität, kompromittierte Zugangsdaten oder eine Kontoübernahme vermutet wird

• Eine potenzielle Schwachstelle, ein Exploit oder ein Eindringen gemeldet wird (Responsible Disclosure)

• Personenbezogene Daten von Kunden oder Mitarbeitenden gegenüber Unbefugten offengelegt worden sein könnten

• Ungewöhnliche API-Aktivität, Rate-Limit-Missbrauch oder Bot-Verhalten auf einen aktiven Angriff hindeutet

• Ein Phishing- oder Social-Engineering-Versuch gegen die Organisation erkannt wird

• Ein Vorfall vorliegt, der eine Datenschutzverletzung nach DSGVO Art. 33 darstellen könnte (72-Stunden-Meldefrist greift)

Nicht an Security eskalieren bei:

• Passwort-Zurücksetzungen (über den Standard-Prozess zur Kontowiederherstellung lösen)

• Generischem Spam oder unerwünschten E-Mails (erfassen und verwerfen, sofern kein gezieltes Phishing)

Anforderungen an den Handoff:

• Sofortige Eskalation — nicht verzögern, um weitere Informationen zu sammeln

• Account-ID, IP-Adressen, Zeitstempel und betroffene Datenarten, soweit bekannt

• Die potenziell kompromittierte Partei nicht vor der Security-Bewertung informieren

• Alle Beweise sichern; zugehörige Datensätze nicht löschen oder verändern

DSGVO-Hinweis: Bei Verdacht auf eine Datenschutzverletzung muss Security innerhalb von 24 Stunden bewerten. Bestätigt sich die Verletzung, müssen Legal und der Datenschutzbeauftragte informiert werden, um die 72-Stunden-Meldepflicht nach DSGVO Art. 33 einzuhalten.

5. Customer-Success-Team (CS)

Eskaliere, wenn:

• Ein Kunde Abwanderungsrisiko, Kündigungsabsicht oder eine Unzufriedenheit signalisiert, die über einen Einzelfall hinausgeht

• Ein Enterprise- oder strategischer Account (definiert über das Account-Tier) ein kritisches Problem meldet — unabhängig vom Schweregrad

• Ein Kunde innerhalb von 30 Tagen 3 oder mehr ungelöste Tickets zum selben Thema eingereicht hat

• Ein Kunde Kontakt zur Geschäftsleitung, ein Account Review oder ein formales Eskalationsmeeting verlangt

• Der NPS-Wert oder die CSAT-Antwort eines Kunden auf starke Unzufriedenheit hindeutet (Wert ≤ 3 von 10)

• Ein Upsell- oder Renewal-Gespräch läuft und ein Support-Thema es zu gefährden droht

• Ein Kunde Bedenken zur Geschäftsbeziehung äußert, nicht nur zum Produkt

Nicht an CS eskalieren bei:

• Standard-Support-Tickets, die innerhalb des SLA lösbar sind (First-Line bearbeiten)

• Feature-Wünschen zufriedener Kunden (im Backlog erfassen und dem Kunden danken)

Anforderungen an den Handoff:

• Kontext zur Kundengesundheit (Account-Tier, Vertragswert, Verlängerungsdatum, soweit bekannt)

• Zusammenfassung offener Themen und der Lösungshistorie

• Ton und Stimmung der jüngsten Kommunikation

• Empfohlene CS-Maßnahme (proaktive Ansprache, Executive Call, Prüfung einer Kompensation)

Schweregrad-Klassifizierung

Nutze diese Matrix, um Dringlichkeit und Reaktionszeit ergänzend zur Routing-Entscheidung oben zu bestimmen.

SEV-1- und SEV-2-Fälle erfordern immer eine Eskalation. SEV-3- und SEV-4-Fälle werden nur eskaliert, wenn sie die teamspezifischen Kriterien oben erfüllen.

Eskalationsprozess — Schritt für Schritt

1. Identifizieren — Stelle fest, ob der Fall die Eskalationskriterien erfüllt (nutze die teamspezifischen Auslöser oben).

2. Schweregrad einstufen — Vergib SEV 1–4 anhand der Matrix. SEV 1 löst immer eine sofortige Eskalation aus.

3. Routen — Wähle das richtige Team (Product / Engineering / Legal / Security / CS). Treffen mehrere Teams zu, eskaliere zuerst an das Team mit dem höchsten Risiko (Security > Legal > Engineering > Product > CS).

4. Dokumentieren — Bereite das Handoff-Paket vor: Ticket-ID, vollständiger Kontext, die je Team erforderlichen Datenpunkte (siehe Anforderungen an den Handoff oben).

5. Benachrichtigen — Informiere das Eskalationsteam über den vorgesehenen Kanal (internes Ticket, Slack-Channel oder Incident-Tool). Bei SEV 1: direkt anrufen oder pagen — verlass dich nicht auf asynchrone Tools.

6. Kommunizieren — Informiere den Kunden, dass sein Fall eskaliert wurde, und setze eine realistische Erwartung für den nächsten Kontakt. Versprich keine unrealistischen Zeitpläne.

7. Nachverfolgen — Bleibe primärer Ansprechpartner für den Kunden, bis das Eskalationsteam die Verantwortung übernimmt. Hake nach, wenn innerhalb des Reaktionsziels keine Bestätigung eingeht.

Multi-Team-Eskalation

Wenn ein Fall mehrere Eskalationsziele betrifft, gilt diese Prioritätsreihenfolge:

Security → Legal → Engineering → Product → Customer Success

Eskaliere zuerst an das zutreffende Team mit der höchsten Priorität. Briefe das sekundäre Team parallel und verweise dabei auf das primäre Eskalationsticket. Lege keine doppelten Eskalationspfade an — ein Ticket, ein Owner, Stakeholder in Kopie.

Kommunikationsregeln während der Eskalation

• Bestätige dem Kunden innerhalb von 30 Minuten den Eingang eines SEV-1- oder SEV-2-Falls, auch wenn noch keine Lösung vorliegt.

• Spekuliere nie in kundengerichteten Nachrichten über Ursachen, Fix-Zeitpläne oder Haftung, solange die Eskalation läuft.

• Rechtsfälle: Sende nach einer Eskalation an Legal keine Kundenantwort, bis Legal die Formulierung freigegeben hat.

• Sicherheitsfälle: Bestätige oder dementiere gegenüber dem Kunden keine Datenschutzverletzung, bevor Security die Erstbewertung abgeschlossen hat.

• Halte den Kunden auf dem Laufenden in vereinbarten Intervallen (z. B. alle 4 Stunden bei SEV 1, jeden Werktag bei SEV 2) — auch wenn die Nachricht nur lautet, dass die Untersuchung läuft.

Output Format — Eskalations-Handoff

Nutze beim Verfassen eines Eskalations-Handoffs diese Struktur:

ESKALATIONS-HANDOFF

Ticket-ID: [ID]
Datum/Uhrzeit: [Zeitstempel mit Zeitzone]
Eskalierende Person: [Name / Team]
Eskalationsziel: [Product / Engineering / Legal / Security / Customer Success]
Schweregrad: [SEV 1 / SEV 2 / SEV 3 / SEV 4]

KUNDENKONTEXT
Account: [Name, Tier, Vertragswert falls bekannt]
Kontakt: [Name, Rolle, E-Mail]
Renewal- / Health-Risiko: [Ja / Nein / Unbekannt]

PROBLEMZUSAMMENFASSUNG
[2–4 Sätze zum Problem, seinem Umfang und seiner Auswirkung auf den Kunden]

BISHERIGE SCHRITTE
[Stichpunktliste bereits durchgeführter Troubleshooting-Schritte oder Antworten]

NACHWEISE / ANHÄNGE
[Fehlerlogs, Screenshots, Zeitstempel, API-Traces — oder "keine vorhanden"]

GEFORDERTE MASSNAHME
[Konkrete Bitte: untersuchen, Workaround liefern, Rechtsforderung prüfen, Security-Bewertung durchführen usw.]

GESETZTE KUNDENERWARTUNG
[Was dem Kunden wann kommuniziert wurde]

Guardrails

• Schließe ein Ticket nie als „gelöst" ab, wenn das zugrunde liegende Problem nur eskaliert und nicht behoben wurde.

• Sage nie einen Fix-Zeitpunkt, eine Rückerstattung oder eine Kompensation zu, ohne ausdrückliche Freigabe des zuständigen Teams.

• Teile interne Eskalationsdetails, Teamnamen oder den Incident-Status nie mit dem Kunden, sofern nicht ausdrücklich freigegeben.

• Verzögere eine Security-Eskalation nie, um mehr Informationen zu sammeln — eskaliere sofort und sammle parallel.

• Lass dir den Eingang des Handoffs immer vom Eskalationsteam bestätigen. Bleibt die Bestätigung innerhalb des Reaktionsziels aus, hake proaktiv nach.