© balakate , 123RF

Mit Ticketsystemen bewältigen Kundendienste und Supportmitarbeiter zahlreicher Unternehmen die Probleme ihrer Kunden und Anwender schnell und effizient. Wie es um die Benutzerfreundlichkeit dieser Systeme steht, untersucht der Test anhand einiger quelloffener Vertreter der Sparte.

Über Ticketsysteme fangen Mitarbeiter in mittelständischen und großen Unternehmen die Sorgen und Probleme ihrer Kunden, die etwa per E-Mail oder Telefon hereinflattern, effizient ab. Sind mehrere Mitarbeiter im Support tätig, befördert ein Ticketsystem im Idealfall Synergien und beschleunigt die Problemlösung an Kundenarbeitsplätzen.

Doch wie steht es um die Benutzerfreundlichkeit und die Ausstattung der einzelnen Systeme für die Supportmitarbeiter? Das hat sich das Linux-Magazin für Zammad [1], Request Tracker [2], OTRS [3] und Kix [4] angesehen.

Zammad

Das noch junge Projekt Zammad [1] ist eine Clean-Sheet-Entwicklung unter Federführung des OTRS-Entwicklers Martin Edenhofer (siehe auch Artikel “Trouble as a Service”), die unter der GNU-AGPL-Lizenz steht. Die Web-basierte Client-Server-Applikation erfreut Mitarbeiter dank HTML-5-Einsatz nicht nur durch ein optisch aktuelles Erscheinungsbild. Auch die Bedienfreundlichkeit ist hoch, Zammad fühlt sich eher wie eine native Desktopanwendung an.

Bedienungskonzept

Im Webbrowser erscheint Zammad als moderne dreigeteilte Oberfläche, die links eine vertikale Taskleiste in Gestalt von App-Tabs aufweist. Diese Tabs, die vor allem Tickets repräsentieren, bringt der Anwender frei in eine von ihm gewünschte Reihenfolge, um Ordnung ins Chaos zu bringen. Änderungen innerhalb der Tabs speichert Zammad sofort auf dem Server. Es stellt den aktuellen Zustand wieder her, sobald ein Nutzer den Browser neu öffnet oder sich über eine andere Maschine anmeldet. Auch erst halb eingegebene Ticketbeschreibungen gehen so nicht verloren.

Die Oberfläche sieht nicht für alle Agenten, so heißen die Ticketsystem-Mitarbeiter, gleich aus. Sales- und Support-Mitarbeiter sitzen durchaus vor unterschiedlich komplexen Oberflächen, wenn der Admin dies so einrichtet.

Zammads Kollisionserkennung signalisiert, wenn zwei Agenten am selben Ticket arbeiten. Änderungen an Tickets hebt Zammad optisch hervor, indem es in der linken Leiste die Icons farblich anpasst. Dabei erfordern Änderungen nicht – wie sonst bei Webanwendungen üblich – einen Reload der Seite: Der Zammad-Server führt automatisch einen Push auf die beteiligten Clients durch, sobald es Änderungen an einem Ticket gibt (Abbildung 1).

Abbildung 1: Zammad bietet übersichtliche Optionen, um Vorfälle zu überwachen und zu bearbeiten.

Rechts im Browserfenster befindet sich vertikal eine Streamleiste, die von oben nach unten die Änderungen im Ticketsystem verfolgt (Abbildung 1). Hier sehen die Mitarbeiter sofort, welcher Kollege an welchem Ticket gearbeitet hat. Auch diese Leiste aktualisiert Zammad bei neuen Aktionen umgehend ohne einen Reload der Browserseite.

Wählt der Agent einen Eintrag im Stream aus, der eine Aktivität eines Mitarbeiters oder Kunden visualisiert, blendet das Programm eine Statistikseite zu dem betroffenen Nutzer ein. Über die Schaltfläche »Aktion« oben rechts in der statistischen Ansicht und einen anschließenden Klick auf »Historie« im Drop-down-Menü betrachtet der Nutzer die letzten Aktivitäten der Person in Zammad.

Klickt er in der Streamleiste auf eine Mitteilung über eine automatische Aktion des Systems, öffnet sich die Ticketansicht. Die zeigt im mittleren Fenstersegment die ausgewählten Tickets und absolvierten Aktionen an. Wählt er im linken Bereich eines seiner Tickets aus, erscheinen mittig alle relevanten Daten dazu und er bearbeitet es weiter.

