How to Choose a Marketing Technology Stack, Part 5 of 7: The Marketing Technology RFP

In this series, we’ll unpack our marketing technology deployment strategy. We’ll learn how to properly plan a marketing technology stack rollout, develop a sensible governance model, examine what could go wrong, and succeed on the first try rather than patch and duct tape a disaster repeatedly.

Part 5: The Marketing Technology RFP

Believe it or not, choosing the actual marketing technology is one of the easiest steps in the process now. Why? After all, aren’t there thousands upon thousands of vendors, as Scott Brinkner illustrates with this marketing technology super graphic:

Yes, thousands of companies are vying for our attention, our interest, our data, and our dollars. Had we started the process of searching for a marketing technology stack by evaluating the landscape and trying to choose vendors, we would unquestionably be overwhelmed. The only thing differentiating all these vendors would be the quality of their sales skills.

However, consider what we’ve determined thus far in our analysis of our own needs:

• Our overall strategy and goals, what we aim to achieve, and how we’ll measure success
• Our people governance, from team members to stakeholders, who will be doing what
• Our budget, needs, and timeframe
• Our deliverables, methodologies, and business case
• Our dependencies, risk analysis, polices and procedures, and oversight

When we take a step back and look at all we have defined, we realize that choosing marketing technology vendors will be significantly easier. We’ve defined, by the steps above in previous posts, all the disqualifying conditions that rule out choosing many vendors. For example, if we work in an industry in which PCI or HIPAA compliance are must-haves, we identified those in our process and governance models. Thus, any vendor lacking PCI or HIPAA compliance is out of consideration.

If we determined in our people phase that we require multiple team members with varying levels of access to information, then any vendor which doesn’t provide granular access control lists and permissions must be ruled out.

Creating the Dreaded Marketing Technology RFP

How do we distill down all our research to this point? We create a marketing technology RFP template for our vendors to complete. No one likes or enjoys RFPs, but when we’ve done our due diligence in defining the strategy, people, and governance in our marketing technology plan, creating and issuing an RFP is straightforward.

We build an RFP based on our previous steps:

Strategy

In the RFP, we state our strategy, goals, KPIs, and metrics. For example, if we’re choosing a social media publishing tool, we might state:

Our goal is to accelerate our sales pipeline with social media. We will measure the tool’s effectiveness by social touchpoint and velocity of sale, benchmarked quarterly.

This outline of strategy clearly articulates what we want from a vendor’s tool. A vendor who focuses on awareness rather than sales acceleration might opt not to participate.

Background

For companies unfamiliar with our organization, we should provide useful information and background for their proposal. Use whatever appropriate boilerplate necessary to detail industry, background, company size, and other needs relevant to the vendors involved.

Proposal Guidelines/Scope

In our RFP, we clearly articulate our budget, timelines, deliverables, and milestones. We also specify RFP logistics as well, so that vendors are clear about what to submit and when. For example, we might put the following in the guidelines:

This RFP is due on 31 March 2017 at 11:59 PM Eastern Time. All materials must be received by this time; no submissions will be accepted after this time.

The submitting organization must include in its proposal the following:

• Budget: not to exceed $125,000 annually
  
• Project to begin no later than 1 May 2017 and conclude implementation no later than 31 August 2017
  
• Deliverables required:
  
  • Fully deployed social media publishing infrastructure
    
  • Connection to all relevant social media accounts
    
  • Two (2) one-hour trainings delivered to staff by webinar
    
  • One (1) web portal with documentation for the product
    
  • Fifteen (15) hours of support per month
    
• Milestones:
  
  • 1 May 2017: Project begins
    
  • 1 June 2017: Requirements gathering concluded
    
  • 1 July 2017: First user testing to begin in beta
    
  • 1 August 2017: First user training to begin in production
    
  • 31 August 2017: Project concludes
    

If a vendor is unable to meet any of the criteria above, they will know not to submit for the RFP. In our guidelines, we might also want to specify other parts of our governance process, such as who the day to day contact will be, or how the vendor will be managed.

Criteria for Selection

The final section of the RFP should specify how a vendor will be chosen. Factors such as experience, budget, previous examples, expertise, industry knowledge, conflicts of interest, and other selection criteria should be clearly spelled out so that vendors may elect not to participate if they are unlikely to be chosen. We might state:

SHIFT Communications will evaluate proposed solutions on the following criteria. To ensure consideration for this RFP, your proposal should be complete and address the following:

– Experience: detail how you have deployed similar solutions to similar companies of our size

– Budget: detail how you will achieve an on-budget deployment, and certify your understanding that if your submission is accepted, you may not request any additional funding for any reason; you will absorb any and all unplanned costs

– Features: detail how your product aligns to our strategy in section one and our specific features needs in schedule A (attached)

– Conflicts of interest: declare any conflicts of interest you may have with competing companies; if you have a conflict of interest, detail how you will resolve it and ensure confidentiality

Be clear in how selection criteria will apply to the accepted proposal.

Make the RFP as long as it needs to be

One final note on the RFP: make it only as long as it needs to be based on the scope of the project. Consider the governance models we explored in part 4; very tactical projects require little more than a scope or project charter. Enterprise-wide strategic projects incorporate a complete governance model with everything from values and ethics to regulatory impacts detailed in them.

Our RFP process should mirror our governance process; whatever we need to govern a project effectively also belongs in our RFP.

The Importance of the Marketing Technology RFP Process

The RFP process may seem tedious and laborious, but it’s vital for marketing technology stack vendor selection because it ensures we’ve chosen a vendor who meets all the criteria of our strategy, people, and governance. Choosing a vendor simply because we met them at a trade show or read their white paper inevitably leads to disappointment when they don’t live up to their hype in deployment. Choosing a vendor who aligns to our requirements ensures that we make the most correct choice possible up front.

Next: Rolling Out

In the next post in this series, we explore the rollout of our solution: what can go right or wrong, and common mistakes. Stay tuned!

Christopher S. Penn
Vice President, Marketing Technology

[cta]