IVR Deconstructed

To glean information about a product, service, or public opinion, market researchers and/or pollsters need to collect data from a representative sample size.  The most effective way to reach a sample that reflects the attitudes of a large population is to conduct interviews in person or to randomly call respondents that meet relevant demographic characteristics.  Although these traditional means of collecting data assure a randomized sample of the population participates in studies, it is not the most cost effective or efficient method of collecting data.  In contrast, web surveys are a low cost alternative to employing a workforce to conduct interviews over the phone.  However, many survey experts argue online surveys only collect data from opinionated Internet users who only answer questionnaires to receive an incentive.  Those skeptical of data collected through web surveys state the data is not representative of larger public or customer opinion.

IVR is a technology gaining traction with market researchers and pollsters because it automates the process of calling large representative sample sets at a much lower cost than using call center representatives.  The Plum Survey platform gives survey administrators the ability to create surveys that are deployed over the phone and web and capture data from the greatest number of respondents.  Outbound calls placed through Plum’s survey platform can be randomized and automated phone dialogs solicit more truthful answers as they remove interviewer bias present in telephone and interviews conducted in person.

For more information about Plum Surveys please visit http://www.plumvoice.com/plumsurvey

Most companies and call centers utilize a PBX or ACD system to rout calls to employees, agent groups, or departments by asking callers to input information such as an extension, the name of a department, or the reason why they are calling. PBX systems that employ auto attendant functionality are good at routing calls but do so without much intelligence and many times a caller ends up in the wrong agent queue or department. This leads to caller frustration and longer call handle times. That’s why many companies are looking to IVR to rout calls more intelligently by using empirical customer information. Because an IVR system can integrate with customer relationship databases, historical information about a caller’s past inquires such as buying habits and purchases can be used to rout calls to the right person who can manage their needs appropriately. IVR call routing solutions can be deployed via a hosted IVR platform or an onsite IVR system.

Here is some information about Plum’s system redundancy, security, and disaster recovery capabilities…

Plum’s datacenter solutions are built from fully redundant components.   Each datacenter rack contains multiple VoiceXML IVR gateways, redundant data networking components, and telecom circuits from redundant carriers.   Each datacenter component has been reliably deployed in thousands of settings. Plum uses proven, hardened server hardware from Hewlett Packard that offers state-of-the-art reliability, system redundancy, and manageability.  Telephony gateway components have collectively handled billions of calls.  Data networking hardware is provided by Cisco.  Application software architecture adheres to the VoiceXML IVR standard that handles millions of calls daily.  The result is a complete carrier-class solution producing “Five 9s” of uptime.

Security –Plum adheres to security best practices, with physical security, data encryption, etc.

PCI Certification- Plum is a PCI certified vendor. ControlScan conducts third party security compliances scans on a monthly basis.

Back-up for additional peace of mind — Plum offers live backups of each system component located at Plum datacenter

Disaster recovery – Plum operates multiple datacenters and configures telecom traffic for failover to alternate datacenters, located at widely dispersed geographic locations.   Telecom traffic can be sourced over redundant telecom carriers for path diversity.

Data Center Facts
Plum’s primary hosting facilities are “Class A” datacenters, with state-of-the-art features and capabilities, with access to telecom vendors around the globe.

•    24×7x365 uptime and support.
•    Telecom circuits with “perfect” voice and touchtone quality
•    Minimal application latency
•    Full redundancy of all components
•    Surplus capacity

Voice Connectivity
Plum uses top quality voice circuits from various providers.  Plum believes that best-in-class
IVR solutions require best-in-class telephony connections.  Plum guarantees quality of service as well as uptime.  Plum’s telecom partners include:

•    British Telecom
•    Colt
•    Global Crossing
•    Paetec
•    Qwest

Circuits from additional telecom vendors (ex: AT&T, Sprint, etc.) can be made available.
Plum consults with customers to meet specific telephony or CTI requirements, including requirements for failover routing via VoIP.