Rechts im Fenster blendet das System beim Bearbeiten eines Tickets einige wichtige Informationen zu diesem ein. Dazu zählen zum Beispiel der aktuelle »Status«, der »Besitzer« des Tickets oder die »Priorität«. Die entsprechenden Felder lassen sich ändern. Beispielsweise kann der Nutzer ein Ticket auf Wunsch über diesen Dialog schließen, sobald er das jeweilige Problem behoben hat.

Dashboard

Zammad verzweigt nach dem Einloggen aber zunächst in das Dashboard (Abbildung 2) und dort in die Gruppe »Meine Statistik«, die dem Überblick dient. Hier sieht der Bearbeiter anhand aussagekräftiger Symbole im zentralen Fensterbereich die ihm zugewiesenen Tickets. Er erfährt, ob Tickets Eskalationsstufen erreicht haben. Der Überblick verrät auch Bearbeitungszeiten für Fälle, den prozentualen Anteil bearbeiteter oder die Zahl wieder geöffneter Tickets.

Abbildung 2: Das Dashboard von Zammad zeigt dem Agenten einige statistische Daten an.

Außerdem ist zu erkennen, welches Medium Mitarbeiter und Kunden für die Kommunikation verwenden. Den entsprechenden Kanal listet Zammad in kleinen vertikalen Balken auf. Neben dem Telefon und der E-Mail stehen hier auch ein Chat und soziale Netzwerke zur Wahl – das Ticketsystem lässt sich sehr flexibel einsetzen.

Zammad bietet außerdem die Option, Service Level Agreements (SLA) zu verwalten und – damit einhergehend – Response-Zeiten zu überwachen. Über das Zahnradsymbol links unten im Fenster erreicht der Nutzer die für ihn konfigurierten Verwaltungsdialoge. In denen ruft er die Service Level Agreements über den gleichnamigen Eintrag in der neu eingeblendeten Gruppenleiste auf.

Hier gibt der Agent in einem überlappenden Dialog die entsprechenden Daten ein. Für das automatisierte Monitoring nimmt der Anwender in der Leiste »Verwalten« zusätzlich eine Zeiterfassung und Automatisierungen zu frei definierbaren Vorgängen vor.

Request Tracker

Das vom US-amerikanischen Unternehmen Best Practical Solutions LLC vertriebene Ticketsystem Request Tracker (kurz RT, [2]) ist auch eine Client-Server-Applikation, die ein Web-basiertes Interface bereitstellt. Während die Kunden primär per E-Mail Anfragen an RT richten, arbeiten der Administrator und die Mitarbeiter Web-basiert im Browser. Dadurch lassen sich auch mobile Systeme verwenden.

Ticket-Übersicht

Das Browser-Interface wirkt optisch etwas nüchtern und angestaubt. Request Tracker legt anhand der eingehenden E-Mails selbsttätig Tickets an, die sich die Mitarbeiter im Webinterface entweder selbst zuweisen oder die ihnen ein Administrator aufdrückt.

Bearbeitet ein Mitarbeiter ein Ticket, protokolliert die Software alle Aktionen mit, was dank der Zeitstempel später eine genaue Rekonstruktion der Ticketgeschichte erlaubt. Im Startbildschirm nach dem Einloggen zeigt die Software zunächst noch nicht zugewiesene Tickets an sowie verschiedene Informationen zu Tickets, die der angemeldete Mitarbeiter bereits bearbeitet.

Abbildung 3: Das Startfenster von Request Tracker zeigt nach Gruppen kategorisiert die aktuellen Tickets an.

Im oberen linken Bereich erscheinen hoch priorisierte Tickets. Ein sofortiger Einstieg ist somit sowohl mit einem neuen Ticket als auch mit einem noch nicht abgeschlossenen Vorgang möglich. In der oben im Browser angeordneten Menüleiste kann der Mitarbeiter jeweils Optionen in verschiedenen Menüs aufrufen, die auch dem Monitoring und Reporting dienen (Abbildung 3).

Klickt der Agent auf ein Ticket, erscheinen in einem weiteren Bildschirm zahlreiche wichtige Angaben zu diesem Ticket in einem Bearbeitungsbildschirm.

Bearbeitungsfenster

RT bietet im Rahmen der Ticketbearbeitung mehrere Statusdefinitionen, die dem Monitoring und dem Reporting dienen. So wechselt der Status eines Tickets in der Gruppe »Grundlagen« je nach Bearbeitungsstand. Der beginnt beim Anlegen (Status »neu«) und reicht bis zum Schließen oder Löschen eines Tickets. Der Agent ändert den Status über ein Drop-down-Menü.

