Benutze Pflichtfelder im Ticket sparsam. So bleibt der Service Desk schnell und sauber

Ein Ticketformular soll den Service Desk entlasten. Wenn jedes zweite Feld Pflicht ist, passiert oft das Gegenteil. Nutzer raten, schreiben Platzhalter oder brechen ab, bevor der Betrieb überhaupt weiß, was passiert ist.

Pflichtfelder sind Felder, die ein Nutzer ausfüllen muss, bevor er ein Ticket absenden kann. Sie sollen Mindestinformationen sichern, zum Beispiel betroffenen Service, Kontaktweg, Dringlichkeit oder eine kurze Beschreibung. Für ITSM-Generalisten ist die Kernfrage deshalb nicht, wie viele Felder ein Formular technisch abfragen kann. Entscheidend ist, welche Information wirklich vor dem ersten Kontakt nötig ist und welche später sauberer im Ablauf ergänzt wird.

Ein Pflichtfeld ist eine Hürde im Meldeweg

Jedes zusätzliche Pflichtfeld wirkt wie eine kleine Schranke. Eine Schranke kann sinnvoll sein, wenn ohne diese Information keine Bearbeitung möglich ist. Sie wird aber schädlich, wenn der Nutzer die Antwort nicht kennt oder erst recherchieren müsste. Dann entstehen Fantasiewerte, wiederholte Standardtexte oder Auswahlentscheidungen, die später niemand mehr ernst nimmt.

Gerade im Service Desk zählt der erste saubere Kontakt. Ein Formular muss schnell genug sein, damit Störungen, Anfragen und Rückfragen überhaupt im richtigen Kanal landen. Wenn der Meldeweg schwerer wirkt als eine Chatnachricht oder eine Direktmail an einen bekannten Techniker, verliert das Ticketformular seine Steuerungsfunktion. Die Organisation bekommt dann zwar ein formal schönes Formular, aber weniger verlässliche Eingangsdaten.

Am Anfang zählen nur steuernde Informationen

Sparsame Pflichtfelder sind nicht gleich oberflächliche Pflichtfelder. Sie konzentrieren sich auf die Angaben, die sofort eine Folgehandlung auslösen. Dazu gehören meist der betroffene Service oder Themenbereich, eine verständliche Problembeschreibung, Erreichbarkeit, gewünschter Zeitpunkt und ein grober Einfluss auf Arbeit oder Kunden. Diese Felder helfen bei Routing, Priorisierung und Rückfrage.

Andere Informationen können wichtig sein, müssen aber nicht zwingend vor dem Absenden kommen. Kostenstelle, genaue Gerätekennung, umfangreiche Fehlercodes, interne Projektbezeichnung oder betroffene Schnittstelle sind oft erst nach einer ersten Einordnung sinnvoll. Wenn solche Felder zu früh verpflichtend sind, verschiebt der Prozess Arbeit auf Personen, die den Kontext gerade nicht haben. Das Formular wird scheinbar vollständiger, die Datenqualität aber schlechter.

Gute Formulare erklären, warum sie etwas fragen

Atlassian zeigt für Jira Service Management, dass Felder je Request-Typ angepasst werden können, damit Kunden nur die für ihre Anfrage relevanten Angaben sehen. Die Nutzererfahrung bleibt dabei entscheidend. Die Nielsen Norman Group weist in ihren Form-Design-Empfehlungen darauf hin, dass Formulare klar, kurz und verständlich sein müssen, damit Nutzer sie zuverlässig abschließen. Microsoft dokumentiert in Power Apps, dass Spalten als optional, empfohlen oder erforderlich markiert werden können. Diese Unterscheidung ist auch für ITSM-Formulare hilfreich.

Ein Feld muss also nicht sofort Pflicht sein, nur weil die Information irgendwann nützlich wäre. Besser ist eine sichtbare Begründung: „Diese Angabe brauchen wir, um den richtigen Supportweg zu wählen“ oder „Ohne Rückrufnummer verzögert sich die Bearbeitung bei Rückfragen“. Solche Hinweise machen die Hürde nachvollziehbar. Sie zeigen auch, ob das Feld wirklich steuernd ist oder nur aus Gewohnheit im Formular steht.

So prüfst Du Pflichtfelder im Ticketformular

• Streiche jedes Pflichtfeld, das nicht vor der ersten Bearbeitung gebraucht wird.
• Trenne Pflichtangaben von empfohlenen Angaben und späteren Bearbeitungsfeldern.
• Teste das Formular mit typischen Nutzern, nicht nur mit Prozessverantwortlichen.
• Prüfe abgebrochene Formulare, Platzhalterwerte und häufige Rückfragen als Qualitätssignal.
• Erkläre bei wichtigen Pflichtfeldern kurz, welche Folgehandlung davon abhängt.

Ein guter Praxistest lautet: Kann ein normaler Nutzer das Ticket in zwei Minuten absenden, ohne interne Systemnamen, Kostenstellenlogik oder Fehlercodes zu kennen? Wenn nein, sollte das Formular nicht härter, sondern klüger werden. Der Service Desk braucht am Anfang genug Information für Routing und Priorität. Alles Weitere gehört in den Bearbeitungsdialog, in dynamische Folgefragen oder in interne Felder.

So bleibt das Ticketformular ein Steuerungswerkzeug statt ein Abschreckungsformular. Wenige gute Pflichtfelder führen zu besseren Eingängen, schnelleren Rückfragen und weniger Schattenkanälen. Genau das hilft dem Service Desk mehr als eine lange Maske, die formal vollständig wirkt, aber im Alltag falsche oder erfundene Daten sammelt.

Quellen und Einordnung: Atlassian Support zu Feldern in Request Types, Nielsen Norman Group zu Web Form Design, Microsoft Learn zu Spalten und Feldanforderungen in Power Apps. Stand der Quellenprüfung: 24.07.2026. Bildquelle: Pexels / Foto-ID 5699456 / C00 Lizenz.