Inhaltsverzeichnis

 

1. Vorwort Inhalt

Wikipdia listet als ersten Absatz im Artikel „Ticketsystem„:

Ein Issue-Tracking-System (TTS; Synonyme: Help-Desk-System, Serviceticket-System, Ticketing-System, Task-Tracking-System, Support-Ticketing-System, Trouble-Ticket-System, teilweise auch Fallbearbeitungssystem) ist eine Art von Software, um Empfang, Bestätigung, Klassifizierung und Bearbeitung von Kundenanfragen (Tickets bzw. Fälle) zu handhaben. Als Anfragen werden eingehende Kundenanrufe, E-Mails, Faxe und ähnliches betrachtet.

Wichtigstes Feature hierbei ist der zentrale Anlaufpunkt für eingehende Anfragen; ein Kunde oder ein firmeninterner Mitarbeiter bei größeren Firmen weiß im Allgemeinen nicht, welche Einzelperson sein Anliegen am ehesten bearbeiten kann. Mit Hilfe eines Ticketsystems können die Anfragen kanalisiert den richtigen Personen im Unternehmen zugeleitet werden; außerdem speichert das System im Allgemeinen zu jeder Anfrage Historie und Eingaben aller Beteiligten. Es ist so wegen der durchgeführten „Visualisierung“ von Arbeitsabläufen sehr einfach möglich, bestehende Strukturen zu prüfen und zu überarbeiten.

2. Wünschenswerte Features Inhalt

In diesem Kapitel möchte ich Ihnen Features vorstellen, die ein einfacher gestricktes Ticketsystem mindestens besitzen sollte. Es muss sowohl für den Helpdesk-Mitarbeiter („Agenten“) wie auch für den Anfragenden („Kunden“) sehr einfach und übersichtlich zu bedienen sein.

2.1 Plattform Inhalt

An den Rechner von Kunde und Agent dürfen keine großen Erwartungen gestellt werden, Betriebssystem und Benutzerrechte können beliebig breit gestreut sein. Es ist daher sicherzustellen, dass das System ohne Installation auskommt und auf möglichst vielen Plattformen läuft. Eine webbrowserbasierte Oberfläche für den Benutzer / Administrator erscheint zweckmäßig, auf der Serverseite sollte eine SQL-Datenbank die Speicherung der Inhalte übernehmen.

Die größte Entwicklergemeinde hat derzeit wahrscheinlich PHP, an Open-Source-Datenbanken erscheint MySQL mit seiner InnoDB-Storage-Engine sehr ausgereift und für die Zwecke optimal geeignet.

2.2 Benutzer-Schnittstelle Inhalt

Wie eingangs bereits erwähnt, sollte die GUI für Agenten webbasiert sein und auf allen modernen Browsern ungefähr gleich aussehen, zumindest aber die gleichen Funktionalitäten anbieten. Kunden oder reguläre Mitarbeiter der Firma sollten sich per Mail an eine zentrale eMail-Adresse an den Helpdesk wenden können, es bietet für den Kunden drei Vorteile:

• Dokumentation: Im eMail-Ausgang des eMail-Programms des Kunden liegt die gesendete Mail zur Dokumentation und Nachvollziehbarkeit bereit.
• Spam-Bekämpfung: Mail-Filter zum Blockieren von unerwünschten Nachrichten sind relativ ausgereift; andere Schnittstellen wären gegen unerwünschte Kontaktaufnahme möglicherweise nicht so robust.
• Einfachheit: Der Kunde muss nicht die Bedienung einer neuen grafischen Oberfläche erlernen, sondern kann sein gewohntes eMail-Programm benutzen.

Das System wird deswegen ein oder mehrere eMail-Postfächer benötigen. Optimal wäre es, wenn einzelne Abteilungen jeweils auch eigene Adressen bzw. Postfächer eingerichtet bekommen könnten, sodass z.B. Mails an die Systemadministratoren an „sysadmin@domain.tld“ und Fragen an Redakteure an „redaktion@domain.tld“ geschickt werden können; trotzdem sollten beide Postfächer in einem System zusammen laufen, damit gegebenenfalls Anfragen aus anderen Bereichen bzw. Abteilungen innerhalb des selben Tickets beantwortet werden können, ohne dass erneut eMails versendet werden müssen.

