Guide · Persistent deal memory

Persistent Deal Memory: Keeping Context Between Conversations

Every complex deal accumulates context: who said what, what was promised, what changed. Persistent deal memory keeps that context connected to its sources across conversations, so the next decision starts from what is actually known.

Definition

Persistent deal memory is the running, source-linked record of an opportunity: stakeholders and their roles, statements and who made them, commitments on both sides, open dependencies and the facts that changed over time. It differs from notes, which describe one meeting, and from CRM fields, which store a current value without the reasoning or history behind it.

	Meeting notes	CRM record	Persistent deal memory
Scope	One conversation	Current field values	The whole opportunity over time
History	Scattered across documents	Usually overwritten	Changes kept with sources
Attribution	Often informal	Rarely captured	Each statement tied to a person and moment
Commitments	Listed once	Sometimes a task	Tracked until confirmed complete

Worked example: what changes between calls

An example opportunity across four touchpoints:

Discovery call. The buyer's director says the rollout will cover two regions. Memory records: scope = two regions (director, confirmed).
Email. The rep commits to sending a data-handling document. Memory records a seller commitment, due Friday.
Second call. The buyer's project lead says the second region “may wait until next year”. Memory does not overwrite the first fact; it records a changed scope — reported by a different person, not yet confirmed by the director.
One week later. The rep sent the document. The buyer agreed to review it but has not responded. Memory shows the seller commitment complete and the buyer review waiting — silence is not completion.

The CRM still shows the original deal size. Memory shows why that number may be at risk, who introduced the doubt and what to ask the director next.

What memory must handle well

Attribution. A statement from the buyer's director carries different weight from the same statement repeated by the seller.
Contradictions. When two sources disagree, both remain visible with dates until someone resolves it.
Commitments. Each has an owner, a side and a status; completion requires evidence.
Inference labelled as inference. If the system concludes something, it says so and shows why.

Step-by-step: building memory into your process

Capture conversations with consent, alongside email and CRM context.
After each touchpoint, review what changed: new people, new facts, contradicted facts.
Record commitments with owner and side, and close them only on evidence.
Before forecast calls, review open dependencies and unresolved contradictions.
Use memory to prepare the next conversation, not to replace it.

Diagnostic questions

“What did we know about this deal three calls ago that has since changed?”
“Which commitments are open, and whose are they?”
“Where did this close date come from?”
“Who last confirmed the scope?”

Common failure modes

Overwriting an earlier fact instead of recording that it changed.
Losing who said something, so a guess is later treated as a decision.
Closing tasks when a message was sent rather than when it was acted on.
Context living in one rep's head, lost when the deal changes hands.

Evaluation checklist

Ask the vendor: “What does it know from three calls ago, and where did it come from?”
Check that changed and contradicted facts are kept, not silently replaced.
Check seller/buyer attribution on statements and commitments.
Check how waiting dependencies are shown versus completed tasks.
Ask what data is stored, where, for how long, and who can access it.