Zu den Grundlagen gehört auch, den geschätzten Zeitbedarf für die Bearbeitung eines Tickets für das spätere Billing zu definieren.

Zusätzlich tragen Support-Mitarbeiter für das Reporting rechts im Bildschirm in der Gruppe »Datumsangaben« alle relevanten Daten mitsamt den entsprechenden Uhrzeiten ein. Über diesen Dialog verwalten Mitarbeiter zugleich nach vorheriger Definition Tickets nach SLA-Vorgaben.

Relation und Historie

Um jedes Ticket in Relation zu einem Vorgang zu setzen, bietet die Software in der Gruppe »Personen« links im Fenster die Option, alle Beteiligten einzutragen. Im Bereich »Erinnerungen« tragen die Mitarbeiter zudem feste Termine ein, um Fristen nicht zu verpassen. Hängt das Ticket noch von anderen Vorgängen ab, so kann der Bearbeiter diese im Segment »Beziehungen« vermerken.

Abbildung 4: Das Überwachen einzelner Tickets ist sehr gut gelöst.

Eine Historie bietet die Software im unteren Bereich des Bearbeitungsbildschirms in der Rubrik »Verlauf«. Der listet in Tabellenform sämtliche Aktionen auf, die im Kontext zum jeweiligen Ticket stehen (Abbildung 4).

Menüs

Über die Menüs »Reports« und »Werkzeuge« stellt der Mitarbeiter individuelle Listen für das Reporting und sein Monitoring zusammen. Im ersten Menü warten Optionen, die die Aktivitäten des Nutzers betreffen. Über das Menü »Werkzeuge« lässt er sich Ticket-bezogene Listen zur Erinnerung, zur täglichen Arbeit oder zu Freigaben von Tickets am Bildschirm anzeigen. Die Listen darf er bearbeiten oder mit Kommentaren versehen.

OTRS

Das unter der GNU-AGPL-Lizenz stehende OTRS-Ticketsystem [3] bietet seinen Anwendern ebenfalls eine Web-basierte Oberfläche und ermöglicht dadurch den Plattform- und Geräte-übergreifenden Zugriff auf den Helpdesk. Supportanfragen nimmt der Mitarbeiter dabei entweder per E-Mail, Telefon oder über ein ebenfalls Web-basiertes Frontend beim Kunden entgegen.

Das Webfrontend gestattet nicht nur die Einsicht in die vorhandenen Tickets, sondern auch deren Bearbeitung. Eine Web-RTC-Schnittstelle ermöglicht einen direkten Videokontakt zwischen Kunde und Mitarbeiter, und die E-Mail-Kommunikation lässt sich über PGP oder S/MIME verschlüsseln.

Mitarbeiter fassen in OTRS bei Bedarf mehrere gleichartige Tickets zusammen, um so den Bearbeitungsaufwand zu verringern. Eine optional installierbare Wissensdatenbank unterstützt die Agenten dabei. Sie enthält auch Textbausteine, die beim Bearbeiten von Tickets und dem Aufsetzen von damit zusammenhängenden Kundenbenachrichtigungen helfen.

Interface

OTRS zeigt gleich nach dem Anmelden wichtige Informationen in einer Übersicht: Hier findet der Agent tabellarisch seine gesperrten, eskalierten, offenen und neuen Tickets. Ein Doppelklick auf eines zeigt nähere Informationen.

Abbildung 5: Monitor und Statistik in einem – das OTRS-Hauptfenster.

Rechts in einer vertikalen Statistikleiste stößt er auf eine kleine grafisch aufbereitete Statistik zu seiner Arbeit: Sie zeigt die neu angelegten und geschlossenen Tickets der letzten sieben Tage (Abbildung 5). Mitarbeiter erhalten so stets einen Überblick ihrer Aktivitäten. Über den Menüpunkt »Tickets« im Browser ändern sie jederzeit die Ansicht, um so Kategorien-basiert Prozesse nachzuvollziehen.

Reporting

OTRS gibt den Mitarbeitern eine leistungsfähige Reporting-Funktion an die Hand. Dazu steht im Übersichtsbildschirm oben in der Menüleiste die Option »Berichte« bereit. Hier erhält der Anwender über den Eintrag »Statistiken« einen schnellen Überblick über bereits vorhandene Module. Diese listet OTRS tabellarisch auf. Zusätzlich ergänzt der Mitarbeiter über die Schaltfläche »Hinzufügen« eigene Listen.

Listenreich

