1st, 2nd, 3rd Level Support
Wenn ein Anwender ein IT-Problem hat, soll er es nicht selbst rauskriegen müssen, ob er das Netzwerk-Team, den Datenbank-Spezialisten oder den Hersteller anrufen soll. Dafür gibt es den Multi-Level-Support: ein gestaffeltes Modell, in dem das Anliegen erst an einer einfachen Anlaufstelle (1st Level) ankommt, dort entweder gelöst wird oder an spezialisiertere Stellen (2nd, 3rd Level) weitergereicht wird. Das Modell ist effizient: einfache Fragen blockieren keine teuren Spezialisten, und spezialisierte Themen werden nicht von Generalisten halbgar bearbeitet. Diese Lektion zeigt die drei (manchmal vier) Levels, wer dort jeweils arbeitet, welche Kennzahlen wichtig sind und wann ein Ticket eskaliert wird – mit dem wichtigen Unterschied zwischen funktionaler und hierarchischer Eskalation, der gerne in Prüfungen gefragt wird.
1) Die Support-Pyramide
Stell dir eine Pyramide vor: viele Menschen an der Basis, wenige an der Spitze. Das 1st-Level-Team ist groß und nimmt alles entgegen, ein 2nd-Level-Team ist kleiner und löst Komplexeres, das 3rd-Level-Team ist klein und meist außerhalb der Firma. Klick die Stufen an, um die Aufgaben, typischen Bearbeitungszeiten und Tools zu sehen:
2) Wer macht was?
| Level | Wer | Was | Typische Tools |
|---|---|---|---|
| 1st | Service-Desk-Agents, oft Quereinsteiger oder Azubis | Annahme, Klassifizierung, Standard-Lösungen, Eskalation | Ticket-System, Knowledge Base, KEDB, Remote-Support |
| 2nd | Fach-Administratoren (Netzwerk, Server, AD, DB) | Diagnose, Spezialprobleme, Konfigurations-Änderungen | Monitoring, Wireshark, RDP/SSH, eigene Admin-Tools |
| 3rd | Hersteller-Support, Entwickler, externe Spezialisten | Bugs, Patches, Architektur-Beratung, RCA bei komplexen Vorfällen | Hersteller-Portal, Code-Zugriff, Spezial-Tools |
Manche Organisationen führen zusätzlich einen Level 0: Self-Service-Portal, Chatbots, FAQ-Suche. Ziel: Anwender löst das Problem ohne menschlichen Kontakt. Ein moderner Service Desk hat oft eine Level-0-Quote von 15-25 % – Tickets, die nie als Ticket entstehen, weil der Anwender selbst eine Antwort gefunden hat. Mehr in Service Desk.
3) Funktional vs. hierarchisch eskalieren
Sehr wichtiger ITIL-Begriff: nicht jede Eskalation geht „eine Stufe höher" im technischen Sinne. Es gibt zwei Eskalations-Typen, die unterschiedliche Zwecke haben:
↗ Funktionale Eskalation
Weitergabe an ein fachlich kompetenteres Team.
- 1st Level → 2nd Level → 3rd Level
- Auslöser: Wissen oder Berechtigungen fehlen
- Gehört in jeden normalen Ticket-Flow
- Bsp: „VPN-Problem, ich kann das nicht selbst lösen → an Netzwerk-Team"
↑ Hierarchische Eskalation
Weitergabe an einen Vorgesetzten oder Manager.
- Agent → Teamleiter → Manager → IT-Leitung
- Auslöser: Entscheidungs- oder Ressourcenbedarf
- Bei Konflikten, drohenden SLA-Brüchen, kritischen Incidents
- Bsp: „Großkunde droht zu kündigen → Geschäftsführung informieren"
Faustregel: funktional für mehr Technik-Wissen, hierarchisch für mehr Entscheidungs-Befugnis. Beide können parallel stattfinden – ein Major Incident wird gleichzeitig funktional (an Spezialisten) und hierarchisch (an Manager) eskaliert.
4) Ein Ticket wandert durch die Levels
5) Wichtige KPIs pro Level
| KPI | Bedeutung | Messpunkt |
|---|---|---|
| First Contact Resolution (FCR) | Anteil der Tickets, die im 1st Level beim ersten Kontakt gelöst werden | Ziel: 60-80 % |
| Eskalationsquote | Anteil, der weiter ans 2nd Level geht | typisch 20-40 % |
| Re-Eskalations-Rate | Tickets, die mehrfach zwischen Levels hin- und herwandern | sollte gering bleiben < 5 % |
| Mean Time to Resolution (MTTR) | Gesamtzeit Ticket-Eröffnung bis Lösung | aus SLA abgeleitet |
| Wartezeit pro Level | Wie lange liegt ein Ticket im 2nd Level bevor jemand drangeht? | SLA-relevant |
| Customer Satisfaction (CSAT) | Bewertung durch User nach Ticket-Abschluss | Ziel: > 4.2/5 |
6) Skill-Profile pro Level
Was sollte ein 1st-Level-Agent können? Was ein 2nd-Level-Spezialist? Die typische Erwartungs-Mischung:
- 1st Level: Breit, nicht tief. Kommunikation ist wichtiger als Technik – am Telefon ruhig bleiben, gezielt fragen, dokumentieren. Standard-Tools kennen (Active Directory, Office, Self-Service-Portal), grobe Netzwerk-Diagnose. Schnell schreiben. Geduld.
- 2nd Level: Tief in einem Bereich. Netzwerk, Linux/Windows, DB, Storage – jeder Spezialist hat sein Revier. Erfahrung mit dem Live-System, kennt die Eigenheiten. Kann Workarounds bauen, ohne den Hersteller-Support zu brauchen.
- 3rd Level: Code-Ebene. Beim Hersteller: Entwickler, die das Produkt geschrieben haben. Bei Eigenentwicklungen: das Dev-Team selbst. Auch interne Systematische-Fehlersuche-Experten oder Architekten.
Karriereweg in der Praxis: Azubi → 1st Level (1-2 Jahre) → 2nd Level (Spezialisierung) → 3rd Level oder Teamleitung. Der Sprung 1st→2nd ist der wichtigste Hebel; wer ihn schafft, kommt vom „Telefon-Helden" zum „Problem-Löser".
7) Anti-Patterns
- Eskalations-Ping-Pong. Tickets wandern mehrfach zwischen 1st und 2nd hin und her, weil die Verantwortung unklar ist. Lösung: klare Übernahme-Regeln, „der Bearbeiter ist verantwortlich, bis er aktiv übergibt".
- 1st Level als reines Telefon-Annahme-Team. Wenn 1st Level nichts selbst lösen darf/kann, wird daraus eine Sekretariats-Stelle. Lösung: Schulung, Berechtigungen, Knowledge Base.
- „Mein Problem direkt zum Spezialisten". Anwender umgehen den 1st Level („ich kenne den Maier persönlich"). Funktioniert kurzfristig, blockiert langfristig die Spezialisten. Lösung: alles geht durchs Ticket-System.
- 3rd Level als „Mülleimer". Tickets, mit denen niemand weiterweiß, landen pauschal beim Hersteller – auch wenn der Fehler im eigenen Setup liegt. Hersteller schickt zurück, Zeit verloren. Lösung: vor Eskalation prüfen, ob es wirklich Hersteller-Sache ist.
- Keine Wissens-Rückführung. 3rd Level löst, 2nd Level lernt nichts. Beim nächsten Mal wieder Eskalation. Lösung: Lessons Learned in KEDB und Knowledge Base.
Zusammenfassung
Multi-Level-Support staffelt Anwender-Anliegen über mehrere Eskalations-Stufen, um Effizienz und Spezialisierung zu kombinieren. 1st Level (Service Desk, Hotline) nimmt alles entgegen, löst Standard-Probleme selbst (Ziel 60-80 % First Contact Resolution), eskaliert den Rest. 2nd Level sind Fach-Administratoren mit tiefem Wissen in einem Bereich (Netzwerk, Server, DB). 3rd Level sind Hersteller-Support oder Entwickler. Optional Level 0: Self-Service vor menschlichem Kontakt. Funktionale Eskalation (mehr Wissen) vs. hierarchische Eskalation (mehr Befugnis) – beide können parallel laufen. KPIs: FCR, Eskalationsquote, MTTR, CSAT, Re-Eskalations-Rate. Antipatterns: Eskalations-Ping-Pong, 1st Level als reine Annahme, Anwender, die den Service Desk umgehen, 3rd Level als Mülleimer, fehlende Wissens-Rückführung.
Verwandte Lektionen: Incident Management · Ticket-Priorisierung · Service Desk · und mehrWeitere relevante LektionenProblem ManagementKEDBKnowledge BaseSLATicketsystemeSystematische FehlersucheChange Management