plan-deal-strategy

制定交易策略

上下文收集

每当此技能询问上下文时，优先使用 answers-ask-user-input 技能和 ask_user_input 工具，而不是 request_user_input 等其他工具；否则直接在对话中提问。

将当前交易的证据或明确提供的报价背景转化为切实可行的策略，以推进销售或规划初步销售流程。此技能负责交易地图、采购委员会、谈判立场、异议、推进顺序和行动计划；它不用于首次通话准备、数据优先的潜在客户开发或回写工作流。

通用技能说明

强制要求：如果当前上下文中尚未包含 plugins/sales/skills/index/SKILL.md## Cross-Skill Best Practices，请阅读并严格遵守。

关键依赖类别

以下类别对此工作流尤为重要；仅当其他来源能实质性改善策略时，才使用它们。

• [阻塞项] ~~CRM：用于确认权威的客户和商机身份、阶段、金额、预计成交日期、负责人、联系人及近期活动。如果上下文中没有足够可靠的交易事实，这会阻塞默认的当前交易策略流程。
• ~~会议记录：用于了解利益相关方的措辞、异议、承诺、决策、采购信号及通话连续性
• ~~电子邮件：用于了解面向客户的推进情况、审批、谈判、法务／采购往来及尚未答复的请求
• ~~内部消息：用于了解内部阻碍、负责人协调、升级路径及执行风险
• ~~知识与文件：用于查阅客户计划、共同执行计划、实施文档、风险日志及策略资料
• ~~日历：用于了解即将召开的决策会议、管理层会议、采购／法务里程碑及时间压力
• ~~销售情报：仅在交易信息已明确后，用于完善对利益相关方或公司的假设

对于 CRM 管理的交易事实，始终以 ~~CRM 为准。辅助来源可用于完善风险、利益相关方、时间安排和行动信息，但不能虚构或覆盖阶段、金额、负责人、预计成交日期或当前交易是否存在。

参考资料加载

SKILL.md 负责常规交易策略流程和输出内容。只有在额外细节确实重要时，才加载参考资料：

• 如需处理结构化输入、旧版别名、模式枚举、阶段提示、时间范围边界或种子证据规范化，请使用 references/request-schema.yaml。
• 当风险类型、严重程度、可能性、置信度、优先级或缓解措施字段存在歧义时，请使用 references/risk-rubric.md。

工作流指南

1. 确认资格并选择模式

• 仅在发现阶段之后，已有活跃客户、商机、续约、采购流程或足够详细的交易上下文时使用此技能。
• 收集足够证据，以识别当前交易进展，以及至少一个阻碍、利益相关方问题或后续行动需求。如果已有足够的锚点但证据有限，则应提供低置信度方案包，并明确指出信息缺口，而不是编造细节。
• 如果请求是首次通话准备，且几乎没有以往证据，并且已有会议锚点，则转交给 prepare-for-meeting；否则询问基本客户背景，并提供轻量的手动准备建议。
• 默认使用 Full Strategy Pack。如果用户只要求一项成果，则使用相应的部分模式，并将调查范围限定在该成果内。

2. 确定交易锚点

• 从用户提到的客户账户、商机、续约、计划、链接或笔记入手。
• 将 sfdc_account_id 视为 crm_account_id 的旧版别名。
• 如有可用数据，优先使用 ~~CRM，识别客户账户和最符合所提产品、解决方案、续约、利益相关者、时间安排及近期活动的商机。
• 如果用户要求制定交易策略，但未提供客户账户、商机、续约、计划、链接或笔记，则优先使用 ~~CRM 搜索并排序，通过 ask_user_input() 提供最多五个具体的当前商机候选项。对于“为我最合适的当前商机制定交易策略”这类笼统请求，不要假设目标；应提供由连接器支持的候选项，并在进行广泛信息补充或起草前请用户选择。
• 根据所选商机名称、产品或解决方案相关词语、活动标题和用户措辞，建立一个精简的别名集合。用它验证相关会议、邮件线程和文档，并排除同一客户账户下属于不同交易进程的材料。
• 如果仍有多个合理的商机候选项，最多读取三个来源，通过 ask_user_input() 提供最多五个具体候选项，然后在进行广泛信息补充前请用户选择。如果最终只有一个推断出的候选项，则在进行广泛信息补充或起草前，通过 ask_user_input() 请用户确认。
• 如果 CRM 不可用，但用户提供的证据已足够，则明确指出 CRM 数据缺口后继续。不要将同一客户账户下其他商机的证据视为所选交易进程的证明。

