Be Confident Your Contact Center Technology Delivers The Brand You Promise

Be Confident Your Contact Center Technology Delivers The Brand You PromiseToday, most B2C interactions involve some form of contact center technology. With the exception of in-store purchases, contact center technology is responsible for providing the vast majority of brand impressions that customers have through experiences with toll-free numbers, self-service IVR, and CTI screen pop—and that’s just one of the channels. There are also self-service websites, apps, social media scrapers, blended queuing processes, and more.


VOC programs ask customers for feedback on the experience as they remember it – which is extremely important when determining if the experience delivered was pleasing, useful, efficient, or memorable. But it’s also critical to monitor the experience delivered by the organization’s technology and compare it to what was intended. Customers don’t know whether or not the technology with which they’re interacting is actually doing what it’s intended to do, they just know whether or not it’s available when they want to use it and lets them get what they need quickly and efficiently.


Data that’s easy to collect with regularity is what’s frequently relied upon for decision making and tuning—the data collected inside the contact center related to congestion, CPU consumed, call arrival rate, etc. Accurate, unemotional, precise data about the experience actually delivered has to come from the outside in, the way customers really access and interact with technology, and be collected in a controlled fashion on a regular basis.


There are ways to gain a true assessment of the customer service experience as delivered. It starts with documented expectations for the experience as it’s supposed to be delivered. Defined expectations establish functionality, performance, and availability specs as benchmarks for testing.

It’s in every company’s best interest to know that the technology it put in place is, first of all, capable of making all those connections it has to make, and then actually delivering the customer service experience that it intended to deliver. To do that, you need reliable data gathered from automated, outside-in, scripted test interactions that can be used to assess the functionality that’s been put in place, as well as the technology’s ability to deliver both at peak load and then continuously once in production.

Think of automated testing as using an army of secret shoppers to access and exercise contact center technology exactly as it’s intended to be used: one at a time, then hundreds, thousands, tens of thousands of virtual customer secret shoppers. Think also about the technology lifecycle: development – cutover – production – evolution.

Start with automated feature/function testing of your self-service applications— voice and web—to ensure that what was specified actually got developed. Precisely verify every twist and turn to ensure you are delivering what you intended. Do that before you go live and before you do unit testing or load testing. Using an automated, scripted process to test your self-service applications ensures you have reliable discrepancy documentation—recordings and transcripts—that clearly document functionality issues as they are identified.

Next step, conduct load testing prior to cutover. Use automated, scripted, virtual customer test traffic, from the outside-in, through the PSTN and the web—to ensure your contact center technology really can perform at the absolute capacity you’ve designed and also at the call arrival and disconnect rates that are realistic. Plan failure into the process—it’s never one and done. Leave enough time to start small, to identify and address issues along the way.

Once in production, continuously access and exercise contact center technology just like real customers, through the PSTN and through the web—to ensure it’s available, assess its functionality, and measure its performance so you can be confident that technology is delivering the intended experience, 24×7.

If you have self-service applications that undergo periodic tweaks or enhancements, automated regression tests using those initial test cases will ensure all functionality is still on task after tweaks to the software or underlying infrastructure.


VOC feedback tells you what customers think about your efforts and how they feel about dealing with your brand and technology. Automated testing and monitoring allow you to determine if the interfaces you’ve provided are, in fact, providing the easy-to-use, low-effort experience you intend.

It’s pretty straightforward—quality and efficiency of experience drive loyalty, and loyalty drives spend. You HAVE to have both perspectives as you tweak the technology, and that’s the message. Listen to your customers as you decide what you want your technology to do, and then make sure your technology is doing what you intend it to do.

Originally Published in Speech Technology Magazine.

Building a Better IVR: Some Tips for Success

The IVR is an integral part of any call center. Customers can call the center and get what they need without ever talking to a human, allowing agents greater availability to handle the more pressing calls. Yet despite their obvious advantages, most IVR systems aren’t perfect and can benefit from some improvements.

