Best Practices for Outbound Calling on the Plum Voice Platform
Last updated
Last updated
Most voice automation applications are designed to handle incoming calls. But sometimes you can’t wait for customers to call you. Fortunately, you can automate outbound voice calls using the Plum Voice platform.
The backend outbound calling process is more complex, in many cases, than handling inbound calls. Therefore, we’ve put together this list of best practices to help you optimize your outbound calling applications for the nuances of the Plum platform.
Every deployment of a voice application has its own outbound calling queue. Here are the basic steps of the outbound call process:
A call is queued by sending a phone_number POST variable to the application deployment’s queue API. This also returns a unique call_id.
The call is inserted into the queue and put into the queued state while waiting for idle outbound capacity.
When idle outbound capacity is available the call is taken off the queue, dialed, and put into the dialing state.
When the call is answered it is placed into the connected state and the associated application executes.
When the call disconnects it is placed in the completed state.
Before your application ever sends a phone number to the outbound queue make sure you’ve accounted for the following items:
As of 2019, new federal regulations went into effect to protect consumers against spam calling. As a result, most telco carriers require inbound calls hitting their system to have ANI set. The ANI shows where the call originated, and carriers block calls without a specified origination location. The ANI must be a number in your Plum account.
Again, this is a carrier-level requirement. Plum Voice does not block your outbound calls, but we cannot control how carriers handle your incoming calls.
For more information about this topic:
Robocalling, STIR/SHAKEN, and ANITo set an ANI for a phone number use the following format:
See this DEV docs page for more information on formatting phone numbers.
Inbound and outbound calling are different systems within the Plum platform. Even if you are set up for PCI-compliant inbound calls you need to specify outbound calling as PCI in your API calls.
If you’re making calls that may contain sensitive information or have any other reason to require secure communications with customers, be sure to check the PCI flag in your API call.
By default the PCI option for outbound is disabled.
The API parameter for this is is_pci. To enable outbound calling that originates in Plum’s PCI environment, set the value of this parameter to 1. To disable this feature, set the parameter value to 0.
All server and VXML requests must be white listed in Plum's PCI environment before you can complete an outbound PCI call.
Once you've gotten your outbound queue configured, you'll want to double check the following items to ensure optimization of your outbound campaign.
There are two ways to queue calls using Plum’s outbound API. You can queue a single call or multiple calls at once. What’s the difference you may ask?
Imagine you have a bunch of marbles that you need to put into a jar. You can pick up each marble individually and place them in the jar one at a time, repeating the process over-and-over until all the marbles are in the jar (single call API). Or you can scoop up all the marbles and pour them into the jar at once (multiple calls API). The latter tactic is much faster and more efficient.
Plum’s platform isn’t designed to use the single call API to queue multiple calls. Looping the single call API in this way can cause a Distributed Denial of Service (DDoS) event, which will result in all your calls failing.
What is DDoS? A Distributed Denial of Service (DDoS) attack takes advantage of the specific capacity limits for any network resource(s), such as web service infrastructure. The DDoS attack sends multiple requests to the web resource with the goal of exceeding the resource's capacity to handle multiple requests. As a result, the attack prevents the web resource from functioning correctly.
Plum Voice recommends scheduling batch calls to begin at a fifteen-minute interval past the hour.
We do NOT recommend scheduling batches at or near the top of the hour (e.g., 00) because doing so can cause unnecessary call spikes that can negatively impact call completions.
For example, instead of scheduling calls at 10:00am, opt for 9:45am, 10:15am, 10:30am, or 10:45am.
Your outbound calls will go out once when they reach the top of the queue. Our system uses a First In, First Out (FIFO) approach to placing calls.
The time of day, the number of calls a client wants to make, and the number of other campaigns in the Plum Outbound Queue can affect how quickly a client's calls get placed. Any phone numbers that fail get put back into the Plum Outbound Queue so it may take longer for some calls to complete than others.
You may want to alter the message contained in your outbound call depending on whether a person answers the phone or if it goes to voicemail.
The Plum outbound system’s ‘callee type’ detection allows the call to begin immediately while the system listens to the first 4 seconds of the call to determine who or what is on the other end of the line.
Limitations of Callee Type Detection Algorithms
Please note that callee type detection is not a perfect science and is not 100% accurate. Therefore, we (nor any other vendor) cannot guarantee it will work every time for every phone call. The algorithm for the default detection solution attempts to isolate human speech audio and uses that audio to gauge the difference between spoken audio and silence. The solution then attempts to identify the source of the audio based on the collected data. So why isn't this solution 100% accurate? The algorithm relies on patterns and predictability to determine the callee type. However, people and voicemail greetings can have drastically different patterns for answering phone calls. If the voicemail greeting is very short or intentionally mimics expected human speech patterns, the algorithm may interpret that as a human.
You can access the current callee type using the global variable session.connection.callee_type. The value of this variable changes depending on what the system detects during the 4-second listening window. We recommend playing an initial prompt to the recipient and then performing any branching logic against this variable.
The possible values for session.connection.callee_type are 'processing', 'voice', 'answeringmachine', 'fax', and 'unknown'.
We have some examples of how to use callee type detection for DEV and Fuse.
Plum's Outbound Queue is optimized for placing calls. As a result, getting to the next call in the queue takes priority over updating the status of the previous call. Each phase of the outbound process contains several potential status changes. In order to ensure that calls go out as quickly as possible, call status updates may be delayed.
In other words, our system prioritizes placing calls over sending status updates.
Dialing via the outbound queue and the processing of call status data are two separate, yet inter-related processes within the Plum Platform. It is possible, therefore, that a call or a call campaign can be completed before all the status updates for those calls are processed in their entirety.
Once the platform updates call status data, it sends that information to the customer using the provided result_url. Call data timestamps indicate the start and end times for that specific call.
If a call fails to connect, then:
The Plum Voice Platform updates the status to ‘Failed’.
Any phone number with a status other than ‘Completed’ gets placed back in the call queue to be redialed.
This process continues until the phone numbers reach the maximum number of retries.
If the phone number expires (i.e., maxes out retry attempts) the Plum Voice Platform posts a request to result_url including all the parameters defined in the Outbound API (i.e. phone_number, message_reference, call_id).
If an outbound campaign does not complete all calls in the queue before the session ends (the scheduled_timestamp and expiration_timestamp control the session window, see Outbound APIs), the incomplete calls automatically expire and get cleared from the Outbound Queue. The Platform posts the details of the incomplete calls to the result_url and performs the result_url callback.