3. 按渠道收集证据

• 使用所选客户账户和交易进程别名，在 ~~Meeting Transcripts、~~Email、~~Internal Messaging、~~Knowledge & Files 和 ~~Calendar 中查找相关近期证据。
• 优先使用最窄的相关时间范围；除非用户指定其他时间范围，否则默认查看最近 90 天。
• 不要一开始就要求用户提供会议记录、邮件线程或文档链接；使用所选客户账户和交易进程别名来发现相关材料。
• 阅读足够的材料，以支持对当前交易进程、利益相关者立场、采购风险和后续行动的判断。如果首个同一客户账户下的材料属于其他交易进程，则在有可用结果时继续查看下一个有针对性的结果；否则跳过该材料、标注信息缺口，或请用户选择。
• 将每个渠道标记为可用、不可用、无内容、过时、存在冲突或仅由用户提供。核心策略获得足够支持后即停止；不要用间接替代信息追查不可用来源中的事实。

4. 制定策略

• 制定精简的交易概览：计划、目标成果、交易进程／时间线、正在推进的工作流、在有证据支持时会实质影响交易执行的近期客户账户或服务背景、阻碍因素和依赖项。
• 根据有证据支持的人员和角色，建立采购委员会。角色使用 economic_buyer、decision_maker、champion、influencer、blocker、procurement、legal、security 或 unknown；立场使用 supportive、neutral、skeptical、blocking 或 unknown；影响力使用 high、medium、low 或 unknown。对推断出的角色、立场或影响力标注 Inference:。
• 列出采购风险，包括严重程度、可能性、置信度、负责人或建议负责人、缓解措施、时间安排和来源。如果分类或优先级存在歧义，请加载 references/risk-rubric.md。
• 默认提出 5-7 项高价值行动。每项行动都需要负责人或建议负责人、截止日期或 TBD、预期成果、关联风险／利益相关者以及来源。

5. 将证据与推断分开

• 有实用来源链接时，请在文中引用；没有稳定链接时，才使用纯文本来源标签。
• 不要将会议加入链接、通用会议室链接或不透明的连接器 ID 作为证据链接。
• 如果证据相互冲突，应降低置信度并注明证据缺口，而不是强行得出结论。
• 只有在直接证实的情况下，才使用确切日期和已确认的客户方负责人。否则，使用相对时间、TBD 或 建议负责人：；当置信度较低或证据稀少时，避免给出精确到日的截止日期。
• 只有在交易已明确的基础上，公开或用户提供的市场背景确实有助于完善公司或利益相关方假设时，才使用这些信息。将其视为辅助背景，绝不能将其作为账户或交易事实的硬性依据或凌驾于事实之上。

后续步骤选项

首次输出后，从以下选项中提供最相关的后续步骤。明确建议一个过渡步骤，不要列出菜单。除非你非常确定其他选项更有用，否则只能从以下选项中建议：

• 将已排序的行动转化为共同执行计划或执行跟踪表。
• 围绕风险最高的决策准备下一次客户、合作伙伴或内部会议。
• 起草供审核的、针对特定利益相关方的电子邮件或 Slack 文案。
• 起草供审核的、可直接用于 CRM 的商机更新。
• 深入分析证据仍不足的某个障碍、利益相关方或采购风险。

