robm | 2021-12-07 16:26:30 UTC | #1
Hi, I'm currently working on a project and for that I have built a menu in Scripter. When on call, the agents can select a new queue and a new skill by using a pulldown menu and when both are selected they can transfer the call towards a secure flow. This flow then takes care of splicing the received data and sending the calls to the new queue and skill. This all works fine.. but...
When the agent is assigned to the queue and skill he or she wants to transfer to. The call can end up directly at this agent after the transfer. The agent in that case is not able to take the call and has to wait till the end of the ringing goes off-queue and back on-queue and then is able to take the call.
I have made a workaround by playing 15 sec. of music on hold everytime we transfer a call this way. This is offcourse not what the customer wants :slight_smile: So I was thinking can I use a Data Action to check ig the agent wants to transfer the call to a queue he or she is member of?
I have been experimenting with some Data Action but cannot find the result I would. I would like to input for example the userId (agentId) and then get back the queues. That I then can compare with the queue I have selected for the transfer. If they match I can play the music on hold (just to be sure) and otherwise I can just do a transfer.
Long story I know..
BR, Rob
Jason_Mathison | 2021-12-07 18:55:36 UTC | #2
Hi Rob,
In the event that an agent transfers a call to a queue and it is assigned back to the agent, is the desired behavior that the agent would be able to pick up the call right away? Can you describe why the agent can't take the call right away?
--Jason
robm | 2021-12-07 20:12:43 UTC | #3
Hi Jason,
What happens is; Agent selects new queue by dropdown list (value is stored as variable) Then selects new skill by dropdown list (value is stored as variable) Then they can push the transfer button, this invokes a transfer to a secure flow. The flow receives the variables and they are used to populate a screen pop and a transfer to ACD block. The transfer to ACD does what it does and transfers the call towards the new queue with the new skill.. all good here. If the agent has that queue and skill then the call directly gets pushed to the agent. The WebRTC starts ringing, but they cannot answer. Because they had no chance of doing the wrap-up and finish the ‘first’ call. So the only button available is disconnect, or they have to wait the ringing period after which they are put off-queue.
Now as a workaround I have put a play prompt of 15 sec. Before the screen pop and transfer to ACD. And in that case there is time for the agent to do the wrap-up and finish the ‘first’ call. And then when the transferred call arrives they are able to answer. But the customer is not happy with the extra 15 sec. :slight_smile:
Regards, Rob
yuezhong | 2021-12-07 22:53:23 UTC | #4
i think you can try .
Build a data action call /api/v2/users/{userId}/queues this will provide you a list of queue that user belong to. (notes, a user belong to a queue, may not joined to the queue). You would better with query parameter /api/v2/users/{userId}/queues?joined=true
Or build a data action call Get the members of this queue /api/v2/routing/queues/67b2a678-c99c-440a-bfb1-0654cb3882f1/members?pageSize=25&name=XXXXXXXXXXX&memberBy=user&joined=true
replace XXXXXXXXXXX as input parameter for agent name.
if agent belong to the queue, it will return, otherwise the entities array will be empty.
regards Yuezhong
Jason_Mathison | 2021-12-08 02:28:23 UTC | #5
Yuezhong looks like he has come up with a promising way to minimize this problem, but in the end this seems like a bug in our platform. Please open up a case with customer care, as it doesn't seem to me like the agent should be assigned the call again while they are doing their wrap up. This is an interesting corner case.
Out of curiosity, if the agent can handle the call, why do they transfer it? It would seem like a weird customer experience to have an agent transfer the call, and then get the same agent again!
--Jason
robm | 2021-12-08 08:43:41 UTC | #6
Hi Yuezhong,
That is indeed the best way to go, I was thinking to difficult. I wanted to compare the queues, but just knowing the user is a member and joined is sufficient. I have tested it out and it works like a charm.
Many thanks for providing this solution! Best regards, Rob
robm | 2021-12-08 08:45:38 UTC | #7
Hi Jason,
Yes indeed he did, I've tested it and it works. It looks like some kind of a bug on the platform, and normally it wouldn't happen. But sometimes the supervisors shift people from queues and skills so there is maybe a 2% chance that is goes wrong. But I wanted to have that exception covered. (And now I can :smiley: )
Thanks, BR, Rob
system | 2022-01-08 08:45:51 UTC | #8
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 12873