Vom Sammelpostfach zum Ticketsystem: der Umstieg ohne Bruch

Fast jede Verwaltung hat es: ein geteiltes Postfach, in das Anfragen laufen. Für den IT-Support, für den Bauhof, für die Öffentlichkeitsarbeit, für das Gebäudemanagement. Zwei bis fünf Personen greifen darauf zu, beantworten, was sie können, und verschieben den Rest in Unterordner. Das funktioniert erstaunlich lange.

Der Kipppunkt kommt nicht durch eine bestimmte Menge an Mails, sondern durch eine bestimmte Menge an Menschen.

Die vier Anzeichen

Doppelbearbeitung. Zwei Kollegen beantworten dieselbe Anfrage, weil beide sie gesehen und keiner sie markiert hat. Der Absender bekommt zwei Antworten, im schlechteren Fall mit unterschiedlichem Inhalt.

Die Frage nach dem Stand ist nicht beantwortbar. Jemand ruft an und fragt, was aus seiner Meldung von vorletzter Woche geworden ist. Um das zu beantworten, muss jemand das Postfach durchsuchen — und findet, wenn es gut läuft, die Mail, aber nicht, was daraus wurde.

Abwesenheit blockiert Vorgänge. Ein Kollege hat einen Vorgang in Arbeit, kommuniziert darüber aus seinem persönlichen Postfach und ist zwei Wochen krank. Der Vorgang existiert für die anderen nicht.

Niemand kennt die Zahlen. Wie viele Anfragen kommen im Monat? Was sind die drei häufigsten Themen? Wie lange dauert eine Antwort im Schnitt? Diese Fragen sind aus einem Postfach nicht beantwortbar — und ohne sie lässt sich weder Personal begründen noch eine Verbesserung belegen.

Wer drei dieser vier Punkte kennt, hat den Kipppunkt hinter sich.

Die Fehler, die den Umstieg kippen

Zu viele Felder von Anfang an. Kategorie, Unterkategorie, Priorität, Dringlichkeit, Auswirkung, betroffenes System, Standort, Kostenstelle. Wenn das Anlegen eines Tickets länger dauert als das Erledigen der Aufgabe, wird es nicht angelegt. Die Kollegen weichen zurück ins Postfach aus, und das System ist tot, bevor es lief.

Beginnen Sie mit dem Minimum: Wer meldet, was ist das Anliegen, wer bearbeitet, welchen Status hat es. Alles weitere lässt sich ergänzen, wenn sich zeigt, wofür es gebraucht wird.

Kategorien am Reißbrett. Ein durchdachter Katalog aus fünfundzwanzig Kategorien trifft die Wirklichkeit fast nie. Nach einem halben Jahr sind achtzehn davon leer und die drei meistgenutzten heißen Sonstiges. Besser: mit fünf groben Kategorien starten und nach drei Monaten anhand der tatsächlichen Tickets verfeinern.

Das Postfach parallel weiterlaufen lassen. Solange beide Wege offen sind, wird der bequemere genutzt. Das Postfach sollte deshalb nicht abgeschaltet, aber umgeleitet werden: Eingehende Mails erzeugen automatisch ein Ticket. Dann ändert sich für die Absender nichts, während intern alles an einem Ort landet.

Die Historie wegwerfen. Alte Vorgänge müssen nicht migriert werden, aber sie sollten auffindbar bleiben. Das Postfach im Lesezugriff zu belassen genügt dafür meist.

Was ein Ticket mindestens leisten muss

Damit der Umstieg spürbar entlastet, braucht jedes Ticket vier Eigenschaften:

1. Eine Nummer, die nach außen kommuniziert wird. Sie beendet die Suche bei jeder Rückfrage. Sie gehört in die automatische Eingangsbestätigung und in den Betreff jeder weiteren Nachricht.
2. Genau einen Verantwortlichen. Ein Ticket, das einer Gruppe gehört, gehört niemandem. Eine Gruppe kann Eingangskorb sein, nicht Bearbeiter.
3. Einen Status, der etwas aussagt. Drei bis fünf Werte reichen. Wichtig ist ein eigener Status für Vorgänge, die auf eine Rückmeldung von außen warten — sonst stehen sie als offen in der Statistik und verzerren jede Auswertung.
4. Den gesamten Schriftwechsel am Vorgang. Antworten aus dem persönlichen Postfach sind der häufigste Grund, warum ein Ticketsystem nach einem Jahr nur noch halb gefüllt ist.

Was Sie nach drei Monaten wissen

Der Nutzen, den niemand vorher einplant, sind die Zahlen. Nach einem Quartal lassen sich Aussagen treffen, die vorher Behauptungen waren:

• Wie viele Anfragen kommen tatsächlich, verteilt über Wochentage und Monate.
• Welche drei Themen erzeugen die Hälfte des Aufkommens — und damit: wo lohnt sich eine Anleitung, eine Schulung oder eine technische Änderung mehr als weitere Bearbeitung.
• Wie lange dauert die erste Reaktion, und wie lange die Erledigung.
• Wie viele Vorgänge werden wieder geöffnet, weil die Lösung nicht getragen hat.

Der zweite Punkt ist der wertvollste. Wenn ein Drittel aller Tickets dieselbe Ursache hat, ist die Lösung selten mehr Personal, sondern eine Änderung an der Ursache.

Der realistische Zeitplan

Ein Umstieg dieser Art scheitert nicht an der Software, sondern an der Gewöhnung. Ein Ablauf, der in der Praxis trägt:

• Woche 1 bis 2: Kategorien grob festlegen, Postfach umleiten, Team einweisen. Keine Berichte, keine Auswertungen, keine Automatik.
• Woche 3 bis 8: Betrieb, mit einer wöchentlichen kurzen Runde, was hakt. In dieser Phase entstehen die Anpassungen, die wirklich gebraucht werden.
• Ab Monat 3: Kategorien nachschärfen, erste Auswertungen, gegebenenfalls Selbstbedienung für Melder öffnen.

Wer die dritte Phase vorzieht, landet bei den Fehlern aus dem vorigen Abschnitt.

Häufige Fragen

Müssen die Melder sich anmelden? Für den Anfang nicht. Eine Mail an die bekannte Adresse genügt und senkt die Hürde. Ein Portal mit Anmeldung lohnt sich, sobald Melder ihren Stand selbst einsehen sollen.

Was ist mit telefonischen Meldungen? Die gehören genauso ins System, angelegt von der Person, die den Anruf annimmt. Sonst entsteht ein blinder Fleck, der ausgerechnet die dringenden Fälle enthält.

Brauchen wir Prioritäten? Erst, wenn mehr Tickets offen sind, als sich zeitnah abarbeiten lassen. Vorher ist die Priorität ein Feld, das jeder anders ausfüllt.

Wie gehen wir mit Vorgängen um, die eigentlich Projekte sind? Als eigenen Vorgangstyp führen oder gar nicht ins Ticketsystem nehmen. Ein Ticket, das neun Monate offen steht, macht jede Auswertung unbrauchbar.