Timeline and status: work backward, then keep it visible
Two clocks decide RFP outcomes: the countdown on each proposal, and your view across all of them at once. This page covers sequencing a single response from its deadline, and reading status across a pipeline of live RFPs.
Build the timeline backward from the deadline
Start at the submission deadline and work backward, not forward from today. Forward planning quietly assumes you have all the time between now and the due date; backward planning exposes where you do not.
- Deadline. Fix the submission date and time, including the buyer's time zone.
- Submission buffer. Reserve the last slot before the deadline for final assembly and upload. Portals fail, files are large, and formatting takes longer than anyone expects. Never plan to finish at the deadline.
- Final approval. Before that, the human owner reviews and approves the complete proposal. Nothing submits without this.
- Review round. Before approval, a full internal review. Assume it surfaces changes and always runs a little late.
- Long poles first. Identify the items with the longest lead time and start them on day one.
The long-pole checklist
These are the items that blow deadlines because they depend on someone outside the core team:
- Custom or non-standard pricing that needs leadership sign-off.
- Bespoke creative, mockups, or a custom-built demo.
- Security, privacy, or legal questionnaires and reviews.
- Executive sign-off on commitments or terms.
- Anything requiring a clarifying answer from the buyer (ask early; their reply has its own lag).
Start every long pole at the beginning. A response is rarely late because the writing was slow; it is late because one dependency was picked up three days before the deadline.
The status model for a pipeline of RFPs
When several RFPs run at once, track each against the same small model so the one about to slip is obvious:
| Field | What it captures |
|---|---|
| Stage | Where it is: qualifying, briefed, in production, in review, submitted, won/lost |
| Next action | The single next thing that has to happen |
| Owner of next action | Who owes that action |
| Days to deadline | The countdown to submission |
| Risk | Anything threatening the deadline or the quality |
The weekly sweep
Once a week, read every live RFP against that model and ask one question per row: is this on track to submit on time at the quality we want. The sweep exists to catch the RFP that is quietly stalling while there is still time to intervene. Sort by days-to-deadline, and give the one with a stalled next action and a near deadline attention first.
The point is not a tidy tracker. It is that no winnable RFP is ever lost to a clock nobody was watching.