Planning Before (and Beyond) RFPing CDP Vendors

Long before you issue requests for CDP vendor proposals, there is significant work happening. It’s important to acknowledge and document this work so that you can quickly move through it and select the best vendor. You can also use the documentation as a playbook to help you move through vendor selection seamlessly in the future. 

If you take the time to plan for each step in the process, you will be able to dedicate the time and resources necessary to choose the right vendor for your business. 

Define key use cases.

In theory, you would begin your CDP vendor selection journey by defining your goals. In practice, the most realistic way to define your goals is to envision the most common use cases you expect the system to support. 

Use cases are the critical link between general objectives and system requirements. Properly defined use cases will identify all the capabilities and resources needed to achieve your goals. Building a comprehensive list is important because any missing capability will prevent you from reaching your goals, whether that gap is in the CDP or somewhere else. Your actual deployment will probably begin with simple use cases such as customer profiling and retargeting lists. But the list you use to develop requirements should also include advanced cases like omni-channel orchestration. If you leave those out, you may find advanced features are not available when you’re ready to use them, which is too late. Defining use cases is also an important part of the organizational process of building an understanding about what the CDP will do—and what it cannot do. This is key to setting priorities and managing stakeholder expectations.

Convert use cases into requirements.

A use case defines the tasks and resources needed to reach its goal. A closely related, but separate, step involves converting those into actual system requirements. This conversion requires a deep understanding of the tasks being executed and the system features that support such tasks. In particular, you’ll want to identify requirements that are shared across all use cases, such as identity management and flexible data transformation. These are core CDP capabilities that should be explored in detail. If no one on your project team has the understanding to do this well, then bring in an outside resource that does. A knowledgeable outside resource can also spot gaps in your use case definitions and give clearer insight into other resources you’ll need to reach your goals, such as staffing and process changes.

Screen vendors against requirements.

Once you have a solid requirements list, you can begin to screen vendors against it. Initial screening will quickly reduce the huge field of CDP vendors down to a manageable number, since many CDPs will lack expertise in your industry. Others will offer capabilities that you aren’t looking for, or simply not be available in your region. This sort of screening can be done using publicly available information, or through quick email or phone conversations. If too many vendors remain after this first round, you might do a short, written Request for Information (RFI) which is different from an RFP. An RFI can give you a sense of key features and services, which is helpful when you are narrowing your consideration set. Try to whittle the possibilities to about a half-dozen qualified candidates.

Demo qualified products.

The purpose of initial product demonstrations is to get a general feel for each system and the company that sells it. If your project team lacks experience with CDPs, the demonstrations will also help build a clearer understanding of the CDP category as a whole. Have your requirements list and a conversation guide handy [Can we share a sample?] so you can ask the right questions and take notes on the answers each vendor provides. This alone should eliminate some additional contenders. Don’t expect an initial demonstration to cover all the details you need to start ranking vendors, let alone select one.

Issue the RFP.

Some companies issue RFPs before any demonstration, but this usually results in RFPs being sent to many firms that are not realistic candidates. A proper RFP should only go to companies that seem well qualified. It gives a chance to collect many details that can’t be covered in even a long demonstration. RFP responses then become the basis for further questions which can be resolved in writing or in a second round of targeted demonstrations.

Schedule scenario demos.

The second round of demonstrations is quite different from the first round of demos. Instead of letting the vendor present what they want to show, in this round, the buyer specifies what it wants to see. This is usually done through scenarios based on project use cases. Each scenario presents a set of tasks for the vendor to demonstrate, sometimes using data the buyer has provided in advance. All vendors are asked to demonstrate the same scenarios, so the buying team can get a clear sense of how the products compare.

Be sure you understand how much preparation was needed before the demonstration: vendors can often make something look easy by doing the hard bits in advance. One way to avoid this is to limit the time the vendor has to prepare the scenario demonstration. Also make sure everything you see demonstrated is actually included in the price the vendor has quoted. If your company has substantial data volume, check that any demonstrated solution is scalable to those volumes. This may require a separate type of test or demonstration. Buying teams should develop scenario scorecards and compare notes shortly after each demonstration to develop a shared assessment of each vendor.

Complete supplemental research.

The use case scenario demos can be supplemented with other discussions based on RFP responses. In some cases, there may be a need for other types of research such as technical demonstrations, proof of concept implementations, or pilot projects. This is also the time to check with reference clients, clarify pricing questions, and meet prospective vendor team members.

Make a decision.

Sometimes, a clear winner emerges from the selection process. More often, there are several viable candidates. Once the research is complete, many teams will develop a scorecard  [Can we share a sample?]with all major factors, weight those factors, and score each vendor against each factor. The numerical ranking that results from this process is interesting, but the real value is in the team discussions about assigning weights and vendor scores. These identify topics that need further research and build consensus around the final choice. Do be sure to keep the project moving: you will never have perfect information or zero uncertainty. Delaying a choice usually only means you are delaying the benefits you will receive when your system is deployed.

Want to learn more about how you can best approach a CDP vendor when in the RFP stage? Download our complete guide today.