Ticketprioritäten in OFORK

Ticketprioritäten helfen dabei, eingehende Anfragen nach Dringlichkeit und Auswirkung einzuordnen. In OFORK steuern sie, welche Tickets zuerst bearbeitet werden sollen, welche Vorgänge besondere Aufmerksamkeit benötigen und wie Supportteams ihre Arbeit strukturieren.

Eine gute Prioritätslogik ist bewusst einfach. Wenn zu viele Stufen verwendet werden, wird die Einordnung unklar und Agenten bewerten ähnliche Fälle unterschiedlich. Für viele Service-Desks reichen drei bis fünf Prioritäten aus.

In diesem Guide: Prioritätsstufen, Verwaltung, neue Prioritäten, Gültigkeit, Kim-KI-Priorisierung, Best Practices und Auswertung.

Warum Prioritäten wichtig sind

Nicht jedes Ticket hat dieselbe Dringlichkeit. Eine Passwortfrage, ein einzelner Bedienfehler und ein kompletter Systemausfall müssen unterschiedlich behandelt werden.

Prioritäten helfen bei:

schnellerer Bearbeitung kritischer Tickets
klarer Reihenfolge im Tagesgeschäft
besserem Eskalationsmanagement
transparenter Kommunikation im Team
aussagekräftigen Statistiken
SLA-orientierter Bearbeitung

Wichtig ist, dass Prioritäten nicht als Gefühlsskala verwendet werden. Sie sollten an nachvollziehbare Kriterien gebunden sein.

Empfohlene Prioritätsstufen

Für viele OFORK-Installationen ist ein schlankes Modell sinnvoll.

Eine einfache Struktur:

Niedrig: Anfrage ohne Zeitdruck, allgemeine Rückfrage, einfache Änderung
Normal: reguläre Supportanfrage ohne akute Störung
Hoch: dringende Anfrage mit spürbarer Einschränkung
Kritisch: Ausfall, Sicherheitsproblem oder starker geschäftlicher Einfluss

Wenn Ihr Team kleiner ist oder wenige Eskalationen hat, reichen oft drei Stufen:

Niedrig
Normal
Hoch

Je weniger Stufen verwendet werden, desto einfacher bleibt die tägliche Entscheidung.

Prioritäten in OFORK verwalten

Prioritäten werden in OFORK in der Administration verwaltet. Dort können vorhandene Prioritätsstufen geprüft, angepasst oder neue Stufen ergänzt werden.

Typische Verwaltungsaufgaben:

Namen von Prioritäten prüfen
aktive und inaktive Prioritäten verwalten
neue Prioritätsstufen anlegen
bestehende Prioritäten umbenennen
nicht mehr benötigte Stufen deaktivieren
Auswirkungen auf Statistiken und Prozesse prüfen

Prioritäten sollten nicht unüberlegt geändert werden, wenn sie bereits produktiv verwendet werden. Bestehende Tickets, Berichte, Prozesse und Automatismen können auf diese Werte Bezug nehmen.

Neue Priorität anlegen

Eine neue Priorität sollte nur angelegt werden, wenn die vorhandenen Stufen nicht ausreichen.

Sinnvolle Fragen vor dem Anlegen:

Gibt es dafür ein klares Kriterium?
Können Agenten die Stufe eindeutig von anderen Prioritäten unterscheiden?
Wird diese Priorität regelmäßig verwendet?
Hat sie Auswirkungen auf SLA, Eskalation oder Reporting?
Ist der Name für alle Teams verständlich?

Beispiele für klare Namen:

Niedrig
Normal
Hoch
Kritisch

Ungünstig sind uneindeutige Namen wie “Wichtig”, “Sehr wichtig”, “Sofort” und “Top”, wenn nicht exakt geregelt ist, wann sie verwendet werden.

Prioritäten bearbeiten

Bestehende Prioritäten können angepasst werden. Dabei sollte besonders auf den Namen und die Gültigkeit geachtet werden.

Wichtige Felder:

Name: eindeutige Bezeichnung der Prioritätsstufe
Gültigkeit: legt fest, ob die Priorität verwendet werden kann

Wenn eine Priorität nicht mehr verwendet werden soll, ist Deaktivieren meist besser als Löschen. Dadurch bleiben alte Tickets und Auswertungen nachvollziehbar.

Vorsicht bei Umbenennungen

Prioritäten können in mehreren Bereichen verwendet werden.

Mögliche Abhängigkeiten:

Ticketfilter
Statistiken
Prozessregeln
automatische Zuweisungen
Eskalationsregeln
Vorlagen
gespeicherte Suchen
externe Auswertungen

Vor einer Umbenennung sollte geprüft werden, ob die Priorität in Regeln, Reports oder Prozessen verwendet wird. Sonst entstehen später schwer nachvollziehbare Fehler.

Automatische Priorisierung mit Kim-KI

Kim-KI kann OFORK bei der automatischen Priorisierung unterstützen. Dabei wird der Ticketinhalt analysiert und eine passende Priorität vorgeschlagen oder nach definierten Regeln gesetzt.

