How to Make it Work | Computer Telephony

There’s no way for me to tell you everything that can go wrong (or right) with a CTI install. There are so many things that can’t be anticipated by outsiders, which is another key reason why you want to have an internally directed plan, rather than handing everything over to a consultant or a systems integrator.

Many companies need help defining the scope of what CTI should do in a business context (not just from a technical point of view). That help can come in the form of a consultant or systems integrator, who typically work with a company to coordinate the entire plan of an installation, help select the products from the various layers, and if necessary create any custom linkages or applications to suit the situation.

Or, that help can come from one of the vendors themselves. This is more common than it used to be, as vendors have worked hard to orient themselves in a way that makes more sense to the end-user: end-to-end coverage of the entire CTI process, from the component layer through the applications and service. They often set up

So use this short list as a tickler, to spark some thoughts about the kinds of things that applies to your particular business circumstances. These aren’t the only things to watch for and pay attention to; they are just the ones I hear about most frequently.

• Single out the high-volume areas of your call center operations. For a telemarketer selling stereo equipment, the customer service and new orders division may field many calls, while the help desk may get a relatively low load. For a PC vendor, however, the help desk may be just as inundated, or more so, in the face of decreased sales.

  Before implementing any computer telephony technology, you should define the internal environment. The areas with high volume are going to have the highest payback when you implement open applications. Possibly, only one or two of your applications would really benefit from computer-assisted telephony.

  The telecom manager should also assess the nature of each department, to see if the switch-to-host application would enhance or besmirch the corporate image. (Yes, failure to do this could prove extremely embarrassing.)

  When calling the complaints division, for instance, the caller usually expects to air her grievances to a live agent. Her resentment and frustration may only build if greeted by a VRU unit.

• LANs, minis or mainframes — size up your host solution. For smaller call centers, a local area network can serve as the entire host side of the solution. Clearly, the last few years of application development have shown that a LAN-based or client/server-based application gives you more flexibility when it comes to importing telephone functions to the workstation than you’d get with a mainframe.

  Of course, if you have a mainframe or mini already in place, you’ll probably work with this existing hardware. You can often use these hosts as central servers, connected to workstations via local area networks, combining the flexibility of a LAN with the processing power of a mainframe.

• Pin down the vendor on probable savings and goals. Before you even think of contacting a vendor, you should evaluate the time it takes to handle a given call. Only then will you know what your projected savings might be.

  Bear in mind that most applications salespeople are just that — salespeople. Get past the vague promises and pin them down on how much will be saved. Demand detailed projections and scenarios. Ask to speak to a few happy customers — even among happy customers you may find some potential drawbacks of a particular system.

  If you’re fortunate enough to be running a regional monopoly — a utility or water works — you can call colleagues from other areas to discuss any open applications they may have implemented. If you run a mail order house, you may have less luck getting your competitors to divulge their secrets.

• Starting over or improving upon the existing order. Many applications can be integrated into an open CTI environment rather painlessly.

  For instance, you may have an application that calls up customer profile information by having the agent key in the customer’s social security number. Using ANI, the open application automatically summons the file to the agent’s screen simply by replacing the social security number with the caller’s home phone number.

  Many open applications, like predictive dialing engines, are more efficient or economical if purchased as turnkey applications. Sometimes, it pays to scrap the old order rather than undergo an ill-fitting adaptation.

• Test the waters. There are two ways to test computer telephony apps prior to full implementation. Dummy applications are available, simulating call traffic, your workforce, the equipment you plan to employ, your network services and your application code. You can also have a test region on the host, where you can run pilot tests while you’re making changes, perform load analysis.

  Many telecom managers prefer to phase in the new regime gradually through such separate testing areas. One way is to phase in with 10% or 20% of your customer base, then gradually broaden the application to include the entire base through the call center.

• Avoid glitz for its own sake. CTI apps perform some feats so stunning that even the most sober telecom center manager can get carried away with the fancy.

  Few would argue that the act of automatically shunting a caller’s vital data and his phone call to an agent’s terminal before that agent even picks up can save a lot of valuable seconds in WATS time and agent labor. All of these precious seconds are lost, however, when the agent picks up the phone and exclaims — “Hello Mr. Brooks, how may I help you?”

  If you call people by name before you give them a chance to introduce themselves, you’re going to waste 20 seconds of your time with ‘how did you know I was calling?’” The result is a transaction three times as long, and three times as expensive, than the manual solution.

• Don’t ignore agent considerations. Weeks before you implement the application, you should set up a training program — coordinated by the applications developer — to master the system.

  As with any introduction of automation, you may need fewer employees on the job — in this case, agents at their terminals. Perhaps your budget will permit you to divert customer service reps to a larger support group or complaint division. You may also be compelled to reduce the workforce, either through attrition or layoffs.

  Also consider the implementation of new evaluation criteria for those who remain at the call center. If your application incorporates a voice response unit, for example, the unit will handle most of the simple inquiries without any live agent intervention. Which means that your agents handle only trickier, more difficult calls. So you should expect that the duration of an average call fielded by an agent will increase.

• Reality checks. Three months after your application is in place, then three months after that, you should take a look at how much you are saving.

  Note that while it is relatively easy to calculate lower toll free usage or fewer agents needed to staff the phones, other benefits are more difficult to gauge — such as how many new policies have been taken out by insurance customers simply because the agent was able to transfer both their datafile and screen immediately from the life insurance division to the accident group.

  Often, you’ll find you must alter your long-distance contract, your agent scheduling, even the capacity of your computer plant to accommodate the changed call processing environment.

  From a bottom line standpoint, though, these changes are probably for the better. Many end users report a nine to 16 month payback on their investment.