Ein Supportmodell ist das strukturierte Framework, das definiert, wie Support-Anfragen, Störungen und Incidents eines IT-Systems oder Dienstleisters empfangen, kategorisiert, bearbeitet und eskaliert werden. Es legt fest, welche Stufen des Supports es gibt (Level 1, 2, 3), wer welche Anfragen bearbeitet, welche Reaktions- und Lösungszeiten gelten und nach welchen Kriterien eine Anfrage an die nächste Ebene weitergegeben wird. Ein klar definiertes Supportmodell ist die operative Grundlage für SLA-Einhaltung und Kundenzufriedenheit.
Ohne explizites Supportmodell entsteht ein reaktives Chaos: Jeder kümmert sich irgendwie um alles, Priorisierung fehlt, Spezialisten werden für triviale Anfragen blockiert, und kritische Incidents versanden in der falschen Ebene. Das Supportmodell strukturiert den Informations- und Eskalationsfluss so, dass die richtige Kompetenz zum richtigen Zeitpunkt an der richtigen Stelle ist.
Drei-Stufen-Supportmodell im Überblick
Level 1 First-Level-Support – Erster Ansprechpartner: Entgegennahme, Kategorisierung und Lösung einfacher Anfragen anhand von Playbooks und Wissensdatenbank. Reaktionszeit Minuten bis 2 Stunden. Löst 60–70 % aller Anfragen selbständig.
Level 2 Second-Level-Support – Technische Analyse: Tiefergehende Diagnose und Behebung komplexer Incidents. Direkte System-Zugänge, Analyse von Logs und Konfigurationen. Löst 25–35 % der Anfragen. Reaktionszeit Stunden bis 1 Tag.
Level 3 Third-Level-Support – Spezialistenwissen: Core-Engineers, Architekten oder Hersteller-Support für Root-Cause-Analyse und strukturelle Lösungen. Löst 5–10 % der Anfragen. Reaktionszeit Stunden bis Tage je nach Kritikalität.
Supportmodell richtig gestalten
- Klare Eskalationskriterien: Wann wird eine Anfrage von L1 zu L2 eskaliert? Nicht „wenn L1 nicht weiterkommt“ (zu vage), sondern messbar: nach 30 Minuten ohne Lösung, wenn Systeme nicht erreichbar sind, wenn ein definierter Kritikalitätsschwellenwert überschritten wird
- Ticketsystem als einziger Eingang: Alle Anfragen laufen über ein Ticketsystem – keine parallelen E-Mail-, Telefon- oder Chat-Kanäle ohne Ticket-Anbindung. Nur so bleibt der Status jeder Anfrage nachvollziehbar
- First-Time-Resolution-Rate tracken: Welcher Anteil der Anfragen wird vom First-Level gelöst, ohne Eskalation? Niedriger Wert deutet auf mangelnde Wissensdatenbank oder Skillprobleme im L1 hin
- Regelmäßige Modellüberprüfung: Was waren die häufigsten Eskalationsgründe im letzten Quartal? Können häufige L2-Anfragen durch bessere L1-Playbooks auf L1 verlagert werden?
Praxisbeispiel
Ein Automationsdienstleister definiert sein Supportmodell für 12 Kundensysteme. Eingang: Ticketsystem (Jira Service Management), Slack-Kanal für kritische Alerts (werden automatisch in Tickets umgewandelt). L1 (Operations Engineers, 8–18 Uhr): Entgegennahme, Kategorisierung, Lösung nach Playbook, Neustart von Services, Statusseite aktualisieren. SLA: Reaktion 15 Minuten, Erstantwort an Kunden 30 Minuten. L2 (Senior Engineer, On-Call 24/7): Escalation bei Ausfall über 15 Minuten oder Datenqualitätsproblem. Log-Analyse, Konfigurationsänderungen, AWS-Konsole. L3 (Externer AWS-Support + Plattform-Vendor): Infrastruktur-Probleme, Bugs in der Automatisierungsplattform selbst. Ergebnis nach 6 Monaten: 71 Prozent aller Tickets durch L1 gelöst, durchschnittliche Erstantwort 8 Minuten, kein SLA-Breach bei kritischen Incidents.
