Refining Your Systems Proposal

MANAGEMENT IS ACCUSTOMED to seeing systems development proposals that estimate a return on investment. While such projections are more difficult to arrive at for analytical than operational systems, they’re often required to get a marketing database approved.

Here are a few suggested rules of the game.

* Annualize database costs. You will have one-time development expenses for hardware, software licenses, design and development resources, and initial data conversion work. You’ll also have ongoing costs for data processing, database updates, and internal and/or external system management. Project your one-time and ongoing costs as separate categories over a 12-month period. All expenditures need to be weighed against your annual marketing program and related results. Ongoing costs need to be covered by ongoing program results. One-time costs, on the other hand, could be covered over the first two to three years.

* Estimate results within the bounds of your current marketing environment. Rather than making projections based on a bigger budget, a larger staff or other internal improvements, assume the rest of your world will remain the same.

* Make assumptions. At the same time, you’ll need to make some assumptions about the dynamics of your current environment. Based on the past, project the growth of your customer base and customer attrition rate. Also keep track of marketing metrics such as response rates, average order and marketing program costs.

* Set realistic improvement targets. “Realistic” and “conservative” are relative terms. Still, try not to be unrealistic with projections. Your entire proposal could be called into question.

* Categorize improvements. First, identify hard benefits (those that have measurable results) vs. soft benefits (those that do not). Then classify the hard benefits as net margin increases and expense reductions. The former category would include increases in acquisition, retention, cross-sell and upsell response rates, and greater conversion of one-time buyers. The latter category would include reductions in campaigns targeting chronic returners and related return expenses and cuts in promotions to inactive customers and in untargeted efforts overall. Project these improvements annually for at least three years, erring on the conservative side with your outlook.

* Back projected improvements with test results. Provide “real life” examples of programs that have had an impact on results. While past performance is no guarantee of future success, some measurable improvements can lend credibility to your case.

* Weigh returns against investments. Projected returns must then be weighed against the expected three-year investment outlay for the marketing database. With these numbers in hand, you can calculate estimated days for the system to pay off, with and without one-time costs; break-even improvement rates for each initiative and for all initiatives combined; and the monthly, quarterly and annual cost of not using the database. Add some graphics, and this can be a very effective closing argument in your proposal.

Creating a Prototype Although you may have made an impressive case for your effort and projected the sizable results that could be achieved with a bigger database marketing system investment or new system altogether, what can you do if senior management-or maybe your company in general-doesn’t seem to be in a buying mood?

Moreover, what can you do if it’s going to be another year before the multimillion-dollar system investment is approved? How can you prove to management that yours is a worthy cause?

Creating a prototype environment may b e the answer. A short-term focused test-a “learning lab”-can yield many benefits.

* Perhaps your database proposal was resting heavily on several assumptions about customer behavior, or on how you could change that behavior. A prototype allows those assumptions to be tested before management makes a major financial commitment.

* While your short-term marketing focus may be on acquisition or retention, you can learn a lot about your data, analyses and related functional database needs in the testing process.

* You can implement and prove results from a learning lab environment much more readily than if you had begun full-scale database development. Such demonstrations can help win the support of your senior management.

Take a look at where you’ll get the biggest bang for the buck. Is it in consolidating two of your customer files? Profiling your best customers to guide your acquisition efforts? There are often several low-cost, relatively simple steps that can provide some understanding of your customers and the marketing direction you need to take.

When you’re ready to build a prototype, establish a key business objective. Keep in mind this is supposed to be a short-term test, a fairly low-budget effort. Don’t try to solve all your database marketing objectives. Rather, select one that can be addressed before full-scale implementation.

A few other things to remember:

* Keep the effort low cost; don’t overbuild. If you try to do too much with a test environment, you jeopardize its success. Focus on showing results.

* Make sure your marketing strategies, programs and results are scalable. If you can’t expand your programs across the customer base, you haven’t proven you need anything more than a prototype.

Note that, in this case, “scalable” does not apply to your technical architecture. You might be working with flat files in SAS, or a few simple tables in Access for your learning lab effort. You might move to an Oracle database and a variety of OLAP and CRM tools when you roll out. So don’t spend too much time on the technical aspects of your short-term environment.

* Monitor and measure results closely. If the prototype is your test bed, you need to make sure everyone agrees with its progress.

You can use this approach to better understand the dynamics of your customer base. If you’ve done your homework, the findings should support a system that can handle your company’s business analysis and communications needs.

The biggest benefit is the time the learning environment affords: A system is up and running while the company plans a more robust solution.