lazymembers patch to app_queue

1 History
2 Auto Pause
3 lazymembers

The lazymembers feature that Schmooze has built into app_queue (Asterisk versions 11 and higher) addresses a shortcoming that we feel app_queue has with how it handles member penalties. The option to enable lazy members in FreePBX requires the use of the FreePBX Commercial VQ Plus module which enhances FreePBX queues (beyond just this functionality) and FreePBX Distro with Asterisk 11.11 or higher, which already has this patch applied.

Below is some history and examples of how app_queue currently handles member penalties, and how you can address this with the built in auto pause feature in app_queue, or, how we address this with our patch called lazymembers.

History

app_queue inside Asterisk is what handles all the logic of a queue in Asterisk. It has the concept of members (which are your agents), inbound callers, and different ring strategies (such as 'ring all members at once' or 'try them one by one, individually, randomly'). It also has the concept of member penalties, which can be thought of as a way to group agents into hierarchies.

In our example we have the queue "Sales" which has 6 members (or agents). These members are broken into two groups. Group 1 is agents 101, 102, and 103 and we have assigned these agents all a penalty of 1. Group 2 has agents 111, 112 and 113 and we have assigned these agents all a penalty of 2. Below would be our list of members as defined in a FreePBX queue.

We have also set up our ring strategy to be "ringall" for the queue which means we want to ring all available agents, simultaneously.

We then set a ring timeout of 20 seconds with a 5 second retry between dial attempts, and a max hold time of 1 minute.

With this all setup, most people would expect the following to happen when a new caller comes into the queue.

Caller enters queue
Queue rings agents 101, 102 and 103 at the same time for 20 seconds since they all have a penalty of 1 and app_queue will always try the lowest penalty group first.
If none of the agents of 101, 102 or 103 answer the call after 20 seconds the queue will wait 5 seconds then try agents 111, 112 and 113 all at the same time for 20 seconds.
If no answer from penalty group 2 agents, wait for 5 seconds and start over again with agents from penalty group 1
After trying to find an agent for 1 minute, if no answer,the caller will be sent to the failover destination of the queue.

The example above is almost correct, except that if one or more agents with a lower penalty are logged into the queue, are not paused and not on a current call, the call will not cascade to the next higher level penalty group. This is because app_queue treats an available agent as a valid target, and continues calling them over and over until the failover timeout of 1 minute kicks in. So in reality this is what happens:

Caller enters queue
Queue rings agents 101, 102 and 103 at the same time for 20 seconds since they all have a penalty of 1 and app_queue will always try the lowest penalty group first.
Agent 103 forgot to log out, or pause themselves, when they took a lunch break, so that phone rings and isn't answered.
Since agents 101 and 102 are on other calls they are not called. Agent 103's phone continues to ring for 20 seconds, and waits for 5 seconds. However, instead of now trying agents with a penalty of 2 it loops back to penalty group 1 since one or more agents are available to take a call – even though 103 isn't actually answering the call.
It just does this over and over and never moves on to a higher penalty group. However, when agent 101 or 102 complete the call they are on, they will now be called and be able to get that call (since they are part of penalty group 1), but agents with a penalty of 2 or higher will never be tried even though they may be free.

Auto Pause

The current way to handle this, and to have it work in a similar manner to expectations, is to use 'Auto Pause'. Auto Pause means if an agent is called by the queue, and they do not answer, they are marked as paused.

When they are marked as paused, they are temporarily removed from that queue (or all queues, if selected), and app_queue is informed that they're not available to take calls. This allows app_queue to move on to the next penalty group, as expected. The major disadvantage of this is that they will not get any calls from the queue until they un-pause themselves manually. This usually means that someone has to monitor this continuously, and that person needs to have a way to un-pause agents. So in our example above the call would flow like this:

Caller enters queue
Queue rings agents 101, 102 and 103 all at the same time for 20 seconds since they all have a penalty of 1 and app_queue will always try the lowest penalty group first.
Agent 103 forgot to log out or pause themselves when they took a lunch break, app_queue calls them once and if they do not answer they will be paused in this queue
app_queue will wait 5 seconds then try again. As all agents at priority 1 are unavailable, it then increases the priority and tries the next group of agents.
Queue rings agents 111, 112 and 113 all at the same time for 20 seconds, as they have a priority of 2

However, there is now a problem – Agent 103 has been paused and will not receive any call attempts from this queue until they are un-paused my someone. This is not very efficient for most users, and isn't as intuitive as most people would like.

lazymembers

The concept of lazymembers is in the name. It means that we assume, by default, that a member was too lazy to pause or log out of a queue before taking a break. After we try and call them and they do not answer, we treat them as unavailable for just this call, and move on to the next penalty group. So in our example above the call would flow like this.

Caller enters queue
Queue rings agents 101, 102 and 103 all at the same time for 20 seconds since they all have a penalty of 1 and app_queue will always try the lowest penalty group first.
Agent 103 forgot to log out or pause themselves when they took a lunch break but app_queue still tried to call them.
Since agent 103 did not answer we will make app_queue treat them as unavailable for this call.
app_queue will wait 5 seconds then try agents 111, 112 and 113 all at the same time for 20 seconds, as they are the next highest priority
If no answer from penalty group 2 agents wait 5 seconds and start over again with agents from penalty group 1 which will include trying agent 103 again.
After trying to find a agent for 1 minute if no answer the caller will be sent to the failover destination of the queue.

As you can see, the call now flows the way most people expect, and having a single agent forget to pause or logout will not hold up the efficiency of our queue.