← ZoomInfoCONTENT HISTORY

Update to ZoomInfo

Snapshot Sep 30, 2026 · 22:44 UTC · version 6.1.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "name": "personalize-email",
  "description": "Generate 1-3 personalized email variants for a single prospect. The composition bar adapts to the use case — cold_outbound demands a signal → pain → positioning chain; follow-ups / recaps / renewals lean on prior context and next-step framing. Supports cold_outbound, discovery_follow_up, demo_recap, re_engagement, renewal, expansion, objection_handling. Returns subject lines and mobile-readable bodies with a rationale chain. Use for sales prospecting, lead generation, account-based selling, buyer-intent-driven outreach, B2B prospecting. Triggers on phrases like \"write a cold email\", \"personalize an email\", \"draft outreach\", \"follow up on this prospect\", \"email this prospect\", \"outbound to X\", \"send a chaser\".",
  "included_files": [],
  "skill_md_contents": "---\nname: personalize-email\ndescription: Generate 1-3 personalized email variants for a single prospect. The composition bar adapts to the use case — cold_outbound demands a signal → pain → positioning chain; follow-ups / recaps / renewals lean on prior context and next-step framing. Supports cold_outbound, discovery_follow_up, demo_recap, re_engagement, renewal, expansion, objection_handling. Returns subject lines and mobile-readable bodies with a rationale chain. Use for sales prospecting, lead generation, account-based selling, buyer-intent-driven outreach, B2B prospecting. Triggers on phrases like \"write a cold email\", \"personalize an email\", \"draft outreach\", \"follow up on this prospect\", \"email this prospect\", \"outbound to X\", \"send a chaser\".\n---\n\n# Personalize Email\n\nGenerate personalized email variants. Calls `get_gtm_context(detailed: true)` unconditionally, resolves the prospect, runs a relationship-context pre-flight, pulls signals + CRM context, and composes 1-3 variants tuned to the chosen use case. Iteratively refinable.\n\n## The bar — adapts by use case\n\nThe composition bar depends on what the email is trying to do. Don't force a cold-outbound frame onto a follow-up.\n\n| Use case | Anchor for the variant | Pain-bridge required? |\n|---|---|---|\n| `cold_outbound` | **Signal → pain → positioning chain** (specific, recent, verifiable signal; concrete inferred pain; GTM-context value prop) | **Yes — mandatory** |\n| `re_engagement` | Fresh new signal since the last contact → reconnection frame | Yes (lightweight — the signal IS the reason to reach back) |\n| `discovery_follow_up` | Prior conversation reference → next-step framing | No (the prior touchpoint replaces the pain bridge) |\n| `demo_recap` | Recap of what was shown / heard → concrete next step | No |\n| `renewal` | Outcome recap → renewal moment + stakeholder ask | No (anchor is the contract, not a pain) |\n| `expansion` | Existing outcome → adjacent need / persona | Pain-bridge ON the adjacent need, not the existing relationship |\n| `objection_handling` | Acknowledge stated objection → reframe | No (the objection IS the anchor) |\n| `chaser` (treat as a `re_engagement` variant) | One new fact or framing since the last send → \"still relevant?\" | No |\n\nUniversal — every variant: specific to *this* prospect (no template feel); concrete next action; honest about state; ≤ use-case length cap.\n\nThe rule in one line: **never default to \"let me find a pain\" when the use case calls for \"what happens next.\"**\n\n## Always-on context: `get_gtm_context`\n\nCall `get_gtm_context(detailed: true)` first. Parse offerings into:\n\n```\noffering_profile = { offering, pain_points[], value_props[], proof_bank[], cta_ladder[] }\n```\n\nAnchor on **one** `offering_profile`. Pick **one** `value_prop`. Never invent stats or customer names — only what GTM context / proof_bank provides.\n\n## Input\n\n- **Prospect identifier (required)** — ZI person ID / email / name+company / name+domain.\n- **Use case (default `cold_outbound`)** — drives length, framework, CTA, and bar (see above).\n- **Outreach context (recommended)** — natural-language goal (\"competitive displacement against [vendor]\", \"follow up on last week's pricing conversation\").\n- **Prior touchpoint summary (recommended for follow-ups / recaps / chasers)** — what happened last + named participants + open thread. Without it, the skill falls back to `account_research` + `contact_research` to reconstruct.\n- **Sender info (optional)** — name, title, email, phone, signoff. Otherwise omit signature.\n- **User-supplied template/content (optional)** — wins over everything below. Use as skeleton; fill placeholders only.\n- **Variant count (optional)** — 1 / 2 / 3. Default: governed by persona-fit discipline.\n- **Preferred angle (optional)** — `curiosity` / `value-frame` / `urgency`.\n- **Recipient email** — required for sending. Refuse if unresolvable.\n\n## Use-case routing\n\n| Use case | Length | Framework | CTA style |\n|---|---|---|---|\n| `cold_outbound` | 50–80 | AIDA or Becc Holland 4-line | Lowest-friction tease |\n| `discovery_follow_up` | up to 120 | PAS (pain known) | 15–20 min fit check |\n| `demo_recap` | 80–120 | Recap → next-step | Concrete next-step proposal |\n| `re_engagement` / `chaser` | 50–80 | Curiosity / new-signal hook | One-line ask |\n| `renewal` | 80–120 | Outcome-recap → renewal step | Tied to contract step |\n| `expansion` | 80–120 | Outcome-recap → adjacent need | Fit check on adjacency |\n| `objection_handling` | up to 120 | Acknowledge → reframe | Direct one-question response |\n\nFrameworks: **AIDA** (cold) · **PAS** (pain known) · **Challenger** (provocative insight) · **Becc Holland 4-line** (Premise / Hook / CTA / Push-Pull — cold + re-engagement).\n\n## Signal → pain mapping (cold-outbound + re-engagement)\n\nUsed when the use case requires a signal → pain bridge. For follow-ups / recaps / renewals, the bridge is the prior touchpoint or contract moment, not a new pain.\n\n| Signal | Recency | Implied pains | Buying window |\n|---|---|---|---|\n| **M&A — acquirer** | 90d | Integration complexity, redundant tooling, vendor consolidation, IT security review | 3–9mo post-close |\n| **M&A — acquiree** | 90d | Loss of autonomy, vendor contract review, rip-and-replace risk | 0–6mo post-close |\n| **New CEO / C-suite hire** | 30d | Strategy reset, 100-day plan, vendor relationship reset, budget reallocation | 60–180d |\n| **Funding round** | 90d | Enterprise-grade tool need, hiring acceleration, scaling pains. A: replace founder tools · B: process formalization · C+: enterprise readiness | 3–6mo |\n| **Hiring plans / surge** | 30d | Onboarding load, tooling gaps revealed by scale | 0–6mo |\n| **Layoffs / restructuring** | 60d | Cost pressure, consolidation, automation appeal. Sensitivity > urgency | 6–12mo |\n| **Product launch** | 90d | GTM readiness, sales/marketing alignment, enablement gaps | 0–6mo |\n| **Earnings / financial results** | 30d | Public commitments → execution pressure | 30–90d |\n| **Intent topic spike** | 14d | Active research; score 80+ + audience A/B = warm | 0–60d |\n| **Partnership announcement** | 60d | Co-sell pressure, competitive disruption to incumbent vendors | 3–6mo |\n| **Pain Point scoop** | 90d | ZI-curated pain — already the bridge | 0–90d |\n\nWhen multiple signals exist, choose by **(recency × buyer-relevance × stage-alignment)**. Recency weighted heavily — a 14-day signal beats a 60-day one.\n\n## Personalization ladder — use **exactly one**, never stack\n\n| Tier | What | When |\n|---|---|---|\n| **P0** | Neutral trigger (role + market trend) | Last-resort fallback |\n| **P1** | Role/segment insight (ICP-level) | When company-specific signal is thin |\n| **P2** | Company-specific event (news / product / metric) | Default for cold_outbound |\n| **P3** | Individual-specific (quote, prior interaction, CRM note) | Strongest; re_engagement / discovery_follow_up |\n| **Tier 0 override** | User-supplied template content | Always wins; fill placeholders only |\n\n## Proof-source hierarchy — use **exactly one**, in order\n\n1. Direct prior result with this account/contact (from `contact_research` / CRM).\n2. Peer / segment outcome (from `proof_bank`).\n3. Product evidence without metrics (capability → expected outcome).\n4. Fallback: generic capability statement.\n\n**Never invent stats or customer names.** If proof_bank is empty, drop to tier 3 or 4 — never fabricate.\n\n## Tone calibration\n\nWhen tone isn't supplied, infer by seat:\n- **Executives** (C/EVP/SVP) — outcome-first, concise, numeric proof, direct CTA.\n- **Directors / Managers** — problem → approach → outcome → CTA.\n- **Practitioners / ICs** — workflow friction → concrete benefit → quick next step.\n\nUniversal: ~Grade 8 reading level. Slightly casual; slightly unsure phrasing (\"might be off-base, but…\").\n\n## Anti-patterns — fail-fast checklist\n\nIf any fires, regenerate.\n\n1. **Generic congratulations.** Banned openers: \"Congrats on\", \"Saw the news about your\", \"Hope this finds you well\", \"Loved your recent post about\" (without naming + thesis).\n2. **\"Just checking in\" / \"circling back\".** Dead. Use a signal or don't follow up.\n3. **Self-introduction-first.** \"We're a leading provider of…\" / \"Hi, I'm…\" / \"We help [persona]…\" — lead with the prospect.\n4. **\"I noticed...\" crutch.** Stating a public fact without doing something with it.\n5. **Signal without payoff.** Naming a signal then jumping to product pitch — skips the bridge.\n6. **Forcing a pain bridge on a non-cold use case.** Follow-ups, recaps, renewals don't need a freshly invented pain. The anchor is the prior touchpoint or contract moment.\n7. **Generic praise.** \"Love what you're building\" / \"Big fan.\" Must tie to a specific achievement.\n8. **Meeting ask as primary CTA on cold.** Tanks reply rate. Use a tease.\n9. **Length > use-case cap.** Emails over 150 words are 42% less likely to get a reply.\n10. **AI-generated feel.** Hedging, em-dashes everywhere, abstract claims with no verifiable detail.\n11. **Padded subject lines.** Long, punctuation, numbers, first-names, brackets. Keep to 2–6 lowercase words.\n12. **Stale signals.** 90d most categories / 30d hires-exec moves / 14d intent.\n13. **Multiple CTAs.** Exactly one per email.\n14. **Bullets in emails <100 words.** Fragments the mobile read.\n15. **Invented stats / customer names.** Hard rule.\n16. **Personalization stacking.** One ladder tier only.\n\n## Workflow\n\n### 1. Pull GTM context (always)\n`get_gtm_context(detailed: true)` → `offering_profile`. If empty, flag.\n\n### 2. Honor input data first\n**INPUT DATA FIRST, TOOLS LAST.** If user supplied template / sender info / recipient email / prior touchpoint summary / outreach context, use directly. Only call tools for missing data.\n\n### 3. Resolve the prospect\n- ZI person ID → use directly.\n- Email → `enrich_contacts(email)`.\n- Name + company → `enrich_contacts(firstName/lastName/companyName)`; fall back to `search_contacts`.\n- Resolve the prospect's company ID.\n- **Recipient email required** — refuse if unresolvable.\n- **Multi-recipient rule** — use only the first; never reference others.\n\n**Stale-record handling.** If `lastUpdatedDate` >12mo OR current `companyName` doesn't match user-named company: use company-level signals only, skip `contact_research`, surface caveat, suggest verifying role.\n\n### 3.5. Relationship-context pre-flight (mandatory)\n\nTag the resolved company. **Wait for user confirmation when the label is anything other than `prospect`.**\n\n- **`competitor`** — matches `get_gtm_context.competitors`. **Hard-warn.** Surface and ask: reroute to partnership/displacement-defense, acknowledge intentional targeting, or refuse.\n- **`customer`** — in `get_gtm_context.customers` / `proof_bank`. Suggest switching use_case to `expansion` or `renewal`.\n- **`partner`** — in `get_gtm_context.partners` / `integration_partners`. Surface co-sell / integration angle.\n- **`prospect`** — default; proceed.\n\n**Pipeline-account check (specialization).** Run `account_research(zoominfoCompanyId, query=\"Open opportunities, active deal stages, named champions, last activity date\")`. Open opp → `pipeline_account` → suggest `discovery_follow_up` / `expansion`. Renewal date within 90d → suggest `renewal`. Active engagement → suggest `discovery_follow_up`.\n\n### 4. Pull signals in parallel\n\nPull only what the use case needs:\n\n- **Always:** `enrich_companies` (companyId, fields: description, industries, employeeCount, revenue, ...).\n- **Cold / re-engagement / chaser:** `enrich_company_signals` (`signalTypes: [\"NEWS\", \"SCOOP\", \"INTENT\"]`) — returns recent news, scoops, and intent in one call. Rank and filter in step 5 (the news category, e.g. funding / M&A / product / leadership, is carried on each returned signal).\n- **Discovery follow-up / demo recap / renewal / expansion / objection_handling:** primarily `contact_research` + `account_research` for prior-touchpoint reconstruction; news/scoops only as supporting context.\n\nAlways run `contact_research` for the prospect (unless record is stale), with a query tuned to the use case.\n\n`enrich_company_signals` resolves intent topics server-side, so there is no need to pre-resolve topics via `lookup` — request `INTENT` in `signalTypes` and triage the returned topics in step 5.\n\n### 5. Pick the anchor\n\n- **Cold / re-engagement:** rank signals by `(recency × buyer-relevance × stage-alignment)`. Recency: 0-14d = 1.0 · 14-30d = 0.7 · 30-60d = 0.4 · 60-90d = 0.2 · >90d = drop. 80-90d signals carry an \"on the cusp\" caveat. Buyer-relevance: CFO ↔ funding/earnings/M&A · CRO ↔ hiring/product launch · CTO ↔ tech-stack/product · CEO ↔ all. Pick top + record runner-up.\n- **Follow-up / recap / renewal / expansion / objection:** the anchor is the prior touchpoint (or contract moment, or named objection). Pull it from prior-touchpoint summary first, then `contact_research` / `account_research`. If both are silent and no touchpoint can be reconstructed → refuse and surface the gap.\n\n**Refuse-to-produce gate (cold / re-engagement only).** Refuse when **two or more** hold:\n1. **Signal layer thin** — no company-level signal ≤60d.\n2. **`contact_research` GTM-irrelevant** — nothing returned, OR what was returned maps to no value prop.\n3. **Positioning anchor weak** — no clean value prop in GTM context maps to the inferred pain.\n\nAll three → refuse outright. One → proceed but flag. Route refusals to warming channels or a different prospect.\n\n### 6. Bridge to the anchor (use-case-conditional)\n\n- **Cold / re-engagement:** use the signal → pain mapping to infer the pain: *\"For [persona] at a company that just [signal], the dominant unsolved problem in the next 90 days is likely [specific pain] because [reason].\"* Iterate if generic.\n- **Other use cases:** the anchor is the prior touchpoint / contract / objection. The body's job is to acknowledge, surface the next step, and remove friction — not to introduce a freshly imagined pain.\n\n### 7. Anchor positioning in GTM context\nMap the inferred pain (cold/re-engagement) OR the prior touchpoint (other use cases) to one concrete claim from `offering_profile.value_props` — never the elevator pitch. Pick one proof source per the hierarchy. If no value prop maps, flag and offer to reroute.\n\n### 8. Compose variants\n\n**Persona-fit discipline:**\n- **Strong fit** → 3 variants.\n- **Moderate fit** → 2 variants.\n- **Stretch fit** → 1 variant with strong opt-out CTA. Don't force volume.\n\n**Variant angles:**\n- **A — Curiosity.** Lead with observation / question; tease.\n- **B — Value-frame.** Concrete claim or stat tied to the anchor (pain for cold; outcome for follow-up; objection-reframe for objection).\n- **C — Urgency / window.** Timing implication. Cold: only when signal ≤30d and buying window tight. Renewal/expansion: tied to contract date.\n\nLength per use case. Apply chosen framework. Tone: slightly casual, slightly unsure.\n\n**Exactly one** each: personalization tier · anchor · value prop · proof source · CTA.\n\n### 9. Subject lines\n\n2–6 lowercase words. No punctuation / numbers / first-names / brackets. Three patterns — generate then pick strongest:\n1. **Pain → Outcome** (cold). \"pipeline gaps shorten replies\"\n2. **Trigger → Value** (cold / re-engagement). \"post-close stacks\"\n3. **Recap → Next step** (follow-up / recap / renewal). \"monday's pricing thread\"\n4. **Peer / Proof cue** (any). \"how X improved reply rates\"\n\n### 10. Signature\n\nIf `sender_info` available, emit with **two trailing spaces per line** for Markdown line breaks:\n\n```\nBest,␠␠\nJordan Smith␠␠\nSenior Account Executive␠␠\njordan.smith@example.com\n```\n\nIf no sender info → omit signature. Don't invent.\n\n### 11. Self-check before output\n\n- ☑ Word count within use-case cap.\n- ☑ Subject 2–6 lowercase words.\n- ☑ Opens with personalized hook (no generic greeting).\n- ☑ Cold / re-engagement: signal → pain → positioning chain present and specific. Other use cases: prior-touchpoint anchor present.\n- ☑ Exactly one each: ladder tier · anchor · value prop · proof source · CTA.\n- ☑ ~Grade 8; mobile-readable.\n- ☑ No clichés, jargon, filler, invented stats.\n- ☑ Recipient email present.\n- ☑ Signature: two trailing spaces per line OR omitted entirely.\n- ☑ All 16 anti-patterns cleared (including #6 — pain not forced on non-cold use cases).\n\n### 12. Rubric (final scoring)\n\nScore 0–2 per dimension. Bar: ≥8/10. Drop or regenerate failures.\n\n1. **Specificity** — verifiable fact about *this* prospect.\n2. **Anchor strength** — for cold: pain bridge; for follow-up: prior-touchpoint reference; for renewal: contract moment.\n3. **Positioning** — specific GTM-context claim.\n4. **Reciprocity** — gives insight / framing / opt-out before asking.\n5. **Send-worthiness** — would a senior seller press send?\n\n### 13. Present + offer iteration\n\n1. Accept variant.\n2. Different signal (runner-up) — cold / re-engagement.\n3. Different persona at same company.\n4. Tighter anchor.\n5. Switch angle.\n6. Adjust tone (casual / formal / direct).\n7. Switch use case.\n\nIterate from step 6. Track variant evolution. Terminate on accept or pivot.\n\n## Fallback rules\n\n- **Contact lookup fails** → `Hi [First Name]` greeting; continue.\n- **No public/CRM history** → skip `contact_research`; company signals only.\n- **Company sparse** → role-based personalization (drop to P1).\n- **Sender info missing** → omit signature.\n- **GTM context fails** → generic capability statement (proof tier 4); surface gap.\n- **No signal passes recency floor (cold)** → refuse; route to warming.\n- **No prior touchpoint reconstructable (follow-up)** → refuse; ask the user for a summary.\n\nNever block on a single missing tool (recipient email is the hard gate). Never invent data.\n\n## Output Format\n\n### TL;DR — Email for [Prospect Name], [Title] at [Company] · Pass [N]\n\n*Use case: [restate]. Framework: [AIDA / PAS / Challenger / Becc Holland].*\n\n**Anchor.** [For cold: signal + age + one-liner. For follow-up: prior touchpoint summary. For renewal: contract moment. For objection: stated objection.]\n**Bridge.** [For cold: inferred pain in one sentence. For others: omit OR brief next-step framing.]\n**Positioning.** [Specific GTM-context value prop.] *Proof source:* [tier 1/2/3/4].\n\n---\n\n### Variant A — [angle]\n**Subject:** [2–6 lowercase words]\n[Body within use-case cap.]\n\n### Variant B — [angle] *(if persona fit ≥ moderate)*\n**Subject:** [2–6 lowercase words]\n[Body.]\n\n### Variant C — [angle] *(if persona fit strong)*\n**Subject:** [2–6 lowercase words]\n[Body.]\n\n---\n\n### Rationale\n\n| | |\n|---|---|\n| Use case | [label] |\n| Anchor | [signal+age / touchpoint / contract / objection] |\n| Personalization tier | [P0–P3] |\n| Pain (cold/re-engagement only) | [pain] |\n| Value prop | [claim] |\n| Proof source | [tier 1–4] |\n| Framework | [AIDA / PAS / Challenger / Becc Holland] |\n| Rubric | A: [X/10] · B: [X/10] · C: [X/10] |\n\n### Iteration options\n\n1. Accept [variant] → hand off to sequencer.\n2. Different signal — anchor on [runner-up].\n3. Different persona at the same company.\n4. Tighter anchor.\n5. Switch angle.\n6. Casual / formal / direct.\n7. Switch use case.\n\n### Caveats (when relevant)\n\n- **Relationship flag** — if `competitor` / `customer` / `partner` / `pipeline_account`, variants assume user confirmed override.\n- **Thin signal** — variants on weak base; warm on another channel first.\n- **Empty signal (cold)** — 0 variants; route to warming.\n- **Stretch fit** — 1 variant only.\n- **Stale-signal cliff** (60–90d) — urgency angle unavailable.\n- **Edge-of-recency** (80–90d) — on the cusp.\n- **Stale prospect record** — verify role before sending.\n- **No prior touchpoint** (follow-up) — refused; ask for a summary.\n- **GTM-context gap** — positioning generic; update GTM context.\n- **Sender info missing** — signature omitted.\n\n### Chain Targets\n\n- Hand to a sequencer (e.g., Outreach, Salesloft).\n- Multi-step sequence → run once per step with different signals + use cases.\n- Batch personalization → `personalize-at-scale` (future scope).\n- Different prospect at same company → re-run with new identifier.\n"
}

SHA-256: 057e18d294469cdeca62593cd5f810b48eae4f2f0b9777599e789c746a259dcd