Overflow Call Queues

[Andy Mijs]

Hi,

I’d like to request an ‘overflow’ polling strategy for Call Queues. Basically, the same request which is described in already existing forum posts like here; https://www.3cx.com/community/threads/overflow-call-queues.79463/. ‘Overflow’ is defined here as water continuously flowing down waterfall steps; the water fills the first level, when the first level is full the water _overflows_ into the second level. This happens transitively into 3rd-, 4rd level etc

The ‘overflow’ polling strategy could work the same as ‘Skill based routing Ring all’, with a tweak to ring up all agents with a skill number below the current skill. Example below.
Polling Strategy; Skill based overflow (Ring All) <- NEW
Ring time; 30s
Destination if no answer; 1800s, end call
Agents;

• Alfred, skill 1
• Bert, skill 1
• Cedric, skill 2
• David, skill 2
• Eric, skill 3

Queue is called, telephone will ring for available and logged in users with skill 1: Alfred + Bert
30 seconds pass, telephone will ring for available and logged in users with skill at 2 and below (<- NEW): Alfred + Bert + Cedric + David
30 seconds pass, telephone will ring for available and logged in users with skill at 3 and below (<- NEW): Alfred + Bert + Cedric + David + Eric
…
1800 seconds pass, call is ended.


What does this achieve?

• Reduced number of queues for us
  • 3CX limits us in optimizing the balance between having call agents available and lowest caller waiting time in queue.
  • We now emulate overflow queues by implementing up to three ring all queues per ‘topic’ (a thing you could call us for)
• Simpler agent management
  • The agents for each ‘topic’ (reason why the queue exists) are defined in a single screen.
  • The queue workings are more transparent listing all agents together.
  • More straight forward to maintain the listed agents.
• Improved SLA reporting
  • We are not interested in SLA breaches one queue overflowed into another queue.
  • We are interested in SLA numbers across the entire waterfall.

Alternatives;

• Define and maintain multiple queues, one for each overflow. This has following issues;
  • Duplication of data
  • Exponential growth of amount of call queues
  • Ineffective SLA reporting because a ‘Destination if no answer’ counts always as an SLA breach. This is way too strict of an SLA definition in most use cases
• Alternative PBX. This has one or more of the following issues;
  • More expensive
  • More vendor lock-in
  • More legacy protocols

I look forward to your response!