Running a Technology RFP That Actually Gets You a Fair Comparison
We have answered hundreds of technology RFPs from the vendor side. Being honest, most were badly written. Either too vague to compare, or so over specified they killed the competition that makes an RFP worth running. The goal is simple and most miss it: a true apple for apple comparison, where every claim is one the vendor will stand behind in the contract. Here is how we run them so you get exactly that.
An RFP is supposed to do two things: create genuine competition, and let you compare what comes back on a like for like basis so you can choose with confidence. Sitting on the vendor side of hundreds of them, we watched most fail at one or both. The good news is that the failures are predictable, and once you know them the fixes are straightforward. This is how we approach an RFP so it earns the time everyone puts into it.
The point of an RFP is a fair, comparable answer to a clearly defined need, built from claims the vendor will contract to. Most RFPs never get an apple for apple comparison, so the decision ends up subjective, and most never tie the vendor's claims to anything, so the delivery risk quietly lands back on you. Fix those two things and you have run a good RFP.
Most RFPs fail in one of two opposite ways
The first failure is vagueness. The requirement is written in strategic language, transformation, innovation, future state, but never pins down what is actually needed or how it will be measured. When the problem is loose, vendors do not compete on the solution, they compete on interpretation, and every proposal answers a slightly different question. You cannot compare them, so the evaluation becomes a matter of who wrote the nicest words.
The second failure is the opposite, and it is just as damaging. The RFP is so tightly specified, every component, every number nailed down, that it removes the room a good vendor needs to propose a better way of doing it. Over specify and you do not get competition, you get a procurement exercise dressed as one, with a predetermined answer. You lose the very thing the RFP was for.
Both failures destroy comparability from different directions. Too vague and the proposals are not answering the same question. Too rigid and there is nothing left to compete on. The skill is the middle: precise about the outcome you need, open about how a vendor achieves it.
The trap: vendors bend the definitions
When a requirement leaves room, vendors will read it in the way that flatters their kit. Storage is the classic example. Ask for capacity and one vendor quotes raw, another quotes usable, another quotes effective capacity after data reduction they have assumed for your workload. Three numbers, three definitions, all technically answering your question, none of them comparable. The same game plays out everywhere: throughput measured under ideal conditions, an SLA that sounds strong until you read what is excluded, a detection rate quoted against a benign test set. It is rarely dishonest. It is just each vendor answering in the frame that suits them, because you left the frame open.
The fix is not to nail every number down. It is to make them stand behind the claim
The instinct is to close every loophole by specifying everything, raw capacity only, exact test conditions, and so on. Resist it, because that is how you slide into the over specified trap and kill competition. There is a better move, and it is the heart of how we run an RFP.
Let the vendor make their claim. If they say four to one data reduction on your data, fine, let them say it. Then make that claim a contractual commitment. If they will put their number in the contract, with a remedy if it is not met, you no longer need to police the definition, because the risk of the claim now sits with the vendor who made it. If they will not stand behind it, that tells you everything, and it costs you nothing to find out. This flips the whole dynamic. Vendors compete freely on how good they can be, and you are protected not by out specifying them but by holding them to their own words.
Data reduction is just an example. The same rule applies to performance, availability, support response, security efficacy, migration effort, any claim a vendor makes to win. Do not fight over whose definition is right. Ask the vendor to commit to their claim in the contract, with consequences if it does not hold. A claim someone will sign for is worth far more than one buried in a proposal.
Competition is good, even when you have a preferred vendor
Plenty of organisations run an RFP with a vendor they already favour, often for good commercial reasons, an existing estate, a standardisation, a relationship that works. That is legitimate, and it does not remove the case for real competition. Genuine competitive tension gets you a sharper commercial position even from your preferred vendor, and it validates the choice rather than leaving it as an assumption. A vendor who knows they are the only option has no reason to give their best. A vendor who knows the alternatives are real does.
The one discipline here is honesty about intent. If the exercise is really a commercial benchmark to keep an incumbent sharp, structure it as that and be straight with everyone in it. If it is a genuine open contest, run it as one. What you do not do is waste vendors' time on a race they cannot win while pretending otherwise. Fair competition, honestly run, is good procurement. A rigged process dressed as a contest is not, and vendors remember it.
Get to a genuine apple for apple comparison
Comparability is the whole game, and it does not happen by accident. It comes from defining the outcome and the measures once, up front, so every vendor answers the same question in the same terms, and from normalising what comes back so you are comparing equivalent things rather than three different definitions of capacity. Where a vendor proposes a genuinely different approach, and you want to leave room for that, you capture it as a clearly labelled alternative alongside the like for like response, not instead of it. That way you keep the comparison clean and still see the better idea.
Cut the length. Long is not the same as rigorous
Length is the most common tell of a weak RFP. A twelve page executive summary, two hundred lines of yes or no questions, clauses copied forward from procurement exercises nobody remembers. It feels like diligence and it is the opposite. It buries the few things that actually matter, it wastes weeks of everyone's time, and it rewards the vendor with the biggest bid team rather than the best solution. A tight, precise RFP that asks the questions that matter, defines how the answers are measured, and gets to the point, will always produce a better decision than a long one. If something matters, ask it clearly. If it does not, leave it out.
How we run it
We run an RFP through the same discipline we bring to any technology decision, our IDEAL framework, with the vendor side experience to know where the give is.
- Identify. Pin down the real requirement and how success will be measured, before any vendor sees it, so they cannot define it for you.
- Decide. Structure the RFP itself: precise on outcomes, open on approach, tight enough to compare and short enough to respect everyone's time.
- Execute. Run the evaluation and the negotiation, normalise the responses to a true like for like, and turn the winning claims into contractual commitments.
- Adopt and Lifecycle. Make sure the deal survives signature, with the commitments, remedies and review points that keep the vendor honest through delivery and beyond.
The advantage we bring is simply the other side's experience, now on yours. We have written the responses, built the quotes and made the claims. We know which ones a vendor will stand behind and which they will quietly hope you never test.
One thing we are always straight about. On an RFP you can have us whichever way suits you. Stay fully independent and we advise only, with nothing riding on who wins. Or, if you would rather, we can respond to it ourselves as a supplier. Whichever you choose, we tell you plainly which role we are in from the outset. Full transparency, and your call.
Prefer to start with a free, no obligation diagnostic? Book our Technology Procurement and RFP Review, an independent expert read of your live RFP.
Running an RFP, or about to?
Tell us what you are buying and where you are in the process. We will give you an independent, vendor neutral view on how to structure it so you get a fair comparison and vendors who stand behind what they claim. We have answered hundreds of these from the other side of the table.
Prefer email? Reach us directly at hello@c4cgroup.co.uk.
This is how we work in practice. See the technology procurement case study where we cut a UK enterprise's procurement cycles by 45 percent and surfaced 20 to 30 percent in savings, and the VMware licensing case study where an independent audit held a Broadcom renewal uplift under 80 percent and avoided a six figure increase.
Frequently asked questions
How do you run a technology RFP that gets a fair comparison?
By defining the outcome and the measures once, up front, so every vendor answers the same question in the same terms, then normalising the responses so you are comparing equivalent things rather than three different definitions of the same metric. The other half is holding vendors to their claims: let them propose freely, but make the winning claims contractual. That combination, a like for like comparison built from claims the vendor will stand behind, is what a good RFP produces.
Should a technology RFP be highly detailed or high level?
Neither extreme works. Too vague and vendors compete on interpretation, so nothing is comparable. Too detailed and you over specify away the room a good vendor needs to propose something better, which kills the competition the RFP exists to create. The right position is precise about the outcome you need and how it is measured, and open about how a vendor achieves it.
How do you stop vendors gaming an RFP?
Not by trying to out specify them. When you ask for storage capacity, one vendor quotes raw, another usable, another effective capacity after assumed data reduction, all answering your question in the frame that suits them. The fix is not to nail down whose definition wins, it is to let the vendor make their claim and then make it a contractual commitment with a remedy if it is not met. Once the risk of the claim sits with the vendor who made it, the incentive to game the definition disappears.
Can you run an RFP if you already have a preferred vendor?
Yes, and it is common and legitimate. Even with a preferred vendor, genuine competition gets you a sharper commercial position and validates the choice rather than leaving it as an assumption, because a vendor who knows the alternatives are real gives their best. The one rule is honesty about intent: if it is a commercial benchmark to keep an incumbent sharp, structure it as that and be straight with everyone in it, rather than wasting vendors' time on a contest they cannot win.
Why are most technology RFPs too long?
Because length gets mistaken for rigour. Clauses are copied forward, executive summaries run to a dozen pages, and evaluation becomes a two hundred line yes or no spreadsheet. It feels thorough and it is the opposite: it buries what matters, wastes everyone's time, and rewards the biggest bid team rather than the best solution. A tight, precise RFP that asks only the questions that matter and defines how they are measured produces a better decision than a long one.
Should vendor claims in an RFP be contractual?
Yes, and this is where most RFPs leave value on the table. Marketing claims are accepted in proposals but rarely formalised in the contract, which shifts delivery risk back to you. If a vendor claims a data reduction ratio, a performance level, an SLA or a security outcome, ask them to commit to it contractually with a remedy if it is not achieved. A claim a vendor will sign for is worth far more than one that lives only in a slide, and their willingness to sign tells you which claims are real.