Define the boundary and risk tier for call preparation
Call prep begins after upstream research and ends when the seller has an approved, meeting-specific plan. It does not replace account research, discovery, a demo script, a renewal plan, or a reusable template. The sales-call-prep template owns the fillable artifact; the pre-call research accuracy test owns systematic QA of generated briefs.
Define the decision before collecting context. A first conversation may decide whether deeper discovery is justified. A demo may decide whether a defined workflow passes agreed proof criteria. A commercial review may resolve quantities, risk, or an approval path. If no decision is named, the brief tends to become a long summary that does not help the meeting.
Use a risk tier rather than a universal time target. Consider novelty, participant authority, contract value, regulated or sensitive data, technical complexity, prior conflict, and the consequence of a wrong claim. Set a preparation service level for each tier and record when insufficient evidence requires a narrower agenda or reschedule.
Inventory relevant sources and their authority
Inventory sources before drafting. Common inputs include calendar event, CRM account and opportunity, contact records, approved email thread, prior meeting artifacts, support or implementation records, product usage authorized for sales use, public company information, and a governed proof library.
| Input | Authority | Critical question |
|---|---|---|
| Calendar event | meeting logistics | is this the right occurrence, organizer, attendee list, and time zone? |
| CRM | declared commercial state | which fields are observed, derived, stale, or disputed? |
| Prior interaction | conversation evidence | what was actually said, by whom, and when? |
| Public source | external fact | is the source primary, current, and about the correct entity? |
| Proof library | approved claim | does the evidence support this exact audience, product, and wording? |
The ICO’s data-minimisation guidance says personal data should be adequate, relevant, and limited to what is necessary. Apply that principle according to applicable law and policy: a seller does not need every available personal detail merely because a system can retrieve it.
Resolve the meeting, people, account, and opportunity
Resolve the meeting before resolving the story. Google Calendar documents both event identifiers and recurring-event behavior in its Events API. A real prep system must distinguish an event series from one occurrence and should account for forwarded invitations, aliases, assistants, external guests, changed organizers, reschedules, and duplicated events.
Match each attendee to the correct person, account, and—where justified—opportunity. Do not force an opportunity association when several open deals are plausible. Preserve the alternatives and ask for review. Then record participant role for this decision, not a stereotype inferred from job title.
A minimum identity gate checks meeting occurrence, organizer, attendee email or stable ID, account, opportunity, owner, and permitted source access. A critical mismatch blocks automatic briefing or CRM writeback. The stakeholder-mapping guide owns the deeper relationship model.
Separate verified facts, buyer statements, and hypotheses
Represent the brief as atomic statements rather than prose without lineage. W3C’s PROV-O recommendation provides Entity, Activity, and Agent concepts for representing provenance. A practical call-prep record can use source entity, source ID, author or speaker, observed-at, ingested-at, transformation, and brief version.
Label each statement:
- verified fact: supported by an appropriate source;
- buyer statement: attributed to a named participant and date;
- inference: reasoned from evidence but not confirmed;
- hypothesis: a question the call should test;
- conflict: credible sources disagree;
- missing or expired: evidence is absent or too old for the decision.
Never turn a public trigger into a private motive. A leadership change can be cited; “they must need our product” is a hypothesis. Never turn an old buyer statement into current approval. Preserve the as-of date and revalidate consequential claims.
Turn evidence gaps into questions, proof, and a decision plan
Convert evidence into a compact plan:
- Purpose: why the meeting exists and which decision it may support.
- Known state: only relevant verified facts and attributed commitments.
- Unknowns: missing, conflicting, or expired assertions.
- Questions: ordered to resolve the highest-impact unknowns.
- Proof: approved evidence relevant to the buyer’s stated use case.
- Boundary: claims or decisions requiring a specialist.
- Next decision: ideal, fallback, and stop condition.
Questions should follow the evidence gap, not an arbitrary count. A strong opening confirms purpose and available time, then gives the buyer an opportunity to correct the prepared context. The seller should not perform certainty. “Here is what I understand; what is wrong or missing?” is safer than a confident narrative built on stale data.
Adapt the base brief for discovery, demo, risk, and renewal calls
| Call type | Preparation emphasis | Do not duplicate |
|---|---|---|
| Discovery | current state, stakeholders, evidence gaps, open questions | discovery meeting method |
| Demo | approved use case, participants, proof state, branches, backup | demo delivery |
| Technical or risk | architecture, data flow, controls, open exceptions, specialists | legal or security approval |
| Commercial | edition, quantity, usage, term, concessions, authority | contract or finance decision |
| Renewal | original promise, adoption, incidents, billing, outcomes, risk | unsupported expansion assumption |
Maintain one base schema, then show only relevant fields. A renewal brief does not need a fresh generic company profile if the real issue is an unresolved implementation defect. A security meeting does not need persuasive customer logos when the decision concerns data flow and control evidence.
Control AI-generated prep with labels, permissions, and review
NIST’s Generative AI Profile identifies risks including confabulation, data privacy, information integrity, and information-security concerns. An AI-prep workflow should therefore be evaluated as an evidence system, not merely a summarizer.
Test a frozen, consented set containing correct and incorrect identities, aliases, recurring meetings, multiple open opportunities, missing CRM fields, contradictory sources, stale pages, restricted records, malicious instructions in retrieved content, and questions with no supported answer. Measure identity precision, evidence precision, required-field recall, staleness, conflict detection, critical errors, permission violations, and abstention.
Separate permissions to read, draft, share, and write. A system may draft a brief without authority to change the CRM or send it externally. Require preview and approval for consequential claims. Log source, model or rule version, prompt or configuration, reviewer, changes, distribution, and rollback.
Measure quality with a printable evidence record
Use this printable quality record:
| Block | Required fields |
|---|---|
| Meeting | event occurrence, organizer, attendees, time zone, purpose |
| Identity | person, account, opportunity, owner, match confidence |
| Evidence | atomic claim, state, source, source ID, as-of, conflict |
| Plan | unknowns, questions, proof, boundary, decision, fallback |
| Control | permissions, reviewer, version, approval, incident, rollback |
Audit a stratified sample by call type and risk tier. Evidence precision = supported included claims ÷ all included claims. Required-field recall = correctly populated required fields ÷ all required fields with known truth. Report counts with rates and maintain a critical-error register. Revenue outcomes may be monitored descriptively, but do not claim prep caused them without a suitable study.
Calibrate reviewers before using the score for coaching or access decisions. Give two reviewers the same labeled briefs without showing the system verdict, record raw agreement by field, and adjudicate disagreements against the approved source hierarchy. Track false inclusions, omitted critical context, wrong-account errors, permission breaches, and claims that should have been marked uncertain. Re-run the set after a connector, schema, retrieval source, model, prompt, or policy changes. A faster brief is not an improvement if it quietly increases critical error or exposes data to the wrong meeting.
A good prep system makes uncertainty visible. Another qualified person can inspect which meeting was prepared, where each fact came from, what the seller planned to learn, what was approved, and how an error would be corrected.