Making Sense of Marketing Software – Part 4 of 12 by David M. Raab DM Review January, 2000
Last month’s column described a grid that classified marketing software based on processing interval (technology) and campaign complexity (functionality). This is reproduced in Figure 1.
(Figure 2 – Marketing System Grid)
campaign complexity (functionality)
none
simple rules
multi-step campaign, multiple campaigns
processing interval (technology)
batch
conventional campaign management
near-real-time
interactive support
email campaigns
marketing automation
real-time
collaborative filtering
personalized Web site
interaction management
What’s important about the grid is that it gives some idea of which product groups are the best prospects for integration. From a technical standpoint, the horizontal axis dominates: real-time systems have to be built in certain ways to generate quick responses, regardless of the complexity of their campaigns. So it will be technically easier to combine collaborative filtering with Web site personalization than to add interaction management to a marketing automation product.
It also seems logical that making a system run slower is easier than speeding it up: that is, adding batch or near-real-time capabilities to a real-time system is easier than adding real-time functions to a batch process. If true, this would mean it’s easier for a product to expand up the grid than down. But the fundamental requirements for high-performance batch processing and high-performance real-time processing are so different that this isn’t necessarily true.
The vertical axis dominates where marketing functions rather than technical issues are involved. For example, the campaign functions in a conventional campaign management system are much more similar to the campaign functions in a marketing automation system than an email campaign manager. This means that system designers and marketers will find it intuitively easier to understand how systems in the same column should work together, whatever the technical challenges of achieving this integration. Unlike the horizonal axis, the vertical axis has a definite hierarchy: it’s much easier to make a system run simpler campaigns than to add campaign complexity. So adding email campaigns to a marketing automation system is much easier than transforming an email campaign manager into a marketing automation product. But the hierarchy applies only to campaign management functions. When all aspects of a system are considered, a product on the left may be considerably more complex than one to its right. A good customer support system has many more moving parts than an email campaign manager.
Taken together, these observations provide some specific guidelines for vendors seeking to expand their products and for buyers considering a multi-purpose system.
– Products on different horizontal levels may appear similar functionally, but have different underlying technologies. So vendors who want to expand in this direction should anticipate keeping at least some separate data structures and processes to support the new level. This means their current technology (and technical staff) may not be appropriate for the new level–so they should consider purchasing an existing product, and pay close attention to the technology they are buying. Then they can expect a substantial integration challenge at both the technical and personnel levels.
– Marketers purchasing a system that promises to work at multiple horizontal levels should pay close attention to technical issues. If the system was initially developed to work at one level, how did the vendor expand its capabilities to the other levels? If it developed the expansion in-house, did it use different technologies for each level or try to use one technology for all? If it grew through acquisition, how were the different products and technologies combined? If the system is strongest at one level, is it the level you care about most?
– Products on the same vertical level are functionally different but share similar technologies. Vendors who expand in this direction will find it easier to develop an integrated system with their current technical resources but may find it harder to understand the marketing and business requirements of a new application. This means they are likely to need design help from users or specialists in the new field. They may also find themselves selling to a new group of users. If they grow by acquisition, vendors should plan to add the new functions to one or the other existing product rather than keeping separate data structures and processes. Which product they keep will depend on the relative complexity of the different systems, not their position on the grid.
– Marketers considering a system that crosses several vertical columns should look carefully at its functional sophistication in each area. As always, it’s useful to know the genealogy of the product–most systems were originally designed to provide a single function, and are still stronger there than in areas they added later.
– Marketers should also look closely at how a vertically-integrated system will communicate with external products. Point solutions are intentionally designed for easy communication, because they expect to be part of a larger group of systems. But integrated solutions hope to be self-contained, so links to external products are often less of a design priority. The problem is that most integrated solutions don’t extend to all contact methods–Web, phone, direct mail, field, and so on. So if the integrated functions are not accessible to external systems that support these methods, the user will need to duplicate the integrated functions or do without. For example, imagine personalized Web site software with embedded collaborative filtering. Sounds great. But what happens when somebody decides to do collaborative filtering at the call center as well? If the Web site collaborative filtering system isn’t accessible, the user has to buy another one. Now the embedded collaborative filtering doesn’t sound so great after all.
