Resolution Time Metrics: Wie Sie Auflösungszeiten richtig messen

Resolution Time Metrics messen, wie lange ein Ticket von der Öffnung bis zur endgültigen Lösung braucht, und damit im Kern die Qualität Ihres Supports als Ergebnis, nicht nur als Aktivität. Drei Messregeln entscheiden sofort über die Aussagekraft Ihrer Zahlen: Zählen Sie in Geschäftsstunden, pausieren Sie die Uhr bei Kundenrückmeldungen, und berichten Sie den Median neben dem Mittelwert. Wer diese drei Punkte ignoriert, vergleicht am Ende Äpfel mit Birnen und trifft Entscheidungen auf Basis verzerrter Werte.

---

Kurz gesagt:

• Wird in Kalenderstunden gerechnet, verzerren Wochenenden und Feiertage die Resolution Time, weshalb Geschäftsstunden als Maßstab meist sinnvoller sind.
• Das Stoppen der Zeit bei Kundenwarteschleifen automatisiert und die einheitliche Definition des Endpunkts sind essenziell für aussagekräftige Vergleichswerte.
• Der Median der Resolution Time gibt den typischen Ablauf genauer wieder, da extreme Einzelfälle den Durchschnitt stark beeinflussen können.
• Die Unterscheidung zwischen First Response Time, First Contact Resolution und Resolution Time ist entscheidend, um Support-Performance wirklich zu verbessern.
• Die Zusammenstellung klar segmentierter Zielwerte nach Kanal, Priorität und Tickettyp verhindert unrealistischen Druck und sorgt für realistische Service-Standards.

---

Was Average Resolution Time (ART) wirklich bedeutet

Average Resolution Time, oft auch Mean Time to Resolution (MTTR) oder Time to Resolution (TTR) genannt, misst die durchschnittliche Zeitspanne zwischen dem Öffnen eines Tickets und seiner endgültigen Schließung. Alle drei Begriffe beschreiben in der Praxis dasselbe Konzept, auch wenn manche Teams zwischen MTTR für technische Incidents und ART für allgemeine Support-Tickets unterscheiden. Wichtig ist weniger der Name als die genaue Definition der Uhr: Wann beginnt die Messung, und wann endet sie tatsächlich?

Der Startpunkt ist in der Regel eindeutig, nämlich der Moment, in dem ein Kunde ein Anliegen einreicht, egal ob per E-Mail, Chat oder Telefon. Der Endpunkt ist komplizierter. Manche Teams stoppen die Uhr, sobald ein Agent eine Lösung vorschlägt. Andere warten auf die Bestätigung des Kunden, dass das Problem tatsächlich behoben ist. Diese Entscheidung verändert die gemessenen Werte erheblich und sollte im gesamten Unternehmen einheitlich getroffen werden.

Der entscheidende Unterschied zu reinen Aktivitätskennzahlen liegt in der Ausrichtung auf das Ergebnis. Eine hohe Anzahl bearbeiteter Tickets pro Tag sagt nichts darüber aus, ob Kunden ihre Probleme wirklich gelöst bekommen haben. Customerexperience genau diesen Outcome und zwingt Teams dazu, Effizienz und tatsächliche Problemlösung zusammen zu betrachten.

Für Teams mit asynchroner Kommunikation, etwa bei E-Mail-Support über mehrere Zeitzonen hinweg, gewinnt ART noch mehr an Bedeutung. Die Metrik bildet laut Decagon die gesamte Lebenszeit eines Tickets ab, inklusive aller Wartezeiten, Rückfragen und Eskalationen. Das macht sie zu einem der wenigen Werte, die den kompletten Weg eines Kundenanliegens sichtbar machen.

Drei Punkte sollten Sie sich merken, bevor Sie mit der Berechnung beginnen:

