Inbound call management technology: Rethinking the role of the ACD

Inbound call management is much different than it was even five years ago. Thanks to technology advances such as dialed number identification service (DNIS), automatic number identification (ANI), automatic call distributor (ACD), integrated voice response (IVR) and screen pops, the identity of the caller and their complete history can appear almost immediately at the agent's desktop. And not any agent, but the agent who is the most qualified to handle the call will receive it.

Today's ACD has the ability to manage many features: hold the call in queue, play messages or music, collect digits, determine the identity of the caller, route the call to the most qualified agent and even track the success of the phone call! And as today's ACD manufacturers try to capture more and more market share, they are adding even more of these exciting features, trying to make ACDs the ultimate inbound calling necessity for your call center. But is this "feature creep" phenomena the best way to go? Will it provide us with the best way to get the job done?

The Right Tool For The Job

Although an ACD can figure out information on the person calling (using the DNIS and ANI) and use intelligent call routing to determine which agent should handle the call, is it really the best tool for the job? For example, I can certainly use a flatbladed screwdriver on a Phillips-head screw, but wouldn't a Phillips-head screwdriver work better?

Are all of these features being added to an ACD really helping call centers get the most out of the phone call or is there something else that could do the job better?

ACD Functionality... Without The ACD?

An ACD does several things very well including holding the call in queue, playing messages or music, collecting digits and routing calls. But it has some limitations when it comes to intelligent call routing and other features.

Most ACDs have the ability to set up approximately 250 indicators to help route a call to the agent that has the highest probability of handling the call in the most efficient manner. Although 250 indicators seem like an extraordinary amount of detail, it still may not provide us with enough information to be able to enhance the phone call to the highest possible level - which is the ultimate goal for any call center and its agents. A phone switch has a definite limitation to the number of indicators you can put on it, which is currently somewhere around 250 indicators. Now compare that to the limitless possibilities of the number of indicators you can write into an outside adjunct database application that communicates to your ACD.

Suppose a call comes in and according to your 250 preset indicators, five agents are equally qualified to handle the call. The agent that has been waiting the longest in the queue will get that call, because all available agents are deemed qualified. Well, maybe you want to get even more fine-tuned than the "yes or no" or "black-and-white" criteria of these 250 preset indicators. The next level of sophistication would go far beyond 250 parameters and would take into account regression models, reasons why the customer may be calling, percentage of successful sales under these parameters, whether the agents in question are even in the queue or currently taking a call.

An adjunct database application allows for much more flexibility along with creativity. For example, with a switch-based ACD's Intelligent routing, I can program the PBX to intelligently route all Spanish-speaking calls to a Spanish-speaking TSR. This is great, but with a database application I can take that call and not only intelligently route that call to a Spanish-speaking TSR, but I can take it a step further, based on my level of creativity, and intelligently route the call to a female TSR from Spain that speaks Castellian Spanish and specializes in making Paella, the dish of Spain!

Limitless Possibilities

A switch does not have the capability to handle this level of sophistication, but an outside database application does. This is where the process of the ACD, or the ACD functionality, needs to be separated from the actual ACD hardware. A database application that sits outside of the phone world but is communicating with the ACD can more efficiently take over the process to direct the call to the most appropriate agent. The ACD or phone switch would do what it does best (which is holding on to the phone call and moving the phone call), but the database application would actually manage the placement of the call.

We need to rethink the role of the current ACD function. Does it make sense to go out and buy a high-dollar, souped-up ACD piece of hardware to do a job that can be done better with something else? Instead, maybe we should consider installing a bare-bones switch that holds the phone call and gives the database application two very important pieces of information: The DNIS and the ANI. At this point, the adjunct database application takes over and with its limitless routing possibilities. It can not only determine down to the smallest detail which agent should take the call, but also provide the agent with myriad additional and vital information about the call in order to enhance the call to its fullest potential.

Upsizing Your Inbound Call

Picture this scenario. A call comes in and the phone switch holds it while it communicates to the outside application the vital information about the caller the 800 number they called in on and their caller ID. The database application then decides what kind of call this is using thousands of indicators in the database. For example, according to the information in the database, the application determines that this customer has called 4 times before, he has bought $400,000 worth of product in the past 6 months, he is probably calling about a certain product line, he has indicated that he might also be interested in another product line, and statistics show that he is very likely to buy the additional products during this phone call if presented with the following scripting.

The application then decides that out of the five agents that are waiting in the queue, one is the best to handle this call. For this exact scenario, one agent has a 90 percent close ratio compared to the others that have less than 50 percent. The application then instructs the switch to forward the call to the particular agent. The switch does so along with the complete database information on the customer from the application. The agent immediately knows who is calling, the probable reason for the phone call, what products should be pitched according to the history of the customer, and which script to use based on statistics from research done on similar customers in similar situations as well as past history on each call placed by and to the customer.

