Checking queue for logged in agents

[fishhead64]

All our subroutines check for logged in agents before we queue the call and it works great. Is there a way to continue to check after the call is queued so if calls do get queued while an agent is on a call and then goes Make Busy and logs out while a call is still queued, the caller doesn't stay queued forever?


Thanks!
Al Feinberg
MiCollab 9.7.1.103-01
Mitel Standard Linux 11.0.106
OVA 9.4.1.8
MiVoice Business Release level: 9.4
NuPoint Unified Messaging Build: 20.6.0.4.01
Revolutions 2022.2.1
MiCC 9.4.2
MiR 7.0.0-16.0
CCMWeb
PowerPlay

 

[Billz66]

i think you can add an inqueue workflow.
we did something like that for when we use emergency mode to put a queue group into dnd
doing that stopped new calls but then we needed to deal with any that were already queueing

- we added an inqueue workflow that would check at intervals for queue = dnd and then send call to the interflow destination

If I never did anything I'd never done before , I'd never do anything.....

 

[fishhead64]

Thanks, I see a Default UPiQ Inqueue Workflow, but that looks like it checks for place in queue, not what I want here. The condition I added to my Subroutine checks for Logged Agents > 0. And it looks like I can build something similar as an Inqueue Workflow, but how do I tell it at what interval to check? Or does it check all the time by default?

I also see in the documentation Activity - Offer to Agent Group, which I can't find in the Workflow setup. I also see in Agent Groups a prompt "Queue callers to this group if no agents are logged in" and NO is selected.... this didn't seem to be working and the reason I added the Queue Condition "Agents > 0" in the first place.

I may be getting over my head here, certainly don't want to mess anything up.

Thanks!
Al Feinberg
MiCollab 9.7.1.103-01
Mitel Standard Linux 11.0.106
OVA 9.4.1.8
MiVoice Business Release level: 9.4
NuPoint Unified Messaging Build: 20.6.0.4.01
Revolutions 2023.1.2
MiCC 9.4.2
MiR 7.0.0-16.0
CCMWeb
PowerPlay

 

[Lundah]

The UPiQ workflow is a special inqueue workflow that tells the caller what position in queue they are. I don't have a lot of experience with this to be able to offer good advice on this one. Might be work giving your support vendor a call, they should be able to assist.

 

[kwbMitel]

A simpler solution might be to simply prevent an agent from logging out while calls are queued. COS Option I beleive, maybe system option.

Failing that, simply instruct agents not to answer the call and it will be automatically requeued and follow the appropriate after hours routing.

 

[fishhead64]

We found that using the Condition below, when agents finish a call, they are Unavailable (Queue Work Timer = 30 seconds) We want to retain the work timer, but it makes the agents unavailable, meaning new callers get the Closed treatment. How can we still queue callers when this happens. I get that technically they're not "Available" but once the Work Timer expires, they will be. Is there a better way to screen for when no agents are Logged In, not just temporarily unavailable? Probably better posted under thread1329-1826158 but that post is closed.

Thanks!
Al Feinberg
MiCollab 9.7.1.103-01
Mitel Standard Linux 11.0.106
OVA 9.4.1.8
MiVoice Business Release level: 9.4
NuPoint Unified Messaging Build: 20.6.0.4.01
Revolutions 2023.1.2
MiCC 9.4.2
MiR 7.0.0-16.0
CCMWeb
PowerPlay

 

[fishhead64]

Is there a reason why this doesn't work? It's set to NO on all our queues, but calls still queued and waited for no one. Seems like a perfect, easy solution.

Or is this another/better option? We need to understand exactly what "unavailable" means. Is it described in a guide, I couldn't find anything.

Thanks!
Al Feinberg
MiCollab 9.7.1.103-01
Mitel Standard Linux 11.0.106
OVA 9.4.1.8
MiVoice Business Release level: 9.4
NuPoint Unified Messaging Build: 20.6.0.4.01
Revolutions 2023.1.2
MiCC 9.4.2
MiR 7.0.0-16.0
CCMWeb
PowerPlay

 

[Billz66]

regarding this
"Is there a reason why this doesn't work? It's set to NO on all our queues, but calls still queued and waited for no one. Seems like a perfect, easy solution."

did you only make the change in YSE?
was read write enabled on the media servers and were you logged in as an enterpise admin when you did it ?
if not then login to the MIVB and check the skill groups.

if that setting is active on the skill group for a queue then when there are NO agents logged in ,
the queue should go into DND and either reject new calls ( no path unavailable destination)
or send them to the path unavailable destination if there is one set




If I never did anything I'd never done before , I'd never do anything.....

 

[fishhead64]

I did make change only in YSE, but I am an Admin and all ACD Agent Skill Groups are set to No
Queue Callers To Group When No Local Agents Are Logged In and Present - No


I do see that some of our queue's ACD Path - Path Unavailable targets in MiVB don't match with the Night treatments in YSE, but the one we're troubleshooting (Helpdesk) is set properly to their Night Mailbox as are several others.

A few ACD Paths are oddly set back to their queue or the general VM pilot number, etc. But no reports of Night Treatment not working. These have been tested and route to what's set in YSE, not the Path Unavailable target in ACD Path on MiVB.

Does YSE setting override MiVB, or vice versa? Why is the same setting configured in two places?



Thanks!
Al Feinberg
MiCollab 9.7.1.103-01
Mitel Standard Linux 11.0.106
OVA 9.4.1.8
MiVoice Business Release level: 9.4
NuPoint Unified Messaging Build: 20.6.0.4.01
Revolutions 2023.1.2
MiCC 9.4.2
MiR 7.0.0-16.0
CCMWeb
PowerPlay

 

[Billz66]

when the call is being queued the MIVB is the master

inqueue workflows can affect calls but other than that the yse data is mainly for reporting

changes are only written to the mivb from YSE when its set to read write and being done by an enterprise admin

we tend to configure the changes in MIVB where possible then sync the data fromthat to YSE .
we only rarely use yse to assign data to the mivb ( normally when creating ivr ports and ivr hints as its quicker) and our customers only normally use read write when updating skill levels for agents within skill groups
as that also is quicker from YSE

Always be careful with readwrite enabled as you can quickly delete data from the mivb if your not looking at what you are doing .

I once was trying to clean up the list of extensions in YSE by removing the voicemail ports, it was set to readwrite and deleted them all from the mivb ...

If I never did anything I'd never done before , I'd never do anything.....