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öglichst 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.

Autor des Artikels:
Marilla Bax
Vertrieb & Beratung
Schlagworte zum Artikel: