Zuletzt aktualisiert am

Incident Reopen Rate

Definition

Der Prozentsatz der gelösten Incidents, die wieder geöffnet werden, weil der Fix unvollständig war. Das ITIL-Pendant zur Reopen Rate.

Formel

Wiedereröffnete Incidents
Gelöste Incidents
×100

Auch bekannt als

Wiedereröffnungsrate, Ticket Reopen Rate, Reopen Ratio

Kategorie

ITSM & Incident Management

Incident Reopen Rate Rechner

Ergebnis

Gib beide Werte ein, um Deine Incident Reopen Rate zu berechnen.

Was ist die Incident Reopen Rate?

Die Incident Reopen Rate (deutsch: Wiedereröffnungsrate) misst den Prozentsatz der gelösten Incidents, die nach der Schließung erneut geöffnet werden. Im ITIL-Kontext ist sie ein zentraler Qualitätsindikator für das Incident Management: Eine hohe Rate deutet auf voreilige Schließungen, Fehldiagnosen oder unvollständige Lösungen hin.

Die Metrik unterscheidet sich von der allgemeinen Reopen Rate durch ihren Fokus auf IT-Incidents nach ITIL-Definition. Während die Reopen Rate im Kundenservice alle Tickettypen umfasst (Anfragen, Beschwerden, Service Requests), bezieht sich die Incident Reopen Rate spezifisch auf Störungen und ungeplante Unterbrechungen von IT-Services.

Jede Wiedereröffnung ist doppelte Arbeit: Der Incident durchläuft erneut Diagnose, Bearbeitung und Lösung. Für den betroffenen Nutzer bedeutet das verlängerte Ausfallzeiten und Produktivitätsverlust. Laut ManageEngine ist die Reopen Rate eine der wichtigsten ITIL-Metriken, weil sie die tatsächliche Lösungsqualität misst, nicht nur die Bearbeitungsgeschwindigkeit (ManageEngine).

Arten der Wiedereröffnung

Nutzerseitige Wiedereröffnung erfolgt, wenn der Nutzer meldet, dass das Problem trotz Schließung weiterhin besteht. Das ist der häufigste Fall und deutet auf eine unvollständige Lösung hin.

Automatische Wiedereröffnung wird durch Monitoring-Systeme ausgelöst, wenn ein geschlossener Incident erneut auftritt (z. B. derselbe Alarm innerhalb von 24 Stunden). Das signalisiert, dass die Ursache nicht behoben wurde.

Agentenseitige Wiedereröffnung erfolgt, wenn ein Techniker erkennt, dass der Incident voreilig geschlossen wurde oder die dokumentierte Lösung nicht korrekt ist.

Wie berechnet man die Incident Reopen Rate?

Formel
Incident Reopen Rate = (Wiedereröffnete Incidents ÷ Gelöste Incidents) × 100

Rechenbeispiel

Ein IT Service Desk löst in einem Monat 500 Incidents. Davon werden 25 innerhalb von 5 Tagen nach Schließung wieder geöffnet.

Berechnung
IRR = (25 ÷ 500) × 100
Ergebnis
5,0 %

Mit 5,0 % liegt der Service Desk an der oberen Grenze des guten Bereichs. Ein Zielwert von unter 3 % wäre für einen reifen Service Desk erstrebenswert.

Was ist eine gute Incident Reopen Rate?

BewertungIncident Reopen RateEinordnung
Gut≤ 5 %Nachhaltige Lösungsqualität
Akzeptabel5–10 %Optimierungspotenzial vorhanden
Kritisch> 10 %Systematische Qualitätsprobleme

Laut KPI Library ist 5 % ein anerkanntes Ziel für Service Desks, wobei reife Organisationen Werte zwischen 2–4 % erreichen (KPI Library). Eine Rate über 20 % bedeutet, dass mehr als ein Fünftel der Kapazität für Nacharbeit aufgewendet wird.