• ART misst den gesamten Lebenszyklus eines Tickets, nicht nur die aktive Bearbeitungszeit eines Agenten.
• Die Definition des Endpunkts (Lösungsvorschlag versus Kundenbestätigung) muss unternehmensweit einheitlich sein.
• Als Outcome-Kennzahl sagt ART mehr über die Kundenerfahrung aus als reine Volumen- oder Aktivitätsmetriken.

Die Formel: Business-Hours, Pausen und warum der Median zählt

Die Grundformel für Average Resolution Time ist denkbar einfach: Sie teilen die Summe aller Auflösungszeiten durch die Anzahl der in diesem Zeitraum geschlossenen Tickets. Die eigentliche Arbeit beginnt jedoch bei den Konfigurationsentscheidungen, die vor dieser Berechnung getroffen werden müssen.

Zunächst stellt sich die Frage nach Kalenderzeit oder Geschäftszeit. Ein Ticket, das freitagabends um 18 Uhr eintrifft und montagmorgens um 9 Uhr gelöst wird, hat in Kalenderstunden gerechnet fast 63 Stunden gebraucht. In Geschäftsstunden gerechnet, bei einem Support von 9 bis 18 Uhr an Werktagen, waren es effektiv nur wenige Stunden aktiver Bearbeitungszeit. Wer in Kalenderzeit misst, bestraft sein Team für Wochenenden und Feiertage, die niemand beeinflussen kann. Die meisten reifen Support-Organisationen rechnen deshalb in Geschäftsstunden.

Zweitens braucht jede saubere Messung eine Pause-Funktion für den Zustand „Customer-Pending“ oder „On-Hold“. Wartet ein Agent auf eine Rückmeldung des Kunden, etwa eine Bestellnummer oder einen Screenshot, läuft die Uhr weiter, obwohl das Team nichts tun kann. Ohne diese Pause verzerren wartende Kunden die Statistik zulasten des Supportteams. So gehen Sie vor:

1. Definieren Sie einen klaren Status „Wartet auf Kunde“ in Ihrem Ticketsystem.
2. Stoppen Sie die Zeitmessung automatisch, sobald dieser Status gesetzt wird.
3. Setzen Sie die Uhr fort, sobald der Kunde antwortet oder die Wartezeit eine definierte Frist überschreitet.
4. Dokumentieren Sie die Pausenlogik so, dass sie für alle Kanäle gleich funktioniert.

Profi-Tipp: Prüfen Sie regelmäßig, ob Agenten den Pending-Status korrekt setzen. Ein Team, das diesen Status selten nutzt, kaschiert oft eigene Verzögerungen als Kundenwartezeit.

Drittens, und das wird häufig übersehen: Der Mittelwert allein lügt nicht, aber er täuscht. CustomerExperience.io empfiehlt ausdrücklich, den Median parallel zum Mittelwert zu berichten. Wenige extrem lange Tickets, etwa komplexe technische Eskalationen, ziehen den Mittelwert stark nach oben, während der typische Kunde eine viel kürzere Wartezeit erlebt. Liegt Ihr Median deutlich unter dem Mittelwert, verrät das eine kleine Gruppe von Long-Running-Tickets, die eine eigene Ursachenanalyse verdient, statt das gesamte Team für einen schlechten Durchschnittswert verantwortlich zu machen.

Resolution Time, First Response Time und FCR im Vergleich

Viele Teams verwechseln oder vermischen drei Metriken, die unterschiedliche Fragen beantworten. First Response Time misst, wie schnell ein Kunde die erste qualifizierte Reaktion erhält, unabhängig davon, ob sein Problem damit bereits gelöst ist. First Contact Resolution (FCR) misst, ob ein Anliegen bereits beim ersten Kontakt vollständig geklärt wurde, ohne weitere Rückfragen oder Eskalationen. Resolution Time schließlich misst die Gesamtzeit bis zur endgültigen Lösung, egal wie viele Kontakte dafür nötig waren.

