David Raab Article Archive

After years of ballooning excitement, the Internet is due for debunking. In fact, it has already begun: Internet stocks are widely seen as overpriced; Internet sales are recognized as still a minuscule portion of the economy; Internet versions of traditional applications are reported to sell slowly. So, some will argue, perhaps the Internet isn’t quite as important as everyone said it was.

This questioning is a normal phase in the technology development life cycle: after an initial round of excitement, people get disillusioned when the promised benefits do not appear immediately. A few dissonant voices soon swell to a chorus of “over hyped”, “Emperor’s New Clothes” and “Where’s the beef?”. Although Internet-bashing is still at the voice-in-the-wilderness stage, this could change quickly. A sudden collapse of Internet stock prices seems particularly likely to produce a large, angry mob in a very short time.

While deflated expectations are generally a good thing (unless you own the stock), the coming period of Internet disillusion holds perils of its own. The chief danger is that people will mistake the temporary delay in achieving the Internet’s potential for a permanent inability to deliver on its promises. They forget the reason that disillusionment sets in: because the implications of a new technology become apparent much faster than the technology can be matured and deployed. So what happens after initial excitement wears off is that the technology develops steadily, until it eventually appears in a stable form that does truly fulfill its promise. This takes several years, even at Internet speed. But when it happens, anyone who decided they could safely ignore the new technology becomes suddenly, irreparably obsolete.

This is directly relevant to marketing software developers. Most of their present attention is dedicated to battling for sales of conventional customer management systems. The developers are aware of Internet-based applications, but see no substantial demand in their core markets. At most, they see Internet applications in peripheral segments like business-to-business marketing. So it feels like they can safely ignore the Internet for the time being.

They couldn’t be more wrong. The major premise of conventional customer management is that marketers should coordinate all messages to an individual, particularly those delivered through operational “touchpoints”. As these touchpoints increasingly migrate to the Internet in general and the World Wide Web in particular, the ability to manage Internet interactions becomes increasingly central. This will apply specifically in the traditional core industries of database marketing–financial services, retail, travel and telecommunications–where Internet-based interactions are already of growing importance. If customer management system developers turn their back on Internet-based applications, then suppliers of other types of systems will develop the necessary capabilities themselves. And when the customer management vendors later decide to extend to the Internet, they will find the territory already occupied.

Obviously this is important if you’re a vendor. But should marketers really care? Does it matter which vendors provide the services for customer management over the Internet?

Most definitely. On a purely practical level, marketers make big investments in customer management systems–in acquisition cost, in systems integration, and in training. They want to extend those investments to the Internet, not to discard them and start all over again. Systems not engineered for Internet marketing won’t be able to make the transition.

Perhaps even more important, today’s customer management systems embody a great deal of sophisticated knowledge on how customer marketing should be done. Advanced targeting, campaign definition, testing, and response analysis techniques have been refined through years of practice and generations of software releases. Systems developed from a different background will not provide the same capabilities, making marketers’ lives more difficult and their promotions less effective.

Before trying to define the requirements for Internet-based customer management, it is worth looking at software developed for related Internet applications. These systems fall into three broad categories:

personalized Web site vendors like Broadvision (650-261-5100; www.broadvision.com) and Smart Technologies (800-362-7947; www.smartdna.com) help companies give each customer a Web experience tailored to their particular needs and interests. This involves gathering information about customer preferences and then creating custom-generated Web pages with relevant content. These products usually include personalized online catalogs and order processing.

automated service vendors like Brightware (800-532-2890; www.brightware.com), Silknet Software (888-745-5638; www.silknet.com), Kana (650-325-9850; www.kana.com) and eGain (408-737-7400; www.egain.com) focus on responding to customer requests for information or technical assistance. These systems rely heavily on “knowledge bases” of common questions and replies. They typically combine fully automated response to simple questions with tools to improve the productivity of human operators who must respond to more complex queries. These products are generally more focused on e-mail than Web interaction, although they are starting to do both.

marketing automation vendors like MarketFirst (408-261-6950, www.marketfirst.com), MarketSoft (781-674-0000; www.marketsoft.com) and Rubric (650-513-3870; www.rubricsoft.com) focus primarily on business-to-business lead management, while Annuncio (650-3314-6000; www.annuncio.com), Imparto (650-937-1200; www.imparto.com) and Paradigm Ovation (813-287-0028; www.paradigmovation.com) encompass most traditional customer management functions. All allow users to create Web-based campaigns that respond to site visitors’ actions as they occur. Most provide substantial profiling, segmentation, response analysis and reporting as well.

