RFP response process for B2B sales teams

A 60-person B2B software company I worked with got an RFP on a Thursday afternoon. Eighty-one questions, response due the following Wednesday, from a logo everyone in the company recognised. The CEO forwarded it to the team with three words: "all hands, let's win this."

They won nothing. Six people spent parts of five days on it. The security section alone took the CTO eleven hours because nobody had written the answers down since the last time. They submitted at 4pm on the Wednesday, heard nothing for six weeks, and then got a two-line email saying the buyer had renewed with their existing vendor.

Here is the part that stung. When the AE finally got the procurement contact on a call, she admitted the incumbent had helped write the requirements document. Four of the eighty-one questions were describing features only that vendor shipped. The company had never had a chance, and there had been enough evidence in the RFP itself to see it on day one.

That is the real problem with RFPs. Not that they are long. That teams respond to the wrong ones and treat the decision to respond as though it were free.

Most RFPs are decided before you see them

The uncomfortable research first. Forrester found that a large share of B2B buyers walk into a formal evaluation with a preferred vendor already picked, and a meaningful slice say they will choose that vendor no matter what the process produces. Coverage of the 2025 Forrester buying study put it plainly: buyers now use the formal process to confirm a decision rather than to make one.

Win rates say the same thing from the other direction. Loopio's multi-year RFP benchmark data puts the current average win rate around 39%, against a longer-run average nearer 45%. But the average hides the only split that matters. When you are the incumbent or you shaped the requirements, you win most of the time. When the RFP arrives cold from a company you have never spoken to, you are somewhere in the low teens.

If you report one blended RFP win rate to your board, you are averaging two completely different businesses. One is a renewal motion with paperwork attached. The other is a lottery you paid 33 hours to enter.

So the first thing I do with any client that gets more than a handful of RFPs a year is split the number. Cold RFPs and warm RFPs get separate win rates, separate cost tracking, and separate decisions. Usually the split alone changes behaviour, because the cold number is embarrassing enough that nobody wants to defend the effort going into it.

What a response actually costs

Loopio's data puts the average at 33 hours of work per RFP response, spread across around nine contributors. Small and mid-sized companies come in a little lower at 27 hours. That is people time, and in a 60-person company it is your most expensive people: the CTO writing security answers, the head of customer success pulling references, the AE assembling it all.

Do the arithmetic once and you will never look at an inbox RFP the same way. Thirty hours of blended senior time at a loaded rate of, say, €80 an hour is €2,400 of cost per submission. If your cold win rate is 15% and your average deal is €40,000 in first-year revenue, then every cold RFP you enter has an expected value of about €6,000 in booked revenue against €2,400 in cost. That still clears, but only barely, and only if the delivery load does not push out something else. Drop the deal size to €18,000 and the maths inverts. You are paying to lose.

This is why I push clients toward the same conclusion nearly every time: the highest-return change you can make to your RFP process is responding to fewer of them, better.

The bid/no-bid scorecard

Every team says they qualify RFPs. Almost none of them do it in writing, which means the decision gets made by whoever has the most authority in the room and the strongest feelings about the brand name.

Write it down instead. Ten minutes, seven questions, a number at the end. This is the version I have handed to several clients, and it has survived contact with real deals.

Score each item 0, 1, or 2.

1. Relationship. Have we spoken to anyone at this company in the last 90 days? (0 = never heard of us, 2 = active conversation with an economic buyer.)
2. Requirements fingerprint. Do any requirements describe a competitor's specific feature or naming convention? (0 = yes, clearly wired, 2 = vendor-neutral throughout.)
3. Incumbent status. Is there an incumbent, and is this a renewal cycle in disguise? (0 = incumbent present and performing, 2 = no incumbent or a known failure.)
4. ICP fit. Does this account match our ideal customer profile on size, industry, and technical fit? (0 = we would struggle to deliver, 2 = dead centre.)
5. Deal size versus effort. Is the first-year value at least 15x our estimated response cost? (0 = no, 2 = comfortably.)
6. Access. Are we allowed to ask questions and speak to people during the process? (0 = written questions only through a portal, 2 = a scheduled discovery or demo stage.)
7. Timeline sanity. Do we have enough working days to answer well? (0 = under four days, 2 = two weeks or more.)

