Issue-to-Resolution(I2R)
Von der Kundenanfrage bis zur gelösten Reklamation: wie der Issue-to-Resolution-Prozess abläuft, woran er gemessen wird und wo Tickets zwischen Kanälen, Teams und Supportstufen hängen bleiben.
Auch bekannt als: I2R · Issue to Resolution · Case-to-Resolution · Ticket-to-Resolution · Complaint-to-Resolution · Reklamationsprozess
Was ist Issue-to-Resolution?
Issue-to-Resolution (I2R) ist der End-to-End-Prozess vom Eingang eines Kundenanliegens bis zu seiner abschließenden Lösung. Er umfasst die Erfassung über Telefon, E-Mail, Chat oder Portal, Klassifizierung und Priorisierung, die Zuweisung an ein Team, die Bearbeitung mit Eskalationen und Übergaben zwischen Supportstufen, die Lösung, den Abschluss und das Feedback des Kunden. Dazu gehören Serviceanfragen ebenso wie Reklamationen und Gewährleistungsfälle. Weil Kunden einen Service am Ergebnis und an der Wartezeit messen, entscheidet I2R wesentlich über Zufriedenheit und Kundenbindung.
Startet mit
Ein Kunde meldet ein Anliegen über einen Kanal, ein Ticket entsteht.
Endet mit
Das Anliegen ist gelöst, das Ticket geschlossen und das Feedback erfasst.
Typische Phasen
- 1
Erfassung
Anliegen kommen über Telefon, E-Mail, Chat, Portal oder Außendienst an und werden als Ticket oder Fall angelegt, im Idealfall mit Kunde, Produkt und Auftrag verknüpft.
- Anfrage eingegangen
- Ticket angelegt
- Kunde & Auftrag zugeordnet
- 2
Klassifizierung & Zuweisung
Das Ticket wird nach Art, Dringlichkeit und Vertrag eingestuft; daraus folgen Priorität, SLA und das zuständige Team.
- Kategorie gesetzt
- Priorität vergeben
- SLA zugeordnet
- An Team zugewiesen
- 3
Bearbeitung & Eskalation
Der First Level löst, was er lösen kann, und gibt den Rest an Second Level, Fachabteilung oder Hersteller weiter. Rückfragen beim Kunden und Eskalationen unterbrechen die Bearbeitung.
- Bearbeitung gestartet
- Rückfrage an Kunden
- An Second Level übergeben
- Eskalation
- Lösung erarbeitet
- 4
Lösung & Abschluss
Die Lösung wird umgesetzt – als Auskunft, Reparatur, Ersatzlieferung oder Gutschrift – und dem Kunden mitgeteilt. Danach wird das Ticket geschlossen oder bei erneutem Problem wieder geöffnet.
- Lösung mitgeteilt
- Gutschrift oder Ersatz ausgelöst
- Ticket geschlossen
- Ticket wiedereröffnet
- 5
Feedback & Auswertung
Kundenzufriedenheit wird abgefragt, wiederkehrende Ursachen werden an Produkt, Qualität oder Logistik zurückgemeldet.
- Umfrage versendet
- Bewertung erhalten
- Ursache zurückgemeldet
Geschäftsobjekte und Systeme
Diese Objekte hinterlässt der Prozess in den Quellsystemen – mit Zeitstempeln, Verantwortlichen und Beziehungen untereinander.
- Ticket / Fall
- Das Kundenanliegen mit Kanal, Kategorie, Priorität, Status und Bearbeitungshistorie.
- Kunde & Vertrag
- Wer das Anliegen meldet und welche Servicevereinbarung dafür gilt.
- Interaktion
- Jeder Kontakt zum Ticket – Anruf, E-Mail, Chatnachricht, Rückfrage oder Antwort.
- SLA
- Vereinbarte Reaktions- und Lösungszeiten je Priorität, mit Uhr, Pausen und Verletzungen.
- Reklamation & Gewährleistungsfall
- Anliegen zu einem gelieferten Produkt, verknüpft mit Auftrag, Lieferung und Rechnung.
- Gutschrift / Ersatzlieferung
- Die kaufmännische oder logistische Folge einer berechtigten Reklamation.
Typische Quellsysteme
- Kundenservice- und Ticketsysteme (z. B. Salesforce Service Cloud, ServiceNow CSM, Zendesk)
- CRM-Systeme
- Contact-Center- und Telefonieplattformen
- ERP für Aufträge, Lieferungen, Gutschriften und Gewährleistung
Kennzahlen, die sich messen lassen
- Time to Resolution
- Zeit vom Eingang des Anliegens bis zur Lösung.
- First Contact Resolution
- Anteil der Anliegen, die beim ersten Kontakt ohne Übergabe gelöst werden.
- SLA-Treue
- Anteil der Tickets, deren Reaktions- und Lösungszeit innerhalb der Vereinbarung liegt.
- Wiedereröffnungsquote
- Wie viele geschlossene Tickets erneut geöffnet werden müssen.
- Übergaben pro Ticket
- Wie oft ein Ticket zwischen Teams oder Supportstufen weitergereicht wird.
- Kundenzufriedenheit
- Bewertung des Kunden nach Abschluss, z. B. als CSAT oder Net Promoter Score.
Typische Probleme
Ping-Pong zwischen Teams
Falsch klassifizierte Tickets wandern zwischen Teams und Supportstufen hin und her. Jede Übergabe startet eine neue Warteschlange, ohne dass jemand am Anliegen arbeitet.
SLA-Uhren, die schön gerechnet werden
Tickets werden auf „Warten auf Kunde“ gesetzt, um die Uhr anzuhalten, oder vorschnell geschlossen. Die SLA-Treue im Bericht stimmt dann nicht mit der Wartezeit des Kunden überein.
Wiedereröffnete und doppelte Tickets
Ungelöste Anliegen kommen als wiedereröffnetes Ticket oder als neuer Fall über einen anderen Kanal zurück – und werden dann getrennt gezählt.
Ursachen außerhalb des Service
Viele Reklamationen entstehen in Lieferung, Abrechnung oder Produktqualität. Ohne Verbindung zu Auftrag und Rechnung bleibt der Service beim Symptom.
So analysiert Noreja Issue-to-Resolution
Ein Ticketsystem zeigt Statuswechsel, aber nicht das ganze Anliegen. Derselbe Kunde meldet sich per E-Mail und Telefon, ein Fall wird geteilt oder zusammengeführt, eine Reklamation hängt an einem Auftrag, einer Lieferung und einer Gutschrift. Noreja verbindet Tickets, Interaktionen, Kunden und die Belege aus dem ERP im Event Knowledge Graph, statt jedes Ticket als isolierten Fall in einem flachen Eventlog zu betrachten.
Der vorgesehene Ablauf – Klassifizierung vor Zuweisung, Eskalation nach festen Regeln, Rückfrage vor dem Anhalten der SLA-Uhr, Abschluss erst nach Rückmeldung des Kunden – wird mit Fachwissen aus dem Service als erwartete Reihenfolge modelliert. So wird sichtbar, wo Tickets diesen Weg verlassen und welche Abweichung zu Wiedereröffnungen führt.
Fragen, die Noreja beantwortet
- Welche Kategorien und Kanäle verletzen die SLAs am häufigsten?
- Welche Tickets werden zwischen Teams mehrfach hin- und hergereicht?
- Wie lange liegen Tickets nach einer Übergabe, bevor jemand sie bearbeitet?
- Welche Lösungen führen besonders oft zu einer Wiedereröffnung?
- Wo wird die SLA-Uhr angehalten, obwohl der Kunde nicht gefragt wurde?
- Welche Aufträge, Lieferungen oder Rechnungen lösen die meisten Reklamationen aus?
Passende Agents aus der Minerva Agent Library
Häufige Fragen zu Issue-to-Resolution
Was ist der Issue-to-Resolution-Prozess?
Issue-to-Resolution (I2R) ist der End-to-End-Prozess vom Eingang eines Kundenanliegens bis zu seiner Lösung. Er umfasst Erfassung, Klassifizierung, Zuweisung, Bearbeitung mit Eskalationen, Lösung, Abschluss und Feedback – für Serviceanfragen ebenso wie für Reklamationen und Gewährleistungsfälle.
Was ist der Unterschied zwischen Issue-to-Resolution und Request-to-Fulfill?
Request-to-Fulfill beschreibt interne IT-Serviceanfragen, etwa nach Zugängen, Hardware oder Software, aus einem Servicekatalog. Issue-to-Resolution betrifft die Anliegen externer Kunden – Fragen, Störungen, Reklamationen – und misst sich an deren Wartezeit und Zufriedenheit.
Wie hängen Issue-to-Resolution und Order-to-Cash zusammen?
Reklamationen zu Lieferungen oder Rechnungen haben ihren Ursprung im Order-to-Cash-Prozess und wirken dorthin zurück: als Gutschrift, Ersatzlieferung oder gesperrte Zahlung. Wer beide Prozesse verbindet, sieht, welche Aufträge die meisten Serviceanliegen auslösen.
Welche KPIs sind im Issue-to-Resolution wichtig?
Typische Kennzahlen sind Time to Resolution, First Contact Resolution, SLA-Treue, die Wiedereröffnungsquote, Übergaben pro Ticket und die Kundenzufriedenheit nach Abschluss.
Demo-Cases mit ausgearbeiteter Analyse
End-to-End-Prozesse, die wir mit Findings, Ursachen und Maßnahmen durchgespielt haben – teils mit Berührungspunkten zu Issue-to-Resolution.
- Touchless-AuftragsabwicklungOrder-to-CashWie Causal Process Mining zeigt, welche Kundenaufträge touchless laufen können – und wo gezielte Prüfung Qualität schützt.
- FernwärmeanschlussLead-to-ActivationVom ersten Kundeninteresse bis zum Lieferbeginn: wie Process Intelligence Nacharbeit, saisonale Bauzeiten und Compliance-Risiken im Fernwärmeanschluss sichtbar macht – und in priorisierte Maßnahmen übersetzt.
Deinen Prozess kausal verstehen — sprich mit uns
Schließe dich Unternehmen an, die mit intelligenter Prozessanalyse Wachstum und Effizienz neu definieren.