Wo der gemeinsame Posteingang den Service Desk ausbremst

Ein gemeinsamer Posteingang wirkt wie eine einfache Lösung. Eine Adresse ist schnell eingerichtet, mehrere Personen können antworten, und niemand muss sofort ein neues Formular, ein Portal oder eine Automatisierung erklären. Genau deshalb bleibt so ein Postfach in Support, Fach-IT und Betrieb oft länger im Einsatz als geplant. Aus der Übergangslösung wird ein verdeckter Arbeitskanal neben dem Service Desk.

Verantwortung verschwindet zuerst

Der erste Bremsklotz entsteht bei der Verantwortung. In einem Ticket ist sichtbar, wer den Fall besitzt, wann er eingegangen ist, welche Priorität gilt und welche nächste Aktion offen ist. Im Postfach sieht man oft nur gelesene und ungelesene Nachrichten, Weiterleitungen, Markierungen oder Antwortketten. Das reicht für Kommunikation, aber nicht für verlässliche Steuerung. Wenn mehrere Personen glauben, jemand anders habe die Mail schon übernommen, verliert der Betrieb Zeit.

Der zweite Punkt ist die Messbarkeit. Ein Service Desk braucht mehr als eine beantwortete Nachricht. Er muss wissen, wie schnell Anfragen aufgenommen werden, welche Themen häufig auftreten, wo Eskalationen hängen bleiben und ob vereinbarte Zeiten eingehalten werden. Ein Postfach kann solche Signale nur begrenzt liefern. Es zeigt Kommunikation, aber nicht automatisch Bearbeitungsstatus, Kategorie, Auswirkung, Priorität und Abschlussqualität.

Störungen brauchen früher ein Ticket

Besonders kritisch wird es bei Störungen. Eine Mail mit dem Betreff „geht nicht“ kann harmlos sein oder mehrere Nutzer betreffen. Wenn sie im gemeinsamen Postfach liegen bleibt, fehlt der Moment, in dem daraus ein Störungsticket mit Auswirkung, Dienstbezug und Eskalationsweg wird. Der Service Desk bekommt dann nicht nur eine späte Meldung. Er bekommt auch weniger Kontext, weil Rückfragen und Zwischenantworten bereits in einer Mailkette verstreut sind.

Das heißt nicht, dass gemeinsame Posteingänge verboten sind. Sie können sinnvoll sein, wenn sie klar begrenzt werden. Ein Postfach eignet sich für Vorabfragen, externe Kontaktpunkte oder seltene Themen, solange es eine Regel gibt, wann daraus ein Ticket werden muss. Diese Regel sollte einfach sein. Alles mit Störung, Nutzerwirkung, Berechtigung, Bestellung, Änderung oder Frist wandert in den Service Desk. Alles, was nur Information oder Abstimmung ist, darf im Postfach bleiben.

Ein Owner hält die Grenze sichtbar

Damit die Grenze funktioniert, braucht das Postfach einen Owner. Diese Rolle prüft nicht jede Mail selbst, sondern sorgt für Regeln, Sichtbarkeit und Aufräumdisziplin. Wer darf antworten? Welche Antwortvorlagen sind erlaubt? Wann wird weitergeleitet? Welche Nachrichten werden täglich in Tickets überführt? Wie lange darf eine Mail ohne Zuordnung liegen? Ohne diese Mindestregeln wird das Postfach zum Schattenprozess, der zwar Arbeit enthält, aber nicht sauber geführt wird.

Auch die Nutzerkommunikation muss ehrlich sein. Wenn ein Postfach nur für Rückfragen gedacht ist, darf es nicht wie ein vollwertiger Supportkanal beworben werden. Sonst erwarten Nutzer dort dieselbe Verbindlichkeit wie im Service Desk, bekommen aber weniger Transparenz. Ein kurzer Hinweis in Signatur, Intranet oder Autoantwort kann viel Reibung vermeiden: Für Störungen und verbindliche Anfragen bitte den Service Desk nutzen, dieses Postfach dient nur der Abstimmung.

Die Bestandsaufnahme zeigt Schattenprozesse

Für ITSM-Teams lohnt sich deshalb eine kleine Bestandsaufnahme. Welche Funktionspostfächer nehmen echte Arbeit entgegen? Welche davon haben eine Ticketregel? Wo werden SLAs, Eskalationen oder Berechtigungen außerhalb des Service Desk entschieden? Und welches Postfach muss nicht abgeschafft, sondern nur sauber an den Ticketprozess angebunden werden?

Der praktische Maßstab ist einfach. Ein gemeinsamer Posteingang darf Kommunikation erleichtern, aber er sollte keine Arbeit verstecken. Sobald dort steuerungsrelevante Fälle entstehen, braucht es eine sichtbare Übergabe in den Service Desk. Das kann man klein beginnen: eine tägliche Sichtung, eine eindeutige Ticketregel, ein kurzer Hinweis für Nutzer und ein Owner, der Ausnahmen nachhält. Sonst bremst das Postfach nicht wegen schlechter Absicht, sondern weil es Verantwortung, Priorität und Fortschritt nicht so zeigt, wie Betrieb sie braucht.

Quellen und Stand

• Google Workspace Admin-Hilfe, Collaborative Inboxes, abgerufen am 11.07.2026: Collaborative Inboxes
• Atlassian Support, Jira Service Management E-Mail-Anfragen, abgerufen am 11.07.2026: Receive requests from an email address
• Atlassian, Help Desk und Service Request Management, abgerufen am 11.07.2026: Help desk and service request management