Dokumentation sichert Erfahrungswissen
Professioneller Support bedeutet, Fachwissen und Erfahrungswissen zu kombinieren in der Ticketsoftware
Kunden erwarten in von einem anspruchsvollen Support vor allem eins, schnelle Hilfe. Wenn möglich eine direkte Lösung für ihre Anfrage/Incident (Störung), mindestens jedoch einen Workaround oder eine verbindliche Zusage, wann ihnen geholfen wird. Diese Erwartung fordert viel ab von einem technischen Supportmitarbeiter, dem ganzen Helpdesk Team. Sind sie doch eher Generalisten und haben eben nicht auf alle Fragen sofort eine Antwort parat. Hier hilft eine gut gefüllte Wissensdatenbank, die im Idealfall in das Ticketsystem/Servicesoftware integriert ist. Doch das Wissen einer Wissensdatenbank muss erstmal aufgebaut werden. Erfahrungswissen ebenso wie Fachwissen.
Die Bereitstellung von Bedienungsanleitungen, Dokumentationen und sonstigen Beschreibungen allein macht noch keine Wissensdatenbank aus. Ein Supportteam nährt sich vor allem vom Erfahrungswissen, wie verhält sich Produkt A im Anwendungskontext B bei Kunde D unter folgenden Bedingungen…? Und welche Lösungsschritte haben unter diesen oder ähnlichen Bedingungen schon mal geholfen die Störung zu beheben/den Incident zu lösen? Antworten auf solche Fragen sind der eigentliche Supportschatz und Datenbasis für die Wissensdatenbank. Dieses Wissen lässt sich am ehesten durch gut und zeitnah erfasste Tickets ableiten, die einen gewissen Redaktionsprozess durchlaufen. Die Ticketqualität, also inhaltliche Aussagefähigkeit, ist dazu Voraussetzung. Denn ein Ticket mit dem Eintrag „Kunde ist wieder happy, hatte diverse Fragen, die ich alle beantworten konnte“ hilft keinem und erzeugt kein Wissen.
Mit einer gut ausgestatteten und leicht bedienbaren Servicesoftware mit integrierter Wissensdatenbank können Mitarbeiter ihre Lösungskompetenz voll ausspielen. Kombiniert mit dem Erfahrungswissen und der richtigen Anwendung der analytischen Problemlösung, findet sich so deutlich schneller eine adäquate Lösung für die Störung/Anfrage des Kunden als mit viel Fragerei bei den Kollegen, ob sie diesen Fall schon mal hatten. Serviceteams / Supportteams sichern so ihr Erfahrungswissen und werden schneller/professioneller schon im 1st-Level. Die Erstlösungsquote beginnt zu steigen, im Sinne der Kunden wird schnelle Soforthilfe somit wahrscheinlicher. Mindestens steigt die Vorqualifizierung der Tickets und somit ist im 2nd Level ein schnelleres Arbeiten möglich.
Wie erreicht man Ticketqualität?
Was gehört in ein Ticket?
Neben der Beschreibung, wer den Fall meldet (Melder) und wer den „Schaden“ (Betroffener) hat, sollte das Ticket alle Informationen enthalten, die die Störungs-/Anfragesituation bestmöglich beschreiben:
- Priorität (Ermittelt aus Auswirkung und Dringlichkeit)
- Betroffenes Produkt/Komponente
- Zeitstempel
- Eingangskanal (Telefon, Mail, Chat usw.)
- Betreff
- Beschreibung aktuelle Situation
- Lösungs-/Bearbeitungsschritte
- Tatsächliche Lösung
Wie sieht eine hilfreiche Beschreibung im Ticket aus?
Ein Ticket sollte den Incident so gut wie möglich umfassend beschreiben, dabei jedoch kurz und strukturiert bleiben, um allen Beteiligten eine schnelle Aufnahme der Situation zu ermöglichen:
- Welche Komponente/Hard-/Software ist betroffen?
- Unter welchen Bedingungen?
- Führt zu welchem Verhalten?
- Was wurde bereits versucht?
- Ist das Verhalten reproduzierbar oder tritt nur sporadisch auf?
- Tritt es nur am aktuellen Arbeitsplatz auf oder auch anderen (könnte also auch Bedienfehler sein)?
Wie wird die Priorität im Ticket richtig ermittelt?
Die Priorität wird in der Regel ermittelt/abgeleitet aus der Dringlichkeit und der Auswirkung. Dabei wird betrachtet, wie dringend es für den User ist und auf einer Skala von z. B. 1-3 eingestuft. So kann ein Incident eines Mitarbeiters durchaus dringend sein, wenn er eine geschäftskritische Situation vor sich hat z. B. eine Präsentation für einen strategisch wichtigen Kunden. Dieser Incident würde zwar als „Einzelausfall“ in der Auswirkung beschrieben, also niedriger Priorisiert als ein Produktionsausfall. Er kann jedoch durch die Dringlichkeit hoch gestuft werden.
- Die Dringlichkeit ist meist getrieben vom Kunden und seiner zu erledigenden Aufgaben (zeitliche Betrachtung)
- Die Auswirkung lässt sich aus IT-Sicht oft leichter bestimmen, dabei soll vor allem betrachtet werden, wie viele sind betroffen und welche Auswirkung hat es auf die weitere Arbeit / Produktion (Totalausfall/Teilausfall/Einzelausfall/Bedienungsfrage/Andere)
- Die Priorität ergibt sich aus der Kombination von Dringlichkeit und wird meist vom Ticketsystem aus einer hinterlegten Matrix abgeleitet/vorgeschlagen)
Wann wird ein Ticket dokumentiert?
Diese Frage ist eigentlich mit einem kurzen Satz zu beantworten: Die besten und effizientesten Ergebnisse erreichen Sie mit sofortiger Dokumentation.
Denn ein Ticket, welches Sie erfassen, „wenn Zeit“ ist, hat dann schon ein hohes Interpretationsrisiko und steht bis dahin vor allem keinem anderen zur Verfügung, der Support ist nicht aussagefähig.
Wie wird aus einem Ticket "Wissen" in der Wissensdatenbank?
Eine Wissensdatenbank befüllt sich im Idealfall aus dem Wissen, welches Sie in Ihrem Ticketsystem durch Tickets erzeugen. Es gibt mehrere Wege, dieses Wissen/Ticket in die Wissensdatenbank zu überführen:
- Ticket wird als Wissenseintrag vorgeschlagen per „Haken“
- Redakteure durchsuchen regelmäßig Tickets nach hilfreichen Impulsen
- Wissensdatenbank durchsucht direkt Tickets nach Wissen
- Mitarbeitende erarbeiten selbst einen Wissenseintrag, wenn sie nichts passendes gefunden haben
In der Praxis wird es oft eine Mischung aus diesen Punkten sein. In jedem Fall ist es empfehlenswert, eine Art Redaktionsprozess festzulegen. Entweder über definierte Redakteure oder nach dem KCS Prinzip – jeder ist Redakteur und kann mitgestalten.
Knowledge Templates - Erfahrungswissen strukturieren
Wenn aus einem Ticket ein strukturierter Wissenseintrag werden soll
Eine Checkliste für den Aufbau und die Gestaltung eines Wissenseintrags hilft – ein sogenanntes Knowledge Template – um eine gleichbleibende Struktur für Wissenseinträge im Ticketkontext zu erreichen.
Im Idealfall können Sie ein solches Knowledge Template tatsächlich als Vorlage in Ihrer Wissensdatenbank hinterlegen und mit dem Ticketsystem verknüpfen. So machen Sie es Ihren Servicemitarbeitern leicht, aus einem Ticket direkt einen Wissenseintrag zu erzeugen.
