rfp-response

Applies from the moment a request for proposal lands until the proposal is submitted and tracked. Produces a qualify decision, a response built to how the buyer will actually score it, a deadline-driven work plan, and a pipeline status read.

An RFP is a timed exam someone else wrote. Two things lose winnable deals: bidding on the ones you were never going to win, and losing track of the clock on the ones you could. This skill front-loads the qualify decision so effort goes where it can pay off, then keeps every live RFP visible against its deadline.

Qualify before you invest

Before anyone writes a slide, decide whether to bid. A response is expensive; a reflexive yes to every RFP burns the team and lowers the win rate on the ones that mattered. Score fit, winnability, and whether the request is even real (some RFPs exist to justify an incumbent already chosen). The bid/no-bid rubric, the disqualifiers, and how to route ownership once you commit are in references/qualify-and-route.md.

Anchor on the deadline, not the flight dates

Read the request for the one date that governs everything: when the proposal is due. Keep it separate from the campaign or engagement dates the RFP also lists - people routinely record the flight dates as the deadline and miss the submission by a week. Put the proposal deadline at the top of every working artefact, above the engagement dates, so no one has to hunt for it.

Structure the response to the scorecard

Buyers score RFPs against stated (and unstated) criteria; the response is built to that scorecard, not to your standard pitch. Answer every question they asked, fully, in their order; lead each section with the criterion it satisfies; and start from a clean canonical template, never from the last deal's response. The full response structure, the "answer what they asked" discipline, and why you never reuse a previous RFP's deck are in references/response-structure.md.

Work backward from the deadline

Sequence the work from the due date, not forward from today. Identify the long-pole items (custom pricing, creative, security or legal review, exec sign-off), start those first, and leave a buffer for the review round that always runs late. Nothing goes out without a human owner approving the final submission. The reverse timeline, the long-pole checklist, and the status model are in references/timeline-and-status.md.