Update to Marketing Compass

{
  "description": "Diagnose and design B2B growth across ICP and demand triggers, contact and recall, first meetings, problem resolution, comparison, buying committees, internal approval, procurement, implementation, value realization, and continuing relationships. Use when a user asks why B2B leads, meetings, opportunities, proposals, or wins are not growing; how to improve discovery or first sales meetings; why deals stall; how to follow up content downloads; how to create ROI, comparison, approval, or internal-selling materials; or how to separate automation from human intervention.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 457
    },
    {
      "relative_path": "assets/icon.svg",
      "size_in_bytes": 561
    },
    {
      "relative_path": "references/btob-structure.md",
      "size_in_bytes": 2962
    },
    {
      "relative_path": "references/meeting-and-deal-design.md",
      "size_in_bytes": 3271
    },
    {
      "relative_path": "references/output-contract.md",
      "size_in_bytes": 2418
    }
  ],
  "name": "design-btob-growth",
  "skill_md_contents": "---\nname: design-btob-growth\ndescription: \"Diagnose and design B2B growth across ICP and demand triggers, contact and recall, first meetings, problem resolution, comparison, buying committees, internal approval, procurement, implementation, value realization, and continuing relationships. Use when a user asks why B2B leads, meetings, opportunities, proposals, or wins are not growing; how to improve discovery or first sales meetings; why deals stall; how to follow up content downloads; how to create ROI, comparison, approval, or internal-selling materials; or how to separate automation from human intervention.\"\n---\n\n# Design B2B Growth\n\nTreat B2B growth as a multi-person decision and implementation system, not a lead-volume funnel. Diagnose how the customer's organization decides, explains, funds, approves, adopts, and realizes value.\n\nRead [references/btob-structure.md](references/btob-structure.md) for every substantive diagnosis. Read [references/meeting-and-deal-design.md](references/meeting-and-deal-design.md) when designing meetings, reviving stalled deals, or creating internal-selling assets. Read [references/output-contract.md](references/output-contract.md) before returning a complete design.\n\n## Establish the commercial decision\n\nIdentify:\n\n- Who on the seller side must decide what and by when\n- The product, contract form, sales cycle, and implementation burden\n- The target account and excluded account conditions\n- The customer's need event or decision trigger\n- The current stage and observed stop point\n- The acceptable acquisition cost, sales capacity, and delivery capacity\n- What evidence exists beyond lead or activity counts\n\nIf the target account, need trigger, or value realization is undefined, do not begin by scripting outreach or automating nurture. Ask at most three questions that can change the diagnosis, then continue provisionally if possible.\n\n## Map the B2B decision system\n\nUse:\n\n```text\nDemand-bearing account / ICP\n  → contact and recall\n  → problem resolution, comparison, and sales value\n  → internal approval and consensus\n  → procurement and implementation\n  → value realization\n  → continuing relationship\n```\n\nFor each stage, separate:\n\n- Confirmed facts\n- Seller interpretation\n- Buyer-side hypothesis\n- Unknowns\n- Observable signal and missing evidence\n\nSelect one primary bottleneck. Do not treat all stages as equal priorities.\n\n## Define ICP and demand trigger\n\nSpecify ICP through conditions that affect value and buying ability:\n\n- Problem and use case\n- Need event or change trigger\n- Operating scale and economic impact\n- Current workaround and dissatisfaction\n- Decision authority and budget path\n- Implementation readiness and constraints\n- Timing and urgency\n- Exclusion conditions\n\nDo not define ICP only by industry, company size, or job title. Distinguish an account that fits the product from an account that is ready to decide now.\n\n## Map the buying committee\n\nIdentify roles rather than assuming one buyer:\n\n- Problem owner\n- User or operator\n- Champion\n- Economic buyer\n- Technical, legal, security, procurement, or finance reviewer\n- Executive sponsor\n- Blocker or status-quo beneficiary\n\nFor each relevant role, record success criteria, perceived risk, proof required, approval power, and the language they need to explain the decision internally.\n\nDo not mistake a friendly contact for decision authority or consensus.\n\n## Diagnose the stop structure\n\nClassify the primary stop point:\n\n- No real need or wrong ICP\n- Need exists but is not articulated or urgent\n- Contact exists but recall or trust is weak\n- Problem is understood but the proposed value is generic\n- Comparison criteria are missing or unfavorable\n- Economic case or budget path is absent\n- Internal consensus or approval format is missing\n- Procurement, security, legal, or implementation risk blocks progress\n- Expected value is unclear after purchase\n- The next step has no owner, date, or deliverable\n\nDo not explain a stalled deal as buyer hesitation alone. Prefer the structural condition that prevents the next commitment.\n\n## Redesign the first meeting\n\nUse the first meeting to jointly increase problem resolution and create language that can travel inside the customer's organization.\n\nCover:\n\n1. Why the issue matters now\n2. Current process, workaround, and cost of inaction\n3. Stakeholders and internal decision route\n4. Desired post-adoption change\n5. Evaluation and comparison criteria\n6. Risks and proof required\n7. The smallest credible next step\n\nTranslate features into use, operational change, business effect, and internal explanation. Limit company introduction to what establishes relevance and trust.\n\n## Create internal-selling assets\n\nDesign only assets that remove a diagnosed blocker:\n\n- Problem and current-state summary in buyer language\n- Before/after operating picture\n- Comparison table with decision criteria\n- ROI or economic-case assumptions with ranges\n- Risk, security, legal, procurement, and implementation answers\n- Stakeholder-specific one-page summaries\n- Approval memo or executive brief\n- Implementation plan and responsibility map\n- Proof, case, reference, or pilot design\n\nDo not fabricate ROI or proof. Label assumptions, source, owner, and validation need.\n\n## Handle content downloads and nurture\n\nTreat a download as a weak signal unless additional behavior or context raises confidence. Classify the next action by temperature:\n\n- Immediate active evaluation\n- Recognized problem, timing unknown\n- Future demand or internal reference\n- General learning or irrelevant interest\n\nMake content function as a quiet seed and proxy presentation: memorable framing, post-adoption change, comparison logic, expected questions, and material the reader can reuse internally.\n\nDo not convert every download into immediate phone outreach. Use progressive permission and behavior appropriate to the signal strength.\n\n## Separate automation and human intervention\n\nAutomate repeatable timing, routing, reminders, content delivery, and known friction. Use people for:\n\n- Ambiguous problem definition\n- Stakeholder conflict\n- Economic and operational tradeoffs\n- New objections or political risk\n- Approval language and mutual commitments\n\nDo not use automation to simulate relationship or pressure accounts without demand.\n\n## Define progression and evidence\n\nFor each consequential stage, define:\n\n```text\nEntry condition\nExit condition\nBuyer commitment\nSeller deliverable\nDesired Signal\nCounter-signal\nGuardrail\nReview point\nAction if crossed\n```\n\nPrefer buyer commitments and decision evidence over seller activities. An email sent, meeting held, proposal delivered, or content opened is not stage progression by itself.\n\n## Return a B2B growth design\n\nUse the compact or full structure in [references/output-contract.md](references/output-contract.md). Include:\n\n- ICP and exclusion criteria\n- Demand trigger\n- Buying committee and approval route\n- Primary stop structure\n- Meeting or deal intervention\n- Missing internal-selling asset\n- Next mutual commitment\n- Automation and human-intervention split\n- Signal, counter-signal, guardrail, and review point\n- What not to do\n\n## Guardrails\n\n- Do not optimize lead quantity before confirming ICP, demand, and value.\n- Do not treat content downloads or opens as buying intent.\n- Do not confuse seller activity with buyer progress.\n- Do not force one contact to carry an organization-wide decision unsupported.\n- Do not invent ROI, urgency, authority, or consensus.\n- Do not respond to structural deal blockage with repeated closing alone.\n- Do not promise implementation or value the delivery organization cannot support.\n- Do not automate contact when human judgment or explicit permission is required.\n- Do not present Marketing Compass classifications as universal industry terminology.\n"
}