At a glance
A useful martech RFP starts with the workflows, data and outcomes the organisation needs, then asks suppliers to demonstrate how their product handles them. Separate essentials from preferences, compare full lifecycle costs, demand evidence and use a focused trial only to resolve genuine uncertainty.
Most software can look impressive in a feature matrix. The difficult questions appear later: who cleans the data, which integration needs custom work and how much effort the weekly campaign will take.
A martech RFP should expose those questions before the contract is signed. Its purpose is to compare how suppliers solve your actual problem, not how confidently they tick boxes.
Describe the work before the requirements
Choose three to five workflows that matter most. Describe the starting data, the person doing the work, the intended result and the systems involved.
For example: “A regional marketer must create an approved campaign using centrally maintained segments, localise the content and return engagement data to the CRM.” That gives a supplier something concrete to demonstrate.
The UK Government’s Technology Code of Practice offers a useful public framework for considering user needs, integration and technology purchasing. It is written for government, but the discipline of defining the need before selecting the product is useful more widely.
Ask for evidence, not a yes
| Weak question | Stronger request |
|---|---|
| Does the system integrate with our CRM? | Show the objects, fields, direction, timing and failure handling |
| Is it easy to use? | Let a representative user complete the agreed workflow |
| Does it support reporting? | Build the report from our sample definitions and explain any gaps |
| Is implementation included? | List supplier and customer tasks, effort, dependencies and exclusions |
Use the same scenario and sample data for each shortlisted supplier. A polished demonstration of unrelated functionality should not outweigh a clear answer to your core requirement.
Separate essentials from preferences
Define the requirements that would rule a product out. Keep the list short and defensible. Then score the remaining criteria according to their importance.
If every requirement is mandatory, the document probably includes wishes that have not been challenged. If the scorecard gives equal weight to an essential integration and a minor interface preference, it can produce a mathematically neat but commercially poor choice.
Ask stakeholders to agree the weighting before the demonstrations. Changing it after everyone develops a favourite makes the process harder to trust.
Price the whole relationship
Request licence assumptions, usage limits, implementation, migration, training, support, integration maintenance and exit assistance. Ask what happens when volumes grow or the team adds another region.
Include the work your own team must provide. A low implementation fee may assume substantial internal effort. The supplier should make that assumption visible.
Run a stack audit before procurement to identify tools you can retire and capabilities you already own. When customer data is central, use our CRM, CDP and warehouse comparison to avoid buying the wrong category of product for the job.
Use a trial to resolve a question
A trial is valuable when it tests a specific uncertainty. Can the team build the segment? Does the integration preserve the required fields? Can a colleague maintain the workflow after the consultant leaves?
Agree the success criteria and required support before starting. Do not let the trial become unpaid production work for the buyer or an unstructured tour of every feature.
Write down the trade-off you are accepting
No supplier will be strongest on every dimension. Record why the chosen product wins, where it is weaker and how the team will handle that weakness.
That record is useful six months later when people ask why a limitation was accepted. It also makes implementation priorities clearer.
A good RFP ends with a decision the organisation can explain. If the only explanation is that one vendor scored 87 and another scored 84, the evaluation has probably missed the most important conversation.