Reifegrad des Service DeskTypische Reopen Rate
World-Class< 3 %
Reif3–5 %
Durchschnitt5–8 %
Unreif8–15 %

Quellen: KPI Library, ManageEngine, Atomicwork

Incident Reopen Rate senken

Lösungsdokumentation standardisieren. Vor der Schließung muss der Incident einen dokumentierten Lösungsweg enthalten: Was war das Problem? Was wurde getan? Wie kann der Nutzer prüfen, ob es gelöst ist? Lückenhafte Dokumentation ist ein Hauptgrund für Wiedereröffnungen.

Nutzerbestätigung vor Schließung einholen. Den Incident erst schließen, wenn der Nutzer bestätigt, dass das Problem behoben ist. Automatische Schließung nach X Tagen ohne Rückmeldung ist riskant und treibt die Reopen Rate hoch.

Root Cause Analysis für wiedereröffnete Incidents. Jeden wiedereröffneten Incident analysieren: War die Diagnose falsch? War der Fix unvollständig? War es ein neues, verwandtes Problem? Die Ergebnisse in die Knowledge Base einfließen lassen.

Known Error Database (KEDB) pflegen. Bekannte Fehler und bewährte Workarounds dokumentieren. Wenn Techniker auf erprobte Lösungen zugreifen können, sinkt das Risiko von Fehldiagnosen.

Qualitätsprüfung vor Schließung. Bei kritischen Incidents (Priority 1–2) eine Peer-Review der Lösung einführen, bevor der Incident geschlossen wird.

Incident Reopen Rate vs. Reopen Rate vs. Problem Resolution Rate

MetrikWas sie misstKontextFokus
Incident Reopen RateWiedereröffnete IncidentsITIL / IT Service ManagementIncident-Lösungsqualität
Reopen RateWieder geöffnete Tickets (alle Typen)Kundenservice allgemeinGesamte Ticketqualität
Problem Resolution RateAnteil gelöster Problems (Ursachenanalyse)ITIL Problem ManagementUrsachenbeseitigung

Die Incident Reopen Rate und die allgemeine Reopen Rate überlappen sich, haben aber unterschiedliche Bezugsrahmen. Im ITIL-Kontext ist die Incident Reopen Rate granularer, weil sie zwischen Incidents (Störungen) und Service Requests (Anfragen) unterscheidet. Die Problem Resolution Rate ergänzt beide: Sie misst, ob die Ursache hinter wiederkehrenden Incidents tatsächlich behoben wird.

Pro und Kontra der Incident Reopen Rate

Pro

  • +Direkter Qualitätsindikator für die Lösungsnachhaltigkeit
  • +Deckt systematische Schwächen in Diagnose und Lösung auf
  • +Einfach zu berechnen und aus jedem ITSM-Tool exportierbar

Kontra

  • Unterscheidet nicht zwischen echtem Lösungsversagen und neuen, verwandten Problemen
  • Kann Techniker dazu verleiten, Incidents offen zu lassen statt zu schließen (Rate-Gaming)
  • Zeitfenster für Wiedereröffnung variiert zwischen Organisationen (3, 5, 7 Tage), was Vergleiche erschwert

Einfluss von KI auf die Incident Reopen Rate

KI senkt die Incident Reopen Rate durch bessere Diagnosen und vollständigere Lösungen. KI-gestützte Root-Cause-Analyse erkennt Muster in historischen Incident-Daten und schlägt die wahrscheinlichste Ursache vor, bevor der Techniker manuell suchen muss. Das reduziert Fehldiagnosen, die ein Hauptgrund für Wiedereröffnungen sind.

Automatische Validierung vor Schließung ist ein weiterer KI-Hebel: Das System prüft, ob der gemeldete Fehler tatsächlich behoben ist (z. B. durch automatisierte Tests oder Monitoring-Checks), und warnt den Techniker, wenn die Symptome weiterhin auftreten. Statt sich auf die Einschätzung des Technikers zu verlassen, liefert die KI eine objektive Prüfung.