Kim-KI kann unter anderem erkennen:

Dringlichkeit aus dem Text
Hinweise auf Ausfall oder Störung
betroffene Systeme oder Services
Anzahl betroffener Personen
Eskalationsrisiko
negative Stimmung oder Beschwerde
wichtige Fristen
wiederkehrende Probleme

Beispiel:

Ein Ticket mit dem Inhalt “Unsere komplette Buchhaltung kann sich nicht mehr anmelden” ist anders zu bewerten als “Ich hätte gerne nächste Woche eine neue Signatur”.

Kim-KI kann solche Unterschiede erkennen und die Bearbeitung entsprechend vorbereiten.

Priorität nicht allein entscheiden lassen

Automatische Priorisierung ist hilfreich, sollte aber kontrolliert eingesetzt werden. Für kritische Fälle ist eine menschliche Prüfung sinnvoll.

Best Practices

Eine gute Prioritätsverwaltung ist einfach, verständlich und stabil.

Empfehlungen:

maximal drei bis fünf Prioritäten verwenden
klare Namen nutzen
jede Priorität schriftlich definieren
Beispiele für typische Fälle dokumentieren
kritische Stufen sparsam einsetzen
alte Prioritäten deaktivieren statt entfernen
Prioritäten regelmäßig auswerten
Kim-KI-Vorschläge mit echten Tickets prüfen

Prioritäten sollten nicht dazu dienen, jedes Ticket “wichtig” zu machen. Wenn zu viele Tickets als hoch oder kritisch markiert werden, verliert die Priorisierung ihren Wert.

Beispiel für Prioritätsregeln

Ein einfaches Regelmodell kann so aussehen:

Priorität	Bedeutung	Beispiel
Niedrig	kein Zeitdruck	allgemeine Frage, geplante Änderung
Normal	regulärer Supportfall	einzelner Benutzer hat ein Problem
Hoch	spürbare Einschränkung	mehrere Benutzer betroffen
Kritisch	akuter Ausfall	zentraler Dienst nicht verfügbar

Dieses Modell kann später erweitert werden, sollte aber zu Beginn bewusst kompakt bleiben.

Prioritäten und SLA

Wenn Service Level Agreements verwendet werden, sollten Prioritäten mit Reaktions- und Lösungszeiten abgestimmt werden.

Beispiel:

Kritisch: schnelle Reaktion, sofortige Bearbeitung
Hoch: bevorzugte Bearbeitung
Normal: reguläre Bearbeitung
Niedrig: Bearbeitung nach Aufwand und Planung

Wichtig ist, dass die Priorität nicht nur im Ticket sichtbar ist, sondern auch in Prozessen, Benachrichtigungen und Auswertungen sinnvoll genutzt wird.

Prioritäten in Queues und Prozessen

Prioritäten wirken besonders gut, wenn sie mit Queues, Services und Prozessen kombiniert werden.

Beispiele:

kritische Tickets in einer Service-Desk-Queue sichtbar hervorheben
Tickets mit hoher Priorität schneller eskalieren
Benachrichtigungen an Teamleiter auslösen
Kim-KI-Vorschläge für Queue und Priorität kombinieren
Reports nach Service und Priorität erstellen

So entsteht aus der Priorität nicht nur ein Feld im Ticket, sondern ein aktives Steuerungsmerkmal.

Prioritäten auswerten

Prioritäten können in Statistiken verwendet werden, um die Belastung und Qualität des Supports zu bewerten.

Sinnvolle Auswertungen:

Anzahl Tickets je Priorität
durchschnittliche Bearbeitungszeit nach Priorität
Eskalationen nach Priorität
Entwicklung kritischer Tickets pro Monat
Prioritäten je Queue oder Service
Anteil automatisch priorisierter Tickets

Wenn dauerhaft zu viele Tickets mit hoher Priorität entstehen, sollte geprüft werden, ob echte Störungen vorliegen oder ob die Einstufung zu großzügig erfolgt.

Häufige Fehler

Typische Probleme bei Prioritäten:

zu viele Prioritätsstufen
unklare Namen
keine schriftlichen Kriterien
Agenten bewerten unterschiedlich
kritische Priorität wird zu häufig verwendet
alte Prioritäten bleiben aktiv
Automatisierung setzt falsche Prioritäten
Reports werden durch Umbenennungen unklar

Diese Probleme lassen sich vermeiden, wenn Prioritäten bewusst einfach gehalten und regelmäßig überprüft werden.

Fazit

Prioritäten in OFORK sind ein zentrales Werkzeug für geordnete Ticketbearbeitung. Sie helfen Teams, wichtige Vorgänge schneller zu erkennen und den Arbeitsvorrat sinnvoll zu steuern.

Die beste Prioritätsstruktur ist nicht die umfangreichste, sondern die verständlichste. Mit klaren Stufen, sauberen Regeln und optionaler Unterstützung durch Kim-KI wird Priorisierung in OFORK nachvollziehbar, messbar und praktisch nutzbar.