Zum Hauptinhalt springen

Documentation Index

Fetch the complete documentation index at: https://docs.enneo.ai/llms.txt

Use this file to discover all available pages before exploring further.

Die folgenden Einstellungen definieren die grundlegende Steuerungslogik des Smart-Routings bei der automatischen Ticketzuweisung. Sie steuern, welche Tickets bevorzugt bearbeitet werden, welche Sachbearbeiter infrage kommen und ob bestehende Bearbeiter-Zuständigkeiten erhalten bleiben. Gemeinsam bilden die Optionen den Rahmen für die Ticketverteilung im operativen Alltag – insbesondere im Zusammenspiel aus Priorisierung, Skill-Matching und Bearbeitungskontinuität. Die Konfiguration ermöglicht eine gezielte Anpassung an organisatorische Anforderungen, beispielsweise hinsichtlich SLA-Einhaltung, Teamspezialisierung oder konsistenter Betreuung laufender Kundenanliegen.

​
Verteilungsreihenfolge

Die Verteilungsreihenfolge legt fest, nach welchem Kriterium entschieden wird, welches Ticket als nächstes einem Sachbearbeiter angeboten wird. Jede Option besteht aus einem Primär- und einem optionalen Sekundärkriterium (Tiebreaker für den Fall, dass mehrere Tickets im Primärkriterium gleichwertig sind). Die möglichen Sortieroptionen und ihre Wirkung:
  • Priorität — Jeder Tag kann eine Prioritätsstufe tragen: urgent, high, medium, low. Diese wird beim Tagging auf das Ticket übertragen. Tickets mit höherer Stufe kommen zuerst. Haben mehrere Tickets dieselbe Stufe, entscheidet das Sekundärkriterium.
  • SLA-Fälligkeit — Wenn ein Tag mit einer SLA-Frist konfiguriert ist, berechnet das System daraus einen Fälligkeitszeitpunkt auf Basis von Erstellungsdatum und Geschäftszeiten. Tickets ohne SLA-Konfiguration gelten systemseitig als “fällig am 31.12.2099” — sie werden in SLA-basierten Modi immer ans Ende der Warteschlange gesetzt, unabhängig vom Alter.
  • Letzte Kundennachricht — Zeitpunkt der jüngsten eingehenden Kundennachricht. Gibt es keine (z.B. bei intern erstellten Tickets), wird stattdessen das Erstellungsdatum verwendet.
Die vier konfigurierbaren Modi im Detail: 1. Nach SLA-Ablaufdatum Nur ein Kriterium: Fälligkeit aufsteigend. Das Ticket mit der nächsten SLA-Deadline wird zuerst verteilt. Tickets ohne SLA landen am Ende der Warteschlange — unabhängig davon, wie alt sie sind. 2. Höchste Priorität zuerst — bei Gleichstand nach SLA-Ablaufdatum Primär: Priorität (urgent > high > medium > low). Sekundär: Fälligkeit aufsteigend. Innerhalb derselben Prioritätsstufe entscheidet, welches Ticket als erstes fällig wird. Tickets mit niedriger Priorität aber kurzem SLA werden nie vor Tickets mit hoher Priorität verteilt — auch wenn sie bereits überfällig sind. 3. Höchste Priorität zuerst — bei Gleichstand nach letzter Kundennachricht (LIFO) Primär: Priorität. Sekundär: Letzte Kundennachricht absteigend. Bei gleicher Priorität kommt das Ticket zuerst, bei dem der Kunde zuletzt geschrieben hat. Ältere Tickets derselben Prioritätsstufe rutschen weiter nach hinten, je mehr neue eintreffen. 4. Höchste Priorität zuerst — bei Gleichstand nach frühester Kundennachricht (FIFO) Primär: Priorität. Sekundär: Letzte Kundennachricht aufsteigend. Bei gleicher Priorität wird das Ticket zuerst verteilt, bei dem die letzte Kundennachricht am längsten zurückliegt — klassisches Warteschlangenprinzip innerhalb einer Prioritätsstufe.
Die Priorität wird pro Tag konfiguriert, nicht pro Ticket (Routing und Tags → Tags). Ein Ticket erhält die Priorität des zugewiesenen Tags. Hat ein Ticket mehrere Tags mit unterschiedlichen Prioritäten, gilt die höchste. Tags ohne Prioritätskonfiguration haben den Standardwert low.

​
Tag-Matching

Diese Einstellung bestimmt, wie streng die Skill-Übereinstimmung zwischen Sachbearbeiter und Ticket beim automatischen Routing geprüft wird. ALLE — Ein Ticket wird einem Sachbearbeiter nur dann angeboten, wenn er alle Tags des Tickets als Skill besitzt. Dies stellt eine genaue Kompetenzabdeckung sicher, kann jedoch die Verteilungsquote erheblich senken, wenn Tickets mehrere spezialisierte Tags tragen. MINDESTENS EIN — Es genügt, wenn der Sachbearbeiter mindestens einen der Tags des Tickets als Skill besitzt. Mehr Bearbeiter kommen in Frage, die Verteilung ist breiter, aber weniger zielgenau. Die Wahl zwischen beiden Modi hängt von der Teamstruktur ab: Kleine, generalistisch aufgestellte Teams profitieren oft von MINDESTENS EIN TAG, spezialisierte Strukturen mit klar abgegrenzten Zuständigkeiten eher von ALLE TAGS.
Zusätzlich lässt sich in den Benutzer- und Team-Settings der Backlog-Zugriff für spezifische Tags einschränken. Damit sind nur noch solche Tickets sichtbar, deren Tags explizit für den jeweiligen Benutzer oder das Team freigegeben sind.

​
Last-Agent-Routing

Wenn aktiviert, wird bei einer erneuten Kundenantwort auf ein bereits bearbeitetes Ticket versucht, dasselbe Ticket wieder dem zuletzt zuständigen Sachbearbeiter zuzuweisen. Ziel ist Kontinuität in der Bearbeitung ohne manuellen Aufwand. Im Fall einer Abwesenheit des Bearbeiters ist eine manuelle Neuzuweisung erforderlich, sofern keine Abwesenheitsvertretung im Benutzerprofil hinterlegt ist. Die Konfiguration der Abwesenheit erfolgt in Benutzerverwaltung → Benutzer → Persönliches Benutzerprofil