A real pre-call brief for a banker or private equity investor is not a company summary. Roughly 80% of its value comes from the firm's own history with the people on the call: every prior interaction, the deals already shown, what happened last time, open commitments, and what has changed since, each point cited to its source. The public-web paragraph most “AI meeting prep” tools produce covers the 20% a first-year could Google in four minutes. The hard part, and the part that changes how the call goes, is institutional memory. That is exactly the part that lives in a CRM most teams do not trust.
The ritual it replaces
Watch what actually happens in the fifteen minutes before a sponsor call at most firms. Someone opens LinkedIn to check whether the person on the invite still has the same title. Someone opens PitchBook to see whether the fund closed. Someone scrolls their own sent folder searching the sponsor's name, because the last conversation lives in email, not in the CRM. And someone pulls up the CRM record, glances at a “last contact” field from eleven months ago, and quietly decides not to rely on it. This ritual exists because the system of record is not trusted, which is a rational response given the state of the data. At one mid-market advisory firm on DealCloud (~25 bankers), the baseline we measured before any tooling was 58% of sponsor records stale by more than a year and only 7% of investment-criteria fields filled in at all. Nobody preps from a record like that; they prep around it, by hand, every single time.
Why the company-summary version fails
Generic meeting-prep AI assembles what the public web knows: founding year, headquarters, AUM from the website, recent press. It is not wrong; it is just not the job. The banker's questions before a call are relational, not encyclopedic. Have we shown them anything in this space before, and did they pass, and why? Did we promise them a teaser we never sent? Did their check size change since we last mapped them? A public-web summary cannot answer any of these, because the answers exist only in the firm's own email, calendar, call notes, and deal history. Prep that skips the firm's own memory produces the most embarrassing failure mode in coverage work: re-pitching a deal the sponsor already declined, to a person who remembers declining it.
The anatomy, section by section
Here is what a pre-call brief contains when it is built to be used rather than admired:
- Who is actually on the call. Names, current roles, and how your firm knows each person: who at your firm has the relationship, and how warm it is. Not a bio; a map of the room.
- Every prior interaction. The full contact history across email, meetings, and calls, dated, with a one-line gist of each. This is the section that replaces the sent-folder archaeology.
- Deals already shown. Which opportunities this sponsor or buyer has seen from your firm, and the outcome of each: passed, engaged, went quiet. With the pass reasons, where they were captured.
- What happened last time. The last substantive conversation, in enough detail to pick up the thread, including tone, not just facts, when the source supports it.
- Open commitments. Anything either side said they would do and has not visibly done. Walking into a call unaware of your own unfulfilled promise is worse than no prep at all.
- What changed since, with citations. Role moves, fund closes, revised criteria, each item linked to its evidence: the SEC filing, the firm's website, the email. A claim without a citation is a rumor wearing a suit.
- Suggested questions. Two or three openings derived from the gaps above (the unresolved pass reason, the new fund's mandate), so the prep converts directly into the first five minutes of conversation.
Timing is a feature, not a detail
A brilliant brief delivered on request is a brief nobody requests at 7:40 a.m. before an 8:00 call. The brief has to arrive because the meeting exists: when an event with an external party hits the calendar, the brief shows up in the inbox, unprompted, with time to read it. This is the difference between a research tool and a workflow, the same difference we describe in the pre-call brief use case. If prep requires remembering to ask for prep, it inherits the failure rate of human memory, which is the problem it was supposed to solve.
The loop that makes next quarter's brief better
Here is the part that separates a brief generator from a memory system. The call happens. The same system that wrote the brief captures the call (a notetaker that stages CRM updates rather than just a summary) and proposes the field changes the conversation implied: new criteria, a pass reason, a next step with an owner. A human approves each one, the system writes to DealCloud or Salesforce, and reads the record back to confirm. Which means the next brief about this sponsor is built on verified fields, not on the decayed record that made the manual ritual necessary in the first place. The brief and the update are two halves of one loop; run only one half and the other decays.
The loop compounds in measurable units. In the same live deployment, 40 sponsor records were enriched in a single week from SEC filings and firm websites. Each enrichment is a cited, approved update, and each one a line in some future brief that no longer needs to be re-researched by hand. A cited 54-buyer list, with 10 shortlisted, came out of the same verified memory. None of this is “the CRM is fixed.” It is something more useful: every call now leaves the record slightly more trustworthy than it found it, and every brief starts from what the last call verified. That is what prep looks like when it is built on memory instead of search.
