Introducing Call Progress Events – Flexibly Track and Control your Outbound Calls

Introducing Call Progress Events – Flexibly Track and Control your Outbound Calls

Today we’re excited to announce Call Progress Events, a new feature that enables you to build advanced outbound dialing applications and gives you the ability to have granular call control. You no longer need to maintain complex application state because Call Progress Events uses webhooks to instantly notify you of what’s happening during an outbound call and alert you when it progresses through key events, such as Initiated, Ringing, Answered and Completed.

Until now we provided notifications for the major call status changes: when a call was initiated and when a call completed. But as our customers’ call center, outbound dialing and call tracking solutions scaled we saw the need for providing granular call metadata to power call analytics systems and rules-based call distribution systems.

Webhooks for Key Events

Call Progress Events are enabled by using the new StatusCallbackEvent TwiML parameter which will trigger a webhook to be sent on every call-state change: initiated, ringing, answered and completed. The new StatusCallbackEvent TwiML parameter is available in the API and for the , , and nouns on .

For example, if we wanted to make a call from 866-567-1234 to 415-555-1212, and receive notifications for every event we can specify the StatusCallbackEvent parameter in our API request:

 Track Calls Status for Call Analytics Systems

After enabling Call Progress Events, you can track the current status of your outbound calls instead of having to poll the API to check the status of a call and maintain complex application state. With this you could build analytics systems to understand the lifecycle of your calls and and predict the best time to call your customers.

Flexible Call Control for Rule-Based Distribution

You can also set rules in your application based on these events such specifying all calls to customers should only ring a maximum of 10 seconds. If customers can’t be reached in 10 seconds, you should redirect agents to talk to the next customer. To implement this, you could specify Call Progress Events webhooks to be sent on the initiated, ringing and answered events for your call to the customer. After you receive the ringing event, set a timer that either expires after 10 seconds or gets canceled when you receive the answered event.

Let’s say we now have Agent Alice on the line but you’ve noticed via your webhooks that the call to Customer Bob has been ringing for 10 seconds.

Your application will now redirect Agent Alice’s call to the next customer. In the parameters sent with every event webhook you will not only get the call status, you’ll also get the Call Sid and Parent Call Sid (if applicable) which are needed to redirect calls. We’ll get the Parent Call Sid to redirect Agent Alice’s call:

And we’ll use this Call Sid in the POST to the API that redirects Agent Alice’s call leg to connect with the next customer:

The next customer picks up the phone quickly and Agent Alice is able to help them out!

This is just one use case for flexible call leg control but the possibilities are endless. You can control any call leg and redirect it to new TwiML with just one POST to the API.

We think Call Progress Events will help you build applications that efficiently connect your customers and agents and let you focus on your business rather than maintaining application state. Learn more about Call Progress Events in our API and TwiML docs for , , and . We can’t wait to see what you build.