Twelve or above, respond properly. Eight to eleven, respond only if you can reuse 70% of the content from your library. Below eight, decline, and send a short note offering to be considered next cycle. That note is not a courtesy, it is pipeline. I have seen two clients get invited back into the following year's process precisely because they were the vendor that respectfully passed rather than the one that sent 40 pages of boilerplate.

One caveat I want to be honest about. This scorecard is a filter, not an oracle. I have watched a client score a nine, respond anyway on gut feel from the AE, and win a €140,000 contract because the buyer's CFO had used the product at a previous company. Rules are for the median case. Keep an override, make someone senior sign it, and count how often the override was right. If it is right more than half the time, your scoring weights are wrong and you should fix them.

Build the content library before the next one lands

The reason that CTO spent eleven hours on the security section is that the answers existed only in his head and in three PDFs from 2024 that nobody could find. That is the single most common failure inside a response, and it is fixable in a week.

Your library needs four categories, each with an owner and a review date:

• Company and legal. Registration details, insurance, certifications, org chart, financial summary. Owner: whoever runs operations. Review annually.
• Security and compliance. SOC 2 or ISO status, GDPR posture, data residency, subprocessors, pen test cadence, DPA template. Owner: CTO or head of security. Review quarterly, because this is the section that goes stale fastest and the one where a wrong answer is a real liability.
• Product and technical. Feature coverage, integrations, API limits, roadmap language, uptime history, support SLAs. Owner: product. Review quarterly.
• Proof. Case studies, reference customers by segment, implementation timelines, named metrics you are allowed to publish. Owner: marketing. Review every six months.

Store answers as question and answer pairs, not as finished documents. Documents rot as a unit. Pairs get reused, edited, and improved individually. Tag each pair with the segment and the last approval date. When a pair is more than six months past review, the tool should refuse to auto-insert it without a human check.

Whether you keep this in a dedicated tool like Loopio or Responsive, or in a Notion database with a decent tagging scheme, matters far less than whether it exists and has an owner. Under about 25 RFPs a year, a well-maintained Notion or Google Drive structure with a strict naming convention is genuinely fine and costs nothing. Above that, the licence pays for itself in recovered CTO hours.

Run the response like a project, not a fire drill

Two details in there do most of the work.

The first is auto-filling from the library before anyone opens a document. If 60% of an 80-question RFP is answered on day one by content that already exists and has been approved, the human effort collapses from 33 hours to something like 10, and all of it goes into the part that actually differentiates you.

The second is the win themes. Most responses answer the questions and nothing else. The buyer's evaluation committee is reading eight of these, and by document four every vendor sounds the same. A short section header that names their outcome ("reducing your onboarding time from 6 weeks to under 2") and then answers the questions underneath it is the difference between being competent and being remembered. Buying committees are groups, and the person championing you internally needs language they can repeat in a meeting you are not in. That is the same dynamic that makes multithreading a deal work.

Track RFPs in the CRM as their own motion

This is the RevOps part, and it is where most teams have nothing at all.

An RFP is not a normal deal. It has a different cost structure, a different win rate, and a different sales cycle, and if you leave it mixed in with your inbound and outbound pipeline your forecast will be wrong in a specific direction: too optimistic, because RFP deals look advanced (there is a document! there is a deadline!) while being less likely to close than a self-sourced opportunity at the same stage.

Add these fields to the deal record, whether you are in HubSpot, Salesforce, or Attio:

• rfp_flag (boolean)
• rfp_source (inbound cold, existing customer, partner referral, we shaped it)
• bid_score (the number from the scorecard)
• bid_decision (bid, no-bid, bid with override)
• response_hours (logged after submission, honestly)
• incumbent_present (boolean)
• evaluation_criteria_published (boolean)

