Like waves approaching a beach, several generations of future technology often are visible simultaneously. In database marketing, the closest wave — having already crested — involves “conventional” campaign management systems, which provide segmentation and response analysis for single mailings.
Overtaking these are “continuous” customer management systems. These manage streams of related communications delivered through both traditional direct response media and operational “touchpoints,” such as customer service and point of sale. These systems are well understood but not yet widely installed. They'll get the most attention as their vendors compete furiously to establish themselves as market leaders in time for the impending sales boom.
Not quite so well defined, but definitely visible behind the customer management systems is the wave of “real time” relationship management systems that eventually will follow. These will respond to customer actions as they occur. More importantly, they will move beyond delivering marketing messages to actually making operational decisions, such as pricing or credit authorization.
Early versions of these systems already exist on the Internet where instant response to customer actions is an immediate and unavoidable requirement. But linking Web systems to core corporate operations still is quite difficult, and many Web implementations rely on self-contained rule sets that are independent of other systems. Eventually, of course, companies will want to treat their customers the same regardless of whether they are interacting through the Web or elsewhere. This will require that the rules controlling these interactions migrate away from Web systems — or other channel-specific repositories such as call-center scripts or automated telephone attendant menus — to common locations that drive all touchpoint systems.
If the goal were only to coordinate marketing messages, then one common location in the corporate database marketing system would be adequate. But because relationship management extends beyond marketing messages to true operational decisions, each type of decision will have to originate within the appropriate operational system: pricing, credit, collections, returns processing, etc. It will take some pretty intricate plumbing to make marketing information and considerations available to the different operational systems.
But the alternative — a central marketing system that controls all operational decisions — is even less plausible.
Exactly how these systems will work is not yet clear: the wave still is quite far from shore. But some hints are available. Many of today's leading new technologies — object databases, component-based designs, peer-to-peer messaging, cross-application process integration, distributed processing — enable this type of decentralized coordination, and some of the theoretical foundations for making decisions that optimize long-term relationships are appearing. It's even possible to find a few systems that offer limited versions of these functions today.
DecisionPOS (Advanced Software Applications, 412/429-1003; www.asacorp.com) is designed to support real-time model execution at customer touchpoints such as call centers and point-of-sale terminals. The system currently works only with models developed in ASA's own ModelMAX and ScorXPRESS products, which create direct response and fraud detection models respectively. But the approach could be extended to others as well.
The core of DecisionPOS is an administrative module that lets the user hook up existing models to sources of input data and to use the resulting model scores to control scripts for conversations with the customer. In operation, the system either can run on its own, with its scripts controlling the entire customer interaction, or, more likely, be called at an appropriate moment from within an existing operational application. These calls, which must be custom-coded into the operational system, would execute a C or Assembler routine or Windows executable created automatically by DecisionPOS. These packages incorporate the scripts, data linkages and models.
Script design in the system is similar to most call-center scripting applications.
The user defines a series of logical statements, checking the value of a database variable or model score, and specifies the action to take depending on whether the statement is true or false. This action may be to display a text message, to execute another logical statement or even to call another script. Scripts can have any number of branches, and allowing one script to call another lets the system bring together the flow from several different branches.
When a model is specified within a script, DecisionPOS lists the input data
elements that model requires and prompts the administrator to define the source of each element. If these are all available within existing databases, the model can execute automatically and return a score.
If some elements aren't available, DecisionPOS will create an input screen that lets the operator add those elements on the fly — presumably by asking the customer or prospect to provide them. The application also can write the new data back to an existing database or store it in a separate file. Since there are no data validation or standardization capabilities within DecisionPOS' data-capture screens, storing the data separately and later adding it to the main databases through a controlled update process probably is a safer approach.
The administrator also can design a screen to capture data elements not needed for a particular model and can control the details of screen design, such as type size, color and placement. Scripted messages appear automatically on the screens.
A test mode in the system lets the administrator check that a given script functions as intended, although there is no automated simulation capability to estimate how often the different branches would be exercised. The system lets the administrator track which scripts are executed, which models are run, what responses are received and other statistics during actual operation. This information is stored in either a text file or Microsoft Access database, where it is available for analysis. The system doesn't provide any standard reports, however.
The administrator module of DecisionPOS runs on Windows 95, 98 or NT. Completed scripts can be deployed to mainframe, Unix or Windows systems. Pricing of the system is $80,000, plus $150 to $300 per user, depending on the number. The system was initially announced last year and has four test installations, with formal release scheduled for October. Interestingly, ASA reports its major obstacle hasn't been technology, but getting organizations to accept the degree of decision-making power the system puts into the hands of front-line operators. This is one of the key organizational issues raised by real-time relationship management.
Of course, DecisionPOS is not a full implementation of a real-time relationship management system and doesn't claim to be: it supports only some touchpoints, can't automatically adjust its models as customer behavior changes and offers no approach to optimizing long-term relationships. It is in fact an unintegrated “point solution,” solving one particular part of the relationship management challenge. Such products are typical in the first stage of a new technology.
Taken in this context, DecisionPOS is an interesting product in its own right and an intriguing hint of things to come.
David M. Raab is principal of Raab Associates, a consultancy specializing in marketing database technology.
