Support für das Supportcenter

Kunden werden von verschiedenen Abteilungen eines Unternehmens betreut. Der IT-Support steht häufig im direkten Kundenkontakt und das in heiklen Situationen: nämlich dann, wenn der Kunde ein Problem hat. Funktioniert eine Software oder Hardware nicht, wie sie aus Sicht des Kunden sollte, ist seine erste Anlaufstelle der Helpdesk. Wie schnell das Problem gelöst wird, trägt dazu bei, wie der Kunde diese Serviceleistung erlebt und hat so direkten Einfluss auf die Kundenzufriedenheit. Daher ist es nicht verwunderlich, dass IT-Dienstleister danach streben, Workflows im Supportcenter zu optimieren.

Das Ticketsystem ist das zentrale Werkzeug eines Supportcenters, mit dem täglich gearbeitet wird. Daher sollte dieses Tool den Unternehmen die Möglichkeit geben, den optimalen Workflow abzubilden und es bei der Einhaltung unterstützen. Die meisten Ticketsysteme bieten dafür eine starre und unvollständige Lösung, indem Pflichtfelder definiert werden, die beim Aufnehmen des Problems ausgefüllt werden müssen. Allerdings folgen bis zur Problemlösung weitere Schritte, die ebenfalls standardisiert ablaufen sollen. Im banibis Ticketsystem wird diese Prozessorientierung in den Vordergrund gestellt: IT-Dienstleister können für jeden Ticketstatus zusätzliche Felder als Pflichtfelder definieren und so ihren gesamten Arbeitsablauf abbilden – vom ersten Schritt, der Ticketerstellung, bis zum Abschluss des Tickets. Auf diese Weise wird nicht nur das Supportcenter bei der Einhaltung des Workflows unterstützt, es wird außerdem dem Kunden eine Serviceleistung auf gleichbleibendem Qualitätsniveau geboten. Im Folgenden zeigen wir dafür konkrete Anwendungsfälle.

Qualitätssicherung im Supportcenter

Hat sich ein Arbeitsablauf einmal eingespielt, werden die einzelnen Arbeitsschritte im Großen und Ganzen eingehalten. Definierte Prozesse helfen dabei, dass eine einheitliche Bearbeitung eingehalten und für den Kunden eine Serviceleistung auf einem hohen Qualitätsniveau erbracht wird. Um im Supportcenter zu gewährleisten, dass die vorgegebenen Arbeitsschritte eingehalten werden, ist es sinnvoll, die Änderung des Status eines Tickets an Bedingungen zu knüpfen.

Bevor ein Ticket eskaliert wird, sollte der 1st Level Support häufige Fehlerursachen bereits ausgeschlossen haben. Dieses Vorgehen wird mit Hilfe von Pflichtfeldern dokumentiert, bevor das Ticket an die nächste Stufe zur Bearbeitung weitergegeben wird. Der 2nd Level Support kann so sicher sein, dass diese Schritte eingehalten wurden und kann sich auf die Problemlösung konzentrieren. Außerdem wird der Kunde nicht mehrfach mit Lösungsvorschlägen konfrontiert, die das Problem oder den Fehler nicht beheben.

Wird aus Kostengründen der 1st Level Support an ein Call Center ausgelagert, wird es in der ersten Zeit einen hohen Abstimmungsbedarf geben, damit die Servicequalität nicht darunter leidet. So kann vorübergehend ein Genehmigungsprozess eingeführt werden, bei dem das eigene Supportteam die Lösungsvorschläge des neuen 1st Level Supports überprüft, ob diese angemessen sind. Erst nach erfolgter Genehmigung kann die Lösung an den Kunden zur Abnahme geschickt werden. Alle Fehler, die nicht vom externen Dienstleister gelöst werden können, werden weiterhin vom internen 2nd Level Support bearbeitet.

Nachdem Optimierung und Effizienzsteigerung ein laufender Prozess ist, kann es immer wieder zu Anpassungen im Workflow kommen. So kann das Ergebnis von internen Analysen sein, dass es mehrere Kontaktversuche benötigt, um den Kunden zu erreichen. Gerade Unternehmen, die im B2C Bereich tätig sind, werden das festgestellt haben. Oft ist dem Endkunden einfach nur wichtig, dass alles wieder funktioniert, eine detaillierte Lösungsbeschreibung ist für sie nicht relevant – und deswegen reagieren sie gar nicht mehr auf die Anrufe. Als IT-Dienstleister will man jedoch sicherstellen, dass das Problem zur Zufriedenheit der Kunden gelöst wurde. Daher kann man festlegen, dass es drei Kontaktversuche seitens des Supportcenters geben muss, bevor das Ticket von „Abnahme“ auf „Erledigt“ gesetzt wird. Falls der Kunde zu einem späteren Zeitpunkt meint, er wurde nie über die Lösung informiert, sind die entsprechenden Informationen im Ticket dokumentiert.

