How to Tell If You're Column Fodder — and What to Do About It

The short version

Some RFPs are written to be won by someone else, and you are in the process to make it look competitive. The tells are not in what the document asks for — they are in its shape: whose vocabulary the requirements are written in, which ones are mandatory, and how the scoring is weighted. All of it is readable in about an hour. If you read it in week one you still have moves. If you read it in week five you have an invoice for your own time.

Every technical sales team has lost a bid it never had. The post-mortem usually blames the response — not enough detail, wrong tone, a weak demo. Sometimes that is true. Often the response was fine and the outcome was fixed before the document reached you.

The RFP is a document with an author

Somebody helped write it. That is not corruption, it is how enterprise procurement actually works: a vendor who spent nine months building a business case with a buyer will be asked to help shape the requirements, because they are the ones who understand the problem in detail. The buyer gets a better document. The vendor gets a document shaped like their product.

Your job is not to be outraged about this. It is to notice it early enough to do something, and to know the difference between an RFP that is genuinely open and one that is a formality with three columns.

Six tells you can read in an hour

The language belongs to someone

Requirement phrasing that mirrors a specific vendor's datasheet — their feature names, their acronyms, their way of splitting one capability into three sub-requirements that nobody else splits.

A mandatory requirement only one architecture meets

Not a hard requirement — a shaped one. “Must provide native agentless collection” is a sentence with a vendor's name invisibly attached to it.

Weights that favour an installed base

Heavy scoring on integration with systems the incumbent already owns. Migration effort scored as risk — a criterion only the challenger can lose points on.

No access to the people who wrote it

One Q&A window, answers published to all bidders, no discovery calls. That is a document designed to be answered, not a decision being made.

A timeline that assumes you already have the answer

Three weeks to respond to two hundred requirements means the response either exists already or will not be good. Ask who that suits.

“Current environment” reads like a reference architecture

The incumbent's stack described in loving detail while the future state stays vague. The vague future state is “more of the same.”

The uncomfortable version

No single tell is proof — buyers write clumsy RFPs for innocent reasons all the time. Two together is a pattern worth testing. Four together is a decision, and the decision is not yours to win by writing harder.

Ghost positioning: the requirement nobody can meet

There is a subtler move worth naming, because it is the one that catches strong challengers. A requirement is written so precisely that every vendor scores partial — including the favourite. On the surface it looks fair. Its actual function is to neutralise a differentiator you genuinely have, by describing it in someone else's vocabulary at a level of specificity that turns your honest “yes” into a “partial.”

The favourite loses the same points you do, and then closes the gap with a roadmap slide in the presentation round. You cannot out-answer this in the document. You can only surface it, which means getting the criterion discussed rather than scored.

The tell: look for the requirement where your strongest capability is described in terms you would never use. That is usually ghost positioning, and it is aimed at you specifically.

What to do in the first week

Three moves, in order. All of them have to happen inside the Q&A window, which is why week one matters and week five does not.

Ask the one question only the author can answer. Not “can we have a call” — a specific technical question whose answer reveals which architecture the requirement assumes. Either the answer tells you what you needed to know, or the refusal does. And because Q&A responses go to every bidder, you have put the question on the record.
Reframe the weighting rather than fighting the requirement. You will not get a mandatory requirement removed. You can sometimes get a criterion added — usually about risk, total cost across the contract term, or exit and portability. Propose it as a question, not a complaint. If it lands, the scoring model changes for everyone, including the favourite.
Put a win theme on the table early. A win theme is not a feature and not a slogan; it is the sentence you want the evaluation committee repeating to each other when you are not in the room. It has to be true, and it has to be about their problem rather than your product.

When to walk — and how to walk well

Walking away is a competitive move, not a surrender. Do it in writing, to the person who owns the business outcome rather than to the procurement mailbox, and say plainly why: which requirements you read as pre-shaped, and what you would need in order to bid seriously.

Two things follow. You keep the relationship intact for the re-compete, which is the bid that is actually winnable. And occasionally the process changes, because someone senior did not know the requirements had been drawn that tightly and does not want a single-vendor outcome on their own governance record.

The real cost of a bad bid is never the bid. It is the good bid you under-staffed because your strongest SE spent three weeks on this one.

Read the shape first

None of this requires a tool. It requires reading the document once for what it asks and a second time for who it sounds like, and doing that in the first week rather than the last. If you want the structured version of the same judgement, the bid/no-bid checklist turns these tells into criteria you can score, and a maintained battlecard is where the pattern from one RFP becomes useful on the next one.

The teams that win more do not answer better. They answer fewer, earlier, and on documents they had a real chance at.

Qualify before you commit the team

WinIQ scores RFP requirements against what you can actually support — full, partial or gap, with the source — so the bid/no-bid conversation happens in the first week instead of the fifth.

Request a Demo