Jeder hat schon mal die Erfahrung gemacht, dass man bei einer Hotline angerufen hat, bei einem Service Desk, einer Supportabteilung, oder auf einer Webseite eines Dienstleisters eine Störung gemeldet hat. Der zuständige Agent dokumentiert die Anfrage in einem Ticket-Tool. Ticket-Tools sind das Ordnungsinstrument in der heutigen Servicewüste.
Der Dienstleister informiert, daß er ein Ticket für diese Störung in einem Tickettool angelegt hat:
“Wir werden uns um Ihr Anliegen kümmern. Bitte verweisen sie in jeder Kommunikation mit uns auf folgende Ticketnummer”.
Möglicher Standardtext nach der Eröffnung eines Tickets in einem Tickettool
Meistens stecken dahinter Tools wie SM9, Jira, Service Now oder auch Remedy. Dies sind große Player im Bereich der Service Management Tools. Service Management ist eine Disziplin, die im Rahmen der IT Infrastructure Library (ITIL) beschrieben wird. Diese Tickettools werden gerne z.B. bei den Service Management Prozessen Incident Management und Problem Management eingesetzt.
Ticket da! Ist damit alles gut?
Vor- und Nachteil dieser Tools ist, dass im Lebenszyklus der eingestellten Tickets nicht mehr EIN verantwortlicher Mitarbeiter zur Bearbeitung und Lösung der Störung zuständig ist. Der Erfasser weist Tickets in ihrem Lebenszyklus an zuständige Gruppen oder Mitarbeiter zu. Die Tickets bekommen unterschiedliche Status-Zustände, bis der Bearbeiter die Ticket schließt.
Der Vorteil ist, daß die Abarbeitung nicht mehr von einem bestimmten Mitarbeiter und seiner Verfügbarkeit abhängt. Urlaub und Krankheit können also durch andere Mitarbeiter aufgefangen werden und alle Informationen zu der Störung sind im Ticket sichtbar.
Der Nachteil ist, daß nicht nur ein Bearbeiter sich um den Fall kümmert. Und im Falle von Verzögerungen kann der Kunde nicht einen einzelnen Bearbeiter verantwortlich machen. Der Kunde, der eine Ticketnummer erhalten hat, kann sich nur noch auf diese Ticketnummer beziehen und nicht mehr auf eine Person, wenn es Probleme in der Lösung der Störung gibt.
Tickets und der gelieferte Service
Haben wir damit die Goldenen Zeiten für Kunden erreicht? Meine Erfahrung ist eine andere. Der Kunde fühlt sich gut behandelt, wenn ein Agent eine Störung nicht nur schnell behebt, sondern dieser den Fortschritt der Störungsbehebung auch gut kommuniziert. Und diese Kommunikation sollte idealerweise durch einen persönlichen Kundenbetreuer erfolgen. Die Kundenbetreuung übernehmen heutzutage aber eher die schriftlichen Mitteilungen (Notifications), die durch die Tickettools bei Änderung des Status versendet werden.
Ein Ticket ist aber nur der Auslöser für die Leistung eines Services. Welche Eigenschaften machen denn einen Service aus? Das Bild am Beginn dieses Beitrages beschreibt es schön satirisch.
Serviceeigenschaft GÜNSTIG
Wenn man Glück hat, dann spricht man bei der Störungsmeldung noch mit einem persönlichen Kundenbetreuer. Aber überall wird versucht Kosten zu sparen – ganz speziell in der Kundenbetreuung. Und daher sind die Prozesse in der Kundenbetreuung hoch automatisiert. Wir halten fest: GÜNSTIG.
Und ein Tool kann natürlich bei der Automatisierung sehr helfen. Vor allem, da man heute nicht mehr selbst die Infrastruktur betreiben muss, sondern diese Ticketsysteme auch als Software-as-a-Service (SAAS) kaufen kann. Und dann auch noch flexible Abrechnungsmodelle pro Ticket oder pro angelegten Nutzer bei einem anderen Dienstleister bestellen kann. Welches Abrechnungsmodell es letztendlich wird ist natürlich abhängig von unterschiedlichen Faktoren wie der Größe der Firma, der Anzahl der Nutzer, der Anzahl der Supportfirmen und Supportgruppen, die in der Software konfiguriert werden.
Serviceeigenschaft SCHNELL
Geschwindigkeit in der Lieferung eines Services wird in den meisten Fällen durch Service Level Agreements (SLAs) oder Operational Level Agreements (OLAs) erzwungen. Da spricht man von Meßfaktoren wie Reaktionszeit, Antwortzeit und Lösungszeit. Und um es kompliziert zu machen, werden diese Zeiten in Abhängigkeit von der Ticket-Priorität gemessen. Durch SLAs und OLAs wissen die Mitarbeiter, wie schnell sie ein Ticket aufgreifen müssen und wie schnell sie es lösen müssen. Ob das funktioniert hat, wird am Ende eines Messzeitraumes (meistens ein Monat) über einen Report transparent gemacht.
Idealerweise zeigen die Tickettools auf, ob man noch innerhalb der SLA-Zeiten für das einzelne Ticket ist. In dem Moment, wo der Mitarbeiter den Status des Tickets auf “Gelöst” setzt, hört die Uhr auf zu ticken. Sehr häufig sind die SLA- oder OLA-Vorgaben herausfordernd festgelegt, also kann im Idealfall das Ticket SCHNELL bearbeitet werden.
Ich will allerdings nicht verschweigen, daß es Möglichkeiten gibt, diese Zeitvorgaben auszuhebeln. Einerseits kann man den Status so verändern, daß die Zeitmessung gestoppt wird, und erst nach einem bestimmten Ergebnis (wie z.B. Rückmeldung durch den Kunden) weiter läuft. Auch kann man ein Ticket herunterpriorisieren. Dann gelten viel längere Zeiten für das Ticket. Und zum Schluß gibt es noch die Möglichkeit ein Ticket anders zu bearbeiten als erwartet. Da kommen wir zur letzten Serviceeigenschaft.
Serviceeigenschaft GUT
Wie in einem Stille Post-Spiel geht bei der Bearbeitung viel Information und Wissen verloren, wenn das Ticket von unterschiedlichen Mitarbeitern zu unterschiedlichen Zeiträumen unabhängig voneinander bearbeitet wird. Die Qualität in der Service-Erbringung ist immer davon abhängig wie gut die Dokumentation des Tickets ist, und wie sehr die Informationen im Ticket auch ausgewertet werden von den beteiligten Mitarbeitern.
Und da erlebt man sehr häufig, daß ein Bearbeiter das Ticket geschlossen hat, obwohl er die Störung nicht für den Kunden behoben hat. Oder der Bearbeiter hat etwas ganz anderes gemacht, als der Kunde eigentlich ursprünglich gewünscht hat. Sehr häufig ist die Qualität der Serviceerbringung auch abhängig von der Restzeit, die die SLA-Uhr im Incident Ticket anzeigt. Nur um die SLAs einhalten zu können, wird auch mal ein Ticket ohne Lösung oder mit mangelnder Dokumentation geschlossen. Soviel zur Serviceeigenschaft GUT.
Fazit
Leider steckt in dem gezeigten Bild viel Wahrheit. Unternehmen, die Services oder Produkte für ihre Kunden erbringen handeln gewinnorientiert. In den meisten Fällen ist der Kundensupport eine lästige Verpflichtung, die Kosten verursacht. In wenigen Fällen wird ein guter und schneller Kundensupport als Differentiator gesehen, der zu zufriedenen Kunden führt und damit auch zu mehr Umsatz führen kann.
Ich kann nicht einschätzen, ob es Firmen gibt, die Wert auf alle drei Serviceeigenschaften GÜNSTIG, SCHNELL und GUT für Kunden legen. Irgendwo schließen in einem markwirtschaftlichen Umfeld zwei der Eigenschaften doch immer die dritte Eigenschaft aus.
Aber Tickettools können als Best Practice von IT-Firmen schon dabei helfen alle drei Serviceeigenschaften zu unterstützen. Erfolgsfaktoren sind aber weiterhin die am Prozess beteiligten, das Tool nutzende Mitarbeiter des Dienstleisters. Wenn diese erfahren und motiviert sind, dann ist es möglich, dass der Kumde bestens bedient wird und guten, schnellen und trotzdem günstigen Service erhält. Sehr häufig ist das nur möglich, wenn die Kostenstruktur der Mitarbeiter günstig ist. Motivation schließt aber auch eine attraktive finanzielle Kompensation ein. Häufig ist das nur in Niedriglohnländern möglich.
Aber vielleicht kann man auch mit deutschen, gut bezahlten und motivierten Experten erfolgreich sein, wenn trotz hoher Gehaltskosten der deutsche Kunde zufrieden ist und den Dienstleister weiterempfehlen kann. Ich würde mir wünschen, daß Firmen erfolgreich sind, die diesen Weg gehen.
Abschreckende Beispiele für schlechten Kundenservice (trotz Ticketsystem) findet man regelmäßig bei c‘t in der Kolumne „Vorsicht Kunde“. Absolut für all diejenigen zu empfehlen, die wissen wollen, wie schlechter Service die Reputation einer Firma negativ beeinflussen kann.
