Win-loss intelligence starts on day one
Most teams collect the wrong signals after a bid, and the wrong signals compound. An opinion piece on what to capture from the moment the RFP lands, not the day after the award email.
The best time to start a win-loss post-mortem is the day the RFP lands. The worst time is the day the award email arrives.
That’s the opinion piece. The rest of this post is why.
The signal you can capture now
When a team runs a debrief two weeks after submission, the signal quality is already degraded. Writers don’t remember which SME gave them the encryption paragraph. The capture lead doesn’t remember why the bid/no-bid cleared the floor. The proposal manager remembers the fire drills but not the small decisions — which section got pushed to Saturday, which win theme was swapped in during the red-team review.
Memory is not the only casualty. The real signal — the one that actually changes the next bid — is what the team debated during the response. That debate is gone by week three. What remains is a sanitized narrative shaped by the outcome.
If we lost, the narrative is “we lost because of price.” If we won, the narrative is “our executive summary was strong.” Both are almost always wrong.
What to capture, and when
The framework we use is simple: every bid has an artifact trail that starts at intake, not at award. The trail captures:
- Intake. The bid/no-bid score and the rationale in one paragraph. Not the score alone — the paragraph is the part you’ll re-read.
- Capture. The three win themes in plain language. The named evaluators. The incumbent and their known posture.
- Draft. Which sections were written against which KB blocks. Which blocks were edited in-response. Which sections required a new SME ticket.
- Review. Every red-team and gold-team comment that was not acted on, with the written rationale for deferring. This is the most undervalued artifact in the whole pipeline.
- Submit. The time delta between “draft final” and “submit final.” Tight-delta submissions are a leading indicator of what will fail next time.
- Post-mortem. The debrief itself, yes — but running against the artifacts above, not against memory.
A team that captures this during the bid — not after it — can run a 30-minute post-mortem with real data. A team that doesn’t capture this runs a two-hour post-mortem that discovers nothing, because every claim is underwritten by vibes.
The “we lost on price” problem
Leulu & Co’s piece on post-mortems names the pattern: the debrief ends, the document is published, people move on. Nobody asks at sprint planning what happened to the actions from last week’s incident. Lessons don’t embed in workflow. Same mistakes recur.
I’d extend that. The deeper failure is that the “lesson” itself is fabricated in the absence of data. “We lost on price” is the default lesson of every lost bid in B2B, and it’s almost never the full story. Price is usually the proxy the evaluator gives the vendor because it’s the least painful to deliver. The actual reason is a compliance gap, a mismatched win theme, a missing piece of past performance, a capability the incumbent had and we didn’t — and we didn’t know to ask.
That’s the post coming next week. But the precondition for answering the question is capturing the evidence before the award, not after.
What good looks like
A team running win-loss well has three habits.
First, every bid writes to a post-mortem record on day one. The record is half-empty at kickoff and fills in as the response moves through the pipeline. The award email triggers a rollup, not a from-scratch interrogation.
Second, every debrief updates the KB. Not a shared drive. Not a wiki page. The knowledge base the next bid will draft from. If the debrief doesn’t move blocks around — promoting the ones that worked, retiring the ones that didn’t — the debrief was a ritual, not a retrospective.
Third, the team measures the half-life of a lesson. A lesson from March should still be visible in the way a December bid gets drafted. If it isn’t, the embedding step failed. Lohfeld names this in their piece on proposal processes: slowness and frustration come from work that keeps starting from zero.
What we’re building against this
This is the opening of a five-part series on win-loss intelligence. Over the next two weeks Sarah walks through what to capture, how to run a debrief that finishes in 30 minutes, the five anti-patterns we’ve seen (ours included), how findings become KB edits, and the eighteen-month view after running this ourselves.
The engineering team has also been writing about the schema, the embedding clustering work, and the evidence linking. Those posts land alongside Sarah’s.
The unifying claim: win-loss intelligence is not a report you generate after the bid. It is evidence you capture during the bid, so the next bid starts further along than the last one did. Every bid either compounds or doesn’t. The date the compounding begins is the day the RFP lands.