Agent can't manually switch from WORK to READY when a call is waiting in the Queue

[ML@Spie]

Hello,

I have a situation which I'm struggling with and can't figure out.

There's a call center application with a CSQ set with an automatic 30 seconds WORK state after answering a call.

The weird behavior is that :

- if there's no call waiting in the queue the agent can manually change its state from WORK to READY before the end of the 30 seconds and make himsel/herself available to answer a call

- if there's a call witing in the queue, then the agent can't manually change its state from WORK to READY and the call is transfered to him/her only at the end of the 30 seconds. The other strange thing is that if the agent tries to change its state from READY to WORK, it looks like the call is assigned to him/her but will only be transferred at the end of a timer.

This was working before I change the script just to add another announcement before the "select resource" object in the script.

I thought the reason was in fact the "call hold-delay timer-call unhold" sequence in the loop but the delay is set to "interruptible" so if an agent becomes available it should stop the delay and attempt transfer.

One thing I can think of is that I changed the way the script is called.

Instad of calling it using a "Call Subflow", I am using now a "Trigger Application" and am wondering if the way I set the "Trigger Application" variable inside the called application's script could be the reason of this behavior.

I looked around but couldn't find a documentation describing what are the conditions that could prevent an agent in WORK state to manually switch to READY.

Thank you in advance for any hint.

[Chris Deren]

Is the Prompt you are playing set to "Interruptible"?

[ML@Spie]

Hello Chris,

Thank you very much for replying and trying to help.

I thought about it and checked it and yes the "Delay" object is set in the script as interruptible.

And I made some tests outside of office hours with only one agent being in "not Ready" state so the call is being put on hold for 30 seconds, and as soon as I switch the agent state to "Ready" the call is distributed to the agent.

[Chris Deren]

So, is all well now? Is so, please rate all useful posts!

[ML@Spie]

Sorry if my answer was confusing but no, the problem is the same. What I meant is that I confirmed that the "Delay" object was set to "interruptible" and that making some tests, when switching from "not ready" to ready the call on hold during the delay is distributed.

But agents still can't switch from "work" to ready manually when there is a call waiting in the queue.

[Chris Deren]

Can you post your script?

[ML@Spie]

I didn't questioned the deployment which had been in prod for years, but as I dug deeper, I found out that the customer's telephony configuration of agents matches several of the unsuported configurations for agents phones listed in the release notes like:

• In the Unified Communications Manager Administration Directory Number Configuration web page for each Unified CCX line, setting Maximum Number of Calls to a value other than 2.
• Agent extensions cannot be added to hunt lists or hunt groups.

Now I'm busy digging around figuring all the unsuported configurations which are in place and will try to fix all those first before potentialy wasting time in script analysis.

[ML@Spie]

Hello,

Well cleaning the Agents telephony unsupported features (putting back the Maximum Number of Calls to 2 and setting the DN of agents only once in one partition), apparently did not solved the issue.

I'm still puzzled about what could be the issue.

Here's the script

[ML@Spie]

Hello,
I was going through the documentation, for example this one.

What I do not understand is that according to this diagram, the agent is in "work", and using finesse he/she places himself/herself in "ready" status. The agent is switched to the "ready" status but the agent is assigned directly to the call so his/her status switches to "reserved".

BUT, the agent and the caller are not connected.

As I was saying, it does look like the call is assigned to the agent, but until the end of a timer (which I start to wonder if it is the "work" timer or something else) the two are not connected.

What could generate such a behavior ?

[ML@Spie]

Hello Chris,

I finally solved this issue.

In the end the agent was able to change their status but the call was not delivered.

And the problem was... bug CSCvh53945

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvh53945/?reffering_site=dumpcr

Thank you for trying to help

[Chris Deren]

Great, thanks for the bug ID, +5.