CustomerExperience.io beschreibt den Unterschied treffend: First Response Time schützt das Gefühl, gehört zu werden. Resolution Time schützt das eigentliche Ergebnis. Ein Kunde, der innerhalb von zwei Minuten eine automatische Empfangsbestätigung erhält, fühlt sich ernst genommen, auch wenn sein Problem erst drei Tage später gelöst wird.

Die Gefahr liegt in der isolierten Optimierung einer einzelnen Kennzahl. Ein Team, das ausschließlich auf schnelle First Response Time trainiert wird, produziert womöglich viele oberflächliche Erstantworten, die das eigentliche Problem nicht lösen und die Resolution Time in die Länge ziehen. Umgekehrt kann ein Team, das nur auf niedrige Resolution Time optimiert, Tickets vorschnell schließen, ohne die Kundenzufriedenheit zu prüfen. Die drei Metriken gehören zusammen betrachtet, nicht als Ranking, sondern als Dreiklang.

Benchmarks für 2026: Zielwerte nach Kanal und Priorität

Zielwerte für Resolution Time unterscheiden sich stark je nach Kanal und Dringlichkeitsstufe eines Tickets. Ein pauschaler Zielwert für das gesamte Unternehmen ignoriert diese Realität und führt entweder zu unrealistischem Druck auf komplexe Fälle oder zu zu laxen Zielen für einfache Anfragen.

Nach Kanal gestaffelt zeigen sich 2026 folgende grobe Muster: Live-Chat-Anfragen werden typischerweise innerhalb weniger Stunden gelöst, weil sie meist einfachere, synchron bearbeitbare Anliegen betreffen. E-Mail-Support braucht naturgemäß länger, oft einen bis mehrere Werktage, da die Kommunikation asynchron verläuft und häufiger Rückfragen erfordert. Telefonsupport liegt oft dazwischen, weil viele Anliegen direkt im Gespräch gelöst werden, komplexere Fälle aber an Fachabteilungen weitergereicht werden müssen.

Nach Priorität gestaffelt orientieren sich viele Support-Organisationen an einem P1-bis-P4-Schema:

• P1 (kritisch, z. B. Systemausfall): Zielwerte im Bereich weniger Stunden, oft mit eigenem Eskalationspfad.
• P2 (hoch, funktionale Einschränkung): Zielwerte innerhalb eines Werktages.
• P3 (mittel, Standardanfragen): Zielwerte innerhalb weniger Werktage.
• P4 (niedrig, Feature-Wünsche oder allgemeine Fragen): Flexiblere Zielwerte ohne engen SLA-Druck.

CustomerExperience.io ordnet diese Prioritätslogik sowohl der First Response Time als auch der Resolution Time zu, mit jeweils eigenen SLA-Zielen pro Priorität. Das verhindert, dass ein kritischer Systemausfall im selben Topf landet wie eine einfache Rückfrage zur Rechnung.

Branche und Komplexität verschieben diese Richtwerte zusätzlich. E-Commerce-Support mit standardisierten Anliegen wie Rücksendungen oder Lieferstatus erreicht laut CloudTalk oft kürzere Zeiten als B2B-Software-Support mit technisch komplexen Fällen, die mehrere Abteilungen involvieren. Ein Unternehmen mit stark saisonalem Geschäft, etwa im Weihnachtsgeschäft, sollte seine Zielwerte zudem an Volumenspitzen anpassen, statt das ganze Jahr über dieselbe starre Zahl zu verlangen.

Künstliche Intelligenz verändert diese Benchmarks zusätzlich, allerdings nicht immer in die erwartete Richtung. Laut Decagon kann KI-gestützter Support die Resolution Time senken, wenn eine solide Wissensdatenbank und klare Governance-Regeln vorhanden sind. Fehlt diese Grundlage, kann der gemessene Durchschnitt sogar steigen, weil einfache, schnell lösbare Tickets vollautomatisch wegfallen und nur die komplizierteren Fälle beim menschlichen Team landen. Ein sinkender ART-Wert bedeutet also nicht automatisch, dass Ihr Team schneller arbeitet. Er kann auch bedeuten, dass sich die Zusammensetzung der Tickets verschoben hat.

