RFP response

Purpose

An RFP is a timed exam written by someone else. Two things lose winnable bids: responding to requests the team was never going to win, and losing track of the deadline on the ones it could. This skill makes the bid decision first, so effort goes where it can pay off, then builds the response to how the buyer will score it, and keeps every live bid visible against its deadline.

When to use

• An RFP, RFI, or brief arrives and a response is due.
• A bid decision is needed.
• Several bids are live and one may slip.

Route elsewhere when:

• The question is the pricing model. Use pricing-monetization-ops.
• The question is the sales process after a win. Use revenue-handoffs.

Inputs

• The request document, with its scoring criteria if published.
• The proposal deadline, which is the submission date. Record it separately from any campaign or engagement dates in the request.
• Team capacity and the named owners for pricing, legal, security, and sign-off.
• Known facts about the buyer: whether an incumbent is already in place, and any signals that the request is a formality.

Procedure

1. Decide bid or no-bid before anyone writes. Score fit with the team's ideal customer, winnability (including whether an incumbent is already chosen), and whether the request is genuine. A disciplined no-bid protects the win rate on the bids that matter. Record the reason either way.
2. Anchor on the deadline. Put the proposal deadline at the top of every working document, above the engagement dates.
3. Build the response to the scorecard. Map each published criterion to a section. Answer every question asked, in the buyer's order. Open each section with the criterion it satisfies. Start from a clean template, never from the last response. Old content brings wrong references, metrics, and claims.
4. Plan backward from the deadline. Mark the long-pole items: custom pricing, security or legal review, creative, and executive sign-off. Start those first. Leave a buffer for a review round, which usually runs late.
5. Assign owners for each section and each long-pole item, with a date.
6. Require human approval of the final submission. No response goes out without a named person approving it.
7. Track the pipeline of bids. For each live bid: stage, next action, owner, and days to the proposal deadline. Run a weekly sweep, and flag any bid whose next action is overdue or whose deadline is inside the review buffer.

Output

• Bid or no-bid decision, with fit, winnability, and genuineness scored and the reason recorded.
• For a bid: the section map against the scorecard, the owner for each section, and the backward plan with long-pole items marked.
• A status table across all live bids, with the flagged ones at the top.

Quality bar

Every bid has a recorded decision. Every question in the request is answered, in the buyer's order. The proposal deadline is the one at the top of the working file. Long-pole items start first. A named person approves the submission. Watch for bids on every request, responses built from a previous deal, and flight or campaign dates recorded as the deadline.