Database Prospecting Solutions: Choose the Right Database Prospecting Solution Model

InfoManagement Direct, February 2001

Steve Scruton

In Part 1 of this two-part series we described the three basic models of database marketing solutions: shared, hosted and integrated. We said that in a shared model, the marketer realizes significant advantages over traditional service bureau based implementations — i.e., marketers still share software and hardware costs with other service bureau subscribers but gain the ability to analyze data and generate counts before committing to a campaign. In the hosted, or ASP, model marketers gain direct desktop access to relational database management, campaign management and data analysis tools via remote connectivity. Users, even remote ones, can do hands-on analysis of the data, where in a shared model they depend on service bureau personnel to act as intermediaries. In an integrated model, the marketer implements a solution on- site that fits the organization's specific needs. Here, the solution provider offers many of the benefits of a systems integrator – offering best-of-breed components and a solution architecture that can meet the needs of the largest and most sophisticated marketer.

What We All Want

All of these models have two things in common. First, they provide genuine database marketing capabilities. Second, they all require an up-front analysis of the marketer's individual situation. That analysis begins with the value question: Why do you want a database marketing solution in the first place? It doesn't matter how small or big your program, every marketer wants what an effective relational database solution can bring – greater processing efficiencies, faster time-to- market, an expanded prospect universe and improved targeting. The next obvious question is: How much of these things can my organization afford and benefit from?

Table 1 lists the criteria used to make exactly this type of evaluation. In general, what you gain as you move from left to right in this chart are robustness, customizability and flexibility. Robustness means you can add more of your own data to the data mart, and you have greater latitude to customize the applications or, at least, your use of the applications. Your ability to define data content goes up and so does your ability to track the success of your campaign and integrate results from past campaigns into the targeting of future campaigns. On the other hand, as you move to the right, you also gain added cost (both acquisition and support costs), and solutions take longer to implement.

Figure 1: Relational Database Marketing Solution Models Selection Criteria

Two questions probably weigh more heavily than others on the selection process: Do I buy the software and have remote connectivity (the distinction between model 1 and models 2/3)? Do I want to be locked into the provider's ETL cycle (the distinction between models ½ and model 3). You also have to decide which of these two questions should be answered first. If the buy question is more important, that probably means setting your own ETL schedule is not a priority. If it is a priority, than you already know you'll have to incur the cost of software licenses.

Table 2 gets into detail about questions marketers should consider in order to determine where they fall on this continuum of low cost and fast implementation versus robustness and customizability. Actually, helping organizations answer these questions (and asking others) is one of the solution provider's value responsibilities — a process called requirements definition. Obviously, the bigger or more frequent the campaigns, the greater the number of users, the more complex the data (both in content and structure) and the more to the right on Table 1 the selected solution model is likely to fall — i.e., the more likely it's going to be a hosted or an integrated solution.

On to Implementation

What happens after requirements definition differs sharply depending on the model chosen. In models 1 and 2, the implementation impact is obviously much more limited than in model 3. In model 1, the "implementation" is pretty much the establishment of a protocol between the marketer's organization and the solution provider's. Things to be settled include what consulting services will be provided, modes of interaction (meetings, phone calls, email, etc.), report formats, content and frequency — e.g., how often the service bureau will provide counts and what information is needed to generate the counts.

In model 2 – the hosted solution – interaction will be less between people and more between people and the applications with which the marketer's personnel have remote access. Questions such as, "How often or in what format reports need to be done?" are de- emphasized since the users can generate pretty much any reports they want as long as those are allowed by the software. Another element that may be needed (that is not required in model 1) is an assessment of training needs and training follow through. Organizations also need to look at how and to whom application access will be deployed — since these issues impact the organization's existing networking and computing infrastructures.

In model 3, requirements definition is just the first in a multiphase process that moves on to solution design, development and deployment. Phase I is also more robust than for the other two models because it must address both business requirements (phase I, stage I) and functional requirements (phase I, stage II). For example, it might look at whether additional servers are needed — say, one each for data analysis, campaign management and data mart builds (ETLs).

In model 3, the next step is to create a solution architecture. Figure 1 shows an example — one of many that might be considered in light of the marketer's specific needs. Solutions like this represent the ultimate in market prospecting power. Their inherent scalability means they have only one real limit – the amount of compute power the marketer wants to bring online. In these days of rapidly declining processor and storage prices, that's almost like saying you can prospect without any limits at all.

Figure 3: Example Relational Dtabase Prospecting Solution Architecture

Steve Scruton has been senior vice president of sales and marketing since 1996 for MITI Prospecting Solutions, a company that is focused on providing the best and most effective multichannel prospecting and acquisition solutions in the industry. Scruton has worked in the data/database marketing industry for 11 years, concentrating on consumer data. He has more than eight years of credit-based experience, and has developed a strong background in credit card, retail banking, finance and insurance database marketing applications. He has developed large scale prospecting solutions for companies such as First Union, CENTEX, The Money Store, Wells Fargo and Nationwide Insurance.

For more information on related topics, visit the following channels:

• DW Design, Methodology
• Databases