Auch die Kanalwahl selbst verschiebt sich mit der Zielgruppe. Jüngere Generationen bevorzugen laut Statista tendenziell Messaging- und Chat-Kanäle gegenüber klassischer E-Mail oder Telefon, was Auswirkungen auf die Kanalverteilung und damit auf die aggregierten Benchmarks eines Unternehmens hat. Wer sein Kundensegment kennt, kann diese Verschiebung in der Zielsetzung vorwegnehmen, statt später überrascht zu sein, warum die E-Mail-Zahlen sinken, während der Chat explodiert.

Wie Sie Ihre Resolution Time gezielt senken

Eine niedrigere Resolution Time entsteht selten durch einen einzigen großen Wurf. Sie entsteht durch mehrere kleinere Hebel, die zusammen wirken, und durch die Bereitschaft, unbequeme Wahrheiten über die eigenen Prozesse anzuerkennen. Die folgende Reihenfolge orientiert sich am typischen Wirkungsgrad, den Support-Teams in der Praxis beobachten.

1. Handoffs kartieren und entstauen. Jeder Übergang eines Tickets zwischen Agenten, Teams oder Abteilungen kostet Zeit, oft mehr als die eigentliche Bearbeitung. Zeichnen Sie den Weg eines typischen Tickets nach, von der Eröffnung bis zur Schließung, und markieren Sie jeden Punkt, an dem ein Wechsel stattfindet. Häufig zeigt sich, dass ein einzelner überlasteter Eskalationspfad für einen Großteil der langen Bearbeitungszeiten verantwortlich ist. Ein gezielter Blick auf typische Fehlerquellen im Kundensupport hilft dabei, diese blinden Flecken systematisch aufzudecken.

2. First Contact Resolution gezielt erhöhen. Je mehr Anliegen beim ersten Kontakt vollständig gelöst werden, desto weniger Tickets bleiben lange offen. Eine gut gepflegte, durchsuchbare Wissensdatenbank reduziert die Zeit, die Agenten mit der Suche nach Informationen verbringen. Erweiterte Befugnisse für Agenten, etwa das eigenständige Genehmigen von Rückerstattungen bis zu einem bestimmten Betrag, vermeiden unnötige Rücksprachen mit Vorgesetzten. Regelmäßige Schulungen zu den häufigsten Ticketkategorien zahlen sich hier direkt aus, weil sie Unsicherheit bei Agenten reduzieren, die sonst zu Rückfragen und Verzögerungen führt.

3. Triage und Priorisierung schärfen. Ein Ticket, das falsch kategorisiert oder an die falsche Warteschlange geleitet wird, verliert wertvolle Zeit, bevor überhaupt jemand daran arbeitet. Eine klare SLA-Matrix, die Tickets automatisch nach Priorität und Kategorie routet, verhindert, dass kritische Anliegen in derselben Warteschlange wie Standardanfragen versauern. Automatisiertes Routing basierend auf Schlüsselwörtern oder Kundenmerkmalen beschleunigt diesen Schritt zusätzlich.

4. Automatisierung für wiederkehrende Ticketkategorien einsetzen. Analysieren Sie, welche Ticketarten am häufigsten vorkommen, und prüfen Sie, welche davon sich für Selbsthilfe-Optionen, Chatbots oder automatisierte Workflows eignen. LiveAgent nennt hier gespeicherte Antworten und strukturierte Wissensdatenbanken als bewährte Mittel, um die Bearbeitungszeit ohne Qualitätsverlust zu senken.

5. Root-Cause-Behebung für die häufigsten Tickettypen priorisieren. Manchmal ist die schnellste Lösung, ein wiederkehrendes Problem gar nicht erst als Ticket entstehen zu lassen. Wenn zehn Prozent aller Anfragen dieselbe verwirrende Stelle in einem Bestellprozess betreffen, löst eine Anpassung dieser Stelle mehr Tickets im Voraus, als jede noch so gute Antwortvorlage es je könnte.

