BenjaminRamsay | 2016-12-27 22:08:45 UTC | #1
Using PATCH /api/v2/conversations/callbacks/{callbackId}/participants/{participantId} to try to put an alerting inboud call straight to On Hold. I get back a very specific error in the response:
An alerting call cannot be placed on hold
Why not? And is this something we could request to have allowed?
Perhaps its a strange use case, but our callers are often drivers who know their dispatcher may not be able to answer right away and are happy to be placed directly on hold for a few minutes while the dispatcher finishes another call. Since the UI does not have a button for this, I had hoped to do it with the API, but it seems the problem lies deeper.
Thanks
tim.smith | 2016-12-27 23:00:50 UTC | #2
I've checked with the dev team for this and the short answer is that there's currently a technical limitation preventing this from being possible. The request to add this ability is being tracked as CS-742.
For now, the only way to work around it is for your custom application to answer the incoming call, immediately place it on hold, and then reconnect the call that the user was already on. It won't be the best experience because the process could take enough time for it to be disruptive to the ongoing conversation.
BenjaminRamsay | 2016-12-27 23:46:57 UTC | #3
And trying to answer the call first gets us back to PCDWEBK-3709. I'll periodically check in on both those and we'll see which happens first.
I have one other similar question about transferring directly to voicemail, but I'll ask that under a separate topic.
Thanks for the input
tim.smith | 2016-12-28 17:39:49 UTC | #4
PCDWEBK-3709 is in progress and some good changes have already been checked in. <strike>I'm not sure exactly when it will make it to production though.</strike> It's on track for an early to mid-Q1 release.
rob.gevers | 2016-12-28 17:11:40 UTC | #5
Can you explain your use case a little more as well as describe your call routing configuration? Are these ACD routed interactions that are alerting agents that you are trying to put on hold?
BenjaminRamsay | 2016-12-28 17:38:12 UTC | #6
Typical use case would be non-ACD direct calls that come in while the agent is already on another call (or two, or three). What they used to do in CIC is just stick the new incoming call straight on hold for a minute or so while they wrap up their current call.
This mostly happens when our delivery drivers call in to our dispatching group. They are used to being put straight on hold by the dispatcher, and both parties prefer that to being funneled to voicemail where they have to wait for someone to listen to the message and then call them back.
If that didn't answer your questions, let me know what other specific info would be helpful. Personally, I think this is a somewhat odd use case, but our people are used to having the ability from CIC, so I'm getting lots of requests for it.
Thanks
tim.smith | 2016-12-28 17:55:03 UTC | #7
Have you considered using ACD for this use case? The drivers could call into a queue and be put on hold to wait in the queue if the dispatcher isn't available. The calls would be assigned to the dispatcher based on whatever routing rules you set up (first in first out probably).
BenjaminRamsay | 2016-12-28 18:44:10 UTC | #8
Yeah, we do have ACD queues set up for that, and I consider that the "right way" to do it. I'll continue to push for it, but it involves re-training a lot of years of habits. Drivers often like to call their own dispatcher directly. Other departments often transfer calls to a dispatcher, even if they are already on the phone. Etc, etc. Something for me to work on from the training side... but in the mean time if the API ever allows straight to On Hold, I'll give the people what they want
system | 2017-08-28 19:29:34 UTC | #9
This post was migrated from the old Developer Forum.
ref: 745