By definition, high-end campaign managers are specialized tools for running complex outbound marketing campaigns. However, once a marketing department has acquired such a system, the inevitable desire is to use it for as many things as possible. This saves the cost of buying and implementing additional specialized products. Perhaps more importantly, it makes it easier to coordinate different types of marketing programs, because they all run through the same system. Campaign management software vendors are happy to provide expanded functions because these justify a higher price for their systems, make it more difficult for customers to switch products and permit sales to a broader range of users. The disadvantage from the vendor perspective is that adding such features requires effort from their limited development staff. To overcome this obstacle, many campaign-management vendors have added non-core functions by incorporating third-party products rather than building their own.

The non-core features can be broadly divided into two categories: features to run additional types of marketing programs, and features to provide supporting and administrative functions.

E-mail marketing is the most common extension – in fact, it is nearly universal among today's high-end campaign managers. At its simplest, e-mail requires only that the system generate a list of names to feed an external e-mail server. This is well within the capabilities of any campaign manager. However, real e-mail support generally extends to the set-up and management of e-mail templates, which include options to insert offers and database variables for personalization. This saves users from integrating a separate e-mail authoring system and, in particular, from the chore of mapping that system to the marketing database to make its data elements available for personalization.

Often the e-mail templates can also include logic that selects particular blocks of content based on customer data and, indeed, on other data such as time of day, number of messages already sent in this campaign or previous responses to a particular offer. While it would be simpler for users if this sort of logic was built with the same query interface used in the rest of the campaign management system, many products are not quite so consistent.

The other capability provided by most e-mail modules is an option to track results by embedding unique IDs in outgoing e-mail and capturing them in customer replies. This can be done in a number of ways, including appending the ID to the reply address, embedding it in the message text or attaching it to a reply form. Different methods are appropriate for different situations. E-mail modules also usually provide real-time response tracking and capture e-mail-specific information such as bouncebacks and whether messages were opened. Some products provide opt-out functions that allow customers to request to be excluded from future promotional e-mails.

Multistep marketing programs involve a sequence of marketing contacts and customer responses over time. A common example is a sequence of messages sent in response to a product inquiry. Often this starts with a mail or e-mail message, followed a week or two later by a phone call and then perhaps additional mail or e-mail messages at monthly intervals. Conceptually, this is quite similar to running several independent outbound campaigns, which any high-end campaign manager is configured to do. However, smooth operation requires somewhat different mechanics. The key feature is an ability to lay out the entire sequence of contacts at once and then have all steps execute automatically. This implies an automated scheduler that generates the subsequent contacts when they are due. It also implies a user interface that allows users to specify the interval between contacts as an explicit attribute – that is, "step B occurs three weeks after step A" – rather than simply requiring the user to write a query that includes the interval as one of its terms. Having the interval as an explicit attribute makes it easier to set up the campaign. More importantly, it makes the interval easily available for display, reporting and analysis. If the interval was buried in a query statement, it would take some very sophisticated parsing for the system to extract the interval for such tasks as generating a calendar of future contacts.

A multistep system must also let users define branching conditions to react to customer behavior after the initial contact. For example, a lead management program must stop sending the promotions to people after they make a purchase. As with time intervals, this could theoretically be done through independent queries, but is best handled by making the conditions as visible as possible to the user and the system. This is typically done through an interface that lays out the sequence of contacts on a flow chart, with the branching rules displayed separately at each node. The physical selection process also follows this model, extracting the audience for each step from the audience of the prior step. This is vastly more efficient and less error-prone than using independent queries to select each audience from the main database.

In a sophisticated multistep program, the audience for each step may be divided in a complex segmentation, with each segment receiving a different treatment. Many systems accommodate this by creating separate trees for campaign branches and for segmentation, and then linking one to the other. This approach makes it much easier to see the structure of the multistep program. Where the same segmentation would apply to each step, it also allows the user to create the segmentation just once rather than having to duplicate it many times.

Real-time dialogues represent another extension of conventional outbound campaigns. Like multistep campaigns, real-time dialogues involve a branching sequence of messages and customer replies. However, while multistep campaigns are still generated through batch selections against a customer database, real-time dialogues react immediately to a single customer's actions. This requires a fundamentally different technical approach from batch selections, typically including a data structure optimized for transaction processing and the ability to retain details about the current transaction in memory. The dialog itself is usually set up in a branching tree that looks similar to the trees used for multistep campaigns. While trees for multistep campaigns are usually translated into SQL queries, trees for dialogues are more likely to execute Java scripts or rule engines. Real-time dialogues also require tight integration with touchpoint systems such as call centers or Web sites – requiring yet another set of technologies that are foreign to conventional multistep campaigns.

The implication of all these differences is that even though a campaign manager may support both multistep campaigns and real-time dialogues, the internal components to run these functions may be mostly separate. This, in turn, means that users must evaluate these capabilities independently because maturity in one area does not necessarily imply maturity in the other. It also means users cannot assume the two sets of functions will be well integrated with each other or with the rest of the campaign management system. In fact, the real-time dialogue functions of most high-end campaign managers are still relatively immature. This applies particularly to products that are not part of a larger suite that offers real-time transaction processing in other areas.

Cross-campaign coordination does not itself enable a campaign manager to support new types of marketing programs, but it does help to manage multiple programs simultaneously. Cross-campaign coordination lets a system select the most important message to deliver to a customer who is eligible for several independent campaigns.

In conventional outbound marketing, this sort of coordination usually involves rules which set the maximum number of messages a customer will receive in a given time period. Such a rule might say that customers will receive no more than one e-mail per week. In practice, these rules tend to be fairly complex, with different limits for different media, message types and customer segments. For example, a company might permit more messages to its most active customers and might limit promotion offers but not customer service messages. It's important that these rules be automatically applied to all campaigns, rather than requiring the user to explicitly add them as conditions every time a campaign is built.

An ideal system would set these limits based on an independent assessment of the value of each potential message to each individual customer. However, such values are hard to calculate, so the more common approach is to assign priorities to the campaigns themselves and specify overall limits on contact quantities. The system then determines which campaigns each customer is qualified for – usually in a batch process that considers all campaigns – and selects the highest priority campaigns for each customer, up to the specified contact limit. This method has a number of obvious drawbacks, including that the same priority rankings and contact limits may not be correct for all customers and that new, more valuable campaigns may be added after the initial selections are complete. However, where more advanced approaches are not available, it is better than nothing.

Systems that manage real-time dialogues have a slightly different approach to cross-campaign coordination. Here, the goal is not to enforce limits on the total number of contacts, but to choose the most appropriate campaign to execute during a given interaction. The choice of message may be obvious in the midst of a specific dialog, but significant decisions are required in other common situations – for example, when choosing which banner ads to display on a Web page. The general issue is still how to prioritize campaigns, and the same challenge of how to measure the value of specific campaigns to individual customers still applies. Real-time systems are likely to calculate these values as a transaction occurs, taking into account the customer's most recent actions. They often let customers manage additional constraints – such as limiting how many times the same message is displayed – that are not relevant to outbound marketing.

My next column will continue this series with a look at support and administrative functions.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access