6. Ehrliche Clock-Pausen und kontrollierte Experimente etablieren. Testen Sie Änderungen nicht im gesamten Team gleichzeitig, sondern an einer Teilgruppe, und vergleichen Sie die Resolution Time vor und nach der Änderung über einen klar definierten Zeitraum. Nur so lässt sich unterscheiden, ob eine Verbesserung tatsächlich am neuen Prozess liegt oder an saisonalen Schwankungen im Ticketvolumen.

Profi-Tipp: Bevor Sie in neue Automatisierung investieren, prüfen Sie, ob der Kontext des Kunden, etwa Bestell- oder Kontodaten, bereits direkt im Ticket sichtbar ist. Fehlt dieser Kontext, verbringen Agenten einen erheblichen Teil ihrer Zeit mit dem Wechsel zwischen Systemen statt mit der eigentlichen Lösung des Problems.

Ein oft unterschätzter Hebel liegt zudem in der Zusammenarbeit innerhalb des Teams selbst. Wenn Agenten schnell auf Kollegen oder Fachexperten zugreifen können, ohne ein Ticket formal zu eskalieren, sinkt die Zeit bis zur Lösung spürbar. Erfahrungen zur Team-Kollaboration im Kundensupport zeigen, wie viel Zeit allein durch bessere interne Abstimmung eingespart werden kann, ohne dass ein einziger externer Prozess verändert werden muss.

Wichtig bleibt bei all diesen Maßnahmen die Kopplung an Qualitätskennzahlen. LiveAgent warnt ausdrücklich davor, Bearbeitungszeiten isoliert zu senken, ohne First Contact Resolution und Kundenzufriedenheit im Blick zu behalten. Ein Team, das Tickets künstlich schnell schließt, um die Statistik zu schönen, produziert am Ende mehr Folgetickets und frustrierter Kunden. Das ist keine echte Verbesserung, sondern eine Verschiebung des Problems in die Zukunft.

Reporting-Praxis: Dashboards, Segmentierung und SLA-Anbindung

Ein aussagekräftiges Dashboard für Resolution Time beginnt mit Segmentierung, nicht mit einer einzigen großen Zahl. Ein unternehmensweiter Durchschnittswert verschleiert mehr, als er zeigt, weil er völlig unterschiedliche Ticketarten in einen Topf wirft.

Sinnvolle Segmentierungsachsen sind:

• Kanal: Chat, E-Mail, Telefon und Social Messaging jeweils getrennt betrachten, da sich ihre natürlichen Zeitrahmen stark unterscheiden.
• Tickettyp: Rechnungsanfragen, technische Störungen und allgemeine Produktfragen brauchen unterschiedliche Zielwerte.
• Priorität: P1 bis P4 getrennt ausweisen, damit kritische Fälle nicht im Durchschnitt untergehen.
• Komplexität oder Eskalationsstufe: Tickets, die mehrere Teams durchlaufen haben, gesondert markieren, um deren Einfluss auf den Gesamtwert sichtbar zu machen.

Für die eigentliche Berichterstattung reicht eine einzelne Kennzahl nicht aus. Ein belastbares Reporting-Set kombiniert mehrere Werte, die sich gegenseitig ergänzen und Fehlinterpretationen verhindern.

Diese Kombination beantwortet eine Frage, die eine einzelne Zahl nie beantworten kann: Wird das Team wirklich schneller, oder verschiebt es nur Probleme? Sinkt die Resolution Time, während CSAT und FCR stabil bleiben oder steigen, ist die Verbesserung echt. Sinkt sie, während CSAT fällt, wurden vermutlich Tickets vorschnell geschlossen.

