Introducing Conference Hold

June 20, 2016
Written by

ConferenceHold

Many of you have adopted Twilio Conference to create complex call flows for multi-party scenarios. Over the last few months, the Conference team has been looking at how our API should be improved to make your job easier. Today, we are excited to announce the addition of a dedicated Hold API for Conference. You will be able to put a call leg on hold while keeping the participant in the conference. Before, you had to remove a call leg from the conference and transfer it to a new one. It’s quite a tedious sequence, especially when you had to do it at scale and keep track of a load of call SIDs.

Many multi-party use cases rely on the ability to manipulate participant resources while the call is ongoing. Think, for example, when an agent needs to put you on hold to pass your request to a more experienced colleague. This why we think that Conference Hold will significantly simplify your life in a lot of scenarios.

How Does It Work

You can now update the properties of a participant resource by POSTing the following parameters to the participant SID. This keeps the participant in the conference but redirects the participant’s media stream to a specified TwiML document or audio file.

Here’s are the optional parameters and a description of what they do.

Hold – Specifying true will hold the participant, while false will un-hold.

HoldUrl – The ‘HoldUrl’ attribute lets you specify a URL for music that plays when a participant is held. The URL may be an MP3, a WAV or a TwiML document. If omitted, Twilio will play default hold music.

HoldMethod – Specify GET or POST, defaults to POST
The request would look like this:

$POST /Conference/CFbbe46ff1274e283f7e3ac1df0097ab39/Participants/CA386025c9bf5d6052a1d1ea42b4d16662
    -d "Hold=True" \
    -d "HoldUrl=https://myapp.com/hold" \
    -u 'AC123:{AuthToken}'

To better understand how it works, let’s have a look to one of the most common Contact Center scenarios.

Contact Center Cold Transfer – Before and After

Before

In Contact Center terminology, a “cold transfer” is the situation where a customer is put on hold while transferred to a different department or agent. Until now, you had to do the following.

1. When Customer calls Twilio number CA123:

  • persist the callSid CA123 received from the webhook, as you will have to modify that call leg later on.
  • place Customer into Conference_A

$ POST /Calls/CA123 \
    -d "Url=https://myapp.com/holdconference" \
    -u 'AC123:{AuthToken}'

And serving the associated TwiML.

Conference_B

3. Once the Customer have been moved to Conference_B, Agent_1 can add Agent_2 to Conference_B. You can create a TwiML flow to do it.

    Conference_B

ConferenceHold1

Now

Let’s have a look at how this would be simplified with the new hold capability in the same scenario.

1. When Customer calls Twilio number CA123, Place Customer into Conference_A as before.

$POST /Conference/CFbbe46ff1274e283f7e3ac1df0055ab39/Participants/CA386025c9bf5d6052a1d1ea42b4d16662
    -d "Hold=True" \
    -d "HoldUrl=https://myapp.com/hold" \
    -u 'AC123:{AuthToken}'

3. Finally, it’s time to bring in the second agent. You can create a TwiML flow to add Agent_2 into the conference.

$POST /Conference/CFbbe46ff1274e283f7e3ac1df0012ab39/Participants/CA386025c9bf5d6052a1d1ea42b4d16662
    -d "Hold=False" \
    -u 'AC123:{AuthToken}'

4. At this point Agent_1 can un-hold the customer and can disconnect. Customer and Agent_2 will remain chatting in the conference room.

Et voila! We have done everything by just using “Conference_A”.

Conference2

How To Enable It

Conference Hold is in Public Beta and you can start experimenting with it right now. Have a look the new documentation here and let us know if you have any questions.