Data Connectivity
•    Throughput greater than 1 Gigabit per second
•    Direct and optimized cross-connects with all major Tier 1 data networks
•    Average monthly latency for round-trip transmissions within the continental US is 45 milliseconds or less
•    Average packet loss within the continental US is less than 0.3%
•    Average jitter over the Internet within the continental US is less than 0.5 Milliseconds

For low latency, Plum offers an audio repository to house large audio files.  Plum can set up special caching solutions.

Physical Environment
•    Multiple layers of hardened physical security
•    24×7x365 security presence
•    Closed-circuit television surveillance with digital storage
•    Multiple layers of electronically controlled card access
•    Multiple Biometric scanners control access
•    Individual locked cages, cabinets and suites

Power Distribution
•    2,750KVA of robust, conditioned, highest quality AC power
•    Four Liebert 600 series UPS systems (3-750KVA &  1-500KVA)
•    5750 KW of redundant generator backup with 30-hour fuel supply and extended refuel contracts
•    Overhead delivery
•    120V and 208V circuits, and diverse power source feeds

Fire Detection/Prevention
•    VESDA (Very Early Warning Smoke Detection) throughout the data center
•    Zoned dry-piped pre-action sprinkler system

Environmental Control
•    Temperature maintained between 64 and 78 degrees
•    680 tons of robust and redundant HVAC
•    24 Liebert HVAC units (20-30 ton & 4-20 ton units) for N+1 redundancy
•    Liebert rooftop glycol drycooler units for  N+1 redundancy
•    Floor water dams with liquid sensors
•    Steam humidification
•    Overhead delivery

High Level IVR Design Principles

1. Employing professional voice talent that uses real studio equipment goes a long way. Audio that is not properly normalized, compressed, noise-reduced and/or encoded is either going to sound bad, or (worse) not work at all in the IVR system. Also, make sure the voice talent is suited to your core audience; gender and age can make a difference (e.g., mature female voices are generally received as more reassuring, and thus may be a better choice for, say, a customer service application).

2. Provide your callers with some way to get to an operator. The goal of an IVR system may be in part to reduce the number of calls that your live staff needs to handle, but there will be times when the system doesn’t fulfill a caller’s needs. Offer such callers a clear way to either talk to a live person or to leave a message for someone to call them back.

3. Keep your prompts informative, but brief. Callers can’t easily review and digest entire paragraphs like they might when viewing a web page. The longer your message, the harder it is going to be for a caller to remember what was said and what they need to do to interact with the system. Use plain language that your customers will understand; industry slang and terminology may only confuse them.

4. It’s really not necessary to tell the caller to press a key to end the call. This is an archaic convention that just muddies the system/caller interaction without really adding anything. Just tell them they can hang up.

5. While it can be tempting to use pre-recorded audio for every static phrase in your application, large sentences with lots of dynamic data can sound choppy when the system switch back and forth between audio and TTS (text-to-speech).

Example: ‘As of’ <tts:date>, your current balance in your <tts:type of account> account is <tts:balance amount>..Rendering the entire phrase in TTS would be a more elegant option.

6. Be mindful of the limitations of the phone interface. Data collection in an IVR application is highly serialized, so it’s difficult to effectively present everything a caller entered to review in totum.

Know Your Audience

The first step in creating an effective, user-friendly IVR is to carefully consider the features your application will need for its typical use case. The following questions should be considered before the first line of code is written.

1. What prompts will the caller hear?

An IVR application is a highly-directed system/caller interaction. It’s important to have a sense of what sort of data you’ll be prompting callers to enter, and what feedback you’ll be providing to their responses.

When determining the call script, identify the specific data that the caller will enter.

Example: Caller enters 7-digit employee ID is far more informative than Caller enters data.

2. What menu options will be provided?

Think through all the necessary options, not just the ‘main menu’ options. Any and all decision points in the call flow require programming and some sort of feedback loop for the caller.

3. What type(s) of data will need to be collected from the caller?

If the data you want to collect is more strongly-typed than just a string of digits, most VoiceXML platforms support ‘natural language’ collection of common data types (dates, monetary amounts, time of day).

4. If information is to be provided to the caller, where do you have this data stored? Is there a preferred method to access this data (SOAP, XML via HTTP, etc.)?