Sales & PartnershipsFree
Sales Deal Post-Mortem and Timeline Review
The timeline rebuilt from the record, the date the buyer stopped, and which of your stated reasons came after it.
River's deal post-mortem rebuilds a finished deal from what was logged rather than from what anyone remembers. Give it the threads, the invites, the call notes and the activity history. It writes the timeline back with the dates attached, marks the point where the buyer stopped driving, and then tests every explanation on the record against that date. The output is a document you can read in a review and a sheet of contributing factors sorted by whether you control them.
The test is a date comparison, and it is unforgiving. A reason that first appears in the record after the deal turned cannot be the reason it turned. Price usually fails this: the proposal goes out weeks after the buyer went quiet. The same check runs on the fixes your team proposes. An action that would have landed after the turn changes nothing, however sensible it sounds in the room, and it is worth knowing before it becomes next quarter's process.
Built for the rep writing up a loss they are still annoyed about, the manager who has heard the same three reasons all year, and whoever has to decide what the team changes next. Run it within a fortnight, while the threads are still findable and nobody has tidied their inbox. A deal that has only stalled belongs with the blocker brief instead, and a formal scored bid goes to the RFP debrief.
Why a remembered post-mortem gets the reason wrong
Everyone in the room already knows the deal was lost, and that knowledge is not neutral. Fischhoff's experiments found that outcome knowledge raises how likely people say a reported event was, and changes which facts they treat as relevant. Worse, the participants were largely unaware it had happened, and overestimated what they would have known without it. His conclusion was that the lack of awareness restricts the ability to learn from the past, which is precisely what a debrief is for.
Fields that investigate for a living solve this by splitting the work in two. An NTSB investigation runs on-scene fact gathering as one phase and analysis of the facts with the determination of probable cause as a separate one, with the sequence of events assembled from the gathered record. Nobody writes a cause while still collecting. A deal post-mortem that opens by asking the rep why they think they lost has merged the two phases before it starts.
Wexford Grainger, $186,000, opened 14 January and marked lost on 4 August. The CRM reason is price. The record says the buyer last initiated contact on 5 March: 17 of the 31 touches before that date were theirs, and 1 of the 40 after it. Pricing did not exist as a topic until the proposal went out on 21 April, 47 days after they had already stopped. The deal was dead for 152 of its 202 days.
How it works
Paste the record
Threads, invites, call notes and activity history, with all of the original dates left intact.
River builds the timeline
Every dated event in order, and who initiated each one, before any reason is considered.
Locate the turn
The week buyer-initiated contact stops and never recovers, marked with what happened around it.
Test every claim
Each stated reason and each proposed fix, against that date, kept only if it pre-dates it.
What you get
- The full timeline rebuilt from dated evidence, with every gap and silence marked
- The date the buyer stopped driving, taken from who initiated each contact
- Every stated loss reason tested against that date, and the ones that fail
- Contributing factors sorted into what you controlled, influenced and could not touch
- Each proposed fix checked for whether it would have landed before the turn
- How long the deal stayed in the forecast after it was actually over
Common questions
The rep was there. Why not just ask them?
Ask them second. Fischhoff's participants could not tell that knowing the outcome had reshaped what they believed they knew beforehand, and they were confident either way. The record does not have that problem. Build the timeline first, then bring the rep in to explain the gaps in it, which is the part only they can do.
How do you find the turn without guessing?
By counting who started each contact rather than how many there were. Activity does not fall off when a deal dies, it changes direction: the seller keeps going and the buyer stops answering. In the worked example the buyer opened 17 of 31 touches before 5 March and 1 of 40 after it, which is not a judgment call.
What if price genuinely was the reason?
Then it will show up before the turn, and the brief will say so. The test is not that price never loses deals. It is that price cannot lose a deal on a date when no price had been quoted. Where the buyer raised budget early and kept raising it, that shows in the timeline and survives the check.
Our CRM activity log is patchy.
It usually is, and the calendar and the mail threads fill most of it. What matters is who sent the first message in each exchange and when, which survives poor note-taking. Where a stretch is genuinely blank the brief marks it unknown rather than smoothing over it. Better logging afterwards is what the CRM summary is for.
Does this turn into blaming the rep?
The opposite, usually. In the worked example the turn was a technical question that sat nine working days while this team answered the same class of question in two on the deals they won that year. That is a routing problem, not a selling problem, and no amount of coaching the rep would have touched it.
Why does it measure how long we carried the deal?
Because a dead deal in the forecast costs twice, once in the number and once in the hours. Wexford sat there for 152 of its 202 days and went through two quarter-end forecasts. Catching that pattern across a set of losses is what makes the quarter-end triage worth running earlier.
Is this different from our regular deal review?
A deal review looks forward at a deal that is still open and tries to move it. This looks backward at one that is finished and works out what was actually true, then keeps only the changes that would have landed in time to matter. Two of the four fixes proposed in the worked example failed that test.
Sales Deal Post-Mortem and Timeline Review
Fill in the form and your workspace opens with the work already underway.