Not the same old script

Call Center Solutions, Jul 1999 by Dearing, Rita

Like any tool, there is a right and wrong way to use a predictive dialing system. The right way increases the success of a dialing campaign by providing agents with scripts to help them achieve three goals: address difficult spots in the conversation; target the call to the specific needs of the individual and lengthen the conversation to increase the probability of achieving the desired result. The wrong way to use a dialer is without scripts, letting agents handle conversations as they see fit.

Traditionally, scripts have been simple paper documents that allowed agents to read a generalized pitch. While certainly an improvement over no scripts, paper scripts were cumbersome and by their very nature, extremely simplistic. Changes to the script required the new script to be printed and redistributed. The solution: screen-based scripts that are displayed on an agent's workstation.

A vast improvement over paper, the real benefit of screen-based scripts was that they made the industry realize the potential of scripting. As long as scripts are presented on workstations, why not, teleservices vendors reasoned, link them to back-end applications so different scripts could be presented throughout a conversation? This turned out to be such a good idea that a whole new class of technology called scripting tools was created.

With these tools, a new generation of scripting possibilities was born. For example, while an agent is reading a generalized script to a customer, the customer expresses objection A, then script A is presented, but if objection B is offered, a different script, script B, is displayed on the agent workstation each, of course, being tailored to the specific issue at hand.

More recently, predictive dialing vendors have taken this approach one step further by linking script presentation rules to information in a customer database. The result: different scripts can be presented, on a case-by-case basis, to individual customers. A telemarketer of time share resorts, for example, may offer different scripts to prospects on the basis of their state of residence, gender, age group or income level.

Even more impressive, with this latest generation of scripting tools - now more properly refer-red to as application development tools - customer-based scripting can be combined with branching techniques. So, for example, script A in the scenario above may differ as a function of the prospect's age group and income level, enabling agents to meaningfully overcome objections to the offer in a tailored way.

The bottom line: with new application development tools, teleservices managers can finally empower their agents with the capability to maximize the returns for each and every call and thereby optimize the overall success of the entire teleservices campaign.

It should never be forgotten, however, that, like any other tool, quality, functionality, flexibility and ease-of-use must all be considered when evaluating application development tools. Quality can best be determined by consulting with other companies using the system and by examining the vendor's track record where support is concerned.

Functionality and flexibility are slightly more difficult to assess because it is often hard to know how the tool will be used before it is implemented. But there is one key point - database support - which should not be overlooked.

All application development tools should be able to define the rules by which any given script is presented to the agent at any given time in the workflow. But to do so, the tool needs to interface with databases containing pertinent information. As a result, to ensure functionality in changing business environments, the application development tool must support not only the databases currently being used, but all those that will be used in the future, as well. The only way to meet this requirement is with a nonproprietary tool that supports any standard ODBC database product. This capability will also facilitate utilization of the application development tool to capture data through the scripts: when an agent asks a question, the response can get logged into the script, stored in an ODBC database and analyzed, and then this database can be used for targeting future scripts.

Another critical issue to consider is ease-of-use. Only by making it as simple as possible to match the teleservices campaign vision to the practical implementation of that vision can application development tools live up to their potential as successful expediters. This means that it is absolutely critical to consider how fast and easy the tools allow teleservices managers to implement new scripts, new branching options and new presentation rules.

Take the scenario, for example, of a newspaper publishing company involved in a teleservices campaign to sell weekly subscriptions to their evening newspaper. With proper programming, any tool can be used to create an application that presents differing sales scripts to prospects as a function of their income bracket, age or number of children. But only a tool that enables teleservices managers to easily update these parameters can be truly responsive to changing market conditions.