SAP eskalieren Schritt für Schritt: Vom Service-Ticket bis Executive Escalation
SAP kennt formale Eskalationspfade, die außerhalb des regulären Support-Kanals liegen. Wer sie kennt, strukturiert nutzt und konsequent dokumentiert, kommt schneller zu Lösungen und schafft gleichzeitig eine verlässliche Steuerungshistorie, die in späteren Vertragsverhandlungen Gewicht hat.
Dieser Artikel beschreibt den fünfstufigen Eskalationspfad von SAP, die Voraussetzungen für jeden Schritt, was bei jeder Stufe dokumentiert werden sollte und wie häufige Fehler im Prozess vermieden werden.
Der Ausgangspunkt: Wann ist Eskalation der richtige Schritt?
Eine Eskalation bei SAP ist dann der richtige Schritt, wenn das reguläre Incident-Management eine Situation nicht innerhalb eines vertretbaren Zeitrahmens auflöst und die Auswirkungen auf den Betrieb, die Planung oder die Vertragsbeziehung zunehmen.
Das können operative Situationen sein: ein Systemausfall, der die definierte SLA überschreitet; eine Supportanfrage, die über Wochen ohne substanziellen Fortschritt offen bleibt; eine Rechnungsposition, die sich nicht klären lässt. Es können auch strategische Situationen sein: ein Renewal-Prozess, der sich durch ausbleibende Rückmeldungen verzögert; eine Vertragsinterpretation, die SAP und Kunde unterschiedlich lesen.
Eskalation ist kein Zeichen einer gescheiterten Beziehung. Sie ist ein normales Instrument der Vendor-Steuerung. Die meisten SAP-Vertragsbeziehungen über mehrere Jahre enthalten mindestens einzelne Eskalationssituationen. Wer den Pfad kennt, nutzt ihn ruhig und strukturiert.
Stufe 1: Standard-Incident und Priority-Hochstufung
Der Ausgangspunkt jeder Eskalation ist ein korrekt klassifizierter Incident im SAP One Support Portal. Die Prioritätsstufen reichen von P1 (Very High, Produktivbetrieb steht still) bis P4 (Low, keine geschäftliche Auswirkung).
Was in dieser Stufe gilt:
Wenn ein Incident eine höhere Auswirkung hat, als die ursprüngliche Klassifizierung abbildet, ist die erste Maßnahme die formale Hochstufung der Priorität. Eine P2- oder P3-Anfrage, die sich über mehrere Tage ohne Lösung hinzieht, kann und sollte auf P1 hochgestuft werden, wenn die tatsächliche Betriebsauswirkung das rechtfertigt.
P1-Incidents erfordern bei SAP eine Reaktionszeit von einer Stunde und eine Erstverfügbarkeit rund um die Uhr. Die genauen SLA-Parameter sind im jeweiligen Support-Vertrag (z.B. Enterprise Support, Preferred Success) festgelegt. Diese Parameter sollten bekannt sein, bevor eine Eskalation gestartet wird.
Was dokumentiert werden sollte:
Incident-Nummer, Eröffnungsdatum, ursprüngliche Priorität, Datum der Hochstufung, konkrete Auswirkungsbeschreibung auf den Betrieb, bisherige Antworten von SAP und deren Inhalte. Diese Dokumentation ist die Grundlage für alle weiteren Eskalationsstufen.
Häufiger Fehler: Incidents werden zu breit oder zu technisch formuliert. Wer die Geschäftsauswirkung nicht klar benennt (welcher Prozess steht still, welche Transaktionen sind betroffen, seit wann), läuft Gefahr, dass der Incident nicht mit der richtigen Dringlichkeit behandelt wird.
Stufe 2: CSM und TAM formal einbinden
Wenn ein Incident trotz korrekter Priorität und ausreichend Zeit keinen substanziellen Fortschritt zeigt, ist der nächste Steuerungsmoment die formale Einbindung des Customer Success Managers (CSM) und, bei technischen Infrastrukturthemen, des Technical Account Managers (TAM).
Was in dieser Stufe gilt:
CSM und TAM sind keine Support-Ressourcen, die Incidents lösen. Sie sind Koordinations- und Eskalations-Enabler innerhalb SAPs interner Struktur. Der CSM kann den Incident intern sichtbar machen und die Priorisierung beeinflussen. Der TAM hat direkten Zugang zu den technischen Teams und kann Statusklarheit herstellen, die über das Support-Portal nicht erreichbar ist.
Die Einbindung von CSM und TAM erfolgt schriftlich, mit Verweis auf Incident-Nummer, Dauer, Priorität und konkreter Beschreibung der fehlenden Lösung. Eine mündliche Erwähnung am Rande eines regulären Status-Calls genügt nicht. Die Anfrage sollte als formale Eskalationsmitteilung formuliert sein.
Was dokumentiert werden sollte:
Datum und Inhalt der Kontaktaufnahme mit CSM/TAM, deren Rückmeldungen, versprochene Maßnahmen und deren Zeitrahmen, Folgetermine. Wenn CSM oder TAM eine Eskalations-Timeline zusagen, wird diese schriftlich festgehalten.
Steuerungsmoment: Hier zeigt sich, wie verlässlich SAP auf informell-kollegiale Eskalationsanlässe reagiert. Diese Information ist für die spätere Einschätzung der Vendor-Beziehung relevant.
Stufe 3: AE-Eskalation mit schriftlicher Problemdokumentation
Wenn die Einbindung von CSM und TAM keine Lösung bewirkt oder das Problem über die technische Ebene hinausgeht (z.B. vertragliche Unklarheiten, Rechnungsstreitigkeiten, Renewal-Verzögerungen), ist der Account Executive (AE) die nächste Eskalationsinstanz.
Was in dieser Stufe gilt:
Der AE ist der primäre kommerzielle Ansprechpartner. Er trägt Umsatzverantwortung für die Kundenbeziehung und hat damit ein strukturelles Interesse daran, offene Problemsituationen aufzulösen. Gleichzeitig agiert er innerhalb seiner eigenen Organisation, was bedeutet, dass er nicht alle Probleme direkt lösen kann, aber Einfluss auf interne Priorisierung hat.
Die Eskalation an den AE erfolgt schriftlich. Eine E-Mail, die folgendes enthält: Betreff mit Eskalationskennzeichnung, Kurzfassung der Situation in drei bis fünf Sätzen, Chronologie der bisherigen Schritte (Incident-Nr., Kontakte, Zusagen), konkrete Erwartung an den AE (Lösung bis wann, Rückmeldung bis wann). Diese E-Mail ist kein Beschwerdeschreiben. Sie ist eine sachliche Statusmitteilung mit klar formulierter Erwartungshaltung.
Was dokumentiert werden sollte:
Die gesendete E-Mail inklusive Zeitstempel, die Antwort des AE, jede Folgekommunikation, Zusagen und ihre Erfüllung oder Nichterfüllung. Diese Dokumentation ist der Kern der Eskalationshistorie.
Häufiger Fehler: Die AE-Eskalation wird mündlich am Telefon durchgeführt und nicht schriftlich nachgefasst. Mündliche Zusagen sind schwer zu belegen. Die schriftliche Nachfassung nach jedem Gespräch ("zur Bestätigung unseres Gesprächs vom...") ist deshalb ein fester Bestandteil des Eskalationsprozesses.
Stufe 4: Eskalation über SAP Executive Sponsor
Wenn die AE-Eskalation keine Lösung bringt oder das Problem eine strategische Dimension hat, die über die Handlungsmöglichkeiten des AE hinausgeht, kommt der SAP Executive Sponsor ins Spiel.
Was in dieser Stufe gilt:
Viele SAP-Vertragsbeziehungen ab einer bestimmten Größenordnung sehen einen Executive Sponsor auf Seiten von SAP vor. Dieser kann ein VP, ein Regional Director oder ein anderer Senior Manager sein, der die Beziehung auf strategischer Ebene trägt. In welcher Funktion und unter welchem Namen ein solcher Ansprechpartner besteht, ist im jeweiligen Vertrag oder in der Kontostrategie verankert, oder lässt sich über den AE erfragen.
Die Einbindung des Executive Sponsors ist eine Eskalation der Beziehungsebene, nicht nur des Inhalts. Sie signalisiert, dass die Situation eine Entscheidungshoheit erfordert, die über die operative Ebene des AE hinausgeht. Das kann bei Situationen relevant sein, in denen ein AE zwar Verständnis signalisiert, aber nicht über die organisatorische Entscheidungsmacht verfügt, eine Lösung herbeizuführen.
Die Kommunikation auf dieser Ebene erfolgt formal und verdichtet: Eine einseitige Zusammenfassung der Situation, der bisherigen Schritte, der ausgebliebenen Lösung und der konkreten Erwartung. Kein ausführlicher Chronologiebericht. Die Executive-Ebene entscheidet auf Basis der Zusammenfassung, nicht des Detailprotokolls.
Was dokumentiert werden sollte:
Datum und Form der Kontaktaufnahme, Inhalt der Kurzdarstellung, Rückmeldung des Executive Sponsors, folgende Maßnahmen und deren Ergebnisse.
Steuerungsmoment: Eine Eskalation, die bis auf die Executive-Sponsor-Ebene eskaliert wird und dort gelöst wird, liefert eine wichtige Einschätzung der Bereitschaft von SAP, außerhalb der Standardprozesse zu handeln. Diese Einschätzung fließt in die Renewal-Vorbereitung ein.
Stufe 5: Executive Escalation auf C-Level (SAP CxO)
Die höchste Eskalationsstufe ist die Executive Escalation auf C-Level, also auf Ebene von SAP-Führungskräften mit globaler oder regionaler Verantwortung.
Wann diese Stufe angemessen ist:
Diese Stufe ist für Situationen reserviert, in denen das Problem eine Grundsatzdimension hat: eine fundamentale Vertragsverletzung durch SAP, eine systemische SLA-Verfehlung, die über einen langen Zeitraum anhält und auf den Stufen darunter nicht aufgelöst wurde, oder eine strategische Richtungsentscheidung (z.B. bei RISE-Migrationen), die von SAP-Seite nicht getroffen wird.
C-Level-Eskalationen sind selten. Wer sie ohne ausreichende Vorbereitung und Dokumentation der vorangegangenen Stufen initiiert, riskiert, dass sie nicht die gewünschte Wirkung entfalten.
Was in dieser Stufe gilt:
Voraussetzung ist eine vollständige Dokumentation aller vorangegangenen Stufen. Ohne belegbaren Nachweis, dass Stufen 1 bis 4 durchlaufen wurden und zu keiner Lösung geführt haben, hat eine C-Level-Eskalation keine belastbare Grundlage. Die Dokumentation wird zur Sachdarstellung verdichtet: ein strukturiertes Briefing, das Situation, Chronologie, ungelösten Kern und die konkrete Erwartung auf wenigen Seiten darstellt.
Die Kontaktaufnahme auf diesem Niveau erfolgt über den bestehenden Beziehungskanal (z.B. CEO-to-CEO, wenn die Kundengröße das rechtfertigt) oder über die SAP-interne Eskalationsstruktur, die auf Anfrage beim AE oder Executive Sponsor benannt werden kann.
Was dokumentiert werden sollte:
Alles wie in den vorherigen Stufen, plus das finale Briefing, den Kommunikationskanal, die Reaktion und das Ergebnis. Dieses vollständige Eskalationsprotokoll ist ein wertvolles Dokument für künftige Vertragsverhandlungen.
Was bei jeder Eskalationsstufe dokumentiert werden sollte
Unabhängig von der Stufe gilt ein einheitliches Dokumentationsminimum:
- Datum und Uhrzeit jedes Kontakts
- Name und Rolle der involvierten Personen auf Seiten von SAP
- Inhalt der Kommunikation (E-Mail-Versatz, Gesprächszusammenfassung per Nachfass-E-Mail)
- Konkrete Zusagen und deren Zeitrahmen
- Tatsächliche Erfüllung oder Nichterfüllung
- Eskalationsauslöser (was hat die Hochstufung ausgelöst)
Ein einfaches Eskalationsprotokoll in Tabellenform reicht dafür aus. Was zählt, ist Vollständigkeit und Belastbarkeit. Gut geführte Eskalationsprotokolle sind in Renewal-Verhandlungen verwertbar: Sie belegen, wo SAP Leistungen nicht erbracht hat, und stärken die Verhandlungsposition des Kunden.
Wie Eskalationshistorie als Steuerungsinstrument dient
Eskalationen sind nicht nur operative Ereignisse. Sie sind Indikatoren für die Qualität der Vendor-Beziehung und für die tatsächliche Leistungserbringung von SAP. Eine gut dokumentierte Eskalationshistorie liefert drei verwertbare Outputs:
Vertragsrelevanz: Wenn SAP SLA-Verpflichtungen wiederholt nicht erfüllt, ist das ein Vertragsthema, das in der Renewal-Vorbereitung adressiert werden kann. Ohne Dokumentation ist das schwer zu belegen. Mit Dokumentation ist es eine belegbare Grundlage.
Beziehungseinschätzung: Die Art und Geschwindigkeit, mit der SAP auf Eskalationen reagiert, sagt etwas über die tatsächliche Servicequalität und die Verlässlichkeit als Vendor aus. Diese Einschätzung fließt in die strategische Bewertung der SAP-Beziehung ein.
Interne Legitimation: Für interne Stakeholder, die den Wert aktiver Vendor-Steuerung hinterfragen, ist eine dokumentierte Eskalationshistorie ein handfester Beleg dafür, dass strukturierte Steuerung konkrete Ergebnisse erzeugt.
Häufige Fehler im Eskalationsprozess
Mündliche Eskalation ohne schriftliche Spur: Die häufigste Schwachstelle im Eskalationsprozess. Telefonische Eskalationen sind wirksam, wenn sie schriftlich nachgefasst werden. Ohne Nachfassung existiert die Eskalation für die Dokumentation nicht.
Fehlende Geschäftsauswirkung: Technische Problembeschreibungen ohne Verknüpfung zur geschäftlichen Auswirkung werden langsamer priorisiert. Die Beschreibung "welcher Prozess ist betroffen, welches Volumen, seit wann" gehört in jeden Eskalationstext.
Zu frühe Executive-Eskalation: Wer Stufen überspringt und direkt auf Executive-Level eskaliert, ohne die unteren Stufen nachweislich durchlaufen zu haben, schwächt die eigene Position. SAP wird fragen, warum der normale Prozess nicht genutzt wurde.
Kein eigener Eskalations-Tracker: Unternehmen, die Eskalationen ad hoc in E-Mail-Postfächern verwalten, verlieren Überblick und Kontinuität. Ein zentrales Eskalationsprotokoll, das unabhängig von Personalwechseln gepflegt wird, ist Teil einer funktionsfähigen SAP-Governance.
Eskalation als Beziehungsrisiko betrachtet: Eskalation wird manchmal vermieden, weil die Beziehung zum AE nicht belastet werden soll. Ein strukturierter, sachlicher Eskalationsprozess belastet die Beziehung nicht. Er ist ein normales Governance-Instrument und wird von professionellen SAP-Teams als solches wahrgenommen.
Nächste Schritte
Wie ist Ihre SAP-Governance für Eskalationssituationen aufgestellt? Wissen alle relevanten Rollen, welche Stufen der Eskalationspfad kennt, und wo die Dokumentation geführt wird?
Ein Vertragscheck schafft Klarheit darüber, welche Governance-Strukturen bereits belastbar sind und wo strukturelle Lücken bestehen. Erstgespräch vereinbaren.
Weiterführend: SAP-Account-Management verstehen: Rollen, Anreize und was das für Sie bedeutet und der Hub: SAP als strategischen Vendor managen.
Nächste Schritte
Möchten Sie Ihre SAP-Vendor-Governance auf Lücken und Steuerungsmomente prüfen lassen?
Dieser Beitrag gehört zum Themen-Hub SAP als strategischen Vendor managen. Für die Bewertung eines konkreten Vertrags liefert der FinOptory Vertragscheck in vier Wochen eine strukturierte Grundlage.
Zuletzt aktualisiert: Juli 2026