Despite the functional breadth of the best marketing automation systems, they are still mostly limited to Internet contacts. This means they cannot provide the cross-medium coordination that is at the heart of the customer management concept, let alone integrate with operational systems for full-scale relationship management. The Web site and automated service vendors are also largely limited in this way–although some of the automated service systems are beginning to look at telephone call center integration.

But, before expanding their reach to additional media, the Internet systems will first need full control of the Internet relationship. Today, the three classes of systems all offer slightly different capabilities, so that a truly comprehensive solution would probably require one product from each group. But this is awkward and expensive to implement, not to mention confusing and inconvenient for customers. Since all three sets of vendors aspire to providing a comprehensive, integrated Internet experience, they will have to either expand their products to encompass the others, or find ways to integrate them easily. The approaches they use to solve this problem will later allow them to expand to non-Internet media as well.

The most likely approach will be to split their systems into two major layers. One will control the presentation of materials to the customer–whether this happens by Web page, e-mail, or, later, in a telephone call center or retail point of sale. Obviously the presentation methods will be specific to the medium involved.

The second layer will involve common services used to accept inputs from the presentation layer, decide how to respond, and then communicate the decision back to the presentation layer for delivery.

This model applies all three groups of Internet-based systems. That is, delivering personalized Web sites, responding to customer questions, and executing interactive marketing campaigns all involve the same general tasks of evaluating a customer input and determining how to respond. This suggests that a single system might well be able to control all three functions.

Of course, the specifics of the process will vary with the type of decision. The automated service systems in particular have advanced techniques for classifying unstructured customer inquiries, such as text messages, and trying to find appropriate responses. The other two groups of systems rely more on structured interactions, such as filling out forms and executing fairly simple sets of if/then rules. But so long as the flow of the interaction process is generally the same, it should be possible to embed different decision-making methods in the same general structure. The Web site and marketing automation products already use this type of approach to integrate specialized tools such as affinity recommendations or statistical model scores. All that’s really required is a set of Application Programming Interfaces (APIs) to structure the transfer of information back and forth. Object-oriented technology standards like COM, DCOM and CORBA make this feasible, if not necessarily easy.

The common services layer will have one other critical function: to keep track of previous contacts with the same customer. The Internet is inherently “stateless”, meaning it deals with each input without memory of what has happened before–sort of the computer equivalent of Alzheimer’s Disease. This is obviously not acceptable when the goal is to manage a continuous relationship. To overcome the problem, systems must record interactions in a database and look up past history when deciding how to react to a current situation. The systems also need information that originated outside of the Internet, including sources within the company–such as purchases and customer service requests–and external databases such as demographics, lifestyle and credit information. This uses pretty standard technology, although doing it in real time for individual customers requires structures resembling traditional online transaction processing systems. This contrasts with conventional marketing databases, which use structures designed for group-oriented analysis. Since analysis is still needed as well, some data will probably be stored in both formats.

While the general picture here seems simple enough, the details surely are not. One issue is how to manage the translation between the presentation and common services layers–that is, how do you take inputs from different formats and put them in a common language so they can be handled consistently? Today’s vendors of single medium systems sometimes argue this is neither necessary nor desirable: instead, they maintain a separate “knowledge base” should serve, say, the human operators in the telephone call center and the form-based queries generated on the Web, given the differences in the mode of interaction. But this seems more like a translation problem than a need for different underlying databases–it is hard to believe a customer should get different answers to the same question depending on how she asks it, or that anybody would voluntarily accept the requirement to keep separate knowledge bases in synch. As vendors develop cross-media solutions they will undoubtedly decide that unified knowledge bases are in fact superior.

The translation problem is a tricky one, since it is not even clear where the translator should reside. If it is in the presentation layer, then it will be automatically “aware” of the capabilities of whichever presentation system (Web, e-mail, call center, etc.) it belongs to. This is good, but means that each presentation system will have to independently maintain compatibility with the language used by the central system. That is, introducing a new category in the central system would require adding it separately to each presentation system–an obvious invitation to confusion. But if there is one central translation system, then that system must be kept aware of the specifics of each presentation system that will address it. Perhaps an industry standard will evolve to allow this type of cross-medium translation, but I am not aware of any being created to date. (If any readers know otherwise, please tell me about it.)

The translation problem exists in both directions: not only must presentation layer inputs be converted to a common language, but responses must be transformed into formats needed for presentation back to the customer. Again, this needs a choice of location: where do you store the media-specific items such as HTML pages, telemarketing scripts, direct mail text messages, etc.? As with inputs, there is a trade-off between the complexity of making one central system serve all presentation media, and the administrative challenge of keeping separate presentation systems aware of what the central system might send them. Again no standard exists, although some vendors have developed proprietary solutions that embed output in different formats within a single, all-purpose document.

