Ein Ticketsystem einführen, das nach drei Monaten noch benutzt wird

In fast jedem Fall, den wir gesehen haben, war die Software nicht das Problem. Gescheitert ist die Einführung daran, dass der alte Weg offen blieb. Solange Kunden weiter an persönliche Adressen schreiben und Kollegen weiter im Türrahmen fragen, ist das Ticketsystem eine zusätzliche Arbeit – kein Ersatz für eine bestehende. Der zweite häufige Fehler ist Überstrukturierung: Wer vor dem ersten Ticket fünfzehn Kategorien, vier Prioritäten und drei Eskalationsstufen festlegt, hat ein Modell gebaut, das mit der Wirklichkeit nichts zu tun hat und das niemand pflegt.

Fangen Sie mit der Struktur an, die es ohnehin schon gibt – den Abteilungen. Support, Technik, Buchhaltung: jedes Team ein eigenes Postfach mit eigener Adresse. Damit ist die wichtigste Frage beantwortet, nämlich wer zuständig ist, und zwar ohne dass jemand etwas zuordnen muss. Kategorien, Prioritäten und Fristen kommen später, wenn Sie an echten Vorgängen sehen, welche Unterscheidungen wirklich gebraucht werden. Diese Reihenfolge ist der Unterschied zwischen einem System, das die Arbeit abbildet, und einem, dem die Arbeit folgen soll.

In dieser Zeit entstehen die Gewohnheiten, gegen die Sie später nicht mehr ankommen. Praktisch heißt das: täglich zehn Minuten in die Liste der unbeantworteten Vorgänge sehen, jede Anfrage, die am System vorbeikam, freundlich zurück ins System holen, und jede Woche einmal fragen, was gestört hat. Was in dieser Phase auffällt, sind meist Kleinigkeiten – eine Signatur mit der falschen Adresse, ein Formular auf der Webseite, das noch woanders hinschreibt. Genau die entscheiden über den Erfolg.

Die Zahl der Tickets sagt fast nichts: Sie steigt, wenn das System angenommen wird, und das ist gut. Aussagekräftig sind drei andere Größen. Erstens der Anteil der Vorgänge, die im System landen statt daneben – schätzbar über die Zahl der Mails, die noch an persönliche Adressen gehen. Zweitens die Zeit bis zur ersten Antwort, nicht bis zur Lösung. Drittens die Zahl der Vorgänge, die mehr als zweimal die Zuständigkeit wechseln; das ist der zuverlässigste Hinweis auf eine unklare Struktur.

Zwei Fälle sind ehrlich schwierig. Der erste: mehrere Standorte mit gewachsenen, unterschiedlichen Abläufen. Hier hilft nur, zuerst einen Standort vollständig umzustellen und den zweiten danach – parallel geht es fast nie gut. Der zweite: eine bestehende Wissenssammlung, die übernommen werden soll. Erfahrungsgemäß ist die Hälfte davon veraltet; die Übernahme ist eine redaktionelle Aufgabe, keine technische, und sie dauert länger als die gesamte Einrichtung. Wer das vorher weiß, plant es ein statt sich zu wundern.