# Post Call Followup > When the user has just finished a customer call, QBR, renewal conversation, escalation or check-in and needs the follow-up done properly — the customer recap, the internal note, the CRM updates, and the plays the call should trigger. Also use when the user mentions 'just got off a call', 'here are my notes', 'from this transcript', 'follow-up email', 'recap email', 'send them a summary', 'write up my call notes', 'post-call notes', 'action items from the call', 'next steps email', 'summarise the call', 'here's my transcript', 'log this call in Salesforce', 'update the CRM after the call', or 'they didn't commit to anything'. Use this whenever a customer conversation has just ended or notes/a transcript are pasted in, even if they only ask for 'a quick email' and never say the word follow-up. For preparation before the call, see pre-call-brief. For the QBR deck, see qbr-builder. For the renewal runbook, see renewal-prep. For a full risk re-score, see churn-risk. For an escalation war room, see save-play. - Skill: `gaintrace/post-call-followup` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add gaintrace/post-call-followup` - Raw SKILL.md: https://api.skillmd.com/api/skills/gaintrace/post-call-followup/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - License: MIT - Author: gaintrace (https://skillmd.com/u/gaintrace) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/gaintrace/post-call-followup --- # Post-Call Follow-Up You are closing out a customer conversation to the standard a Chief Customer Officer expects: the customer receives a recap that makes the meeting binding, the account record receives a note that survives your departure, and the system receives the signal changes the call just produced. Three artifacts, one call, in a fixed order, with a one-way wall between them. The rookie version is a single email. It records topics instead of decisions, so nothing becomes binding; it sends four days late, after the customer's recollection has hardened; and the part that mattered — the new VP Finance saying "we're consolidating vendors in Q1" — never leaves the notebook, so the forecast, the risk model and the next CSM all stay wrong. The elite version writes the **internal note first** and the **customer recap last**: a recap built from disclosure-tagged lines cannot smuggle internal framing into customer text, and every call produces a note whether or not anything is sent (C30). Read `../cs-context/references/evidence-standard.md` §9 first — a leaked risk phrase in a recap email has ended renewals. ## Before Starting 1. **Read `.agents/cs-context.md`** for the notice period, renewal owner, forecast category rubric and CRM field names. Without them the Step 6 diff is guesswork. If absent, run `cs-context`. Read the **pre-call brief** too if one exists — its objective and walk-out commitment are what you grade the call against. 2. **Get the raw material**, in this order of preference: | Input | What it unlocks | If absent | | --- | --- | --- | | Transcript (any recorder, or pasted text) | Verbatim quotes, exact commitment language, talk-time split | Sentiment read capped at Low confidence | | Typed notes | Decisions and commitments | Ask the six questions in Step 2 rather than guessing | | Calendar invite + attendees | Who was in the room, who no-showed | `UNKNOWN — requires calendar` | | The prior recap | Which earlier commitments closed or were silently dropped | Cannot check follow-through debt | 3. **Establish the clock.** Record the call end time — every latency rule is measured from it, not from when you started writing. Check `../cs-context/references/business-model-profiles.md`: the account's model decides whether a QBR recap is the right artifact at all, and which commitments matter. Operating Rules R2, R14, R16, R18, R19 and R23 (`../cs-context/references/operating-rules.md`) are enforced throughout this runbook. ### Never guess a missing input **Every missing input resolves read it · ask it · mark it — never guessed.** Read it if it is in the transcript, in `cs-context`, or derivable. Ask it if two likely answers produce materially different work. Otherwise write `UNKNOWN — requires ` and cap confidence. Protocol: `../cs-context/references/clarification-protocol.md`. **Ask these four, tappably, in one batch.** Use `AskUserQuestion`: 2–4 mutually exclusive options each, the recommended one first and labelled `(Recommended)`, a one-line description under each saying what it changes, all four in a single ask — never drip-fed one at a time. Drop any question the invite, transcript, request or `cs-context` already answers; if that leaves none, ask nothing and run. | Header | Question | Options — recommended first, each with what it changes | | --- | --- | --- | | `Meeting` | What kind of call was this? | **Check-in (Recommended)** — 24h recap; `interaction` and next step move · **QBR / EBR** — recap leads with their stated objectives; success-plan milestones move · **Renewal** — same-day recap led by the opt-out date; `forecast_category`, `close_date`, `amount` move · **Escalation** — note and escalation first, recap inside 4h after a cool-down | | `Outcome` | How did it actually go? | **Normal (Recommended)** — standard order, Steps 1–10 · **Went badly** — Bad-call mode: escalation first, named internal approver, 2–4h cool-down · **Nothing committed** — the absence becomes the finding; recap carries our commitments plus one dated ask | | `Deliver` | What do you need out of it? | **All three artifacts (Recommended)** — internal note, CRM diff, customer recap · **Recap only** — the stub note first, then Section C; the stub is a debt, not a deliverable · **Internal only** — Sections A and B; no customer text drafted | | `Latency` | How long since the call ended? | **Under 24 hours (Recommended)** — standard recap · **24–48 hours** — standard recap, send today, delay logged · **Over 48 hours** — Repair mode: recap reframed (`references/recap-templates.md` §10), latency logged as our own broken commitment | **Never block.** If nothing comes back, run on the recommended defaults, state them in one line above the Bottom Line, and record every one in the **Assumptions** table. Never ask what `cs-context` holds — CRM field names, notice period, renewal owner, forecast rubric, segment, ownership model. Never ask who attended when the invite or transcript names them. Never ask the user to grade the call's sentiment: that is the analysis. 4. **Take whatever data the user has** — a transcript pasted into the chat, a `.txt`/`.vtt`/`.docx` export, CSV/TSV/XLSX/JSON/NDJSON of attendees, commitments, tickets or prior interactions, warehouse query results, a screenshot described in prose, or no file at all, in which case the answers above and the six questions in Step 2 are the input and the note says so. **Run `../cs-context/scripts/ingest.py` first on any supplied file:** it sniffs encoding and delimiter, finds the real header row under an export's title rows, maps columns onto the canonical schema with a confidence each, normalises dates, money and booleans, resolves accounts across files and reports the join rate. - **Confirm every mapping below 0.80 confidence before using those numbers** — and any contact-name, `renewal_date` or `notice_period_days` mapping at *any* confidence: a wrong mapping there puts the wrong person's name or the wrong date into a customer email. - **Degrade, never refuse.** Two lines of notes still produce all three artifacts, shorter: quote slots `UNKNOWN — requires transcript`, sentiment capped at Low. Under 40% coverage of the seven families, name the gap instead of scoring the signal deltas (R23). - **Never assume the export is complete or current** — ask its as-of date, print it in the header table, and treat any CRM field older than the call as unverified. ## How This Skill Works **Three artifacts, produced in this order, never merged:** | # | Artifact | Audience | Risk language? | Latency | | --- | --- | --- | --- | --- | | **A** | Internal Call Note | Account team, forever | Yes — this is where it belongs | Same day — never skipped, in any mode (C30) | | **B** | System Updates & Triggers | CRM / CS platform / plays | Yes | Same day | | **C** | Customer Recap | The people on the call | **Never** | Within 24h of call end | | Mode | When | Produces | | --- | --- | --- | | **Full** | Transcript or detailed notes supplied | All three, with verbatim quotes | | **Notes-only** | Sparse notes, no transcript | All three; sentiment capped at Low; quote slots `UNKNOWN — requires transcript` | | **Recap-only** | User explicitly wants just the email | The stub note **first**, then C. No mode emits C without a written note (C30); the stub is a debt, not a deliverable | | **Repair** | >48h since the call, nothing sent | C reframed (`references/recap-templates.md` §10); latency logged as our broken commitment | | **Bad-call** | Escalation, complaint, the call went sideways | A and the escalation **first**; C after a named cool-down and a named internal approver | Run sequence: **classify → extract → grade commitments → tag disclosure class → write the internal note → write the CRM diff → fire triggers → write the customer recap → leak scan → schedule the follow-through.** **The 24-hour rule.** Send the recap within 24 hours of call end — a practitioner convention `[P]`, not a measured benchmark, so the mechanism matters more than the number. Four things decay: **shared recollection** (memories harden separately and you negotiate the record), **internal relay** (your champion re-frames it from memory), **commitment gravity** (theirs evaporate, yours do not), and **momentum**. **A recap that lands after the customer's next internal meeting did not happen** — ask on the call when that meeting is, and beat it. --- ## Step 1 — Classify the meeting and grade the objective Name the meeting type — it sets the recap's lead, the mandatory sections, the CRM field that must move and the latency target. What each leads with, plus a worked example per type: `references/recap-templates.md` §2–§9. | Type | Must change in CRM | Latency | | --- | --- | --- | | Check-in | `interaction`, next step | 24h | | QBR / EBR | `interaction`, success-plan milestones, next QBR date | 24h | | Renewal | `opportunity.forecast_category`, `close_date`, `amount` | **Same day** | | Escalation | Ticket link, `account.status`, exec sponsor | **Within 4 hours** | | Expansion | New `opportunity` (type `expansion`) opened same day | Same day | | Technical review | Linked `ticket` / Jira keys, integration state | 24h | | First call, new stakeholder | New `contact` with role, influence, sentiment | 24h | Then grade the call against the objective the pre-call brief set: `Achieved` · `Partially — ` · `Not achieved — ` · `No objective was set` (itself a finding). ## Step 2 — Extract the raw ledger Walk the transcript or notes once and sort every line into exactly six buckets. Do not summarise while extracting — merging the two passes is how nuance gets rounded off. Markers: `references/commitment-extraction.md` §3. | Bucket | Test | Example | | --- | --- | --- | | **1. Decisions** | Settled now, open before the call | "We're going with the SSO-first rollout." | | **2. Our commitments** | We will do a thing | "I'll send the revised pricing by Thursday." | | **3. Their commitments** | They will do a thing | "I'll get the security questionnaire back next week." | | **4. Open questions** | Asked either direction, not answered | "Who signs this on your side?" — unanswered | | **5. Customer-stated facts** | Numbers, dates, names, org changes, budget, competitors | "Our headcount plan is flat through Q1." | | **6. Asked-for and not given** | We requested something and got no answer | Asked for an intro to Finance; they moved on | From sparse notes, ask exactly these six rather than inventing content: who was in the room · what got decided · what did you promise · what did they promise · what surprised you · what did you ask for and not get. Bucket 1 is what the account record is for (R2 — decisions beat indicators). **Bucket 6 is the one everyone drops and the highest-signal bucket in the call:** a request neither accepted nor refused was refused. **Count the exchanges before you call anything a finding (C2).** The first answer is rehearsed, the second considered, the third true. Beside every bucket-4 and bucket-5 line on the account's central issue, record `exchanges` — how many separate times we asked and they answered *on that issue* — and route on it: **1 = thin**, allowed only into block 9 as an open question carrying the literal follow-up to ask, never into block 2, a CRM diff row or a recap decision; **2 = considered**, usable in block 2 with the rule stated; **≥3 = tested**, usable as a finding anywhere (R16). What is thin is the *explanation*, never the event: a stated commercial decision is logged verbatim and fires its trigger on one exchange (R2) while *why* stays in block 9. Every thin line carries a **Follow-up to ask** — the words you will say, *"And what else is driving the Q1 freeze?"*, never a topic. An empty `exchanges`, or a thin line with an empty follow-up, is invalid output, not a draft. ## Step 3 — Grade every commitment A commitment passes the **three-part test**: a named **Actor** (never "we" or "the team"), an observable **Act** (send, approve, schedule, introduce, sign, provision — never "look into" or "explore"), and an **Anchor** that is a date or a dated event boundary (never "soon" or "next few weeks"). Missing any part makes it a courtesy, and recording a courtesy as a commitment is fiction. Full test: `references/commitment-extraction.md` §1–§2. | Grade | Language observed | Binding | What to do | | --- | --- | --- | --- | | **A** | "I'll send the security doc by Friday 5 Sept" | Yes | Log verbatim with the quote and timestamp | | **B** | "We can get that over next week" | Partial | Assign a name and a specific date; state the assumption in the recap so they can correct it | | **C** | "Let me look into that" | No | Convert to an open question with a dated response request, or drop it | | **D** | "That sounds useful" / "Makes sense" | No | Courtesy statement. **Never** record as a commitment | | **E** | Silence following an ask | No | Log in bucket 6 — a relationship signal, not an admin gap | **Binding phrasing — confirm by default, not confirm on request.** "Can you confirm?" gives a busy stakeholder an easy way to do nothing. Record it as already agreed and invite correction: *"I've recorded the security questionnaire coming back from Priya by Thu 11 Sept — tell me if that date needs to move."* Correction is a cheaper reply than confirmation, and silence then reads as agreement. Never write a date we do not control (R19). The ladder for commitments a customer will not confirm: `references/commitment-extraction.md` §5. ## Step 4 — Tag the disclosure class (this is the wall) Before any recap text is written, tag every extracted line with exactly one class. **The customer recap is assembled only from `SHARE` and `TRANSLATE` outputs — nothing else may enter it.** A whitelist, not a warning. | Class | Meaning | Rule | | --- | --- | --- | | `SHARE` | Goes to the customer verbatim or near-verbatim | Decisions, commitments both ways, open questions, next meeting | | `TRANSLATE` | An internal observation with a customer-safe counterpart | Write the counterpart explicitly; the internal line never travels | | `INTERNAL` | Never leaves the account record | Risk language, dollars at risk, forecast calls, sentiment reads, competitor strategy, anything about their people | This is R18, the firewall. "Sponsor absent from three consecutive calls" translates to *"Would it help to bring Dana into the November session?"*; "ARR at risk $148k, forecast moving to At Risk" translates to nothing — it never appears in customer-facing material. Full table: `references/internal-note-standard.md` §4 and `../cs-context/references/customer-voice.md`. Never translate an inference into a statement of fact. ## Step 5 — Write the internal call note Artifact A answers four questions a colleague inheriting this account in six months cannot answer any other way: what happened, what it meant, what changed, and what we now believe that we did not believe before. Full standard and the worked example: `references/internal-note-standard.md` §2–§3. What separates a note from a transcript summary is **what was said → what it likely meant**: state the observation, the inference, **the rule applied**, and what would falsify it. Then the **signal family deltas** — all seven, untouched ones printing `No change — not covered on this call`, which is what makes the note evidence for `churn-risk` rather than an anecdote. **Two blocks that cannot be empty (C30).** Block 9 carries Step 2's thin answers with their `exchanges` and follow-ups. Block 10 — *not written down anywhere else* — carries what you know about this account that exists only in your head: the aside before the call started, why a name is never mentioned, what the previous owner told you. Empty is not a valid value; with genuinely nothing to add it prints "None — blocks 1–9 carry everything I know". **Compute days since the last written note on this account and print it in the header.** Past 14 days, block 10 lists every interaction since that was never written up, one row each, and each becomes a dated write-up task in Step 10 — an unwritten interaction is an unwritten decision (R14). ## Step 6 — Write the CRM diff Never "update the CRM". Emit a **field-level diff** — object, field, old, new, evidence, and the rule permitting the change, naming whichever system of record holds the field. Every rule is in `references/crm-update-rules.md` §3–§7; the four broken most often: | Field | The rule | Why | | --- | --- | --- | | Health band | A call **cannot** move a band on its own — it moves the *inputs* (`contact.sentiment`, `contact.is_active`, `opportunity.competitor`). Two exceptions: a confirmed economic-buyer departure, a stated commercial decision. | Otherwise the score becomes a mood ring and stops predicting anything | | `opportunity.close_date` | Contract-controlled, not rep-controlled. Moves only for an amendment, an agreed extension, or a data-error correction — never because the deal feels slower. | Slipping the date instead of the category is the oldest way to hide a miss | | `opportunity.forecast_category` | Promote only when every entry criterion is now true **and was evidenced on this call**. Any demotion carries a written explanation (ORM 2026 `[V]`, via `renewal-forecast`). | A category with soft entry criteria forecasts nothing | | `contact.role` / champion status | Change on behaviour, not job title — a champion spends their own credibility on you internally. Log the act that proves or disproves it. | Title-based tracking is why "the champion left" is discovered at T-30 | If two systems disagree, write the disagreement into the note rather than resolving it silently. ## Step 7 — Fire the downstream triggers A call outcome that changes the account's state fires a play the same day, with one named owner and a due date. An alert sent to a team is an alert nobody owns — everyone assumes someone else has it `[P]`. Tier what you fire into *act today* / *this week* / *information only*; nine same-day alerts produce none. Whichever platform holds your playbooks, the rule is the same; full catalogue: `references/crm-update-rules.md` §8. The six most common: | Trigger observed on the call | Fires | Owner | Due | | --- | --- | --- | --- | | Competitor named, or an evaluation described | `churn-risk` re-score + shadow-evaluation play | CSM | 2 business days | | Economic buyer departed / replaced | `stakeholder-map` refresh + new-sponsor 30-day plan | CSM + AM | 5 business days | | "We're consolidating vendors" / budget cut stated | `save-play` + forecast review | AM | Same day | | Auto-renew, notice period or termination language raised | Escalate to renewal owner; forecast category review | Renewal owner | Same day | | Explicit ask for seats, a locked feature, or a new product | Open `opportunity` type `expansion`; **log the exact quote** | AM | Same day | | Unresolved P1 or a broken commitment surfaced | Escalation record + named exec sponsor | Support lead | 4 hours | ## Step 8 — Write the customer recap Only now, and only from `SHARE` + `TRANSLATE` lines. Worked examples for all seven meeting types are in `references/recap-templates.md`; the emit-verbatim skeleton is `assets/recap-email-template.md`. **Length and subject.** Keep prose under ~200 words — a recap nobody finishes is a recap nobody acts on, and the reply-rate evidence behind that number is in `references/recap-templates.md` §1. Subject brevity is the opposite call: your customer opens it regardless and then needs to *find it again in six weeks* when the commitment comes due, so optimise for **retrieval** — `Northwind Q3 sync — SSO rollout decision + 3 owners`, never "Follow-up", "Recap" or "Great talking today". **Six slots, in this order:** subject (account + the decision or the thing owed) · opening line (one sentence, not "thanks for your time", not starting with "I") · decisions made (omitted entirely if nothing was decided — never manufactured) · commitments, theirs and ours, each with a named person and a calendar date · open questions with who owes the answer by when · next session as two dated, timed slots, never "let's find time". **Three rules bind every word.** Read `../cs-context/references/customer-voice.md` before writing a line of Section C. - **Warmth is specificity, not adjectives.** The banned phrasebook — "just checking in", "touching base", "circling back", "hope you're well", "reaching out", "we value your partnership" and the rest — is in `../cs-context/references/customer-voice.md`. The test: could this sentence have gone to any of forty customers? Then rewrite it around something only this call produced — their number, their words. - **The disclosure firewall (R18).** Health score or band, risk band or score, ARR at risk, exposure, forecast category, close date, save play, war room, coverage tier, champion-departure inferences, competitor intelligence and any assessment of a named person **never** reach the customer, in any wording — nor does a commitment we inferred rather than heard, anything said in confidence, re-litigation of a complaint, an ask not raised on the call, or a second ask. - **The copy block.** Section C is emitted inside a fenced ```text block below the divider, formatted for an email client: plain text, a blank line between paragraphs, `•` bullets, no markdown headings, no pipe tables, no `**`. **No unfilled placeholders inside the fence.** If a name or date is genuinely unavailable, drop the sentence and raise `UNKNOWN — requires X` above the divider; a block containing `[Name]` is not send-ready. **Register and source material.** An over-warm email after a bad call reads as not having listened; a formal one to a two-year champion reads as a handover. The five registers and their traps are `references/recap-templates.md` §15; mining a transcript, bullet notes or nothing but memory is §16 — read both when the input is thin or the relationship is difficult. Two rules survive every register: **match their energy** (a call that surfaced friction gets an email that names it) and **match their length** (padding tells the customer you are performing effort). **Never write "we then discussed"** — the customer was on the call. ## Step 9 — Leak scan and the two hard cases Run the eight-scan sweep in `../cs-context/references/customer-voice.md` over the draft: risk and forecast vocabulary (risk, churn, at-risk, escalation, save, red, health, score, commit, exposure, ARR, tier) · currency figures not agreed on the call · third parties the customer did not name · Grade C/D items or thin answers (`exchanges` = 1) written as commitments or decisions · any sentence about someone not on the call · any unfilled `[placeholder]` inside the fence. **Any hit is rewritten, not softened** — softening leaves the shape. **The call went badly.** Reverse the order: internal note and escalation first, recap second, with a named internal approver and a 2–4 hour cool-down, still inside 24. The recap acknowledges; it does not defend: what was wrong in their words, what we are changing, who owns it and by when — never a factual correction inside an apology. **They committed to nothing.** Record the absence as the finding rather than padding the recap. A zero-commitment call is a relationship signal, logged in Relationship & engagement in Step 5; the recap carries our commitments only, plus **one** dated, low-cost ask. ## Step 10 — Schedule the follow-through Commitments recorded and not tracked are worse than commitments never made — you have created a written record of your own failure. Every commitment, every thin answer's follow-up (C2) and every unwritten interaction (C30) becomes a dated task with one named owner. `scripts/followup_schedule.py` computes business-day due dates, chase dates, commitment debt and days since the last written note; system: `references/commitment-extraction.md` §6. --- ## Output Template Sections A and B are internal, one markdown block. Section C is emitted separately below the divider, in its own copy block. ````markdown # Post-Call Follow-Up — · · **Sections A and B are INTERNAL. Section C, below the divider, is the only text the customer sees.** call, all three artifacts, standard latency — say the word and I'll re-run on a different setting."> ## Bottom Line <3 sentences: what the call changed, the most important commitment, the one downstream action with owner and date.> | | | |---|---| | Objective grade | Achieved / Partially — / Not achieved — / No objective set | | Attendees (theirs / ours) | · no-shows: | | Commitments: theirs / ours | N / M (Grade A: x, B: y) | | State change | | | Recap due by | · Sent: