The document arrives at 4pm on a Friday. Forty pages, due in ten days, and it looks like real money.
Monday morning the whole company reorganises around it. Your best technical person stops delivering client work to write about implementation methodology. Finance rebuilds the pricing three times. Somebody spends a full day on formatting. Six weeks later you get a one-paragraph email saying the contract was awarded to another vendor.
That is the RFP most small B2B companies keep responding to. Not because it was winnable, but because saying no felt like giving up on revenue.
The teams that do well at this do two things. They decline most of what arrives, and they make the ones they accept cheap to produce.
What an RFP response actually costs you
Count it properly once and the decision gets easier forever.
Add up every hour: the salesperson coordinating, the technical people writing their sections, finance on pricing, whoever does formatting and the compliance check, and the review meetings. For a mid-sized RFP that commonly lands somewhere between 30 and 60 hours of real work. Run your own numbers on the last one you submitted, because they will be higher than you remember.
Then add the part that never gets counted. When your senior technical person spends four days on a proposal, that is four days not spent on delivery, not spent on the two live deals in your pipeline, and not spent on the discovery calls that were already booked.
The direct hours are rarely what hurts. The displacement is. A company that responds to six RFPs a year and wins one has spent something close to a full month of senior time to land a single contract, and has been distracted from its own pipeline for that whole month.
The signals that an RFP is already decided
Most RFPs have a preferred vendor before publication. That is normal procurement behaviour, and it is often a genuine requirement to collect three bids rather than a plan to deceive anyone. The problem is that you become one of the two free bids.
Six tells, and they are visible before you write anything:
- You had no prior contact. The strongest signal by a distance. Buyers who want you in the running usually talk to you before the document exists.
- Requirements match one product's feature list. Oddly specific specifications, named integrations, exact configuration language. Somebody helped write this and it was not you.
- The window is short for the scope. Ten days for a submission that needs a month of real work favours whoever already has the answers written.
- No discovery call is offered. A real process wants bidders to understand the problem. A formality does not.
- Scoring rewards incumbency. Heavy weight on prior experience with that exact system, or on being an existing supplier.
- Questions go unanswered or get answered by pointing back at the document. The buyer is running a compliance exercise.
Two or more of these together is usually a decline. Three or more, and you are volunteering a week of your team's time to help someone else's paperwork.
Use the question period to test it. Ask one specific question about a requirement that looks wired: whether an equivalent certification is acceptable, whether a stated integration is mandatory or preferred. The answers go to every bidder, so you also learn what your competitors are probing. A buyer who engages with that question is running a real process. A buyer who replies by quoting the original document back at you has told you what you needed to know.
The qualify or decline decision
Make this call within 48 hours, not after someone has already started writing. Five questions, twenty minutes, one person with authority in the room.
- Have we spoken to this buyer before? If no, everything below has to be strong to compensate.
- Do we meet every mandatory requirement? Not "mostly". A single missed mandatory usually means automatic disqualification, and the buyer will not tell you before you submit.
- Is this work we actually want? Right size, right industry, right delivery model. Winning work you cannot deliver profitably is a worse outcome than losing.
- Can we reach a decision-maker before the deadline? If nobody will take a call, you are writing into a void.
- What do we give up by doing this? Name the specific deals and delivery work that get delayed.
Write the answers down. That record is what stops the same argument happening every time a document arrives, and after a year it shows you which patterns you win. If you have already defined who your ideal customer actually is, most of these questions answer themselves in about five minutes.
The default should be no. That feels wrong to sales teams, and it is the right default for a company with limited senior time. This is the same discipline as running proper win-loss analysis: you are trying to learn where you actually win rather than where you can technically compete.
Building an answer library
Most of an RFP is questions you have already answered. Company background. Insurance and certifications. Security and data handling. Implementation approach. Support model. References. Team biographies.
Write each of those once, properly, and keep them in one place tagged by question type. Then a response becomes editing rather than writing, and the days you save go into the parts that actually differentiate you.
Three rules make the library work:
Keep every answer in two lengths. A short version around 100 words and a full version. RFPs impose word limits at random and rewriting to fit is where hours vanish.
Put a review date on everything. Insurance certificates expire. Headcount changes. A certification lapses. Someone will paste an expired figure into a submission and a procurement officer will verify it, which is a bad way to lose.
Never paste without reading. The library is a starting draft. An answer that does not address the specific question reads worse than a short original one, and evaluators can tell instantly.
AI helps here, honestly. Give a model your library entry and the new question and it will reshape the answer to the wording asked. It is good at that and poor at anything requiring real knowledge of your delivery or your pricing. Technical and security answers go to the person who owns that area before submission, every time.
Who writes what
In a company with no proposal manager, one person owns the submission: the deadline, the compliance checklist, the formatting, the upload. That person does not write technical content.
Subject-matter experts write only their own area, only in writing, only by a stated internal date. Not in a meeting, not verbally to the owner who then transcribes it. Finance owns pricing. Someone senior reads the whole thing once as a buyer would, near the end, and that person should not be one of the writers.
Set the internal deadline three days before the real one. That buffer is for the file that will not upload, the signature from someone who is travelling, and the mandatory form on page 31 that nobody noticed.
Build the compliance checklist first, before any writing starts. Read the whole document once and list every mandatory item: forms, signatures, page limits, font requirements, file naming, submission method. Public sector buyers reject on format, and they do it without reading your content. Losing on a page limit after 40 hours of work is the most avoidable loss there is.
Pricing without discounting into a bad deal
Price the work the way you would price it for a normal client, then check whether the scope described is actually the scope you would deliver. Those are two separate steps and people skip the second one.
The reflex in a competitive bid is to shave the number. Sometimes that is right. Usually it wins you work you then deliver at a loss for two years, with a client who chose you on price and will treat you accordingly at renewal.
If the requirements force a price you would not accept, that is a decline signal rather than a pricing exercise. Say so in the question period if there is time, because occasionally the buyer did not realise what they asked for and will adjust the scope.
Declining well
A decline is a relationship move if you do it properly.
Reply within a day. Be specific and honest about why: the timeline does not allow you to do the work justice, the scope sits outside what you deliver well, or a requirement is one you genuinely do not meet. Then say what you would be right for, and offer a short call for the next time.
I have watched a decline turn into a direct award nine months later, because the buyer remembered the one vendor who told them the truth instead of submitting a padded response. Procurement people talk to each other and they remember who wasted their time reading a bid that never fit.
The takeaway
Responding to every RFP that arrives is a habit, not a strategy. It fills your senior team's calendar with work that has a low chance of paying and pulls attention off the pipeline you built yourself.
Qualify hard. Decline most. Build the library so the ones you accept cost two days instead of a week. Win a high share of a small number, and let someone else be the third bid.