What if the agent who has a 90 percent close in this scenario is not in the queue, but instead is on another call? The ACD would not even consider this agent, who actually is the best to handle this call. But a database application can be written to instruct the switch to hold onto the call for a certain period of time, waiting for this particular agent, although five other agents are in the queue. In order to service this customer to the highest level, it may be necessary to place him on hold for thirty seconds, rather than introduce him to another agent who is not as familiar or helpful for his situation.

An outside database application has the ability to handle this minute level of detail, whereas a phone switch or ACD does not. The 250 indicators do not provide enough detail in order to upsize this call to its fullest potential.

The Feature Creep Scenario

I recently talked with a customer and was shocked to find out that their ACD not only had the ability of intelligent call routing (limited by 250 indicators), but also had the ability to track the success rate of each phone call. Great capability, right? Well, maybe, if that is all you want to know about the call.

But a database application at the agent's desktop can also track the success of a phone call, and much better than any ACD could ever hope to. A desktop application will not only track the success or outcome of the call but will allow you to report on how long a TSR actually talked with the customer, whether or not any products or services were presented to be pitched to the customer, what was the outcome of the pitched products or services, the time spent on each individual product or service, along with how much time was spent in "after-call work" versus "total live talk time" to the customer.

If the ACD manufacturers want to add relevant features to the ACD, they should concentrate on features that track the mechanics of the phone call as it relates to the ACD, such as: how long did it take that phone call to get answered, how many calls came in on this particular DNIS, what was the average length of calls, etc. These are things that an ACD could handle well.

The adjunct database application can do a much better job at tracking the outcome of the calls such as, what type of products were sold to which customer and what were the problems they encountered. Additionally, all the information a desktop application collects on a particular call can be immediately used for similar customer calls or the next time that particular customer calls.

Benefits of a robust, powerful outside database application will not only greatly enhance the routing capabilities of the call center, but will also give management a far more valuable tool with which they can monitor the processes within the call center.

The Perfect Phone Call

With a well-written database application, customer service can be revolutionized. When I call an 800 number to order merchandise, I would love for an agent to immediately know who I am, why I am calling, and have all my relevant information at her fingertips.

"Hello, Tim Davis," the agent greets me. "Thank you for calling. I see that you have some merchandise on backorder. According to my records, that item was just shipped yesterday and you will be receiving it tomorrow via Priority Mail. By the way, Mr. Davis, we have an item that has just become available that you may be interested in because it is compatible with your current order. It is on special today for five dollars off."

Hummm. That sounds interesting. I ask for more details and how it works with the product I just ordered. The agent immediately responds, giving me the statistical information and benefits of the product I need to make an intelligent decision. "Would you like for me to charge it to the same credit card from which you ordered your last product. And will the billing and shipping address be the same?"

No fuss. No muss. I'm off the phone is less than two minutes. The agent was completely knowledgeable about my situation and needs. I didn't have to dig out my wallet and repeat for the thousandth time my credit card information or my address. This is customer service of the future...thanks to a great database application communicating with the phone switch.

Not only does the customer benefit in this example, but the organization benefits. In addition to building a reputation of having excellent customer service, the company sells more products and saves money. By having all the information at the agent's fingertips, the agent shaved at least 4 minutes off the 800 phone call, thereby saving the organization unnecessary time and money on the call. Multiply that number by the myriad calls received daily by a company's 800 line and we are talking about significant savings.

Why Use An ACD At All?

You may be wondering if I am advocating getting rid of all ACDs and just using a switch that communicates to the outside database application. After all, why spend $5,000 to $6,000 per seat for the hardware alone if you won't be using all the ACD capabilities. Good point. You actually could set up your own ACD process without an expensive ACD. All you really need is a PBX with an open CTI platform and a desire to implement the database application. This scenario would save you money, but it is not an easy route to go. The software application usually is not a simple one to develop.

Bottom Line

Instead of giving up your ACD altogether, I am suggesting that you purchase a bare-bones ACD or ACD functionality that communicates with an outside database application. The ACD process of the future will involve much more than the ACD. It will involve a very complex, all-knowing outside database application that allows for both flexibility and creativity. Companies just now installing call centers or those that are planning on upgrading and increasing current ones need to understand that the PBX and/or ACD is becoming less and less the focal point of the call center. The real heart of a call center is the database application that runs it.

For information and subscriptions: Call TELEMARKETING(R) 203-852-6800 or Fax to: 203-853-2845 or 203-838-4070

Tim Davis is president of Davis Software Engineering, Inc., a software development firm specializing in design, implementation, and installation of computer-telephony integration (CTI) business solutions.

Copyright Technology Marketing Corporation Jan 1997
Provided by ProQuest Information and Learning Company. All rights Reserved