Ticket-Status in OFORK

Ticket-Status zeigen in OFORK, in welchem Bearbeitungsstand sich ein Vorgang befindet. Sie machen sichtbar, ob ein Ticket neu, offen, wartend, geschlossen oder entfernt ist.

Eine saubere Statusverwaltung ist wichtig, damit Agenten den Überblick behalten, Kundenanfragen nachvollziehbar bearbeitet werden und Statistiken den tatsächlichen Zustand des Service-Desks zeigen.

In diesem Guide: Bedeutung von Ticket-Status, Standardzustände, Pending-Status, Schließen, Bearbeitung, Konfiguration, Kim-KI-Unterstützung und Auswertung.

Warum Ticket-Status wichtig sind

Der Status ist eines der wichtigsten Felder in einem Ticket. Er zeigt nicht nur an, ob ein Ticket erledigt ist, sondern steuert auch Arbeitslisten, Erinnerungen, Eskalationen und Berichte.

Ticket-Status helfen bei:

klarer Übersicht über offene Vorgänge
Trennung von neuen und laufenden Tickets
Wiedervorlagen für spätere Bearbeitung
automatischem Schließen von Tickets
Eskalations- und SLA-Steuerung
aussagekräftigen Statistiken
sauberem Abschluss von Supportfällen

Ohne klare Statuslogik bleiben Tickets liegen, werden zu früh geschlossen oder tauchen in Auswertungen falsch auf.

Was ist ein Ticket-Status?

Ein Ticket-Status beschreibt den aktuellen Bearbeitungsstand eines Tickets.

Beispiele:

neu
offen
wartend
geschlossen erfolgreich
geschlossen erfolglos
zusammengeführt
entfernt

Der Status ist damit nicht dasselbe wie Priorität oder Queue. Die Queue sagt, wer zuständig ist. Die Priorität sagt, wie dringend der Vorgang ist. Der Status sagt, wo das Ticket im Bearbeitungsprozess steht.

Typische Standardzustände

OFORK kann verschiedene Standardzustände verwenden. Die genaue Bezeichnung kann je nach Konfiguration angepasst sein.

Häufige Statusarten:

Neu: Ticket wurde erstellt, aber noch nicht aktiv bearbeitet.
Offen: Ticket ist in Bearbeitung.
Wartend auf Erinnerung: Ticket ist auf Wiedervorlage gesetzt.
Wartend auf automatisches Schließen erfolgreich: Ticket wird nach Ablauf einer Frist automatisch erfolgreich geschlossen.
Wartend auf automatisches Schließen erfolglos: Ticket wird nach Ablauf einer Frist automatisch erfolglos geschlossen.
Geschlossen erfolgreich: Ticket wurde gelöst.
Geschlossen erfolglos: Ticket wurde beendet, aber nicht erfolgreich gelöst.
Zusammengeführt: Ticket wurde mit einem anderen Ticket verbunden.
Entfernt: Ticket wurde aus der regulären Bearbeitung entfernt.

Diese Zustände bilden den Lebenszyklus eines Tickets ab.

Neu

Der Status neu wird verwendet, wenn ein Ticket gerade erstellt wurde und noch keine echte Bearbeitung durch einen Agenten erfolgt ist.

Typische Fälle:

neue E-Mail-Anfrage
neues Kundenportal-Ticket
automatisch erzeugtes Ticket
importierter Vorgang ohne Agentenaktion

Neue Tickets sollten zeitnah geprüft und entweder übernommen, einer Queue zugeordnet oder durch Kim-KI vorbereitet werden.

Offen

Der Status offen bedeutet, dass ein Ticket aktiv bearbeitet wird.

Ein Ticket ist typischerweise offen, wenn:

ein Agent daran arbeitet
eine Rückfrage vorbereitet wird
interne Prüfung läuft
eine Lösung gesucht wird
Kommunikation mit dem Kunden stattfindet

Offene Tickets bilden den aktiven Arbeitsvorrat im Service Desk.

Wartend auf Erinnerung

Der Status wartend auf Erinnerung wird verwendet, wenn ein Ticket zu einem späteren Zeitpunkt wieder vorgelegt werden soll.

Beispiele:

Kunde soll später erneut kontaktiert werden
Rückmeldung eines Dienstleisters wird erwartet
ein Termin liegt in der Zukunft
interne Prüfung braucht Wartezeit

