Routing Options

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.

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.

Skill Priority

Among the processors who qualify for a ticket after tag matching, the skill priority decides who is offered it first. It is set per skill, as a number from 1 to 10, where 10 is the highest priority.

Behaviour in operation:

• The ticket is offered first at the highest priority level on which a processor is available.
• If nobody is available there, the next lower level is used immediately. The system does not wait for a higher-priority processor to become free; there is no waiting period and no time threshold.
• Within the same level, chance decides, as before.
• Last-Agent-Routing still takes precedence: where it applies, the last responsible processor is preferred regardless of skill priority.

The priority is stored in the same places as the skills themselves: on the team and in the user profile. There is no interface for it yet; technically it is the skillPriorities field inside the skill settings — a mapping from skill to a value between 1 and 10.

Inheritance: all or nothing. The priority is part of the skill settings and is inherited with them, exactly like the skills and the channels: as long as a user profile has the adoption of team settings switched on, the team's priorities apply and the profile's own stored values have no effect. There is no mixture of team and profile values.

This yields the usual procedure: priorities are maintained on the team and apply to all its members. If an individual processor is to be ranked differently, the adoption of team settings must be switched off for that profile — from that point on, the profile carries its own skills.

Example: A phone line prefers a particular team

The requirement "calls on this line should go to this team first" is not configured on the phone line, but through a tag. A phone line is a subchannel, and a tag can be restricted to a subchannel — which fixes the skill for exactly that line.

1. Create a tag that marks the line and enable its routing relevance, so that it is taken into account in skill matching.
2. In the tag, restrict the subchannel to the phone line in question.
3. Configure a detection rule. The subchannel alone does not assign the tag — it is only a filter. A condition detection with an always-true condition in the sense of 1 = 1 is sufficient.
4. Choose Condition Detection or AI or Condition Detection as the detection method. With AI and Condition Detection the tag is not assigned without the AI step and is therefore not available in time on lines without a voicebot.
5. The detection must not depend on an identified customer (customerNeeded = false in the tag's detection configuration). For calls from unknown numbers no customer is established at the time of assignment — otherwise the tag only takes effect for known callers and the effect appears sporadic.
6. Assign the tag as a skill to the teams in question and set the priority per team.

Calls on this line are then offered first to the available processors of the highest-priority team; if nobody is available there, immediately to those of the next level.

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.