Trifft diese IT-Störung zuerst den Kunden oder nur das Dashboard?

Ein roter Alarm wirkt dringlich. Für den Service Desk ist er aber nur der Anfang einer Entscheidung. Entscheidend ist, ob eine IT-Störung zuerst echte Kundenarbeit, zugesagte Services oder kritische Geschäftsabläufe trifft.

Incident Management beschreibt den Umgang mit ungeplanten Unterbrechungen oder Qualitätsverlusten eines IT-Services. Für ITSM-Generalisten ist das kein reines Technikthema. Es geht darum, Störungen so einzuordnen, dass begrenzte Zeit dort wirkt, wo Nutzer, Kunden und vereinbarte Services am stärksten betroffen sind. Eine gute Priorität verbindet deshalb technische Signale mit Schaden, Reichweite, Dringlichkeit und klarer Verantwortung.

Ein Alarm zeigt Aktivität, aber noch keine Wirkung

Monitoring-Systeme melden CPU-Last, Antwortzeiten, fehlgeschlagene Jobs, volle Warteschlangen oder nicht erreichbare Komponenten. Diese Signale sind wichtig, weil sie früher sichtbar werden können als Beschwerden aus dem Fachbereich. Trotzdem verraten sie nicht automatisch, welcher Vorfall zuerst bearbeitet werden muss. Ein lauter Alarm kann eine interne Teststrecke betreffen. Eine scheinbar kleine Fehlermeldung kann dagegen verhindern, dass Kunden bestellen, sich anmelden oder einen Auftrag abschließen.

Die erste Frage im Service Desk sollte daher nicht lauten, welches System am lautesten meldet. Besser ist die Frage: Wer kann gerade nicht arbeiten, welcher Service ist betroffen und welche Zusage läuft dadurch aus dem Ruder? Erst aus dieser Verbindung entsteht eine Priorität, die mehr ist als eine technische Sortierung.

Schwere und Dringlichkeit dürfen nicht vermischt werden

Viele ITSM-Modelle trennen zwischen Auswirkung und Dringlichkeit. Die Auswirkung beschreibt, wie groß der Schaden ist: einzelne Nutzer, ein Team, ein Standort, ein kritischer Kundenprozess oder ein geschäftsrelevanter Service. Die Dringlichkeit beschreibt, wie schnell gehandelt werden muss, bevor der Schaden wächst. Beides zusammen ergibt eine belastbarere Priorität als ein Bauchgefühl im Ticket.

Diese Trennung schützt vor zwei typischen Fehlern. Erstens wird nicht jede sichtbare technische Störung automatisch zur höchsten Priorität. Zweitens verschwinden kleine, aber geschäftskritische Fälle nicht unter vielen Routinealarmen. Ein Fehler in einer wenig genutzten Schnittstelle kann niedrig bleiben. Derselbe Fehler kurz vor einem Abrechnungslauf, einer Bestellfrist oder einer Kundenkommunikation kann deutlich dringlicher werden.

Der Servicekontext gehört direkt ins Ticket

Eine Prioritätsentscheidung wird schwach, wenn das Ticket nur Symptome sammelt. Hilfreich sind wenige Pflichtfelder, die wirklich zur Entscheidung beitragen: betroffener Service, betroffene Nutzergruppe, sichtbarer Kundenschaden, geschäftlicher Zeitpunkt, mögliche Umgehungslösung, bekannte Abhängigkeiten und erwartete Eskalationsfrist. Diese Informationen müssen nicht perfekt sein. Sie müssen aber früh genug vorliegen, damit der Service Desk nicht nur nach technischer Lautstärke sortiert.

Gerade für Generalisten ist der Servicekatalog dabei wertvoll. Er übersetzt technische Komponenten in Leistungen, Verantwortliche und erwartete Wirkung. Wenn ein Datenbankalarm mit einem Service, einem Service Owner und einer Kundenfolge verbunden ist, entsteht eine andere Entscheidung als bei einem isolierten Systemnamen. Ohne diesen Kontext bleibt Priorisierung oft personenabhängig: Wer lauter ruft, gewinnt.

Priorität braucht eine sichtbare Begründung

Eine gute Priorität ist nicht nur ein Feld mit P1, P2 oder P3. Sie ist eine begründete Entscheidung. Im Ticket sollte kurz stehen, warum dieser Vorfall höher oder niedriger eingestuft wurde. Zum Beispiel: Kundenlogin für zahlende Nutzer teilweise gestört, keine stabile Umgehung, Umsatzprozess betroffen. Oder: interner Report verzögert, Tagesabschluss nicht gefährdet, Umgehung über Export möglich.

Diese Begründung hilft während der Störung und danach. Während der Störung können Führung, Fachbereich und Betrieb nachvollziehen, warum Ressourcen umgelenkt werden. Nach der Störung lässt sich prüfen, ob die Einstufung richtig war. So entsteht Lernen statt Schuldzuweisung. Wenn Prioritäten regelmäßig korrigiert werden müssen, ist das kein Scheitern. Es zeigt, dass die Organisation ihre Wirkungsdaten verbessert.

Der erste Kundenhinweis darf nicht zu spät kommen

Ein riskantes Muster entsteht, wenn der Service Desk erst durch Kundenbeschwerden versteht, wie groß die Störung wirklich ist. Dann ist die technische Erkennung zwar aktiv, aber die geschäftliche Einordnung fehlt. Besser ist ein kurzer Abgleich zwischen Monitoring, Tickets, Statusseite, Servicekatalog und Fachbereich. So lässt sich früher erkennen, ob ein technisches Symptom bereits Kundenschaden erzeugt oder kurz davor steht.

Das bedeutet nicht, dass jedes Incident-Team lange Abstimmungsrunden braucht. Es reicht oft eine klare Triage-Frage: Welche reale Nutzerhandlung ist gerade blockiert? Kann der Nutzer ausweichen? Wie viele kritische Serviceversprechen sind betroffen? Wer entscheidet über eine höhere Priorität, wenn neue Informationen eintreffen? Diese Fragen geben dem Service Desk eine praktische Brücke zwischen Techniksignal und Kundenwirkung.

Was ITSM-Verantwortliche jetzt prüfen sollten

Für bestehende Prozesse lohnt ein kurzer Prioritätscheck. Erstens: Sind Prioritätsstufen mit Auswirkung und Dringlichkeit beschrieben oder nur als Gefühl bekannt? Zweitens: Gibt es im Ticket ein Feld für Kundenschaden oder Servicewirkung? Drittens: Kann ein Alarm automatisch einem Service, einem Owner und einer Statuskommunikation zugeordnet werden? Viertens: Wird nach größeren Störungen geprüft, ob die Priorität im Verlauf angepasst werden musste?

Die wichtigste Verbesserung ist oft nicht ein neues Tool, sondern eine bessere Entscheidungsfrage. Ein Dashboard zeigt, dass etwas passiert. Der Service Desk muss klären, wen es trifft und welche Zusage gerade gefährdet ist. Wenn diese Antwort früh im Ticket steht, wird Priorisierung nachvollziehbarer, Kommunikation ehrlicher und die knappe Betriebszeit wirksamer eingesetzt.

Quellen und Einordnung: Atlassian zu Severity Levels im Incident Management, Atlassian zu Incident Response, IBM zur Einordnung von Incident Management. Stand der Quellenprüfung: 05.07.2026. Bildquelle: Pexels, Foto-ID 5699456.