Escalation constraints

Escalation constraints make advanced routings by changing parameters for and create new escalation constraints. Via the ACE Admin Routing | Escalation constraints... menu choice you can create and delete escalation points.

You can e.g. set the value for how long a call will be queued before it is escalated to the next queue. Escalation constraints are global. They do not belong to specific organisation areas and they can be used for escalation in any organisation areas.

Parametrised escalation constraints

The purpose of escalation is that a contact shall not have to be stuck on a routing destination if the contact by being moved to e.g. another queue could be served faster. There are several types of escalation constraints for this, e.g. queue length in relation to number of agents or escalation are a certain specified time.

Example:

A customer in Uppsala makes a call that is routed to a queue served by Uppsala agents. Should the queue length towards the Uppsala agents be too long, it is judged more important to serve the customer quickly than it is to be served by an agent in Uppsala.

This is why the routing for Uppsala calls is defined with escalation to a queue served by all agents in Uppland, should the queue length be longer than X.

Many escalation constraints are, however, of such a type that they must be parameterised to be meaningful. Examples of such escalation constraints are:

wait(x): Escalate if the contact has not been served after x seconds in queue.
eqt(x): Escalate if the estimated queue time is more than x seconds.

In the Escalation constraint window you can create possibilities for advanced routings by entering values for the parameters for the escalation constraints.

Escalation constraints in ACE Admin consist of the Base constraints and Escalation constraints terms.

The Base constraints tab

In a basic installation of ACE there are pre-defined base constraints that correspond to a code in the routing order. How many and which parameters to be included are defined in the code. You cannot remove or modify anything in these pre-defined base constraints.

If you have created your own routing algorithms they have to be defined as customer unique base constraints.

This function can be used if you have Own escalation constraint in your access role.

Company unique base constraints can be defined or modified until they have been saved in the database, which is performed as soon as you move to another row. The description can be modified at any time. You can also remove customer unique base constraints provided there are no escalation constraints using the base constraint used in the routing. When a customer unique base constraint is removed, the escalation constraints based on the base constraint disappear at the same time.

An information text is shown in the right part of the window describing the function, behaviour, and parameters for the base constraint selected in the list. The following applies for the pre-defined base constraints:

Base constraint	Parameters	Information text
agentConRatio	ratio minAgents	At a queue situation (for the current queue), escalate if there is more than ratio per cent contacts in the queue compared to the number of agents serving the queue. If ratio for example is 200 this means that escalation will take place if the number of contacts is more than two per agent. The parameter minAgents rules whether escalation will take place spontaneously if the number of agents falls below the value of the parameter. If minAgents is zero, no escalation takes place due to too few agents.
eqt	maxTime minAgents	At a queue situation (for the current queue) escalate if the estimated queue time (eqt) for the contact (in this queue) exceeds maxTime seconds. The parameter minAgents rules whether escalation will take place spontaneously if the number of agents falls below the value of the parameter. If minAgents is zero, no escalation takes place due to too few agents. So, eqt calculates the estimated queue time for the incoming contact and escalates from that value. Is therefore not recommended for queues with few incoming contacts and a broad variety of call times.
eqtOrQLen	maxTime maxLen minAgents	Combines the base constraints eqt and qLen. If at least one of the two constraints is fulfilled escalation will occur. The parameter minAgents controls whether escalation is to occur spontaneously if the no. of agents falls below the value of the parameter. Too few agents will never cause escalation if minAgents is set to zero.
longestQTime	maxTime minAgents	At a queue situation (for the current queue) escalate if longest time in queue (for this queue right now) exceeds maxTime seconds. The minAgents parameter rules whether escalation will take place spontaneously if the number of agents falls below the value of the parameter. If minAgents is zero, no escalation takes place due to too few agents. The longestQTime base constraint makes escalation by longest time in queue, maxTime, take place (only) directly when the contact is queued. Escalation by number of agents, minAgents, can also take place if the situation changes while the contact is in queue.
minAgents	minAgents	The minAgents parameter rules whether escalation will take place spontaneously if the number of agents falls below the value of the parameter. If minAgents is zero, no escalation takes place due to too few agents
noEscalation	-	No further escalation. The contact remains in the queue indefinitely or until the contact is routed to an agent or is abandoned by customer. Note that this constraint can be used in the middle of a routing row (to temporarily shortcut the rest of the row).
qLen	maxLen minAgents	At a queue situation (for the current queue), escalate if the number of contacts in queue exceeds maxLength. The parameter minAgents rules whether escalation will take place spontaneously if the number of agents falls below the value of the parameter. If minAgents is zero, no escalation takes place due to too few agents.
wait	time minAgents	At a queue situation (for the current queue) escalate after time seconds. The minAgents parameter rules whether escalation will be take place spontaneously if the number of agents falls below the value of the parameter. If minAgents is zero, no escalation takes place due to too few agents.
minAvailAgents	minAvailAgents	The minAvailAgents parameter rules whether escalation should take place spontaneously if the number of available agents (logged in - not paused) is below the parameter’s value. If minAvailAgents is zero, no escalation takes place due to too few agents.

To be able to use a base constraint in the routing form, an escalation constraint must be created in the Escalation constraint tab. Also for base constraints without parameters an escalation constraint must be created.

The Escalation constraints tab

Escalation constraints that can be used in the Routing of contacts window are created for a specific organisation area.

This function can be used if you have Own routing rows in your access role.

You create an escalation constraint by clicking on the Add button and then

entering a name for the escalation constraint,
defining which base constraint it is based on, and
specifying values for the included parameters.

Limitations for the Escalation constraints tab that it might be helpful to know about:

If you change which base constraint an escalation constraint uses, new parameters are added and they have to be parametrised.
You can only change the value for parameters. Name and number for the parameters cannot be changed.
You cannot change the information text describing the base constraint.
The name of an escalation constraint cannot be changed.
Escalation constraints can be removed but only if they are not already used in the routing. The exception is noEscalation that cannot be removed at all.