Unheimlich spannender Titel den ich mir hier habe einfallen lassen, nicht wahr? Auch wenn, zugegebenermaßen, der Titel nicht grade auf einen dreiteiligen schwedischen Mordkomplott hindeutet, ist das Werkzeug „Ticket Review“ im Service Desk von seinen Möglichkeiten her nicht zu unterschätzen. Ehrlich! Was ich damit genau meine, möchte ich in diesem Beitrag beleuchten.
Ja, ich gebe es zu! Es ist mir schon etwas peinlich aber dies ist mein erster Artikel nach einer längeren Pause. Hatte ich zu Beginn meines Blogs noch jeden Tag etwas zu sagen/schreiben, hat sich das über die Zeit deutlich abgeschwächt. Irgendwie dachte ich, ich habe mit 100 Beiträgen jedes Thema durch. Lange war ich auf der Suche nach etwas Neuem über das ich hier schreiben könnte.
Plötzlich, an einem verregneten Montag lag es direkt vor mir. Nein, kein Ticket Review stand vor mir, sondern ein uraltes, eskalierendes, schlecht gepflegtes Ticket flimmerte über meinen Bildschirm. Für alle die jetzt nicht wissen, was ein Ticket ist. Hier ein kurzer Exkurs:
Tickets beherbergen meist alle Informationen die notwendig sind, um ein technisches Problem zu lösen. Die Betonung liegt auf „Normalerweise“. Zum Beispiel also die Nachricht eines Kunden, Screenshots, Bearbeitungsstatus, Hinweis auf einzuhaltende Service Level Agreements und Priorisierung. Alle Tickets haben eines gemeinsam. Sie funktionieren alle nach dem sogenannten
Shit-in = Shit-out
Prinzip.
Ich entschuldige mich für diese rüde Ausdrucksweise auf meinen Seiten aber einen adäquatere Namen habe ich dafür bisher noch nicht gefunden.
Gemeint ist damit, dass die Qualtiät von Informationen, dass Endergebnis ihres Verwendungszwecks maßgeblich beeinflussen.
Mit anderen Worten. Wenn das Ticket schlecht gepflegt ist und zu wenig Informationen enthält, sich niemand richtig darum kümmert, dann ist die Gefahr einer Eskalation beim Kunden auch relativ hoch. Das führt wiederum zu Frust und Ärger bei den Mitarbeitern.
Doch wer bearbeitet ein solches Ticket? Das ist zunächst der Kunde selber, welcher es vielleicht durch eine E-Mail auslöst und initial mit Informationen versieht. Federführend allerdings ist der Service Desk, IT Support oder Customer Care Bereich. Überall dort wo eine Dienstleistung erbracht wird, fallen Issues, Incidents, Vorgänge, Beschwerden und Tickets an. Immer dann wenn ein Kunde das Produkt oder die Dienstleistung des Unternehmens nicht so nutzen kann, wie er sich das vorstellt. Auf der anderen Seite des Tickets sitzen dann Customer Care Agents, 1st/2nd/3rd Level Supporter, Sachbearbeiter und Kundenbetreuer. Diese bearbeiten die Tickets und versuchen eine möglichst zügige Lösung herbeizuführen.
Wie das bei Menschen so ist, ist allgemein bekannt, dass sie keine Maschinen sind. Das kontinuierliche Abarbeiten von Tickets ist also meist ein schwieriges Unterfangen. Mit manchen Kunden versteht man sich besser, als mit anderen. Manche Tickets sind vielleicht zu schwer zu lösen und erfordern Entscheidungen des Vorgesetzten. Manche wiederum wurden geerbt und irgendwie weiß niemand so richtig etwas damit anzufangen. Niedrige Priorisierung laden zur Verschleppung ein. Oft fehlen auch die wichtigsten Informationen, um dem Kunden überhaupt helfen zu können. Zusammengefasst, kosten sie Mühe & Sorgfalt und zwar gewaltig.
Richtig deutlich wird dies, wenn an bestimmten Tickets mehrere Kollegen arbeiten. Dann treffen verschiedene Informationsbedürfnisse aufeinander, die irgendwie scheinbar nicht auf einen Nenner zu bringen sind.
Ich glaube ich habe das Problem deutlich gemacht, oder? Doch was tun? Wie wäre es mit einem Leitfaden, der den Mitarbeitern plausibel macht, wie Tickets zu pflegen sind? Grandiose Idee! Das ist auch der Grund warum dies in den meisten Unternehmen regelmässig gemacht wird, sich aber effektiv nichts ändert.
Zu Beginn des nächsten Absatzes stellen Sie sich bitte einen weißen Ritter vor, der die dunkle Tür des Ticketings eintritt und danach zusammen mit seinem Einhorn (warum Einhorn?) hindurch reitet. Das Ticket Review ist da.
Das Ticket Review ist letztendlich nichts anderes als das Durchsehen und Überprüfen von Vorgängen durch einen Dispatcher oder Supportleiter. Da dieser die Vorgaben sehr gut kennt, kann er genau sagen wo nachgebessert werden muss. Wenn dies ohne die Zusammenarbeit mit den bearbeitenden Kollegen passiert, ist das allerdings nur die halbe Miete. Richtig Wirkung entfalten Ticket Reviews, wenn sie auf Augenhöhe mit dem zuständigen Mitarbeiter durchgeführt werden.
Das geht so:
Der Dispatcher oder Teamleiter macht mit dem Mitarbeiter einen regelmässigen Termin aus. Das kann jede Woche oder alle 14 Tage sein. Zu diesem Termin sitzen beide Kollegen vor den Tickets und gehe die offenen Störungen oder Vorgänge Punkt für Punkt durch. Dabei wird auf Fragen eingegangen. Was ist hier zu tun, warum gibt es noch kein Feedback, ist die Beschreibung so ausreichend? Für jeden Vorgang werden konkrete Maßnahmen vereinbart. Beispielsweise das Anrufen eines Kunden oder Schließen der Anfrage.
Wenn der Termin sich dann wiederholt, werden die konkreten Maßnahmen von beiden überprüft. Hat es zu bestimmten Vorgängen keine Änderung gegeben und woran liegt das. Liegt vielleicht eine Überlastung des Mitarbeiters vor? Fehlen bestimmt Kenntnisse, welche geschult werden sollten? Der Dispatcher erhält mit diesen Terminen, Stück für Stück ein sehr genaues Bild zum Support, dem Skilllevel und anderen Attributen, die im Tagesgeschäft eine Rolle spielen können.
Das alleine wäre allerdings jetzt noch keine große Innovation. Diese kommt, sobald man sich die Nebenwirkungen genauer ansieht. Durch den regelmässig stattfindenden Termin, kommen Probleme, Missstände und Defizite an die Oberfläche und werden gelöst. Außerdem verbessert sich nicht nur die Ticketqualität, sondern auch das Informationsverhalten der Mitarbeiter. Letztendlich führt dies wiederum zu einer Verbesserung der Kultur im Unternehmen.
Der kausale Zusammenhang zwischen Ticket Qualität und Kultur entsteht durch die notwendige Sorgfalt und Mühe, die notwendig ist, beides zu verbessern. Ticket Reviews sind daher für mich eines DER Werkzeuge, die in keinem Support oder Kundebetreuung fehlen dürfen.
Leave a Comment