Aufbau einer Knowledge-Base

Es kann sehr aufwändig sein, Wissen innerhalb eines Unternehmens zusammen zu tragen und allen Mitarbeiterinnen und Mitarbeitern zur Verfügung zu stellen. Oft wird bereits vorhandenes Wissen nicht berücksichtigt und „verwertet“, sondern es werden Informationen mühsam recherchiert und in einer Plattform gesammelt. Gerade im Supportcenter eines Unternehmens entsteht Wissen durch die Lösung der Probleme und Fehler, die von Kunden gemeldet werden. Dieses Know How kann bei der Bearbeitung künftiger Tickets hilfreich sein und sollte dem Supportcenter zum Beispiel in einem Wiki zur Verfügung gestellt werden. Lösungswege, die der Kunde selber vornehmen kann, können in Self Services wie FAQs einfließen. Damit die interne als auch externe Knowledge-Base laufend mit Informationen aktualisiert werden, muss dieses Wissen aus den Tickets gezogen werden. Dafür erfolgt beim Abschließen eines Tickets eine Bewertung durch den Supportmitarbeiter oder die –mitarbeiterin, ob die Lösung relevant ist, um ins Wiki oder in die FAQs aufgenommen zu werden.

Umfragen über interne Kanäle

Um die Zufriedenheit von Kunden zu erheben, gibt es viele Möglichkeiten. Man kann ein Call Center beauftragen, alle Kunden anzurufen und zu befragen oder Umfragen per Mail schicken. Wie eingangs schon erwähnt, hat das Supportcenter viel Kundenkontakt. Dieser Touchpoint eignet sich gut, die Kundenzufriedenheit zu erheben. So kann bei der Abnahme der Lösung abgefragt werden, wie zufriedenstellend die Problemlösung für den Kunden ist. Erst wenn das Kundenfeedback eingetragen ist, kann das Ticket abgeschlossen werden.

Aber auch andere Informationen können bei diesem Kundenkontakt erhoben werden, wie zum Beispiel die Nutzung von Self-Services. Einfache Problemlösungen sind oft in Wikis oder FAQs abgebildet. Wird dem Supportcenter ein Fehler gemeldet, der in Self-Services abgebildet ist, kann der Mitarbeiter oder die Mitarbeiterin den Kunden fragen, ob dieser Lösungsversuch bereits unternommen wurde. Auf diese Weise erfährt das Unternehmen, wie intensiv dieses Angebot genutzt wird oder ob diese überarbeitet werden müssen, weil sie für den Kunden nicht hilfreich sind. Nachdem Self-Services das Supportcenter entlasten, sollten Unternehmen ihre Kunden auf diese Hilfe zur Selbsthilfe aufmerksam machen.

Diese Anwendungsbeispiele zeigen, wie Pflichtfelder, die an den Status eines Tickets geknüpft sind, das Supportcenter und den Workflow unterstützen können. Natürlich stellt sich jetzt die Frage, warum man diese Felder nicht gleich vorweg als Pflichtfelder definiert, unabhängig vom Ticketstatus. Das ist aus mehreren Gründen nicht sinnvoll, unter anderem weil:

• Manche Informationen machen erst zu einem bestimmten Zeitpunkt Sinn. Wird ein Ticket aus irgendeinem Grund abgebrochen, ist eine Bewertung, ob der Lösungsweg für eine Knowledge-Base relevant ist, nicht notwendig.
• Manche Informationen werden nur eine Zeitlang erhoben. Werden die Self-Services einer Prüfung unterzogen, wird nur im Erhebungszeitraum die Frage gestellt, ob der Kunde den Lösungsvorschlag in den FAQs bereits versucht hat. Erkennt man, dass zu einem bestimmten Problem weniger Meldungen zum Supportcenter gelangen, kann man daraus schließen, dass die Self-Services vermehrt genutzt werden.

Das Feature, Pflichtfelder zu definieren in Abhängigkeit vom Ticketstatus gibt jedem IT-Dienstleister die Flexibilität jederzeit Workflows anzupassen und projektrelevante Informationen aus diesem Kundenkontakt zu erheben – so lange, wie der Bedarf besteht.