Ticketsystem: Kundenanliegen als Vorgang mit Status und Verlauf

Ein Ticketsystem ist eine Software, die jedes Kundenanliegen als nummerierten Vorgang führt: mit Status, zuständiger Person, vollständigem Schriftverkehr und internen Notizen. Es beantwortet zu jedem Zeitpunkt drei Fragen: Was ist offen, wer kümmert sich darum, und was hat der Kunde zuletzt vom Betrieb gehört?

Ticketsystem: Begriff und Aufbau eines Tickets

Der Begriff stammt aus dem IT-Support, wo Störungen seit Langem so verwaltet werden. Heute arbeiten auch Servicebetriebe, Großhändler mit Reklamationsgeschäft und technische Dienstleister damit, bei denen ein Anliegen mehrere Tage und mehrere Hände durchläuft.

Ein Ticket besteht im Kern aus wenigen Feldern:

• Nummer. Eindeutig und für den Kunden sichtbar, damit sich jede Rückmeldung zuordnen lässt.
• Kunde und Bezug. Kontakt und, falls vorhanden, der Auftrag, das Gerät oder die Lieferung, um die es geht.
• Status und Zuständigkeit. Wo der Vorgang steht und wer ihn gerade in der Hand hat.
• Verlauf. Nachrichten nach außen, Anrufe als Notiz und interne Absprachen in zeitlicher Folge.

Das Ticket beginnt, wenn ein Anliegen angenommen ist. Wie Anfragen davor erfasst, zugeordnet und qualifiziert werden, beschreibt Anfragemanagement.

Ticketsystem, CRM oder gemeinsames Postfach

Die drei Werkzeuge überschneiden sich, verfolgen aber verschiedene Zwecke. Ein gemeinsames Postfach verteilt Nachrichten, kennt aber keinen Vorgang: Es weiß nicht, ob eine Mail eine neue Frage ist oder die dritte Nachfrage zum selben Schaden. Ein CRM ordnet Kontakte, Firmen und Verkaufschancen; seine Stärke ist die Geschichte einer Kundenbeziehung, nicht die Abarbeitung eines einzelnen Problems. Das Ticket-Werkzeug organisiert Arbeit an Anliegen, die einen Anfang und ein Ende haben.

Festmachen lässt sich die Unterscheidung an einer Frage: Was wird gezählt? Im Postfach sind es Nachrichten, im CRM Kunden und Geschäfte, in der Ticketlösung erledigte Anliegen. Viele Betriebe brauchen zwei dieser Sichten, selten alle drei als getrennte Programme.

Statuswerte, Zuweisung und Schriftverkehr

Ein Status sollte eine Handlung auslösen, nicht nur einen Zustand beschreiben. Bewährt hat sich eine kurze Liste:

1. Neu. Noch niemand hat das Anliegen übernommen.
2. In Arbeit. Eine benannte Person ist zuständig.
3. Wartet auf Kunde. Eine Rückfrage ist gestellt; der Ball liegt beim Kunden.
4. Wartet auf Dritte. Ersatzteil, Hersteller oder Spedition fehlen noch.
5. Gelöst. Der Betrieb hält das Anliegen für erledigt und hat das mitgeteilt.
6. Geschlossen. Der Kunde hat bestätigt, oder die vereinbarte Frist ist ohne Widerspruch verstrichen.

Zugewiesen wird nach Fachgebiet, Region oder Kundengruppe, und zu jeder Zuständigkeit gehört eine benannte Vertretung.

Technisch hält eine Kennung den Schriftverkehr zusammen. Das Programm setzt die Vorgangsnummer in den Betreff jeder ausgehenden E-Mail; antwortet der Kunde, erkennt es die Nummer und hängt die Nachricht an den bestehenden Vorgang, statt einen neuen anzulegen. Ergänzend werten viele Lösungen die Kopfzeilen In-Reply-To und References aus, die E-Mail-Programme ohnehin mitschicken. Interne Notiz und Antwort an den Kunden stehen im selben Verlauf, aber nur eine verlässt das Haus, und die Oberfläche muss diesen Unterschied unübersehbar machen.

Ebenso wichtig ist, wer geantwortet hat. In einem Praxisfall war bei ausgehenden Kundenkontakten der Absender fast nirgends gespeichert, sodass keine Auswertung sagen konnte, wer einem Kunden geschrieben hatte. Die dort eingeführte Regel lässt sich übertragen: Hat ein Mensch gesendet, ist er der Autor; hat ein Automat verfasst und verschickt, ist es der Automat; das Postfach, über das die Nachricht lief, ist nie der Autor. Wo sich der Absender nicht ermitteln lässt, bleibt das Feld leer, denn ein erfundener Eintrag schadet mehr als eine Lücke.

Wann eigene Tickets nötig sind und wann Aufgaben im CRM genügen

Die Frage ist weniger technisch als organisatorisch. Für ein eigenes Werkzeug sprechen:

• Anliegen ziehen sich über mehrere Kontakte und Personen, etwa bei Reklamationen, Wartung oder Gewährleistungsfällen.
• Kunden fragen regelmäßig nach dem Stand ihres Anliegens.
• Der Betrieb will wissen, welche Arten von Problemen wie oft auftreten.
• Mehrere Standorte oder Schichten teilen sich dieselbe Arbeit.

Gegen ein zusätzliches Programm spricht, wenn Anliegen meist mit einer Antwort erledigt sind oder dieselben zwei Personen alles bearbeiten. Dann genügen Aufgaben im CRM mit Fälligkeit und Zuständigkeit, und der Betrieb vermeidet eine zweite Kundenliste. Passen weder CRM noch fertige Lösung zum eigenen Ablauf, etwa weil Geräte, Einsatzorte und Ersatzteile verknüpft werden müssen, bleibt eine schlanke Fachanwendung als dritter Weg.

Typische Fehler

• Zweite Wahrheit neben dem CRM. Kundendaten werden im Ticket-Werkzeug neu angelegt, statt aus dem CRM zu kommen. Nach kurzer Zeit weichen Adressen und Ansprechpartner voneinander ab.
• Geschlossen heißt nicht gelöst. Wer Vorgänge schließt, sobald die eigene Arbeit getan ist, zählt Erfolge, die der Kunde nicht bestätigt hat. Seine erneute Nachfrage erscheint dann als neues Anliegen.
• Der Kunde sieht nichts. Ohne Statusmeldung nach außen ruft er an, und jeder Anruf erzeugt genau die Arbeit, die das Werkzeug sparen sollte.
• Zu viele Kategorien. Was niemand pflegt, liefert keine Auswertung, sondern Rauschen.
• Telefonate bleiben draußen. Wird nur der Schriftverkehr erfasst, fehlt oft der entscheidende Teil des Verlaufs; eine CTI-Telefonie-Integration schreibt Anrufe automatisch zum Vorgang.

Wie wir Servicevorgänge abbilden

Wir prüfen zuerst, ob das vorhandene CRM den Serviceweg mit Aufgaben tragen kann, bevor ein weiteres Programm dazukommt. Wo es das nicht kann, prüfen wir bei einer vorhandenen Ticketlösung, ob sie eine Schnittstelle bietet, über die sie mit dem CRM verbunden werden kann. Andernfalls entwickeln wir eine Fachanwendung, die Kundendaten aus dem CRM liest, Statusmeldungen verschickt und bei jeder ausgehenden Nachricht den Absender festhält. Den Rahmen dafür beschreibt die Seite Softwareentwicklung.