Antworten an den Kunden sollten dann von der gewohnten Adresse („sysadmin@“ und „redaktion@“) abgeschickt werden können, wobei im Namensfeld (RFC2822) der Sachbearbeiter genannt werden kann, oder -sofern gewünscht- die Mail im Auftrag geschickt werden kann.

2.3 Automatische Antworten. Inhalt

Für Kunden wäre es unter Umständen wünschenswert, über die Bearbeitungsschritte seines Tickets informiert zu werden. Zumindest aber der Erhalt der Anfrage sollte dem Kunden bestätigt werden; einen Statusübergang bei Rückfragen in andere Abteilungen oder 2nd-Level-Support kann für den Kunden Klarheit schaffen und Last vom 1st-Level-Support nehmen („Was ist mit meiner Anfrage XYZ geschehen?“).

2.4 Standardantworten für Agenten Inhalt

Für häufig wiederkehrende Anfragen sollten Agenten in der Lage sein, vordefinierte Texte möglicherweise mit Datei-Anhängen (z.b. Bedienungsanleitungen) auszuwählen und dem Kunden als Antwort zu schicken. Es läßt sich so Arbeitszeit einsparen. Die Standardantworten sollten selbstverständlich vor dem Absenden noch bearbeitet werden können.

Auch wäre es gut, für verschiedene Support-Levels jeweils gleiche Standardantworten definieren zu können bzw. Letztere in mehreren Queues anbieten zu können.

2.5 Status und Prioritäten Inhalt

Selbstverständlich muss ein Ticket verschiedene Status (u-Deklination, deswegen lautet der Plural „Status“ mit langem „u“) zulassen, die unterschiedlich zu visualisieren sind:

• Der erste Status eines Tickets wird wohl „offen“ oder ähnlich sein, eben genau dann, wenn die Anfrage neu erstellt wurde. Zusätzlich kann, wie bei Mails üblich, noch ein Zusatzflag definiert werden, das das Vorhandensein neuer (=ungelesener) Texte innerhalb des Tickets anzeigt.
• Sofern nach Beantwortung eines Tickets die Schwierigkeit aus Sicht des Agenten gelöst ist, sollte das Ticket geschlossen werden. Es ist somit ein Status „geschlossen“ zu definieren.
• Sollte der Kunde noch eine Antwort nachliefern müssen, könnte man, anstatt das Ticket zu schließen, einen Zwischenstatus („warten“) definieren, welcher anders gekennzeichnet wird, damit der Agent weiß, dass hier auf eine Antwort vom Kunden gewartet wird.
• Zu guter Letzt muss ein Ticket auch gesperrt werden können, damit Agenten besonders bei mehreren Agenten pro Queue nicht zwei das gleiche Ticket bearbeiten. Gesperrte Tickets können außer vom „Sperrer“ nur gelesen werden.

Jeder Agent sollte selbst aussuchen können, welche Status er bei Tickets sehen möchte. Der 1st-Level-Support etwa würde wohl nur die „offenen“ Tickets sehen wollen; Mitarbeiter einer Fachabteilung aber haben möglicherweise so wenig Tickets, dass sie auch die geschlossenen aufgelistet bekommen möchten.

Eine wichtige Frage ist die der Prioritäten. Das vorliegende Ticketsystem verzichtet bewußt auf Prioritäten für Tickets, da:

• zu klären wäre, wer die Prioritäten setzen darf.
• sich das System von einem Bugtracker unterscheiden soll.
• es im Gegensatz zum Status keine handfesten Kriterien für die Einordnung in eine bestimmte Prioritätsstufe gibt.
• Möglicherweise vom Datum her „hinten liegende“ oder neuere Tickets mit ähnlichem Inhalt eine höhere Priorität bekommen müßten. Mit anderen Worten: Um die Priorität richtig zuweisen zu können, müßten immer alle neuen offenen Tickets inhaltlich durchsucht werden.
• Die Anzahl von Stufen wohl nicht ganz klar sein würde. Sind es 3 (eMail) oder 5 (OTRS Standard)?

