Allow | 2020-05-18 16:36:51 UTC | #1
We have supervisors who monitor the queues and sometimes if too many calls are holding they will "pluck" a call that is sitting on hold and answer it. Basically they are cherry picking the calls on hold in queues at their leisure.
I see PatchConversationsCall() function and it appears to be what I should use to grab the call and connect them to it, but it requires a ParticipantID and I'm not sure which ID that would be?
I didn't think the agent had a participantID until they were part of a conversation? Therefore I'm assuming this isn't meant to be the agents participantID. Is it the customers participantID? Or am I approaching this the wrong way altogether and need to use a different function?
Jerome.Saint-Marc | 2020-05-18 17:24:58 UTC | #2
Hello,
In PureCloud, every "entity" taking part in the conversation is a participant. The conversation will list all the participants that have taken part in the conversation - like the customer, the ivr/flow, the queue, the agents.
When you request info on a conversation (ex: GetConversation, you will not only get the participants which are currently connected and active, but also the participants that are now "detached" from the conversation. What I mean is that if a call went through a Queue (for distribution) and got connected to an agent, the queue participant will still appear in the conversation (with a disconnected state).
You can find more information on the conversation model, and the participants (of different type - see "purpose" attribute) here: https://developer.mypurecloud.com/api/rest/v2/conversations/overview.html
What I would suggest is to use the PostConversationsCallParticipantReplace function to transfer the call from the queue to an agent. The participantId will correspond to the id of the participant corresponding to the queue ("purpose" = "acd") that you get from the GetConversation. The TransferRequest can target the UserId of the transfer target (agent), or the Address, or the UserName, or QueueId (if the target is a queue), ...
Regards,
Allow | 2020-05-18 18:47:48 UTC | #3
I made the call to PostConversationsCallParticipantReplace and got the following error message (if you need code snippets or anything let me know). I'm going to play with the consult transfer using the agent as the person consulting, but if you have other ideas let me know.
{""message"":""An ACD call cannot be transferred unattended."",""code"":""conversations.error.transfer.acd.call.unattended"",""status"":400,""messageWithParams"":""An ACD call cannot be transferred unattended."",""messageParams"":{},""contextId"":""d57377c7-2458-4ca9-b9d1-0e35a082101b"",""details"":[],""errors"":[]}"
Jerome.Saint-Marc | 2020-05-18 19:25:34 UTC | #4
Yes, sorry, I had tried this with chat or emails but not with calls.
Apparently, it is not possible to transfer a call from a queue to a user.
I have found this older post. It is from 2017 but I believe it is still accurate.
I have tried the 2 methods described in the Conversations Transfer page - https://developer.mypurecloud.com/api/rest/v2/conversations/transfer.html The blind transfer is rejected with the message that you have seen - that an ACD call cannot be transferred unattended. The consult transfer is rejected with the error "You are not a connected participant on the call"
Allow | 2020-05-18 19:42:01 UTC | #5
Got it. Yes I got the same two errors that you did for both scenarios. It's good to have confirmation that this cannot be done at this time. We will spend our time on a work around instead. Thank you.
Allow | 2020-05-18 20:08:34 UTC | #6
To be clear it appears a call in a queue cannot be transferred at all. It cannot be transferred to a user, but also it cannot be transferred to another queue. I get the same message, "An ACD call cannot be transferred unattended." whether I transfer to a user or a different queue.
Allow | 2020-05-19 13:19:55 UTC | #7
@Jerome.Saint-Marc apparently the company I work for was told that the PureCloud client software was being updated to allow users to "cherry pick" calls sitting in queues and that the update would be released in Q2 of this year. I assume that means the underlying API would also be updated to allow that (transferring calls that are sitting in a queue). Is this update still being worked on and is there an estimate release date?
Jerome.Saint-Marc | 2020-05-19 13:52:28 UTC | #8
I don't have details on this - sorry. I also heard that some "cherry picking" capability is in the roadmap. But I don't have information on when this would be available, and what it will cover (emails only, or also calls or other media).
tim.smith | 2020-05-19 13:58:46 UTC | #9
The cherry picking feature is tracked as PURE-2334. It does not currently have a release date.
Stefan_Eyckmans | 2020-05-26 06:59:47 UTC | #10
hi,
just my 2 cents, but isn't it better to check why the calls are not ending up with the agents that want to cherry pick the calls? These agents are available and apparently have the skills the answer the call, why aren't they routed to these agents?
Possible solution is that after a certain amount of time all calls end up in a default queue that has all agents assigned to it (can be configured in a flow). Once an agent has picked up the call can be transferred to a specific queue using PostConversationParticipantReplace.
Allow | 2020-05-26 13:54:22 UTC | #11
Stefan,
Thanks for considering this issue. Your assumption is that the agents are ONQUEUE and "should" be getting calls. That is not correct. These agents are supervisors and/or dispatchers and they have a lot of other jobs to do in the call center other than taking calls. Sometimes, in certain situations, they will jump on and take some calls. In those situations they choose what calls they want to handle. We know we could have them go ONQUEUE and then calls would start flowing to them, but again we want them to be able to PICK which calls they take, not just have the system push the next call it determines they should have.
system | 2020-06-26 13:54:22 UTC | #12
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: 7818