Account Context Builder

• Source: Built by Jonathan Kvarfordt on the GTM AI OS. Supplied as a complete zip and served unchanged.
• Frameworks applied: Across many calls

It covers a job one of the eight revenue seats has to finish, and it states its process, decision rules, and output format clearly enough for an agent to follow.

1. 1.Copy the SKILL.md text below, or download the raw file.
2. 2.Create a folder named exactly account-context-builder in your agent's skills directory.
3. 3.Save the file inside that folder as SKILL.md.
4. 4.Ask the agent one of the trigger requests below.
5. 5.Check the output against what you already know before it leaves your desk.

• build the account record from this call
• score this account
• account context for <company>

---
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 <company>", "update the account after my call", "what's the next step on <account>", 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/<account>.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/<date>-<slug>/`.

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/<slug>.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 <account>?"). 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/<slug>.md`

```markdown
# Account Context: <Account>
Updated: <date> | Last source: Granola "<meeting title>" <date> | Owner: <rep>

## 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.

What does the Account Context Builder skill do?

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.

Where does the Account Context Builder skill come from?

Built by Jonathan Kvarfordt on the GTM AI OS. Supplied as a complete zip and served unchanged.. The source and included files are shown on this page and in the package download.

Why was the Account Context Builder skill chosen for this library?

It covers a job one of the eight revenue seats has to finish, and it states its process, decision rules, and output format clearly enough for an agent to follow.

When should the Account Context Builder skill not be used?

Use it only for the job named above. A skill applied outside its scope produces confident output on the wrong question.

How do I install the Account Context Builder SKILL.md file?

Download the file, create a folder named exactly account-context-builder inside your agent's skills directory, and save the file inside it as SKILL.md. The agent loads it when a request matches the description.