Es erscheint mir daher zweckmäßig, von Anfang an auf Prioritäten zu verzichten.

2.6 Persönliche Queues Inhalt

Im Konkurrenzprodukt OTRS kann jedem Agenten ein Ticket zugewiesen werden; die Bearbeitung ist dann nur noch durch diesen Mitarbeiter möglich. Die Tickets bleiben aber in der entsprechenden Queue liegen. Ich finde das unübersichtlich und verfolge den Ansatz, dass auch Agenten eine eigene persönliche Queue haben können; prinzipiell unterscheidet sich diese nicht von anderen Queues, kann aber nur von dem einen Agenten bearbeitet werden.

Persönliche Queues sollten per Standard grundsätzlich flach im Queue-Baum liegen; jeder Agent kann aus Gründen der Übersicht aber einzelne persönliche Queues ausblenden. Es werden also nur die persönlichen Queues der engeren „Mit-Agenten“ oder bekannter Mitarbeiter aus anderen Abteilungen angezeigt statt alle Mitarbeiter des Systems.

2.7 Anbindung für Kundendaten Inhalt

Eine sehr wichtige Frage ist die der Integration von Kunden der Firma. Es gilt folgende Fragen zu klären:

• Sollten Kunden eine Oberfläche bekommen mit allen ihren bisherigen Anfragen?
• Wie würden sie sich registrieren?
• Können / Sollen / Dürfen wir als Firma Daten aus dem CRM importieren oder Anfragen in dieses überspielen?
• Was geschieht bei unvollständigen Kundendaten oder nicht im CRM vorhandenen Fragestellern?

Nach viel Diskussion in größeren Runden und Gesprächen mit Firmen, die bereits solche Lösungen einsetzen, erscheint es sinnvoll, auf eine Anbindung an einen Firmen-LDAP-Server oder das CRM zu verzichten. Einerseits sind rechtliche Fragen zum Datenschutz nicht einfach zu beantworten, wenn Daten ohne Einwilligung in mehrere Systeme überspielt werden sollen. Andererseits besteht immer die Schwierigkeit der Verfügbarkeit, wenn das angebundene System ausgefallen ist und z.B. Kundendaten nicht gelesen werden können.

Es sollte daher von vorneherein möglichst auf eine saubere Implementierung mit unbekannten Kundendaten (Name, Vorname, usw.) geachtet werden; optional könnte versucht werden, aus dem Mailtext bestimmte Informationen zu extrahieren.

Das System an sich sollte aber Stand-Alone laufen können, da im Zweifelsfalle genau ein angebundenes System das ist, das ausgefallen ist und für das die Support-Anfrage gilt.

2.8 Bemerkungen zur Oberfläche Inhalt

Die Benutzeroberfläche muss sehr einfach und intuitiv bedienbar sein. Insbesondere 2nd- und 3rd-Level Support hat möglicherweise nicht die Erfahrung oder Zeit, Fehler und Imperformanzen des Systems durch manuelle Arbeit auszugleichen.

Es empfiehlt sich daher, sich möglichst an „Industriestandards“ zu orientieren. Einen guten Ansatz dafür bietet die Oberfläche von Outlook, sie ist mit der gut verständlichen Anordnung der einzelnen Bereiche (Ordner, Ordnerinhalt, Mailtext) und ihrer Symbolik auch für Laien gut verständlich.

Weiters sollte die Oberfläche ein optisches Feedbeck bieten, sofern der Benutzer eine Aktion auslöst oder mit der Maus über Bedienelemente fährt.

Besonderes Augenmerk ist auf die Mailfunktionen zu legen. Insbesondere müssen:

• Verschiedene Zeichensätze (Unicode, ISO9660, Latin, usw.) einwandfrei erkannt werden.
• HTML-Mails als solche erkennbar, in Nur-Text umgewandelt und mit entsprechenden Anhängen versehen werden.
• Anhänge korrekt dekodiert und mit richtigen Dateinamen versehen werden.
• bei Antworten die Benutzer unbedingt zur Vermeidung von TOFU animiert werden.
• mehrere unterschiedliche Bildschirmauflösungen und Webbrowser unterstützt werden.