Klickt der Mitarbeiter rechts auf einen der »Start«-Buttons hinter den einzelnen Listen, öffnet die Software ein Einstellungsfenster, in dem er verschiedene Optionen zur Listenanlage festlegt. Dabei darf er über ein Auswahlfeld entweder Grafiken oder eine CSV-Datei zum Weiterbearbeiten erzeugen. Zusätzlich lässt sich die Statistik ausdrucken.

Hat der Mitarbeiter alle Optionen eingestellt und auf »Jetzt ausführen« geklickt, legt OTRS die Statistik an und zeigt sie – falls es sich um eine Grafik handelt – im Programmfenster (Abbildung 6).

Abbildung 6: Zu allen relevanten Vorgängen generiert OTRS auf Wunsch auch Reports aus Statistiken.

Aus den Statistiken fertigen die Mitarbeiter bei Bedarf auch Reports an. Dazu wählen sie im Menü »Berichte« die gleichnamige Option und legen nach einem Klick auf »Hinzufügen« oben links im Fenster einen neuen Bericht mit individuellen Einstellungen an. In ihn dürfen auch die Daten aus mehreren Statistiken einfließen. Ein Klick auf »Speichern« stellt eine PDF-Datei zusammen, welche die Daten optisch ansprechend aufbereitet.

Reports lassen sich zudem auch automatisch anlegen. OTRS erzeugt sie dann in regelmäßigen Zeitabständen, ohne dass der Mitarbeiter jedes Mal die Statistikdaten selbst anfassen muss.

Kix

Das ebenfalls unter der AGPL stehende und von dem Chemnitzer Unternehmen Cape IT GmbH entwickelte Kix [4] ist ein Fork von OTRS 5. Das noch recht junge Produkt ist ebenso eine Web-basierte Client-Server-Applikation. Nach dem Start erscheint im Browserfenster die Oberfläche. Die erinnert noch stark an OTRS mit ihrem sehr ähnlich aufgebauten Dashboard mit tabellarisch untergliederten Tickets und rechts im Fenster einer vertikal angeordneten Statistik. Weil sich Kix bislang optisch stark an OTRS anlehnt, finden sich OTRS-Agenten sofort in Kix zurecht und brauchen keine Einarbeitung (Abbildung 7).

Abbildung 7: Optisch und auch funktionell gleicht Kix dem OTRS noch fast wie ein Ei dem anderen.

Das Produkt der Cape IT GmbH bietet gegenüber OTRS derzeit vor allem den Vorteil der MRO-Version. Die Abkürzung steht für Maintenance, Repair, Overhaul, die Version soll insbesondere das produzierende Gewerbe unterstützen. Mit an Bord sind einige zusätzliche Module, die sich etwa um das Wartungs-Management oder das Field Service Management kümmern, bei dem es darum geht, Geräte vor Ort beim Kunden zu betreuen.

Für die neue Version 18 des Ticketsystems Kix, die Ende des Jahres 2018 erscheinen soll, haben die Entwickler ein komplettes Redesign der optisch etwas angestaubt wirkenden Bedienoberfläche mit Verbesserungen für den Workflow angekündigt.

In der nach Redaktionsschluss (im Oktober 2018) zu erwartenden Variante 17.4 soll Kix zudem in der Lage sein, die Volltextsuche auch auf Anhänge auszuweiten.

Fazit

Alle vier vorgestellten Ticketsysteme stellen die Supportmitarbeiter vor keinerlei größere Probleme in Sachen Einarbeitung und Benutzerführung. Unterschiede finden sich vor allem in den Details und den Ausrichtungen des jeweiligen Systems.

Das jüngste Produkt – Zammad – bietet Agenten nicht nur die modernste und zugleich am einfachsten zu bedienende Oberfläche. Es besticht auch dank der Integration von sozialen Netzwerken als Channel-Medium für den Helpdesk – ein Alleinstellungsmerkmal. Hier haben die Mitbewerber Nachholbedarf.

Während Request Tracker beim Überwachen Ticket-bezogener Vorgänge punktet, bieten OTRS und Kix die meisten Konfigurationsmöglichkeiten, um Statistiken und Reports zu erzeugen.

Die beiden letzten ähneln sich dabei noch stark, die Zukunft des OTRS-Forks Kix ist noch offen. 2019 soll die Software mit einer optisch aufgefrischten und einfacher zu bedienenden Oberfläche erscheinen. Zudem soll sich das System noch stärker an die Erfordernisse des industriell produzierenden Gewerbes und des Gebäudemanagements anpassen.