应避免的后续步骤：

• 未经单独明确请求，不要发送消息、更新 CRM 或创建下游材料。

模式

• Full Strategy Pack — 默认模式；返回以下所有部分。
• Deal Map Only — 返回 Deal Snapshot、Deal Map、Evidence Gaps 和 Inference Notes。
• Buying Committee Only — 返回 Deal Snapshot、Buying Committee Map、Evidence Gaps 和 Inference Notes。
• Procurement Risk Only — 返回 Deal Snapshot、Procurement Risk Register、Evidence Gaps 和 Inference Notes。
• Next Actions Only — 返回 Deal Snapshot、Prioritized Next Actions、Evidence Gaps 和 Inference Notes。

输出格式

完整策略包须严格按以下顺序返回各部分。

# Deal Strategy: [Account / Opportunity]

## Deal Snapshot

- **Account:** [Name + source]
- **Opportunity:** [Name or Unknown]
- **Stage:** [CRM-backed value or Unknown]
- **Close Date:** [Evidenced date or Unknown]
- **Time Window:** [Window]
- **Run Mode:** [Mode]
- **Coverage Summary:** [Available, unavailable, empty, stale, or user-provided-only lanes]

## Deal Map

- **Initiative:** [Business initiative]
- **Target Outcome:** [Customer/business outcome]
- **Current Motion:** [Stage, timeline posture, and deal movement]
- **Active Workstreams:** [3-6 grounded bullets]
- **Top Blockers or Dependencies:** [Up to 5 grounded bullets]

## Buying Committee Map

| Stakeholder | Title | Org | Role | Stance | Influence | Last Signal | Confidence | Source |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [Name] | [Title] | [Org] | [Role] | [Stance] | [Influence] | [Signal] | [High/Medium/Low] | [Link/label] |

## Procurement Risk Register

| Risk ID | Risk Summary | Risk Type | Severity | Likelihood | Owner or Suggested Owner | Mitigation | Target Date | Confidence | Source |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| R1 | [Risk] | [Type] | [High/Medium/Low] | [High/Medium/Low] | [Owner] | [Step] | [Date/TBD] | [High/Medium/Low] | [Link/label] |

## Prioritized Next Actions

1. **Action:** [Concrete action]
   - **Owner or Suggested Owner:** [Owner]
   - **Due:** [Date, relative timing, or TBD]
   - **Linked Risk IDs:** [IDs or None]
   - **Linked Stakeholders:** [Names or None]
   - **Expected Outcome:** [Outcome]
   - **Source:** [Link/label]

## Evidence Gaps

- **Gap:** [Material missing/conflicting evidence]
  - **Impact:** [How confidence or execution is affected]
  - **Smallest Next Collection Step:** [Most efficient way to close it]

## Inference Notes

- Inference: [Claim inferred rather than directly stated, with basis]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}

规则

• 不要编造利益相关方、审批、障碍、负责人、承诺、金额、阶段、预计成交日期或确切日期。
• 将事实与推断分开；没有推断内容时，应省略推断说明，不要为了凑内容而添加。
• 与其给出宽泛建议，不如提出较少但更有力的行动，并优先处理最可能阻碍签约或导致时间延误的风险。
• 在常规输出中使用便于阅读的标题式大小写标签；只有用户要求 JSON 或 YAML 时，才使用机器可读的键。
• 此工作流仅供只读使用。除非用户在后续步骤中明确要求，否则不要更新 CRM、发送消息、发布摘要或创建下游材料。
• 如果证据稀少但交易锚点足够，则应生成低置信度策略包并明确标注缺口，而不是中止。

异常处理

如果没有可信的活跃交易锚点，应说明阻碍；若有具体候选项，则提供候选项，并询问最少的缺失信息。如果无法使用可选渠道，应继续依据最可靠的证据，并明确说明由此带来的置信度限制。