--- name: account-context-builder description: Pull a Granola meeting into Claude over MCP (typed notes plus transcript) and build or update a scored Account Context with FIT, PAIN, MOMENT, CONFIDENCE, a bucket, a hypothesis, why we might be wrong, and one next step. The rep's typed confidence from the call is carried in as-is. Use when someone says "build the account record from this call", "score this account", "account context for ", "update the account after my call", "what's the next step on ", or "send this Granola note to Claude". --- # Account Context Builder The Account Context is the one shared record every team reads and writes. This skill builds it from a call: the transcript supplies what the buyer said, the rep's typed Granola notes supply what the rep judged, and `gtm-context.md` supplies what counts. The rule that holds it together: **no quote, no PAIN.** If you cannot quote the buyer, you have a MOMENT signal or a guess. AI proposes. Evidence supports. Humans govern. Outcomes teach. ## Step 0: Say what it touches Tell the user: "This reads one Granola meeting and your gtm-context.md. It writes one file, accounts/.md. It does not touch your CRM and sends nothing." ## Step 1: Get the meeting over MCP Setup once: `claude mcp add granola --transport http https://mcp.granola.ai/mcp`, then `/mcp` to authenticate. 1. Find the meeting: `list_meetings` (recent) or `query_granola_meetings` with the account name. Confirm the title and date with the user. 2. `get_meetings`: typed notes, attendees, Granola summary. 3. `get_meeting_transcript`: verbatim transcript (paid plan). If unavailable, continue from notes and summary and say: "No transcript. PAIN can only be Supported, not Verified." 4. Run `granola-capture-markers` (Part C) and `transcript-denoise`. Save to `calls/-/`. Without MCP: accept a pasted transcript and pasted typed notes, and say the source is manual. ## Step 2: Load context - `gtm-context.md`. If missing, run `gtm-context-setup` fast mode first. - `accounts/.md` if it exists. This is an update, not a rebuild. ## Step 3: Score FIT (should we pursue?) For each ICP dimension in `gtm-context.md`, score 1 (inside band), 0 (outside), or unobserved, using ledger FIT rows, Rep Read `F+`/`F-` lines (source: rep-recorded), attendee domains, and anything already in the Account Context. ``` Fit Score = 10 x sum(weight x score) / sum(weights of observed dimensions) ``` - A gate dimension observed and failed: bucket is Deprioritize, whatever else is true. - A gate dimension unobserved: ask the user once ("Headcount and region for ?"). If still unknown, FIT cannot be scored; say which field is missing. Never rank it with an asterisk. - Round to one decimal before comparing to the High FIT cutoff. ## Step 4: PAIN (do they have a problem we solve?) List PAIN rows from the ledger: | Quote (verbatim) | Speaker, title | Meeting, time | Confidence | - Verified: named buyer, verbatim, timestamp. - Supported: unattributed speaker, or a rep-recorded quote not found verbatim. - A Granola summary line, a paraphrase, or a rep's `P:` without quotes is not PAIN. Put it under "Pain hypotheses (unverified)". PAIN status for the record: Verified, Supported only, or none. ## Step 5: MOMENT (why now?) Map ledger PAIN, MOMENT, COMPETITOR, IMPACT, and FIT rows plus Rep Read `M:` lines to the signal library in `gtm-context.md`. A Verified or Supported PAIN quote fires the pain-quote signal. Competitor dissatisfaction fires only on a buyer statement of dissatisfaction with a current or recently evaluated vendor; a failed past project is a risk, not this signal. "They were fine" is neutral. Each signal type counts once per account. Only dated signals inside the MOMENT window count. A call statement is dated by the call. | Signal | Points | Evidence | Date | Confidence | MOMENT = sum of points. Show how many points rest on Inferred or Unknown evidence. ## Step 6: CONFIDENCE (how sure are we?) Two fields, side by side. Neither overwrites the other. | Field | Value | Source | |---|---|---| | Rep Confidence | C1 to C5 + the rep's reason | Granola typed notes, set during the call | | Evidence Confidence | High, Medium, Low (compare to rep: C4 to C5 = High, C3 = Medium, C1 to C2 = Low) | High: PAIN Verified and under 20% of MOMENT points Inferred. Medium: PAIN Supported, or 20 to 50% Inferred. Low: no PAIN, or over 50% Inferred | If they differ by more than one step (for example C5 and Low), write one line on the gap and the question that would settle it. If the rep did not type a C, write `Rep Confidence: not captured` and say so. Never estimate it. ## Step 7: Bucket (first match wins) | Bucket | Rule | SLA | |---|---|---| | Deprioritize | Fit below the High FIT cutoff, or a failed gate | remove from working list | | Action, high | High FIT, PAIN Verified, MOMENT 15+ | same business day | | Action, standard | High FIT, PAIN Verified, MOMENT 10 to 14 | within 48 hours | | Research | High FIT, MOMENT 10+, no Verified PAIN | find the pain, then reclassify | | Monitor | High FIT, MOMENT under 10 | nurture, watch for MOMENT | PAIN Supported (not Verified) keeps an account out of Action. The next step becomes confirming the pain in the buyer's words. ## Step 8: Judgment fields - **Hypothesis**: why this account should care, which motion, who is champion and who is economic buyer (match to personas). - **Why we might be wrong**: at least two concrete reasons. Start with the rep's `D:` lines. Add evidence-based risks: incumbent, no economic buyer access, budget timing, a signal that could be diligence instead of intent. - **Next step**: exactly one. Owner, action, date, and the SLA from the bucket. The SLA applies to our first action (recap, business case); a date the buyer agreed to always wins over the SLA. Prefer a COMMITMENT the buyer said out loud. If none exists, the next step is to get one. - **Open questions**: from ledger Gaps and Rep Read `?:` lines. For Action buckets only, add a message draft in Signal, Pain, Consequence, Value, Proof, Action using only Verified and Supported evidence. Value and Proof come from `gtm-context.md` proof points or stay as marked gaps. One ask. Labeled "for human review, not sent". ## Step 9: Write `accounts/.md` ```markdown # Account Context: Updated: | Last source: Granola "" | Owner: ## Snapshot | Bucket | Fit | PAIN | MOMENT (Inferred share) | Rep Confidence | Evidence Confidence | Next step | ## FIT | Dimension | Value | In band | Weight | Source | ## PAIN (verbatim only) ## Pain hypotheses (unverified) ## MOMENT ## CONFIDENCE ## Stakeholders | Name, title | Role | Stance | Evidence | ## Hypothesis ## Why we might be wrong ## Next step ## Open questions ## Message draft (Action only, for human review, not sent) ## Sources Meetings, dates, ledger paths. ## Change log | Date | What changed | Why (evidence) | ``` On update: change only fields with new evidence, keep prior quotes, add a change log row for every changed field (for example "Bucket Research to Action, high: VP Ops quoted pain 14:02 on 10/28 call"). Never delete history. ## Rules - No quote, no PAIN. - Scores are arithmetic, done the same way every time. Judgment writes hypotheses, risks, and drafts, never the scores. - The rep's C is carried in as typed. AI may disagree in its own field. - Inferred evidence never appears in a message draft. - Never write to a CRM, enroll anyone, or send anything.