Wann beginnt die Wartezeit für den Kunden wirklich?

SLA-Zähler wirken präzise, aber sie erzählen nicht automatisch die Kundengeschichte. Im Support beginnt Wartezeit oft schon, bevor ein Ticket korrekt klassifiziert ist, bevor die richtige Gruppe übernimmt oder bevor der Kunde überhaupt merkt, ob seine Meldung ernst genommen wird.

Ein Service Level Agreement, kurz SLA, beschreibt vereinbarte Leistungen und Reaktionszeiten zwischen Anbieter und Kunde. In ITSM-Teams wird daraus häufig ein messbarer Zähler im Ticketsystem. Das ist sinnvoll, weil Betrieb und Support sonst nicht vergleichen können, ob Zusagen eingehalten werden. Gefährlich wird es aber, wenn die Messlogik die echte Kundenerfahrung verdeckt.

Für ITSM-Generalisten ist die Kernfrage deshalb nicht nur, ob eine SLA-Frist formal eingehalten wurde. Wichtiger ist, wann aus Kundensicht die Wartezeit beginnt, welche Erwartung dadurch entsteht und an welcher Stelle der Betrieb reagieren muss. Ein Ticket kann im Tool noch grün sein, während der Kunde längst nachhakt, intern eskaliert oder den Dienst als unzuverlässig erlebt.

Die Uhr im Tool ist nicht die einzige Uhr

Atlassian unterscheidet in seiner Einordnung zwischen SLA, SLO und SLI. Vereinfacht gesagt beschreibt das SLA die Zusage, das SLO ein internes Ziel und das SLI die Messgröße. Diese Unterscheidung hilft, weil nicht jede interne Kennzahl automatisch die gleiche Bedeutung für Kunden hat. Wer nur auf die formale SLA-Uhr schaut, übersieht leicht, dass ein Kunde andere Startpunkte wahrnimmt.

Ein Beispiel ist der Eingangskanal. Eine Meldung kommt per Portal, E-Mail, Telefonnotiz oder Monitoring-Alarm an. Das Ticketsystem startet den Zähler vielleicht erst nach Erfassung, Kategorisierung oder Priorisierung. Der Kunde zählt aber ab dem Moment, in dem er Hilfe erwartet. Zwischen diesen beiden Momenten kann eine Lücke entstehen, die in keiner roten SLA-Anzeige sichtbar wird.

Priorisierung darf die Wartezeit nicht verschleiern

SLA-Regeln hängen oft an Prioritäten. Ein kritischer Ausfall läuft schneller als eine Standardanfrage. Das ist fachlich richtig. Trotzdem kann Priorisierung zum Problem werden, wenn die Einstufung zu spät oder zu defensiv passiert. Dann wirkt die Frist eingehalten, obwohl der Kunde zu lange auf eine belastbare Rückmeldung wartet.

IBM beschreibt Service Level Agreements als Vereinbarungen, die Leistung, Messgrößen und Verantwortlichkeiten zwischen Anbieter und Kunde festlegen. Genau hier liegt der praktische Hebel. Die Priorität darf nicht nur ein Feld sein, das irgendwann nachgezogen wird. Sie muss früh genug geprüft werden, damit die richtige Uhr startet, die passende Eskalation greift und der Kunde eine klare Erwartung bekommt.

Eine erste Antwort ist noch keine Servicezusage

Viele Teams messen erste Reaktionszeit. Der Begriff ist nützlich, aber er kann täuschen, wenn die erste Antwort nur eine automatische Eingangsbestätigung ist. Für den Kunden zählt nicht, ob ein System geantwortet hat. Er will wissen, ob jemand das Problem verstanden hat, welche nächste Handlung folgt und wann er wieder etwas hört.

Deshalb sollte ein SLA nicht nur die erste technische Reaktion kennen, sondern auch die erste belastbare Servicezusage. Das kann eine qualifizierte Rückfrage sein, eine bestätigte Zuständigkeit, eine erste Einschätzung oder ein konkreter nächster Kontaktzeitpunkt. Ohne diese Qualität bleibt die Zahl sauber, aber die Kommunikation schwach.

Übergaben sind kritische Wartezonen

Frische ITSM-Prozesse verlieren Zeit häufig nicht im ersten Ticket, sondern beim Wechsel der Zuständigkeit. Der Service Desk nimmt auf, eine Fachgruppe prüft, ein Provider wird eingebunden, danach landet die Rückfrage wieder im Support. In jedem Übergang kann die Uhr technisch weiterlaufen oder neu bewertet werden. Für den Kunden bleibt es aber dieselbe Wartezeit.

Freshservice stellt Service Level Management als laufende Steuerung von Vereinbarungen, Fristen und Eskalationen dar. Für den Alltag bedeutet das, Übergaben ausdrücklich in die SLA-Logik aufzunehmen. Wer übernimmt? Welche Information muss mitgehen? Wann wird der Kunde informiert? Welche Eskalation startet, wenn eine Gruppe nicht reagiert? Ohne diese Fragen entstehen stille Wartezonen, die später schwer zu erklären sind.

Der bessere Startpunkt entsteht aus Kundensicht

Ein praxistauglicher SLA-Check beginnt mit drei Momenten. Erstens der Zeitpunkt, an dem der Kunde Hilfe erwartet. Zweitens der Zeitpunkt, an dem das Ticket im Tool messbar wird. Drittens der Zeitpunkt, an dem eine qualifizierte Servicezusage erfolgt. Wenn diese drei Momente weit auseinanderliegen, ist das ein Warnsignal, auch wenn die formale SLA noch nicht verletzt wurde.

Das lässt sich ohne großes Projekt prüfen. ITSM-Teams können zehn aktuelle Tickets aus unterschiedlichen Kanälen nehmen und die Zeitlinie nachzeichnen. Wann kam die Meldung an? Wann wurde sie klassifiziert? Wann war die zuständige Rolle klar? Wann erhielt der Kunde mehr als eine Eingangsbestätigung? Wo wurde gewartet, ohne dass es sichtbar war?

Eine gute SLA-Regel schützt Vertrauen

Die ITIL-Praxis Service Level Management dreht sich nicht nur um Messwerte, sondern um erreichbare und verstandene Serviceziele. Ein SLA ist daher kein Selbstzweck. Er soll helfen, Erwartungen zu klären, Leistung sichtbar zu machen und rechtzeitig zu handeln, bevor Vertrauen verloren geht.

Genau deshalb braucht die Wartezeit einen Startpunkt, den Betrieb und Kunde gemeinsam nachvollziehen können. Wenn die Uhr erst läuft, nachdem interne Sortierung fertig ist, misst sie nur den bequemeren Teil des Prozesses. Wenn sie dagegen Eingang, Priorisierung, Zuständigkeit und erste Servicezusage verbindet, wird aus der SLA-Zahl ein Steuerungsinstrument für echte Kundenerfahrung.

Quellen und Einordnung: Atlassian zu SLA, SLO und SLI, IBM zu Service Level Agreements, Freshworks Freshservice zu Service Level Management, AXELOS ITIL 4 Service Level Management Practice. Stand der Quellenprüfung: 19.07.2026. Bildquelle: Pexels, Foto-ID 1178683, C00 Lizenz.