How do you know when your IVR is due for some revamping? One of the best ways is to dial the number yourself. By putting yourself in the shoes of the customer, you’ll get to experience the IVR just as they do. If you find the IVR confusing or feel the desire to hang up in frustration, there’s a good chance your customers feel the same way. And that means it’s probably time to build a better IVR.

So, where do you start? Elaine Cascio, Vice President of Vanguard Communications Corporation and an expert in customer experience, shares some tips for ways to improve your IVR.

Make it Familiar and Easy to Use – Cascio’s first suggestion is to make your IVR more inviting. Again, if you wouldn’t want to stay on the call with your own IVR, there’s little chance your customers are that fond of it either. Cascio suggests to “emulate the processes used by agents wherever possible.” Just as how an agent will try to keep the call as brief and efficient as possible, in order to meet service level and move on to the next call, the same theory should be in place for the IVR. You don’t want to overload the customer with too much information, have them listen to a long, drawn-out message or give them too many steps to get the information they need.

Be Conversational – While brevity is important when developing an IVR, you should still make your IVR conversational and easy to understand. Cascio says to focus on what is being said and how it is presented. She states, “Don’t use jargon – use clear, concise and commonly understood language and terminology.” Additionally, she recommends putting the time into creating a script that is not only easy to follow and inviting, but also reflects the character and services of your brand. Furthermore, it is a good idea to read the scripts aloud before putting them into production and conduct focus groups to see how people respond to the content. Cascio also suggests hiring experienced voice talent to record the messaging.

Leverage Data and Technology – Just as customers will be put off if they have to listen to more information than is necessary, they shouldn’t have to provide the same information each time they call. The IVR can be set up to recognize the number calling or ask callers for their unique pass code and use information already on file to speed the process along. Cascio recommends that IVR systems have the capability for callers to transfer to a live agent, in case they need further assistance. If so, the caller’s data should be easily transferrable from the IVR to the agent, so they don’t have to provide their information once again.

Manage and Measure – Cascio stresses that it is important to perform quality monitoring on calls handled by the IVR in addition to calls handled by live agents. Doing so will keep you informed about how your customers are handling the IVR, and allow you to make sure that it is working properly and helping the business meet its goals. Cascio adds, “Make sure that your measures of success are strategic, customer centric and make a difference in how your business operates.” Quality monitoring can also provide key insight into how successful the IVR is. If a large percentage of callers are hanging up or spending too much time on the IVR, then you’ll know that it may need some more work.

Test, Test and Test Again – Of course, once you’ve made the necessary improvements to the IVR system, you’ll want to make sure they are right. That’s where testing comes in. Cascio recommends setting up focus groups to see if the average caller will understand the language and processes presented by the IVR. Additionally, usability tests will let you know if the IVR is usable and intuitive, and comprehensive user acceptance tests should be conducted prior to deployment.

A good IVR will make the contact center’s operations more efficient and be more cost effective. On the other hand, a poorly developed or executed IVR can be inefficient and wasteful and might even scare your customers away. Since this is the first and often only interaction they’ll have with your business, you’ll want them to be greeted by a coherent and easy-to-use IVR system. By using these tips, you’ll be well on your way to creating a better IVR and, in time, enjoying increased operational efficiency and more customer loyalty.

Thanks to ICMI for the article. 

Preparing for WAN Acceleration

Over the past few years, we have seen server consolidation occurring for many reasons ranging from security to virtualization and simple cost-cutting efforts. In addition to consolidation at the core, users are more distributed accessing the network from a variety of locations including remote and home offices and smart phones.

Having an increased number of remote users accessing applications on fewer servers can introduce significant bandwidth and latency issues. Applications are typically designed to operate in LAN environments, and may not function well when accessed via WAN. In this article, we’ll look at using WAN acceleration technologies to address latency issues, types of WAN accelerators, and key issues when deploying WAN accelerators

