Wrap Timer for Missed Queue Calls

[DarrenWhite99]

We are using a Skill Based Routing queue but have run into issues when there is an available agent in Tier1 that does not answer and the call continues to ring them instead of ringing any of the available Tier2 agents. (Calls are only offered to Tier2 when no Tier1 agents are available and there is no delay in retrying the "available" Tier1 agent). We changed it up to overflow to a Prioritized RingByThree queue (to prevent one absent agent from causing the call to not be offered to anyone else) if the call times out of the first queue, and gave the first queue a short timeout. But this workaround could be avoided if a missed queue call was treated like an answered call, with a wrap timer making the extension temporarily unavailable so that it could ring to the next tier.

So my request would be one of the following:

• Allow the wrap timer to trigger for a missed call. (If wrap is 30 seconds, then a missed call would make the agent unavailable for the standard wrap of 30 seconds)
• Allow a custom wrap timer to trigger for a missed call. (If wrap is 60 seconds, a missed call would make the agent unavailable for a custom wrap time, say 20 seconds)
• A solid third party option to enable this feature.

@VoIPTools is close with their AutoLogout solution (https://www.voiptools.com/product/3cx-auto-logout/) but the agent would need to log themselves back in manually. (And if we set the threshold to 1 missed call that could happen several times during the day)

 

[DarrenWhite99]

Some comments/specifics:
We want a specific group of employees (Level 1s) to handle incoming calls, and only overflow to higher level (2) techs when the front line techs are all busy.
We don't want to use a prioritized queue because we don't want to hammer specific level 1 employees.
The Round Robin Skill Based Routing seems perfect, fairly distributing calls among our front line techs and ringing the next tier of techs when the front line cannot answer. Except that in practice if any front line tech walks away from their desk and misses calls the caller never reaches Tier 2.

Another option we considered/rejected was putting Tier 1 into one queue (standard Round Robin) and Tier 2 techs into another (standard Round Robin) queue, as this means that all callers will have to timeout of Tier 1 before any Tier 2 would be offered the call even if all Tier 1 agents are busy. (And, for our purposes, we actually have several tiers. Which is why we are using the Prioritized RingByThrees strategy for queue 2 to quickly run through candidate agents in order from level 1 to level 5)

 

[VasilisV_3CX]

Hi @DarrenWhite99,

What is the Queue's Maximum Queue Wait Time (seconds) and what is the Queue's Ring Time (Seconds)?

 

[DarrenWhite99]

We want to "live answer" as much as possible, so if we cannot answer within 2 minutes we redirect to an external answering service. We have Tier1, 2, and 3 technicians (and Managers - Tier 4) and would like calls to be handled by Tier1 first, but if none are available then include the Tier2 technicians, if they aren't available then include Tier3, etc. This way senior techs or managers could log in when needed to help cover phones, but still keep the level 1s on the front lines.

Original Configuration:
Queue 1: SBRR - Ring Time 12 seconds, Max Queue Time 120 seconds, Wrap Time 35 seconds
.. but as mentioned, we found that the call would be offered repeatedly to a Tier1 agent if they did not answer, and would never be offered to the available Tier2 agents.

Current Configuration:
Queue 1: SBRR - Ring Time 12 seconds, Max Queue Wait Time 24 seconds, Wrap Time 35 seconds.
After timeout it overflows to Queue 2
Queue 2: HuntByThrees Prioritized Hunt - Priority Queue, Ring Time 15 seconds, Max Queue Wait Time 90 seconds, Wrap Time 35 seconds.
After timeout it forwards to external service.

The current configuration makes queue metrics messy, add complexity to configuration and operation, etc. We would LOVE to have it work with the single SBRR queue. Skill Based Routing was a significant part of why we purchased our Enterprise license. FWIW - We are running v18.0 (Build 314).

 

[VasilisV_3CX]

Hi @DarrenWhite99,

EDIT: You're correct. The current set up is the correct way to do this. If metrics weren't a problem, Ring Groups may be a way to go but since you're requiring metrics you've already got this set up in the only way I can suggest.

 

[DarrenWhite99]

Hi @DarrenWhite99,

EDIT: You're correct. The current set up is the correct way to do this. If metrics weren't a problem, Ring Groups may be a way to go but since you're requiring metrics you've already got this set up in the only way I can suggest.

What is the likelihood/possibility for 3CX to automatically flag an extension that is missing queue calls as unavailable? Many legacy systems will automatically log a user out of a queue after a single missed call. Third party solutions have been created to try to address this need. Implementing a wrap timer to temporarily suspend calls to a missed extension (so that other extensions could be attempted), or supporting an auto-logout would be helpful.

What about remembering extensions that have already been offered a call and not retrying them for the same call until all available extensions in the queue have been tried?
Ie. Queue 401 has extensions 111-113 (Tier 1) and 121-123 (Tier 2). Extensions in calls: 111,122, 123.
Call ID 1001 comes in. Call is offered to 112, no answer. Call is offered to 113, no answer. Normally it would be offered to 112 again, but if 112+113 are in the "Already attempted" bucket, the call would be offered to 121. If 121 did not answer, then 112,113, and 121 would be "Already Attempted", and 111, 122, 123 are busy, there are no available extensions. Instead of holding, anytime no extensions are available the "Already Attempted" bucket could be emptied, allowing normal queue extension ranking and call offerings to occur. If Call ID 1002 came in while 1001 was ringing 113, 1002 would be offered to 112, etc.

 

[VasilisV_3CX]

Hi @DarrenWhite99

Your suggestion makes good sense and has been talked about in the past. In fact there has been a feature request mentioned here before: https://www.3cx.com/community/threads/queue-automatic-logoff-based-on-polls.57774/

I'd suggest upvoting it as the more traction it gains the more likely to be considered for implementation.