Nach Ablauf der Wartezeit erscheint das Ticket wieder zur Bearbeitung.

Wartend auf automatisches Schließen

Dieser Status wird genutzt, wenn ein Ticket nach einer bestimmten Frist automatisch geschlossen werden soll.

Typische Szenarien:

Lösung wurde angeboten und Kunde reagiert nicht
Rückfrage wurde gestellt und bleibt unbeantwortet
Vorgang soll nach Fristabschluss automatisch beendet werden

Je nach Ablauf kann das Ticket erfolgreich oder erfolglos geschlossen werden.

Geschlossen erfolgreich

Ein Ticket wird als geschlossen erfolgreich markiert, wenn das Anliegen gelöst wurde.

Beispiele:

Problem behoben
Frage beantwortet
Änderung umgesetzt
Kunde bestätigt Lösung
Vorgang fachlich abgeschlossen

Dieser Status sollte nur verwendet werden, wenn keine weitere Bearbeitung notwendig ist.

Geschlossen erfolglos

Der Status geschlossen erfolglos wird verwendet, wenn ein Vorgang beendet wurde, aber keine erfolgreiche Lösung möglich war.

Beispiele:

Anfrage nicht umsetzbar
Kunde liefert notwendige Informationen nicht
technische Lösung nicht möglich
Vorgang wurde zurückgezogen
Zuständigkeit liegt außerhalb des Supports

Dieser Status ist wichtig, damit Auswertungen zwischen gelösten und nicht gelösten Vorgängen unterscheiden können.

Zusammengeführt

Wenn zwei Tickets denselben Vorgang betreffen, kann ein Ticket mit einem anderen zusammengeführt werden.

Das ist sinnvoll bei:

doppelten E-Mails
mehreren Tickets zum gleichen Problem
parallelen Kundenanfragen
versehentlich mehrfach erstellten Tickets

Nach dem Zusammenführen sollte die Bearbeitung im führenden Ticket fortgesetzt werden.

Entfernt

Der Status entfernt kennzeichnet Tickets, die nicht mehr regulär bearbeitet werden sollen.

Mögliche Gründe:

Spam
Testticket
irrtümlich erzeugter Vorgang
fachlich ungültiger Vorgang

Entfernen sollte kontrolliert verwendet werden, damit wichtige Vorgänge nicht versehentlich aus der Bearbeitung verschwinden.

Status verwalten

Ticket-Status werden in der Administration unter den Ticketeinstellungen verwaltet. Dort können bestehende Zustände geprüft, angepasst oder neue Zustände ergänzt werden.

Typische Verwaltungsaufgaben:

Statusnamen prüfen
neue Zustände anlegen
bestehende Zustände bearbeiten
Gültigkeit setzen
Statusarten prüfen
Auswirkungen auf Prozesse und Statistiken kontrollieren

Änderungen an Statuswerten sollten sorgfältig geplant werden, weil viele Funktionen darauf aufbauen.

Statusarten

Ein Status hat nicht nur einen Namen, sondern auch eine technische Art. Diese Art bestimmt, wie OFORK den Status behandelt.

Typische Statusarten:

neu
offen
geschlossen
wartend
zusammengeführt
entfernt

Die Statusart ist wichtiger als der sichtbare Name. Sie steuert, ob ein Ticket als offen, geschlossen oder wartend gilt.

Neuen Status anlegen

Ein neuer Status sollte nur angelegt werden, wenn ein echter Prozessbedarf besteht.

Vorher prüfen:

Reichen vorhandene Statuswerte aus?
Welche Statusart ist fachlich richtig?
Soll der Status in Statistiken erscheinen?
Gibt es Automatisierungen oder Regeln dazu?
Verstehen Agenten den neuen Status eindeutig?

Zu viele Statuswerte machen den Prozess unübersichtlich.

Status bearbeiten

Bestehende Statuswerte können bearbeitet werden. Dabei ist besondere Vorsicht bei produktiven Systemen notwendig.

Vor einer Änderung prüfen:

Wird der Status in Tickets verwendet?
Gibt es Reports mit diesem Status?
Gibt es Prozessregeln?
Wird der Status in Automatisierungen genutzt?
Gibt es SLA- oder Eskalationsbezug?

