The Standard MarTech RFP Process Is Broken and Vendors Know It

I've sat on both sides of an RFP — helping a client write one, and helping a vendor respond to one. From the vendor side, the game is obvious the moment you see the questionnaire: answer every question in the affirmative, cite a case study that sounds adjacent to the buyer's industry, and never volunteer a limitation unless directly and specifically asked. From the buyer side, almost nobody asks specifically enough.

The RFP rewards the wrong skill

A 40-question RFP measures how good a vendor's sales engineering team is at writing RFP responses. It does not measure how good the product is at the thing you actually need it to do. I watched a client pick a CDP based on an RFP where every box was checked 'yes, supported,' only to discover during implementation that 'supported' meant 'technically possible via a professional services engagement we didn't mention the cost of.'

An RFP checkbox marked 'yes' tells you a vendor's writer is good at their job. It tells you nothing about whether the feature works the way you need it to.

What actually predicts a good fit

• A working sandbox you configure yourself, not a scripted demo someone else drives.
• A reference call with a customer who isn't hand-picked by the vendor — ask for your own industry and company size, not theirs.
• A specific, painful edge case from your own data pulled through the tool live, not a generic demo dataset.
• A direct question about what the product does badly — the answer quality tells you more than any feature matrix.

The honest alternative to a 40-question RFP is a shorter list of the three or four things that would actually kill the deal if they didn't work, tested directly against your own data before anyone signs anything. It's less defensible in a committee meeting — 'we tried it ourselves' doesn't produce the same paper trail as a scored matrix — but it produces a better decision, and that's the thing the RFP was supposedly there to protect in the first place.