Meeting Notes to CRM - Agent Prompt

Who this is for

Anyone who ends the day with three recorded calls and a CRM that still says what it said at breakfast. Founders doing their own sales, small teams where nobody's job is data entry, and builders wiring a recorder (Fathom, Granola, Gong, Zoom) into an agent pipeline. Use it right after a call, or in a nightly batch over everything the recorder captured that day.

The failure mode this prompt exists to prevent is not laziness - it is the naive automation that replaces it. An agent that summarizes a transcript into one blob note has added nothing structured. Worse, an agent run twice writes everything twice, timestamps the call at whatever time it happened to run, and cheerfully "detects" a budget the buyer never stated. Extraction without rules is pollution with better grammar.

The discipline: what goes where

A transcript contains five kinds of signal, and each has exactly one correct destination. Everything else in the call - pleasantries, tangents, your own pitch - goes nowhere.

Signal in the transcript	CRM write	Rule
The call happened	One activity, type call	occurred_at = meeting start time, never run time
Numbers, pains, budget, timeline quotes	Deal custom_fields (SPICED or MEDDPICC keys)	Evidence only - every value traces to a spoken line
Buyer commits to a concrete next step	Stage recommendation, not a move	Agent proposes with a quote; a human approves
Owed items with owners and dates	Second activity, type note	Explicit commitments only, one line each
Attendee not in the CRM	Contact create	409 on duplicate email returns the existing record - reuse it

Three rules carry most of the weight. Backdating: an activity timestamped when the agent ran is forensic garbage - a deal reviewed Friday looks touched Friday even if the call was Monday. Relm accepts occurred_at on activities precisely so imported history lands on the day it happened. Evidence-only fills: the agent writes a qualification field only when the transcript contains it, attributed to a speaker - "sounded positive" fills nothing. Idempotency by construction: the first line of every activity is a marker like [meeting:fathom_9482]; before creating, the agent checks whether the marker already exists on the deal and updates instead. On REST, an Idempotency-Key header derived from the meeting id backs this up at the transport level.

One credit line: SPICED is Winning by Design's framework; MEDDIC traces to Dick Dunkel and Jack Napoli at PTC in the 1990s, with MEDDPICC adding Paper process and Competition. Field kits for both are in the SPICED template and the MEDDPICC checklist - install one before first use so step 4 has keys to fill.

The prompt

Paste this once as your agent's standing instructions. Then, per meeting, paste the three-line header plus the raw transcript.

