Back to Blog

Every RFP Tells You Who Wrote It

- 7 min read - Competitive Intelligence

The short version

An RFP is the most detailed competitor document you will ever be handed, and your prospect sends it to you unprompted. The requirement language tells you whose vocabulary shaped it. The mandatory list tells you what your competitor is confident about. The scoring weights tell you what the buyer is worried about. Most teams answer the document and then throw all three away.

Competitive intelligence usually means reading what a competitor says about themselves. An RFP is better than that: it is what a competitor convinced a buyer to care about, written in the buyer's own words, with weightings attached. That is a filtered signal no marketing page will ever give you.

You are being handed a competitor's positioning, validated

A vendor's website tells you what they wish mattered. An RFP that their sales team helped shape tells you what a real evaluation committee agreed to write down. The gap between those two things is where most competitive strategy actually lives.

And unlike almost every other intelligence source, this one arrives on a schedule, in a structured format, addressed to you. The only reason it is under-used is that it arrives at the exact moment everyone is busy answering it.

Requirement language: whose words are these?

  • Feature names that are not generic. Workspaces, playbooks, collections, spaces, projects — every vendor picks a word for the same object. When the requirement uses one of them consistently, it is quoting somebody.
  • The shape of a capability. How a requirement splits into sub-bullets usually mirrors somebody's UI. If “access control” is broken into exactly the three sub-capabilities one product happens to ship as three separate screens, that is not a coincidence.
  • Acronyms and version numbers. A requirement that names a protocol version precisely is usually naming the version somebody already supports — and quietly excluding the versions others are on.
  • What is missing. If an entire category you consider table stakes is absent, either the buyer genuinely does not need it, or the vendor who helped shape the document does not have it. Both are worth knowing, and they call for opposite responses.

Mandatory versus desirable is a confidence map

Treat the split as a competitor telling you where they feel safe. Requirements marked mandatory are where the shaping vendor is confident — they are certain they clear the bar and reasonably hopeful someone else does not. Requirements marked desirable are where they are unsure, or where they know they are weak and are hedging so the line does not disqualify them.

The practical consequence is about effort allocation. Most teams distribute writing effort proportional to requirement count. The desirable list is where differentiation still has room to move the score, and it is usually the shorter list. Spend disproportionately there.

A test worth running

Take your last three losses. For each one, mark which requirements were mandatory and which were desirable, then check where you spent your writing hours. If the effort was flat across both, you were answering the document rather than competing in it.

The weights are the real strategy document

Scoring weights are where an evaluation committee's internal compromises get encoded, and they are almost never discussed in the response. Each pattern is a lever:

Heavy weight on integration

An incumbent-friendly criterion. Someone wants the existing estate to keep working — which is a legitimate concern you can address directly rather than a trap you have to survive.

Heavy weight on implementation timeline

Someone senior has a date: a contract expiry, an audit, a board commitment. Find the date and the whole evaluation becomes legible.

Heavy weight on support and SLA

They have been burned, recently, and probably by the incumbent. This is an opening, and it is usually the one nobody bids into.

Heavy weight on commercial terms

Procurement, not the technical evaluator, has the pen. Your technical win may not be the deciding score — plan the deal accordingly.

The pattern lives across documents, not inside one

A single RFP is an anecdote. Your own archive of RFPs, read against each other, is a picture: which requirements always appear in a sector, whose vocabulary keeps recurring, which objections repeat, which trap questions land and which ones do not.

That picture is built from bids you personally ran. It is one of the few genuinely proprietary assets a technical sales team can accumulate, and it costs nothing except the discipline in the next section.

Record it while it is fresh, or it does not exist

The failure mode here is never analysis. It is capture. The intelligence is obvious to everyone on the bid team during the bid and completely gone six weeks later, because the people who held it moved to the next deal.

  • Write the intel note in the same week, not at the end. A short note per RFP: whose language this sounded like, which requirements looked shaped, what the weights implied. Ten minutes while it is still obvious.
  • Update the competitor page from your notes, not from their website. What a competitor claims is available to everyone. What a buyer was persuaded to write down is available only to you.
  • Record what you got wrong. The trap question that did not land, the objection you had no answer for, the requirement you scored yourself too generously on. This is the half that improves the next bid, and the half everyone omits.

If you already run a win-loss review, this belongs in it. If you do not, the RFP intel note is a cheaper place to start than a full review process, and it produces most of the value.

The document you were going to delete

After submission an RFP usually becomes an archive object nobody opens again. It is worth one more hour: read it a second time for who wrote it rather than what it asked, and file what you find where the next bid team will actually look. That is also how a battlecard stays connected to reality instead of drifting into a list of marketing claims.

Your competitors are sending you their positioning through your own prospects, quarterly, in writing. The only question is whether anyone on your team reads it that way.

Stop losing the intelligence with the bid

WinIQ extracts and scores requirements as you work the RFP, so the competitive read survives the submission instead of leaving with the bid team.

Request a Demo