Skip to main content

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.

The following settings define the basic control logic of smart routing for automatic ticket assignment. They control which tickets are prioritized, which processors are considered, and whether existing processor responsibilities are maintained. Together, these options form the framework for ticket distribution in everyday operations - especially in the interplay of prioritization, skill matching, and processing continuity. The configuration allows targeted adaptation to organizational requirements, for example with regard to SLA compliance, team specialization or consistent support of ongoing customer concerns.

​
Distribution sequence

The distribution order determines the criteria used to decide which ticket is next offered to a processor. Each option consists of a primary and an optional secondary criterion (tiebreaker in case several tickets have equivalent primary criterion). The possible sorting options and their effects:
  • Priority — Each tag may carry a priority level: urgent, high, medium, low. This is transferred to the ticket at the time of tagging. Tickets with a higher level come first. If several tickets have the same level, the secondary criterion decides.
  • SLA Due Date — If a tag is configured with an SLA deadline, the system calculates a due date from it based on the creation date and business hours. Tickets without an SLA configuration are systemically considered “due on 31.12.2099” — they are always put at the end of the queue in SLA-based modes, regardless of age.
  • Last customer message — Time of the most recent incoming customer message. If there isn’t one (e.g., for internally created tickets), the creation date is used instead.
The four configurable modes in detail: 1. By SLA expiry date Only one criterion: due date ascending. The ticket with the next SLA deadline is distributed first. Tickets without an SLA end up at the end of the queue — regardless of how old they are. 2. Highest priority first — in case of a tie by SLA due date Primary: Priority (urgent > high > medium > low). Secondary: due date ascending. Within the same priority level, it is decided which ticket is due first. Tickets with a low priority but short SLA are never distributed before tickets with a high priority — even if they are already overdue. 3. Highest priority first — in case of a tie by last customer message (LIFO) Primary: Priority. Secondary: Latest customer message, descending. With the same priority, the ticket in which the customer last wrote will come first. Older tickets of the same priority level are pushed further back as more new ones arrive. 4. Highest priority first — in case of a tie by earliest customer message (FIFO) Primary: Priority. Secondary: Latest customer message, ascending. At the same priority, the ticket in which the last customer message was the longest time ago is distributed first — classic queueing principle within a priority level.
The priority is configured per tag, not per ticket (Routing and Tags → Tags). A ticket receives the priority of the assigned tag. If a ticket has multiple tags with different priorities, the highest applies. Tags without a priority configuration have the default value low.

​
Tag Matching

This setting determines how strictly the skill match between ticket processor and ticket is checked during automatic routing. ALL — A ticket is only offered to a processor if they possess all of the ticket’s tags as their skill. This ensures accurate coverage of competencies, but may significantly decrease the distribution rate if tickets carry multiple specialized tags. AT LEAST ONE — It is sufficient for the processor to possess at least one of the ticket’s tags as their skill. This broadens the range of processors considered, making distribution wider, but less targeted. The choice between the two modes depends on team structure: small, generalist teams often benefit from AT LEAST ONE TAG, while specialized structures with clear responsabilities tend to benefit from ALL TAGS.
In addition, the backlog access can be restricted for specific tags in the user and team settings. This means only such tickets are visible that have tags explicitly approved for that particular user or team.

​
Last-Agent-Routing

If activated, upon a renewed customer response to an already processed ticket, an attempt is made to reassign the same ticket to the last responsible processor. The goal is continuity in processing, without requiring manual effort. In the case of absence of the processor, a manual reassignment is necessary, unless there is a deputy registered in the user profile. The configuration of the absence is done in UserAdministration → User → Personal User Profile.