How to Organize Database Priorities

Posted on by Chief Marketer Staff

When talking with marketing database users about their needs, you’re guaranteed to hear a variety of opinions and expectations.

In some cases, the conversation you hear might sound like it’s describing food processors or other tools, with talk about slicing, dicing and drilling. Automatic on/off switches and variable speeds are of utmost importance to these folks.

In other instances, users might sound like a SWAT team of database marketing geniuses. These people discuss how the system will increase penetration by 67%, generate $2 million in incremental revenue or drive subscription length rates up to 24 months.

Still others will talk about the chance to roll up their sleeves and

How to Organize Database Priorities

Posted on by Chief Marketer Staff

WHEN TALKING WITH marketing database users about their needs, you’re guaranteed to hear a variety of opinions and expectations.

In some cases, the conversation you hear might sound like it’s describing food processors or other tools, with talk about slicing, dicing and drilling. Automatic on/off switches and variable speeds are of utmost importance to these folks.

In other instances, users might sound like a SWAT team of database marketing geniuses. These people discuss how the system will increase penetration by 67%, generate $2 million in incremental revenue or drive subscription length rates up to 24 months.

Still others will talk about the chance to roll up their sleeves and “just get their hands on the data.” That kind of database would seem to resemble a modern-day data delivery mechanism to feed the information-deprived.

A fourth group may view the database as a “customer intimacy machine.” These conversations are usually less interesting than you might think. Typically, these people talk about a system customers will welcome and readily feed with information in an effort to establish a relationship.

Then there are those who are fascinated by technology. They talk about conversion and load programs, relational database management systems and flexible architectures. Discussions could go on for hours about the merits of Oracle vs. Sybase or massively parallel processing vs. symmetric multiprocessing.

So the conversation with the entire user committee tends to be difficult to manage.

Which group is right? Which view is most realistic, practical or effective? It really depends on your perspective. We’ve found the following three tiers useful in helping with users specify their database needs.

– Tier 1: Database applications. At a very high level, what are you going to do with the system? Its business objectives might include retail site selection, cross-selling, personalization, and research or retention programs, among several others. Database applications should address business challenges and promise measurable business results. A business case for a new database development or enhancement initiative should be based primarily on database applications.

– Tier 2: Database features. This tier focuses on key system components that address each of your database applications. These can be categorized as data, process and functionality features. For example, the retail site-selection application may have the following features:

Data: Retail transaction data on current customers in the area; locations of competitors; neighborhood demographics/geographics, etc.

Process: Neighborhood demographics/geographics, consolidation processing.

Functionality: Direct access for the retail site-selection team, integrated mapping capabilities, integrated correlation capabilities.

– Tier 3: Database requirements. Think of this tier as including greater detail about the database features identified above: information relating to how much, when, where and why.

For example, from our features above: Under the transaction data feature, we would specify how many fields, how many records and how often they are updated.

Under the locations of competitors feature, we would specify that we need latitude/longitude information on Store A and Outlets B and C.

Under the direct access functionality, we would specify how many users, the levels of users, how many locations and which types of tool capabilities are required.

Tier 3 requirements are the functional specifications for internal or external development.

Many applications have similar features that can be met by the same set of functional requirements. Yet one or two such requirements may be difficult to fulfill and will serve one feature or application. These should be carefully scrutinized, because requirements need to be grounded in a strong business case that’s not tied to special interests.

In any case, it’s important to address all three tiers of information when specifying your needs. If Tier 1 is missing, the system may not meet users’ business objectives. If Tier 3 isn’t there, there will be a shortfall, as the system will never come to fruition. And it’s much too difficult to get from Tier 1 to Tier 3 without Tier 2 in the middle.

By bracketing conversations into these three tiers, you’ll be able to control potential confusion and gain a better understanding of what expectations might be. Blenders are easier to find than customer-intimacy machines.

More

Related Posts

Chief Marketer Videos

by Chief Marketer Staff

In our latest Marketers on Fire LinkedIn Live, Anywhere Real Estate CMO Esther-Mireya Tejeda discusses consumer targeting strategies, the evolution of the CMO role and advice for aspiring C-suite marketers.

	
        

Call for entries now open



CALL FOR ENTRIES OPEN