Wenn ein Status bereits produktiv verwendet wird, sollte er nicht ohne Prüfung umbenannt oder deaktiviert werden.

Status umbenennen

Beim Umbenennen eines Status können Abhängigkeiten betroffen sein.

Mögliche Auswirkungen:

gespeicherte Suchen
Statistiken
Prozessregeln
Benachrichtigungen
Automatisierungen
externe Auswertungen

Empfehlung: Statusnamen nur ändern, wenn die Auswirkung klar ist und die Änderung dokumentiert wird.

Wichtige Konfigurationsoptionen

Für wartende Tickets und automatische Statuswechsel gibt es zentrale Konfigurationsmöglichkeiten.

Wichtige Beispiele:

Daemon::SchedulerCronTaskManager::Task###TicketPendingCheck

Diese Einstellung steuert, wie regelmäßig wartende Tickets geprüft werden.

Ticket::StateAfterPending

Diese Einstellung legt fest, in welchen Status ein Ticket wechseln kann, nachdem eine Wartefrist abgelaufen ist.

Solche Einstellungen sollten nicht ohne Verständnis der Auswirkungen geändert werden.

Status und Kim-KI

Kim-KI kann bei der Statusbewertung unterstützen. Die KI kann Hinweise liefern, ob ein Ticket weiter bearbeitet, auf Wiedervorlage gesetzt oder geschlossen werden kann.

Mögliche Unterstützung:

Erkennen, ob der Kunde geantwortet hat
Vorschlag für Wiedervorlage
Hinweis auf unbeantwortete Rückfragen
Zusammenfassung vor dem Schließen
Erkennung ähnlicher bereits geschlossener Fälle
Vorschlag für erfolgreichen oder erfolglosen Abschluss

Die endgültige Entscheidung sollte bei wichtigen Vorgängen weiterhin durch Agenten erfolgen.

Status und SLA

Der Status beeinflusst auch SLA- und Eskalationslogik. Ein offenes Ticket wird anders behandelt als ein wartendes oder geschlossenes Ticket.

Beispiele:

offene Tickets können eskalieren
wartende Tickets können aus bestimmten Berechnungen herausfallen
geschlossene Tickets gelten als beendet
nach Wiedereröffnung können Fristen erneut relevant werden

Deshalb muss klar sein, welcher Status fachlich und technisch verwendet wird.

Status in Statistiken auswerten

Statuswerte sind ein zentraler Bestandteil von Reports.

Sinnvolle Auswertungen:

Anzahl offener Tickets
neue Tickets pro Zeitraum
geschlossene Tickets pro Zeitraum
Tickets auf Wiedervorlage
erfolglos geschlossene Tickets
entfernte Tickets
durchschnittliche Zeit bis zum Abschluss
Statusverteilung nach Queue oder Service

Diese Auswertungen zeigen, ob Tickets sauber bearbeitet werden oder ob Vorgänge zu lange offen bleiben.

Best Practices

Empfehlungen für eine saubere Statusverwaltung:

Standardstatus möglichst beibehalten
neue Status nur bei echtem Bedarf anlegen
Statusnamen klar und kurz halten
technische Statusart sorgfältig wählen
Änderungen dokumentieren
Statuswerte regelmäßig auswerten
Kim-KI-Vorschläge kontrolliert einsetzen
geschlossene Tickets nicht als Arbeitsvorrat missbrauchen

Eine gute Statuslogik ist einfach genug für Agenten und präzise genug für Prozesse und Auswertungen.

Häufige Fehler

Typische Probleme:

zu viele Statuswerte
unklare Namen
falsche technische Statusart
Status wird für Priorität missbraucht
geschlossene Tickets werden wieder als Arbeitsliste verwendet
wartende Tickets werden nicht geprüft
Automatisierungen greifen auf falsche Statuswerte
Statistiken werden durch Umbenennungen unklar

Diese Fehler führen dazu, dass Tickets schwerer steuerbar werden.

Fazit

Ticket-Status sind in OFORK ein zentrales Steuerungselement. Sie zeigen den Bearbeitungsstand, steuern Wiedervorlagen, beeinflussen Eskalationen und bilden die Grundlage für verlässliche Statistiken.

Mit wenigen klaren Statuswerten, sauberer Konfiguration und kontrollierter Unterstützung durch Kim-KI bleibt der Ticketprozess übersichtlich, nachvollziehbar und messbar.