Overcoming WAN Performance Problems
To overcome WAN performance constraints and address latency and delay issues many have turned to WAN acceleration solutions. WAN accelerators speed the delivery of applications by eliminating redundant transmissions, staging data in local caches, and compressing and prioritizing data. WAN accelerators generally perform their task via three methods:

Tokenization: Saves bandwidth by ‘remembering’ chunks of data at each accelerator and forwarding tokens as reference points for data previously transmitted, rather than sending the same data over and over. When a token is received, the local accelerator swaps the received token for the referenced data to be forwarded from its local memory. This method works well for most applications with the occasional exception of digital scanner systems.

Compression: Likely the most effective method of acceleration, it compresses the raw data before sending. Data is then uncompressed on the remote machine unbeknownst to the user.

Caching: Data sent to a remote site is cached locally and synchronized at scheduled times, thus allowing content to be sent at off-peak times. This method can greatly reduce the amount of data sent over WAN links during normal work hours. Having data stored locally speeds its delivery to remote offices, and can allow them to function even if the WAN is down. When WAN service is restored, there can be issues with recompiling the newly cached data at each remote site with the core data.

The type of acceleration used will depend upon your goals, the applications you’re optimizing, and network devices and configuration. For example, if you have implemented Quality of Server (QoS) for WAN prioritization, you’ll want to understand whether the WAN accelerator will impact application QoS settings.

Deployment Preparations
Now let’s look at five key considerations your network team will want to make before rolling out any type of WAN optimization device.

  1. Define the applications traversing the WAN and identify the underlying protocols and codecs. You’ll want to understand how each of these protocols is impacted by different types of acceleration. In the case of VoIP, for example, g.711 codec’s quality will be impacted when traversing the WAN, whereas g.729 would only be minimally affected.
  2. Understand which stations are communicating across the WAN and their locations. Ensure that equipment and stations are placed correctly for optimizing WAN performance. If you have multi-tiered applications with web frontends interfacing with SQL servers accessing a database to pull objects, it is best to keep the SQL packets local to one network and not flooding the WAN with 80-byte packets.
  3. Define baseline measurements for application utilization and performance, including utilization throughout the day, application response times, and when operations should occur. Are backups taking too long, or occurring during peak demand times?
  4. What is the actual latency for WAN links? It’s important to understand whether latency is significant enough of an issue to justify WAN acceleration. A rule of thumb is if latency is above 45 ms, it is worth considering WAN acceleration.
  5. Optimize applications by pinpointing delay locations. The WAN is an easy target to blame, however, the backend core processes are frequently the more likely culprit. Issues experienced by users when accessing the WAN may actually be attributed to the LAN, but due to proximity and bandwidth issues they may not be easy to detect. Acceleration in this case may help but not be as effective in resolving delay issues as making configuration changes at the core.

In Conclusion
As more users access applications from remote locations over the WAN, it will be critical for you to ensure a positive user experience. WAN accelerating technology is an attractive way to enhance application delivery while reducing bandwidth needs. The key to successfully deploying WAN optimization technology is to be aware of how acceleration will impact application delivery and quality and understanding the source of delay to improve troubleshooting. In the next issue, we’ll discuss using Observer® to prepare the network for a WAN acceleration deployment as well troubleshooting WAN performance problems

Testing DOCSIS 3.0

Cable providers are using DOCSIS 3.0 as an enabling technology.  To ensure the highest quality of service, a complete testing solution can allows you to verify compliancy and performance testing.

DOCSIS testing should include stateful two-way interactive flows.  To measure true quality of experience or service satisfaction require a ‘Per flow’ test approach in which stateful CPE traffic is presented on the cable modem to CPE Interface.  This allows you to test performance on an end-to-end basis from the CMCI (Cable Modem to CPE Interface) to CMTS-NSI (Cable Modem Termination System – Network Side Interface).  Performance testing includes everything from DHCP, IPv6 CPE behavior, QoS effectiveness and the upstream/Downstream channel bonding capability.

Shenick diversifEye “Per-Flow” Test System can deliver these capabilities.  This PDF is an overview of how diversifeye can help you with your testing requirements.