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.
Status discipline across the pipeline
When several RFPs are live at once, the failure is not any single proposal - it is losing track of which one is at what stage. For each live RFP, know the stage, the next action, who owes it, and the days to deadline. A weekly sweep against that model surfaces the one about to slip while there is still time to move.
What good looks like
- What the best operator notices first: whether the RFP is real and winnable, before the team invests a week. The strongest signal is fit against the disqualifiers and any sign an incumbent is already chosen. A disciplined no-bid on an unwinnable RFP protects the win rate on the ones you should chase; a team that bids on everything wins less.
- The common mistake: treating the RFP as a pitch instead of an exam. The mediocre response leads with the company, reuses the last deal's deck (dragging in the wrong logos, metrics, and claims), answers the questions it wishes had been asked, and discovers the real deadline was the submission date, not the flight dates, a day late. Each of those loses points a stronger competitor banks.
- How you know it worked: every question in the RFP is answered in the buyer's order, each section opens on the criterion it satisfies, the proposal deadline sat at the top of the working file the whole time, a human approved the final submission, and it went in with buffer to spare. Across the pipeline, you can name the stage and next action for every live RFP without opening each one.
Rules
- MUST make an explicit bid/no-bid decision before production starts; capacity is finite and a reflexive bid lowers the win rate elsewhere.
- MUST record the proposal submission deadline at the top of every working artefact, distinct from the engagement or flight dates.
- MUST answer every question the RFP asks, in the buyer's order, built to their evaluation criteria.
- MUST start each response from a clean canonical template, never from a previous deal's response.
- MUST route the final submission through a human owner who approves before it is sent; nothing submits automatically.
- NEVER submit past the deadline; a late proposal is usually disqualified regardless of quality.
1---2name: rfp-response3description: Use this skill when an inbound RFP, RFI, or brief lands and a proposal has to go back by a deadline - "an RFP just came in", "should we bid on this", "build the response", "the proposal is due Friday", "set up the RFP", "where are we on the [brand] RFP", "what's the status of our RFPs", "which RFP is about to slip". Produces a bid/no-bid call, a structured response built to the evaluator's criteria, a work plan sequenced backward from the deadline, and a status read across every live RFP.4---56Applies 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.78An 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.910## Qualify before you invest1112Before 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`.1314## Anchor on the deadline, not the flight dates1516Read 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.1718## Structure the response to the scorecard1920Buyers 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`.2122## Work backward from the deadline2324Sequence 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`.2526## Status discipline across the pipeline2728When several RFPs are live at once, the failure is not any single proposal - it is losing track of which one is at what stage. For each live RFP, know the stage, the next action, who owes it, and the days to deadline. A weekly sweep against that model surfaces the one about to slip while there is still time to move.2930## What good looks like3132- **What the best operator notices first:** whether the RFP is real and winnable, before the team invests a week. The strongest signal is fit against the disqualifiers and any sign an incumbent is already chosen. A disciplined no-bid on an unwinnable RFP protects the win rate on the ones you should chase; a team that bids on everything wins less.33- **The common mistake:** treating the RFP as a pitch instead of an exam. The mediocre response leads with the company, reuses the last deal's deck (dragging in the wrong logos, metrics, and claims), answers the questions it wishes had been asked, and discovers the real deadline was the submission date, not the flight dates, a day late. Each of those loses points a stronger competitor banks.34- **How you know it worked:** every question in the RFP is answered in the buyer's order, each section opens on the criterion it satisfies, the proposal deadline sat at the top of the working file the whole time, a human approved the final submission, and it went in with buffer to spare. Across the pipeline, you can name the stage and next action for every live RFP without opening each one.3536## Rules3738- MUST make an explicit bid/no-bid decision before production starts; capacity is finite and a reflexive bid lowers the win rate elsewhere.39- MUST record the proposal submission deadline at the top of every working artefact, distinct from the engagement or flight dates.40- MUST answer every question the RFP asks, in the buyer's order, built to their evaluation criteria.41- MUST start each response from a clean canonical template, never from a previous deal's response.42- MUST route the final submission through a human owner who approves before it is sent; nothing submits automatically.43- NEVER submit past the deadline; a late proposal is usually disqualified regardless of quality.
swan-gtm