Für die Einbindung in Service-Level-Agreements gilt: Zielwerte sollten nach Priorität gestaffelt und getrennt für First Response Time und Resolution Time formuliert werden, nie als eine einzige pauschale Zahl. Ein SLA, der für alle Tickets dieselbe Reaktionszeit verspricht, egal ob Systemausfall oder Feature-Anfrage, überfordert entweder das Team bei kritischen Fällen oder verschenkt Kapazität bei unwichtigen. Klar formulierte SLA-Ziele je Priorität schützen zudem vor teuren Vertragsstrafen. Wie eng solche Zielwerte in Verträgen gefasst werden sollten, zeigt ein Blick auf SLA-Strafen in Callcenter-Verträgen, wo zu ambitionierte Zielwerte schnell zum wirtschaftlichen Risiko werden können.

Nützliche Dashboard-Widgets für die tägliche Praxis umfassen eine Verlaufskurve der Resolution Time über die letzten zwölf Wochen, eine Verteilung der offenen Tickets nach Priorität, sowie eine Liste der zehn am längsten offenen Fälle mit direktem Zugriff für Teamleiter. Ein solches Setup macht Probleme sichtbar, bevor sie zu einem Muster werden, statt erst am Monatsende in einem Bericht aufzutauchen.

Praxisblick: Was aLIVE Support in der Umsetzung beobachtet

Als Dienstleister für ausgelagerten Kundensupport werden täglich Omnichannel-Daten aus Telefon, E-Mail, Live-Chat und Social-Messaging-Plattformen wie WhatsApp oder Facebook genutzt. Diese Kanalvielfalt zeigt deutlich, wie unterschiedlich Resolution-Time-Werte je nach Kommunikationsweg ausfallen und warum eine getrennte Betrachtung pro Kanal unverzichtbar ist. In Omnichannel-Setups kann eine sichtbare Anzeige des Kunden- und Bestellkontexts direkt im Ticket die Durchlaufzeit reduzieren, da Handoffs und wiederholte Kontextanfragen entfallen.

Entscheider müssen nicht auf einen vollständigen Prozessumbau warten, um erste Schwachstellen zu erkennen. Vier schnelle Prüfungen lassen sich innerhalb eines Tages selbst durchführen:

• Prüfen Sie, ob Mittelwert und Median stark auseinanderklaffen. Eine große Lücke deutet auf einige wenige sehr lange Tickets hin, die eine gezielte Ursachenanalyse verdienen.
• Zählen Sie, wie oft der Status „Wartet auf Kunde“ tatsächlich genutzt wird. Ein seltener genutzter Status kann bedeuten, dass interne Verzögerungen als Kundenwartezeit getarnt werden.
• Vergleichen Sie die Resolution Time zwischen Ihren Kanälen. Liegt ein Kanal deutlich über den anderen, lohnt sich ein Blick auf dessen Routing und Teamzuweisung.
• Ermitteln Sie den Anteil der Tickets, die mehr als eine Woche offen bleiben. Dieser Wert zeigt oft mehr über strukturelle Probleme als jeder Durchschnittswert.

Für eine tiefere Auseinandersetzung mit der Themenwahl lohnt sich ein Blick auf wichtige Kennzahlen im Kundendialog sowie auf die grundsätzliche Bedeutung von Reporting im Support, beide mit konkreten Ansätzen für die praktische Umsetzung im eigenen Team.

Unternehmen, die einzelne Kanäle oder den kompletten Support auslagern möchten, finden entsprechende Leistungen bei Alive für Callcenter-Unterstützung, Live-Chat-Support und E-Mail-Support, jeweils mit Anbindung an bestehende oder eigene Analyse-Tools zur Nachverfolgung von Resolution-Time-Werten. Wer eine Gesamtübersicht sucht, findet diese auf der Leistungsseite von Alive, und für konkrete Anfragen steht die Kontaktseite zur Verfügung.

Warum die Zahl allein noch nichts sagt