Just to add to the confusion, the business decisions themselves will almost certainly depend in part on the medium being used–you might choose to ask more survey questions on a Web page than during a telephone call. So even if a translation system could put inputs in a common language, the decision engine would still need to know the original medium.

A second critical issue is the degree of detail to be contained in each communication from the central system. (The IT folks would probably refer to this as “granularity”, a wonderfully scientific-sounding word that means, well, degree of detail.) At one extreme, each user entry might be sent to the central system for a decision–a solution that maintains close central control, but requires a great deal of communication. At the other extreme, the central system might simply tell the presentation layer to execute an entire communications script or complete business process–for instance, turning control over to an order entry system. This minimizes the load on the network and the central system, but requires that the presentation-level processes be defined in detail in advance. As with translations, the more done independently in the presentation systems, the greater the challenge of keeping the different systems synchronized. A reasonable guess would be that different situations will call for different levels of central control.

A third wrinkle is that systems will actually make multiple decisions while preparing a single response–say, first a campaign management decision to send a cross selling message, and then a product affinity decision about which product to offer. This is quite compatible with object-oriented technology, although it may be a performance challenge to get several systems to render decisions quickly enough to give a fast reply. In fact, the need for quick response is just one of several constraints on the technology of the decision engines–they must function with relatively limited amounts of data (to keep down communication and storage costs); must deal gracefully with incomplete or unexpected values; must adjust automatically as the real world changes (or, at least, inform users when predictions fall below an acceptable standard of accuracy); and, must be able to balance multiple goals (such as balancing likelihood of response against the cost of making a promotion) as well as valuing multiple alternatives simultaneously. Some technologies–in particular neural nets and Bayesian networks–are better at this than others, although as ever the right tool will depend on the task at hand. The issues of multiple goals and values lead to the murky depths of optimization management, which is not unique to the Internet and thus can be set aside for the moment.

The need for multiple decisions also raises a fourth issue: how will the decision sequences get designed in the first place? Must they be hand-crafted to meet each situation, or will there be ways to create and evolve them automatically over time? The question applies both to the structures of the decision-making processes, and to the specific responses they have available to choose from. Today’s systems rely almost exclusively on manual design for both of these, but in the long run the sheer volume of options means that some sort of automated approach seems essential. Some of the automated service systems are moving in this direction with methods that “learn” appropriate responses by watching results over time, and sometimes even assemble their own responses from existing components. But even their developers are generally modest in the claims they make for the systems’ performance.

So where does all this leave today’s customer management system vendors? Must they suddenly enter a race across unfamiliar terrain to solve all these problems before the Internet vendors get there first? And if they decline the contest, have they ceded control over Internet touchpoints and condemned themselves to inevitable marginalization as Internet technology engulfs the rest of the organization? It seems quite clear that whoever solves the problems just described will have no real difficulty duplicating the functions provided by today’s customer management systems. After all, while today’s systems are indeed very sophisticated, they are ultimately just decision engines that work at a lower speed with fewer alternatives than their Internet-based counterparts.

Happily, the future isn’t quite so bleak. The first piece of good news is that the Internet vendors themselves are far from solving these problems. They must first fight their own battles to determine who controls the Internet touchpoints, in which the most expeditious strategy will be to develop closed solutions that combine the presentation and central layers in unified, proprietary systems. This will help individual vendors to serve individual clients, but will also require an all-or-nothing commitment that slows the widespread adoption of any one product. It will also slow the Internet vendors’ move into the non-Internet world, since they will have to custom-build translators for each new medium.

As the Internet vendors compete among themselves, standards will eventually emerge. These may either be de facto standards defined by the APIs of the most popular Internet customer management vendors, or industry-wide standards imposed by users or standards organizations. Either way, the standards will provide an opportunity for customer management systems to adapt themselves to work within the Internet vendors’ frameworks.

But what role will the customer management systems play in this new structure? This will depend largely on the talents and ambitions of the individual firms. Still, it seems the truly unique capability these vendors offer is the ability to define, manage and measure long-term customer strategies. This is something quite foreign to the Internet systems, which are focused on giving customers what they ask for, in terms of personalized Web sites or answers to questions, or on executing specific marketing campaigns such as lead management programs. The customer management systems focus on identifying and encouraging profitable customer behavior, which is rather different. In more concrete terms, it means the customer management systems become decision engines that determine which actions are most likely to increase the value of the over-all customer relationship. This leads directly back to the issue of optimization–a difficult challenge in itself, but at least one where customer management vendors are on familiar turf.

