Modulkonfiguration
Tickets
Das Herzstück des Service-Managements, Tickets, Incidents, Anfragen. Templates steuern, welche Fragen erscheinen, Typen verknüpfen Workflow und SLA, das Routing findet die richtige Workgroup.
Aktualisiert am 18. Mai 2026
Konfiguration · Module · 4.9
Das Modul Tickets ist die Engine hinter jeder Meldung, Incidents, Service Requests, Knowledge-Base-Fragen, Change Requests. Drei Objekte arbeiten hier zusammen: Der Tickettyp steuert Workflow und SLA, das Ticket-Template bestimmt, welche Fragen der Einreichende sieht, und das Routing liefert es an die richtige Workgroup.
Warum das für das Business zählt
„Tickets bleiben hängen“
SLA pro Tickettyp + Eskalationsregeln → niemand kann sie „vergessen“.
„Einreichende vergessen die Hälfte“
Das Ticket-Template erzwingt Pflichtfelder, bevor das Ticket erstellt wird.
„Das falsche Team bekommt es“
Routingregel nach Kategorie/Standort/Asset → automatische Zuweisung an die Workgroup.
„Statusangaben sagen nichts“
Workflow pro Tickettyp → „In Bearbeitung · Wartet auf Kunden · Bereit zur Prüfung · Geschlossen“, kein vages „offen“.
Die drei Konfigurationsobjekte
Tickettyp
Kategorie des Tickets: Incident · Service Request · Change · Wissensfrage · Beschwerde. Steuert Workflow (siehe Building Blocks → Workflows) und SLA.
Ticket-Template
Welche Fragen an die einreichende Person gehen, Beispiele: „Laptop defekt“ fragt nach dem Asset-Tag, „Problem im Besprechungsraum“ nach dem Raum. Reduziert Freitext.
Routingregeln
Bedingung → Workgroup. „Kategorie = IT-Hardware → Workgroup IT-L1“. Stapelbar mit Fallback.
Standardfelder eines Tickets
| Feld | Wozu |
|---|---|
| Titel & Beschreibung | Die Frage oder das Problem. KI nutzt sie für Vorschläge. |
| Einreichende/r / Antragsteller | Wer das Ticket erstellt hat. Kann von der Endnutzerin abweichen (z. B. legt der Empfang stellvertretend an). |
| Tickettyp | Steuert Workflow und SLA. |
| Klassifikation | Hierarchische Kategorisierung (siehe Building Blocks → Klassifikationen). |
| Priorität | Auswirkung × Dringlichkeit (Matrix) oder frei setzbar, vereinbart in 4.6. |
| Workgroup / Bearbeiter | Wer es übernimmt. Über Routing abgeleitet oder explizit gesetzt. |
| Bezogenes CI / Standort | Welches Asset oder welcher Raum betroffen ist. |
| Status & SLA-Uhr | Status aus dem Workflow; SLA zeigt die verbleibende Zeit, pausiert bei „Wartet auf Kunden“. |
| Anhänge & Kommunikation | Screenshots, Fotos, E-Mail-Verläufe, alles auf derselben Timeline. |
Welche Entscheidungen treffen Sie?
Welche Tickettypen unterscheiden Sie?
Klein halten, 3 bis 6 Typen. Zu viele = niemand wählt richtig.
Templates frei oder geführt?
Template-first für spezifische Flows (defekter Laptop, Badge-Anfrage). Freitext für „Sonstiges“ mit Routing über die Klassifikation.
Wer setzt die Priorität?
Einreichende (schnell, neigt zu „alles ist P1“) oder automatisch über Matrix (strukturiert, erfordert Schulung).
Darf die Endnutzerin ihr Ticket selbst schließen?
Bei Service Requests okay; bei Incidents meist der Bearbeiter, das hält die Kennzahlen zur Lösungszeit im Griff.