Die Mittlere Lösungszeit (MTTR) ist die durchschnittliche Zeit, die zwischen der Erstellung eines Support-Tickets und dessen vollständiger Lösung vergeht. Sie ist neben der Erstlösungszeit eine der beiden primären Effizienzmetriken im Support-Betrieb und misst die gesamte Dauer des Support-Erlebnisses aus Kundensicht.
?
Wie wird die MTTR berechnet und welche Faktoren können sie ohne Kontext irreführend machen?
MTTR-Formel: MTTR = Summe (Lösungszeitstempel - Erstellungszeitstempel für alle Tickets im Zeitraum) / Anzahl der gelösten Tickets im Zeitraum. Der reine Mittelwert ist sehr anfällig für Verzerrungen durch eine kleine Anzahl extrem langwieriger Tickets – ein einziger 90 Tage offener, ungelöster Bug kann den Mittelwert dramatisch verzerren, während der Median das typische Kundenerlebnis genau widerspiegelt. Support Ops sollte sowohl den Mittelwert als auch den Median der MTTR berichten und die MTTR auch segmentieren nach: Ticketpriorität (P1 MTTR sollte für Enterprise SaaS 2–4 Stunden betragen; P4 MTTR kann 10+ Werktage betragen und ist akzeptabel); Tickettyp (Abrechnungstickets schließen in Stunden; Engineering-Eskalationen können Wochen dauern); Kanal (Chat-MTTR sollte unter 15 Minuten liegen; E-Mail-MTTR wird in Stunden gemessen); und Kundensegment (Enterprise vs. SMB können sehr unterschiedliche MTTR-Ziele haben). Eine als einzelne, gemischte Zahl angegebene MTTR vermischt all diese Dimensionen zu einer schwer umsetzbaren und leicht manipulierbaren Kennzahl.
?
Welche sind die effektivsten Maßnahmen zur Reduzierung der MTTR, ohne die Lösungsqualität zu beeinträchtigen?
Die Reduzierung der MTTR erfordert die Identifizierung, wo Zeit verbracht wird – der Lösungsprozess hat verschiedene Phasen, in denen Verbesserungen möglich sind. Bearbeitungszeit des Agenten (vom ersten Kontakt bis zur vollständigen Diagnose): Reduziert durch strukturierte Diagnose-Workflows in der Wissensdatenbank ("bei [Symptom] diese 5 Dinge der Reihe nach prüfen"), automatisch ausgefüllten Account-Kontext aus der CRM-Integration und KI-gestützte Lösungsvorschläge basierend auf dem Tickettext. Wartezeit im Engineering (Tier-2-Eskalation wartet auf eine Engineering-Antwort): Reduziert durch die Definition von Engineering-Eskalations-SLAs und die Überwachung der Einhaltung; Aufbau von Tier-2-Diagnosetools, die es Tier 2 ermöglichen, Probleme zu lösen, die zuvor Engineering erforderten; und Aufbau einer Lösungsbibliothek für gängige Engineering-Eskalationsmuster. Kundenwartezeit (Agent wartet darauf, dass der Kunde zusätzliche Informationen bereitstellt): Reduziert, indem Agenten alle benötigten Informationen in einer Nachricht anfordern, anstatt sequenzieller Nachfragen; automatische Wiedereröffnung basierend auf dem Status "wartet auf Kunden", damit Tickets nicht als gelöst markiert werden, während gewartet wird; und proaktive Nachverfolgungs-Timer (automatisierte Erinnerung an Kunden und Agenten, wenn innerhalb von 24 Stunden keine Antwort erfolgt). Nachdiagnose-Haltezeit (Lösung bekannt, aber durch Prozess blockiert): Reduziert durch klar definierte Agentenautorität zur Implementierung gängiger Korrekturen ohne Genehmigung.
?
Wie interagiert die MTTR mit der CSAT, und wann stehen sie in Spannung?
Die Beziehung zwischen MTTR und CSAT ist nicht-linear und kontraintuitiv. Eine Reduzierung der MTTR verbessert im Allgemeinen die CSAT – Kunden schätzen eine schnellere Lösung. Aber eine MTTR-Reduzierung, die durch überstürzte Lösungen, vorzeitige Ticket-Schließung oder oberflächliche Korrekturen erreicht wird, schadet der CSAT aktiv: Ein Ticket, das in 2 Stunden geschlossen wird, ohne das Problem tatsächlich zu lösen, führt zu einem sehr niedrigen CSAT-Score und wahrscheinlich zu einer Wiedereröffnung (gemessen als "Wiederkontaktrate"). Der Spannungspunkt: Wenn das Management die MTTR-Reduzierung als KPI ohne CSAT-Leitplanken incentiviert, optimieren Agenten auf die Abschlussgeschwindigkeit statt auf die Lösungsqualität – sie nehmen Abkürzungen, markieren Tickets als gelöst vor gründlicher Überprüfung und leiten komplexe Probleme ohne echte Hilfe an die Wissensdatenbank weiter. Support Ops mildert dies, indem es: MTTR zusammen mit CSAT und Wiederkontaktrate in jedem operativen Dashboard berichtet (wodurch Manipulation durch das Wiederkontakt-Signal offensichtlich wird); Agenten explizit mitteilt, dass eine lange MTTR bei einem komplexen, sorgfältig bearbeiteten Problem mehr geschätzt wird als eine schnelle MTTR, die durch Ablenkung erreicht wird; und MTTR-Ziele nach Tickettyp festlegt, die realistische Zeitpläne für die Lösungsqualität widerspiegeln, anstatt ehrgeizige Geschwindigkeitsziele.
Wissens-Challenge
Mittlere Lösungszeit (MTTR) gemeistert? Versuchen Sie nun, das verwandte 5-Buchstaben-Wort zu erraten!
Tippen oder Tastatur benutzen