You are my meeting-notes-to-CRM clerk. My CRM is Relm
(MCP: https://api.relmcrm.com/mcp - use the relm_* tools).

INPUT
I will paste a raw transcript preceded by a header:
  meeting_id: <stable id from the recorder>
  occurred_at: <meeting start, ISO 8601 with timezone>
  attendees: <Name <email>, ...>
If any header line is missing, ask for it before writing anything.

HARD RULES
- Read the schema first. Use only field keys, activity types and
  stage keys that actually exist in this workspace.
- Evidence only. Every value you write must trace to a line in the
  transcript, attributed to its speaker. Never infer budget,
  authority or timeline from tone.
- Idempotent by construction. The first line of every activity you
  create is exactly "[meeting:<meeting_id>]". Before creating, list
  the deal's activities; if the marker exists, update that activity
  instead. Re-running on the same transcript must create zero records.
- Backdate. occurred_at on the call activity is the meeting start
  time from the header - never the time you run.
- You do not move deal stages. You recommend, with a quote.

STEPS
1. Resolve people. For each external attendee, create the contact
   (first_name, last_name, email). A 409 duplicate-email response
   returns the existing record - use its id, do not retry.
2. Resolve the deal. Search deals (q=) by company name and attendee
   context. Exactly one match: use it. Zero or several: stop, show
   candidates, ask me. Never create a deal from a transcript.
3. Log the call. One activity: type "call", deal_id plus the primary
   attendee's contact_id, occurred_at from the header. Body: the
   marker line, then outcome in one sentence, decisions, objections
   (verbatim), numbers mentioned, commitments made by each side.
4. Fill qualification fields. Read the deal's custom_fields. For each
   SPICED or MEDDPICC key in the schema that the transcript supports,
   write "confirmed|hypothesis: <short quote> (call <date>)". Never
   blank an existing value; overwrite only if the new evidence is
   more recent AND more specific, otherwise append after " | ".
5. Recommend a stage. Compare what was said against the stages of the
   deal's pipeline. Output: current stage -> recommended stage, the
   single quote that justifies it, confidence high/medium/low.
   Move ONLY after I reply "move it".
6. Write next steps. Second activity: type "note", same deal, first
   line "[meeting:<meeting_id>:next-steps]", body: one line per owed
   item as "- owner - action - due date", explicit commitments only.
7. Report. One table: every record created or updated, its id, and
   the transcript line that justified it.

Example: one transcript, three writes

Input - header plus a five-line excerpt:

meeting_id: fathom_9482
occurred_at: 2026-07-08T14:00:00+02:00
attendees: Dana Reyes <[email protected]>, you

Dana: "Reconciliation is eating about 20 hours a week across my team."
Dana: "This comes out of my ops tooling budget - up to $15k a year I sign myself."
Dana: "Our IT security review usually takes two weeks. Send the SOC 2."
You:  "SOC 2 today, proposal by Friday."
Dana: "If it's live before our September audit, that's the whole point."

Output - the call log (POST /v1/activities), the field fills (PATCH /v1/deals/deal_7kq2mrx0e1), and the next-steps note:

{
  "type": "call",
  "deal_id": "deal_7kq2mrx0e1",
  "contact_id": "con_x8f3k2m9q2",
  "occurred_at": "2026-07-08T14:00:00+02:00",
  "body": "[meeting:fathom_9482]\nOutcome: strong discovery; proposal owed Friday.\nNumbers: ~20 h/week manual reconciliation; budget ceiling $15k/yr (Dana signs alone); IT review ~2 weeks.\nCommitments: us - SOC 2 today, proposal Friday. Acme - start IT review on receipt.\nCritical event: September audit."
}

{
  "custom_fields": {
    "spiced_pain": "confirmed: 'reconciliation is eating about 20 hours a week' (call 2026-07-08)",
    "spiced_impact": "hypothesis: 20 h/wk x ops loaded cost - quantify with Dana next call",
    "spiced_critical_event": "confirmed: 'live before our September audit' (call 2026-07-08)",
    "spiced_critical_event_date": "2026-09-01",
    "spiced_decision_process": "confirmed: Dana signs up to $15k/yr alone; IT security review ~2 weeks (call 2026-07-08)"
  }
}

{
  "type": "note",
  "deal_id": "deal_7kq2mrx0e1",
  "body": "[meeting:fathom_9482:next-steps]\n- us - send SOC 2 report - 2026-07-08\n- us - send proposal - 2026-07-11\n- Dana - kick off IT security review - on receipt of SOC 2"
}

Plus one non-write: "discovery → evaluation, quote: 'send the SOC 2' + review timeline named, confidence high - awaiting 'move it'." Note what the agent did not do: it did not fill spiced_situation (nothing was said about the current stack), and it marked impact as a hypothesis because Dana gave hours, not dollars. A tempting shortcut is pushing all three writes through POST /v1/batch - resist it here: batch ops skip webhooks and automations by design, so your stage-change and follow-up rules would sleep through the update. Batch is for backfilling history, not for live calls.

Apply it with your agent

Point any MCP client (Claude, or anything that speaks MCP) at Relm, paste the prompt above as the system message, then paste transcripts as they land:

{
  "mcpServers": {
    "relm": {
      "type": "http",
      "url": "https://api.relmcrm.com/mcp",
      "headers": { "Authorization": "Bearer relm_live_..." }
    }
  }
}

On REST, the same call-log write with transport-level idempotency - retry it as many times as you like, you get the original result back:

curl https://api.relmcrm.com/v1/activities \
  -H "Authorization: Bearer relm_live_..." \
  -H "Idempotency-Key: fathom_9482-summary" \
  -H "Content-Type: application/json" \
  -d '{"type":"call","deal_id":"deal_7kq2mrx0e1","contact_id":"con_x8f3k2m9q2","occurred_at":"2026-07-08T14:00:00+02:00","body":"[meeting:fathom_9482]\nOutcome: strong discovery; proposal owed Friday."}'

Rehearse on a relm_test_ key first - test mode is free, unlimited and invisible to live data, so a badly tuned clerk can make its mistakes where nobody forecasts from them. Full API reference in the docs. Once transcripts flow in reliably, the daily pipeline review prompt becomes dramatically more useful - it finally has fresh evidence to review.

FAQ

Why doesn't the agent move the deal stage automatically?

Because a transcript is evidence, not a decision. Stage moves fire automations, sequences and forecasts downstream, and an over-eager extraction agent that promotes every enthusiastic call will corrupt all three. The prompt makes the agent recommend a move with the exact quote that justifies it, and write only after you reply. If you later trust it, relax that one rule - the rest of the prompt stays the same.

How does the prompt avoid duplicates when I run it twice on the same transcript?

Three layers. Every activity's first line is a marker like [meeting:fathom_9482], and the agent lists the deal's activities and switches to update mode if the marker exists. Contact creation relies on email dedupe - posting an existing email returns 409 with the existing record, which the agent reuses. And REST writes carry an Idempotency-Key derived from the meeting id, so even a retried HTTP call replays the original result instead of inserting again.

Does this work with Fathom, Granola, Gong or Zoom transcripts?

Yes - the prompt is recorder-agnostic and takes raw text. The only requirement is the three-line header: a stable meeting_id from the recorder, the meeting start time in ISO 8601 with a timezone, and attendee emails. Every mainstream recorder exposes all three; if one is missing the agent is instructed to stop and ask rather than guess.

Should the agent overwrite qualification fields that already have values?

Only when the new evidence is both more recent and more specific; otherwise it appends after a separator with the call date. It never blanks a field. Qualification data is an evidence trail, and a clerk that silently replaces last month's confirmed budget quote with this week's vague remark is destroying information, not maintaining it.

Do I need Relm to use this prompt?

No. The discipline - one backdated activity per meeting, evidence-only field fills, human-approved stage moves, marker-based idempotency - works in any CRM your agent can write to. The prompt is worded for Relm because its MCP server, self-describing schema, email dedupe and Idempotency-Key support make every rule directly enforceable, but the steps translate to HubSpot or Salesforce APIs with different tool names.