Seven fields. Two quarters of data. After that you can answer questions no amount of intuition will answer: what our real win rate is by RFP source, whether our bid score actually predicts outcomes, and what one point of win rate is worth in recovered engineering hours. If you are on HubSpot and running any volume, a custom object for RFPs is cleaner than stuffing this onto the deal, because one account can run several RFPs and a deal record cannot model that well.

Then automate the boring half. A simple n8n or HubSpot workflow that creates the response checklist, assigns section owners by question category, posts a Slack reminder at each milestone, and writes the submission timestamp back to the deal takes an afternoon to build and removes the coordination overhead permanently. We build this pattern for clients as part of AI and automation work, and it is one of the few automations where the payback is measurable in the first month.

Losing well is worth more than most people think

You will lose the majority of cold RFPs. That is fine and expected. What is not fine is losing without learning anything, which is what happens when the debrief is a Slack message saying "gutted, they went with the incumbent."

Ask for the scoring breakdown. Public sector buyers usually must provide it, and private companies often will if you ask within a week and ask politely. Then answer three questions internally and write them into the deal record: where did we score lowest, was it a product gap or a communication gap, and would our bid score have predicted this? That last one is how the scorecard gets better. Feed it into your regular win/loss analysis rather than treating RFPs as a separate universe.

One client of mine found, after two quarters of this, that they were losing consistently on implementation timeline, not price or features. Their honest answer was "10 to 12 weeks" while two competitors were claiming six. They redesigned the onboarding to a phased go-live where the buyer got a working core in four weeks. Their RFP win rate moved from 17% to 29% over the next year. The product barely changed. The answer to one question did.

FAQ

What is the RFP process, in plain terms?

A request for proposal is a document a buyer sends to several vendors describing what they need and asking each to explain how they would deliver it and at what price. The buyer scores the responses against criteria, shortlists two or three vendors, usually runs demos or interviews, then selects one. From a seller's side the process has four stages: the decision to respond, the response itself, a clarification or demo round, and the award. Most of your control sits in stage one.

What is the difference between an RFI, an RFP, and an RFQ?

An RFI (request for information) comes early and is used to build a vendor longlist, so responses are short and the effort should match. An RFP asks how you would solve the problem and is scored on approach as well as price. An RFQ (request for quotation) assumes the requirements are already fixed and is competing mainly on price. If you get an RFQ for something you consider a considered purchase, that is a signal the buyer has commoditised the category in their head and your margin will be under pressure.

What is a good RFP win rate?

Around 39 to 45% is the published cross-industry average, but treat that as close to meaningless until you split it. Segment by whether an incumbent exists and whether you had a relationship before the document arrived. Cold, no relationship, incumbent present: 10 to 20% is normal. Warm, you influenced the requirements: 50 to 70% is achievable. Set targets against the right half. Our guide to calculating and benchmarking win rate covers how to segment this properly.

Should we ever respond to a cold RFP from a company we have never spoken to?

Sometimes, and the test is reuse. If your content library can answer 70% of it in under three hours and the deal is large enough to matter, submitting is cheap enough to be worth the lottery ticket. If it needs original writing from your CTO and your head of product, decline and spend those hours on an account you can actually influence. The mistake is treating the choice as a question of ambition rather than a question of cost.

Do we need RFP response software?

Under roughly 25 responses a year, no. A tagged content library, a checklist template, and a named owner will get you most of the benefit for zero licence cost. Above that, or if your security questionnaire volume is climbing, a dedicated tool starts to pay back in recovered senior hours. Look at how much of your last four responses was genuinely new writing. If the answer is under 30%, your problem is content management and a tool will help. If it is over 60%, your problem is that you are bidding on things you should not be, and no software fixes that.

RFPs are not a marketing problem or a sales problem. They are an operations problem wearing a sales costume: a repeatable process with a cost, a hit rate, and a set of inputs you can measure. Treat it that way and the effort drops while the win rate climbs.

If your team is drowning in response work and nobody can tell you what it costs, that is the same underlying gap we fix in CRM and RevOps engagements: the process exists, but nothing about it is written down or measured. Get in touch and we will start with the last twelve.