The role as a decision engine does not place customer management at the center of the interactive architecture. In fact, one might argue that no system is really central in a world of multiple, distributed components. Nor is it clear that a “central” system would reap the greatest financial rewards–fees charged by credit scoring vendors and product recommendation tools already illustrate how profitable it can be to offer a specialized decision engine.

But if there is a controlling position in the new architecture, it probably belongs to whatever component determines how the decision engines are strung together–that is, whatever builds the decision sequence. Customer management vendors could attempt to provide this function, either through manual definition or automated optimization. Indeed, sequence creation is arguably an extension of their current functions for campaign definition. Whether the customer management vendors can assume the role of sequence definition depends on their ability to interact with the various supporting systems, both within the central layer and across to the presentation layer. This, in turn, will depend on their own technical prowess and, perhaps even more important, on whether appropriate standards become available.

Whatever role a customer management vendor hopes to play in the Internet environment, certain technical approaches will be the price of entry. System buyers concerned about the long-term adaptability of their purchases should keep an eye on how the vendors handle these as well. Important approaches include:

– Separate the system from specific data models. Most of today’s major vendors have already developed a “metadata” layer that lets their system communicate with underlying databases in different structures and formats. This is critical if their systems are to handle the increasing variety of data sources that will become available. Ideally, the metadata layer itself would be use industry standard, although no dominant metadata standard yet exists and system-specific extensions will probably be needed in any case. Object-oriented approaches may provide an alternative, although performance could be an issue.

– Extend metadata to encompass campaign information. Despite the widespread use of metadata to access customer and transaction data, many systems still rely on fixed data structures to hold the data they generate internally–such as campaign attributes and contact history. This greatly simplifies routines that create the data and report against it, since the system knows exactly what to expect. But it will be unacceptable in a world where multiple systems are generating contacts and analyzing the results. So a more flexible approach is essential.

– Decouple the system from specific scoring techniques. Ironically, tight integration of campaign management with statistical modeling and scoring is one of the major improvements to become available in the past year or so. It provides substantial productivity and performance benefits that would be hard to give up. But the new architecture will include many decision engines including multiple scoring tools, each suited for a particular purpose. So systems will need to accommodate many different scoring inputs, presumably through standard APIs. Vendors who have integrated tightly with a single scoring system can of course leave the integration in place, but should eventually rebuild it to work through an API as well.

– Engineer for real-time interaction. Much of the ability to handle real-time, individual customer interactions depends on the underlying data structure, which should be isolated from the customer management system by a metadata layer. But even metadata lauyers makes some assumptions about how the data will be accessed, so it is important that the system be designed to handle one-customer-at-a-time transactions rather than multi-customer batch selections. In particular, the system must be able to manage real-time dialogues without waiting for an update cycle to decide on each response. This probably means breaking large, conventional campaign trees into several smaller branches, which can be executed in whatever sequence makes sense based on a particular customer’s behavior.

– Redefine outbound campaigns in terms of customer interaction. Traditional campaign management is mostly about sending unsolicited messages, and even conventional customer management is largely implemented by delivering predefined messages through touchpoints. But the Internet model is focused on reacting to customer inputs. If Internet system become the primary customer management mechanism, then outbound campaigns must be redefined to fit this approach. This is not conceptually difficult–it simply requires a batch process to initiate interactions instead of the customer. In fact, the Internet marketing automation products already have this capability. But conventional customer management systems may require considerable reengineering to fit the new structure.

– Refine optimization, segmentation and analysis techniques. These are the unique strengths that conventional customer management vendors bring to the Internet world. They include all the classic database marketing skills for strategy definition, test design, response measurement, and program evaluation. Vendors must be sure these capabilities are part of any Internet-compatible offerings they develop, and should in fact develop new ways to apply them in the Internet context. More than anything else, it will be these features that lead marketers to make conventional customer management vendors a part of their Internet solution.

This last point brings us back to the beginning: the Internet will be the central focus for customer management because the Internet controls the touchpoints, and the touchpoints are the critical medium for customer management. This means that conventional customer management systems will have to live within an Internet structure or become isolated and, eventually, irrelevant. It will take several years–possibly a decade–for this to happen. But vendors who don’t prepare now won’t have time to do it later.

* * *

David M. Raab is a Principal at Raab Associates Inc., a consultancy specializing in marketing technology and analytics. He can be reached at draab@raabassociates.com.