twenty-lead-brief

1---2name: twenty-lead-brief3description: Turn a Twenty sales/discovery call into a partner-ready brief and record the lead in the CRM. Use whenever the user has a call recording, transcript, Fireflies link, or a lead folder and wants to qualify the deal, summarize the call, write a partner brief, or prep the partner handoff. Trigger even without the word "brief" - "summarize this call", "what did we learn from the X call", "qualify this lead", "scope this for a partner", "draft a design doc", or pointing at a transcript file all count. Produces a qualification summary, a partner brief, matching criteria, and an Opportunity in the partners workspace. Pass --full for inference mode.4trigger: /twenty-lead-brief5---6 7# twenty-lead-brief8 9First step of the lead path. Takes a raw call and produces everything the rest of the path10needs:11 12```13twenty-lead-brief  →  twenty-partner-shortlist  →  twenty-partner-intro14```15 16Four outputs, in order:17 181. A **qualification summary** printed in the conversation. You can stop here.192. A **partner brief** the partner reads to scope and quote.203. **`partner-match-criteria.md`**, the input to `twenty-partner-shortlist`.214. An **Opportunity** in the partners workspace, carrying the brief's URL.22 23Credentials, the `gql()` helper and every query live in `../_shared/partner-api.md`. Read it24rather than restating anything.25 26---27 28## Step 1 — Get the transcript29 30The user provides it: pasted text, a path (`.txt` / `.vtt` / `.srt`, a meetily folder or31`transcripts.json`), or a Fireflies link or ID.32 33- meetily `transcripts.json` is `{ "segments": [ { "text": … } ] }`: concatenate `text` in34  order.35- `.vtt` / `.srt`: drop cue numbers and timecodes.36- Fireflies: fetch the transcript detail (see the shared reference). Needs `FIREFLIES_API_KEY`.37 38**No transcript means stop and ask.** Never fabricate one, never proceed without one.39 40For a long transcript, read the whole thing before writing. Coverage is the point.41 42---43 44## Step 2 — The qualification summary45 46A **structured extraction against a fixed schema**, not a summary. A "summary that loses47nothing" is a contradiction; the schema is what prevents loss, because every dimension has a48slot and a gap is marked rather than silently dropped.49 50**Rules**51 52- Extract ONLY what is in the transcript. If a field isn't covered, write "Not discussed."53  A visible gap beats a confident fabrication: it is the signal to ask on the next call.54- Separate stated FACTS from your INFERENCES. Mark any inference "(inferred)". Downstream55  matching trusts the facts, so don't contaminate them with guesses.56- Preserve specifics verbatim: numbers, dates, names and roles, tool and CRM names, prices,57  budgets, exact requirements. Never round or paraphrase a number. Specifics are where the58  matching signal lives.59- Use the customer's own words for needs and objections. Quote pivotal lines.60- Don't smooth over a contradiction or a vagueness: note it. A flagged contradiction is more61  useful than a falsely tidy summary.62- With no speaker labels, infer from context who is Twenty and who is the prospect.63  Speech-to-text garbles names: flag an uncertain one "(uncertain)" and never invent one.64- Keep PART A tight: it is the one-pager the rest of the path runs on. Push anything not65  specific to this deal into PART B. State each fact once.66 67**Output (these exact headers)**68 69```70== PART A — DEAL ONE-PAGER ==71 721. ONE-LINE SUMMARY732. COMPANY — name, what they do, size/employees, HQ + countries of operation, industry743. PEOPLE ON THE CALL — name, role/title, side (Twenty vs prospect); infer roles if75   unlabeled and flag uncertain names764. CURRENT SITUATION — what CRM/tools they use today; specific pains775. WHY THEY'RE INTERESTED IN TWENTY786. WHAT THEY WANT — bulleted needs/requirements, verbatim where possible797. IMPLEMENTATION COMPLEXITY (for partner matching)80   - Deployment: cloud / self-host / both / unclear  (+ the evidence)81   - Data model: custom objects, multi-tenant, row-level security, migrations82   - Integrations / custom apps needed83   - Workflows / automation needs84   - Scale: number of seats/users85   - Region + language the partner would need to cover868. COMMERCIALS — budget or prices discussed, plan tier (Pro/Org/Enterprise), seat count,87   deal value, who pays889. TIMELINE & DECISION — key dates, decision-makers, urgency, decision process8910. OBJECTIONS / RISKS / FEARS — including anything that could kill the deal9011. ALTERNATIVES — competitors or other options they're weighing9112. DOES THIS DEAL NEED A PARTNER? — yes / no / maybe + why; and if yes, what kind92    (scope, region, language, seniority/tier)9313. NEXT STEPS / OPEN QUESTIONS / FOLLOW-UPS9414. PARTNER-FACING BRIEF — a 2-4 sentence narrative a partner can skim to decide yes/no,95    drawn only from PART A96 97== PART B — APPENDIX (not deal-specific) ==98 9915. PRODUCT / WEBSITE / GTM FEEDBACK — feedback on the product, pricing page, website100    wording, onboarding, or trial; capture even if off-topic for qualification10116. TERMINOLOGY / DOMAIN-LANGUAGE NOTES — words that mean different things to each side or102    carry domain-specific meaning (e.g. "partner", "donor", jargon)10317. KEY VERBATIM QUOTES — 3-8 direct quotes that capture intent, needs, or objections104```105 106Print it, then save it to the lead folder as `YYYY-MM-DD-<lead>-call-summary.md`.107 108**Stop here if the user only wanted the summary.** Ask before continuing to Step 3: a lead109that is clearly not partner-shaped (section 12 says no) does not need a partner brief.110 111---112 113## Step 3 — The partner brief114 115**The doctrine lives in `design-doc-doctrine.md` in this folder: what to produce, the116structure, the rules, the verification, the self-check. Read it and follow it.** The rest of117this section is only the mechanics.118 119Default output is a **zero-inference partner brief**. Pass `--full` for the inference-enabled120design doc. The doctrine defines both.121 1221. **Gather** — read every source material in full, not just the summary. Convert a `.docx`123   with `textutil -convert txt "<file>" -output /tmp/out.txt` on macOS.1242. **Extract, grounded** — facts vs inferences, per the doctrine.1253. **Draft** in the doctrine's section structure.1264. **Verify load-bearing claims live** — WebFetch against the doctrine's doc map before127   asserting any capability. Build the References appendix as you go.1285. **Reconcile discrepancies** — sources that disagree (call vs braindump, a name differing129   across sources) get flagged both ways, never silently resolved.1306. **Resolve ❓ with the operator** — after a full v1 draft, use AskUserQuestion for the131   unknowns a Twenty insider can answer. Leave customer-facing unknowns as ❓. **Running132   autonomously** (a subagent or batch run) means skipping the questions and leaving every133   unknown as ❓.1347. **Run the doctrine's self-check**, fix, then save as `YYYY-MM-DD-<lead>-partner-brief.md`135   (or `-design-doc.md` in `--full`).136 137---138 139## Step 4 — Publish the brief as a Google Doc140 141The partner gets a link, never an attachment: a Gmail compose URL cannot carry a file, and a142`.md` attachment is a poor read.143 1441. Open the shared Drive folder in Chrome:145 146```bash147open -a "Google Chrome" "https://drive.google.com/drive/folders/1ISDCplqLv6GrBQOOX7Fk4OK07LAK8BPd"148```149 1502. Tell the user: create the Doc there, paste the brief markdown, then paste the share URL151   back. Mention `Tools → Preferences → Enable Markdown` once, so the paste renders headings,152   bold and tables instead of showing raw `##`.153 1543. **Wait for the URL.** If the user skips it, carry on with Step 5 and leave `designDocUrl`155   empty. Say so, because `twenty-partner-intro` will then have no link to send.156 157The folder is shared `anyone with the link can view`, so a partner can open it without an158account. Do not call the Drive API: the connected account is personal, and any Doc it created159would land in the wrong Drive under the wrong owner.160 161---162 163## Step 5 — Write `partner-match-criteria.md`164 165Always, as a third file in the lead folder. This is the input `twenty-partner-shortlist`166reads.167 168- **Hard requirements** — a `Criterion | Why` table. Cover language and region, deployment169  type, data-model complexity signal, migration capability, engagement model (fixed vs170  retainer).171- **Strong preference** — bullets: domain familiarity, migration experience, willingness to172  scope for free, ability to work with non-technical end-users.173- **Nice to have** — bullets: industry-specific workflow experience, partner size fit.174- **Red flags** — bullets: anything that would disqualify a partner silently (language,175  hosting model, engagement type, technical depth).176- **Budget** — what the client said about money, verbatim, or "not stated". Most calls never177  state a ceiling, and that is itself the answer. `twenty-partner-shortlist` shows this next178  to each partner's rate; it never filters on it.179- **Matching notes** — 3 to 5 bullets: technical nuances, the prospect's sophistication180  level, migration unknowns, who the decision-makers are. Draw from Open questions and181  Implementation complexity.182 183---184 185## Step 6 — Record the Opportunity186 187**This step writes to production.** Search before creating, always.188 1891. **Search** for an existing Opportunity on the company name (see the shared reference). If190   one comes back, show it to the user and ask whether to update it or create a new one.191   Never create a silent duplicate.1922. **Resolve the company and the point of contact**: search first, create only on a miss.1933. **Create** the Opportunity:194 195| Field | Value |196|---|---|197| `name` | `<Company> <need in about three words>`, matching existing records: `TADA new CRM`, `Aranya CRM Migration`, `ECF PRO - Self-hosting multi-workspace` |198| `stage` | `NEW` |199| `need` | one line, from section 6 of the summary |200| `requirements` | the requirements text, from section 7 |201| `companyId`, `pointOfContactId` | resolved above |202| `designDocUrl` | `{ "primaryLinkUrl": "<the Doc URL>", "primaryLinkLabel": "Partner brief" }`, omitted if Step 4 produced no URL |203 204Do **not** set `isListed`: that belongs to the marketplace pull flow, which this path does205not use. Do **not** set `introSentAt` and do not create any Application:206`twenty-partner-intro` owns both.207 2084. **Verify** by reading the record back, then print its id and name.209 210---211 212## Output files213 214In the lead folder:215 216- `YYYY-MM-DD-<lead>-call-summary.md`217- `YYYY-MM-DD-<lead>-partner-brief.md` (or `-design-doc.md` in `--full`)218- `partner-match-criteria.md`219 220---221 222## Notes223 224- Keep `partner-match-criteria.md` current as you learn more about the lead. It feeds225  `twenty-partner-shortlist` and, eventually, in-product matching logic.226- Sections 7 and 12 of the summary are the matching axes: `Deployment → deploymentExpertise`,227  scope needs → `partnerScope`, region and language → partner region and languages, scale →228  capacity, the "needs a partner?" tier → `partnerTier`.229- Worked example: `partners-experience/TSF/2026-05-26-tsf-design-doc.md` shows the target230  coverage, flag discipline and verification appendix. It predates the current concision and231  formatting rules, so **follow the doctrine over the example** where they differ.232