Die verbreitete Vorstellung, eine niedrigere Resolution Time sei automatisch ein Erfolg, greift zu kurz. Die eigentliche Frage lautet nicht, ob die Zahl sinkt, sondern warum sie sinkt. Ein Team kann seinen Durchschnitt drücken, indem es Tickets vorschnell schließt, oder es kann ihn drücken, weil Agenten dank besserer Wissensdatenbank tatsächlich schneller zur richtigen Lösung finden. Beide Wege erzeugen dieselbe Kurve im Dashboard, aber nur einer davon verdient Anerkennung.

Konventionelle Beratung konzentriert sich oft zu stark auf einen einzelnen Zielwert, etwa „unter 24 Stunden lösen“. Das ignoriert, dass ein P1-Systemausfall und eine allgemeine Produktfrage niemals denselben Zeitrahmen verdienen. Wer seine Prioritäten nicht sauber trennt, optimiert am Ende für den Durchschnitt und vernachlässigt die Fälle, die wirklich dringend sind.

Mein Rat an Support-Verantwortliche: Investieren Sie zuerst in die Messgrundlage, also Business-Hours-Zählung, Petting-Pausen und Median-Reporting, bevor Sie an Prozesshebeln arbeiten. Eine verzerrte Zahl lässt sich durch keine noch so gute Maßnahme reparieren, weil Sie ja gar nicht wissen, welches Problem Sie eigentlich lösen.

— Markus

Quellen

Wer tiefer in das Thema einsteigen möchte, findet in den folgenden Quellen jeweils einen klaren Schwerpunkt, der die unterschiedlichen Fragen dieses Artikels ergänzt.

• Customerexperience
• LiveAgent — Durchschnittliche Bearbeitungszeit reduzieren: 7 bewährte Methoden
• Statista — US Population Share By Generation

FAQ

Was gilt als guter FCR-Wert im Kundensupport?

Ein First-Contact-Resolution-Wert wird häufig als gut angesehen, wenn er hoch ist, wobei der genaue Zielwert stark von Branche und Tickettyp abhängt. Wichtiger als eine feste Zahl ist die Kopplung an CSAT, da eine steigende FCR ohne stabile Zufriedenheit auf vorschnell geschlossene Tickets hindeuten kann.

Was ist eine Resolution Time genau?

Resolution Time ist die Zeitspanne vom Öffnen eines Support-Tickets bis zu dessen endgültiger Lösung, oft auch als Average Resolution Time oder Mean Time to Resolution bezeichnet. Sie unterscheidet sich von der First Response Time, die nur die Zeit bis zur ersten Antwort misst.

Wie berechnet man die Resolution Rate?

Die Resolution Rate ergibt sich aus der Anzahl gelöster Tickets geteilt durch die Gesamtzahl der eingegangenen Tickets in einem Zeitraum, meist als Prozentsatz ausgedrückt. Für die durchschnittliche Resolution Time gilt hingegen die Formel: Summe aller Auflösungszeiten geteilt durch die Anzahl geschlossener Tickets, idealerweise in Geschäftsstunden gerechnet.

Welche Metrik misst die durchschnittliche Zeit bis zur Lösung eines Vorfalls?

Diese Frage beantwortet Average Resolution Time, häufig auch Mean Time to Resolution (MTTR) genannt, insbesondere im technischen Incident-Management. Die Metrik misst die durchschnittliche Zeit vom Öffnen bis zur endgültigen Schließung eines Vorfalls oder Tickets.

Sollte man Mittelwert oder Median für Resolution Time berichten?

Beide Werte gehören zusammen berichtet, da sie unterschiedliche Aspekte zeigen. CustomerExperience.io empfiehlt den Median als robusteres Maß für die typische Erfahrung, während der Mittelwert Ausreißer und strukturelle Probleme sichtbar macht, die im Median verborgen bleiben.

Empfehlungen

• First Contact Resolution: Messen, Benchmarks und Pilotplan
• Wichtige Kennzahlen im Kundendialog: 2026 Guide
• Customer Effort Score praktisch: 4,0 als Ziel für Supportteams
• Messbarkeit im Service: 9 Tipps für Führungskräfte