Martech, explained · Buying and running · 2:26
How to run a CDP RFP
Five stages, and where the promises go missing
The short answer
A CDP RFP runs in five stages: use cases, shortlist, questions, proof and contract. Many go wrong by starting at the shortlist. Write three use cases that name the data, who keeps them running and how they break; ask who put each vendor on the list; run demos against your use cases; and get every promise into the contract.
Questions this answers
What are the stages of a CDP RFP?
Five: use cases, shortlist, questions, proof and contract. Many teams start at the shortlist and skip the use cases, which is how every vendor ends up answering yes to every row.
What makes a use case comparable?
It names the data it needs, who keeps it running after launch, and how it breaks. A goal such as improving retention gets the same yes from every vendor.
What should you ask a CDP vendor first?
Whether the product was built as one platform or stitched together from acquisitions, what it was called before, and what works today as opposed to what is on the roadmap.
How do you check CDP references?
Ask for more than one, ask each of them about financial ties to the vendor, and find a few yourself.
Why put vendor promises in the contract?
A promise made in a meeting and not written into the contract does not exist once you have signed.
Transcript
Every chapter as text. Click a time to play the film from there.
0:00 Every row says yes
Three vendors, two hundred requirements, and every row in the grid says yes.
You ran a CDP RFP, and you still can't tell them apart.
0:11 Five stages
The grid isn't where it went wrong.
It went wrong earlier, in the order things happened, so let's draw the process.
A CDP RFP runs in five stages: use cases, shortlist, questions, proof and contract.
Many teams start at the second one.
That's the first trap.
0:34 Use cases, not goals
Improve retention is a goal, not a use case.
Ask a vendor whether they can do it, and there's only one answer: yes, followed by forty minutes of screens.
A use case you can compare names the data it needs, who keeps it running after launch, and how it breaks.
Write three of those before anyone sends a demo invite.
0:57 Who wrote the shortlist?
Then the shortlist, which is often settled before the first line is written.
It comes from an agency that resells one platform, a board member who took a vendor's call, or an analyst report used as a buying guide.
Ask who put each name on the list, and why.
1:15 Three first questions
The first conversations tell you the most.
Was the product built as one platform, or stitched together from acquisitions?
What was it called before, and what changed besides the name?
And what works today, as opposed to what's on the roadmap?
1:32 Demos and references
Then proof: demos run against your use cases, not the sales script.
Ask for more than one reference, ask each of them about financial ties to the vendor, and find a few yourself.
Bring in engineering, data and procurement now, because they'll live with the integrations and the fine print.
1:52 Get it in writing
The last stage is where promises go missing.
If a vendor says it in a meeting, write it down and get it into the contract.
Otherwise, it doesn't exist.
2:04 So how do you run one?
How do you run a CDP RFP, then?
Use cases first, a shortlist you can explain, and every promise in writing.
Do that, and the grid finally has something to decide: three columns that differ.
Learn more at Martech Stack Builder, or build your own.
Read more
The articles this film is drawn from.