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
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.
For more information about this topic:
To set an ANI for a phone number use the following format:
For more information on formatting phone numbers, click here.
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.
Once you've gotten your outbound queue configured, you'll want to double check the following items to ensure optimization of your outbound campaign.
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.
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.
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'.
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.