sales-script

销售话术

适用场景

• 准备需求访谈、产品演示或成交会议
• 回复 RFP/RFI，并需要分析需求覆盖缺口
• 制作与竞争对手的功能对比矩阵
• 规划或评估概念验证（POC）
• 准备面向技术演示的脚本，并按利益相关者准备专属谈话要点
• 处理异议或开展赢单／丢单分析

所需上下文

来自 startup-context 或用户：

• 产品／服务——销售的内容、目标客户、核心能力
• 目标用户角色——职位、资历、典型痛点
• 交易背景——阶段、交易规模、相关利益相关者、已知异议
• 竞争格局——客户还在评估哪些方案、你的差异化优势
• 证明材料——指标、案例研究、客户引言
• RFP/RFI 详情——如需回复正式请求，提供需求类别和优先级

工作流

阶段 1：需求访谈与调研

1. 收集背景信息——阅读 startup-context。确定所需脚本类型：需求访谈、演示、RFP 回复、竞争分析或 POC 计划。
2. 梳理客户需求——记录潜在客户的现有架构、痛点、集成需求、安全／合规需求和业务驱动因素。
3. 评估竞争格局——确定该交易涉及的竞争对手。将你的产品能力与对方进行对比，找出差异化优势和薄弱点。
4. 评估需求覆盖度——对于 RFP/RFI 回复，将每项需求归类为完全满足（100%）、部分满足（50%）、计划支持（25%）或缺口（0%）。按优先级加权：必须具备 3 倍、应该具备 2 倍、锦上添花 1 倍。

阶段 2：解决方案设计与定位

5. 将痛点与价值关联——将每项潜在客户痛点与具体产品能力及证明材料（指标、案例研究）关联起来。
6. 构建竞争差异化优势——针对客户的每项优先事项，至少找出一项有力的差异化优势。如果没有，则标记并升级给产品团队处理。
7. 设计谈话主线——围绕客户的优先事项组织对话或文档，而不是罗列你的功能。

阶段 3：脚本与演示准备

8. 起草脚本——撰写完整脚本，包括时间安排、谈话主线、问题、过渡提示和针对不同利益相关者的谈话要点。
9. 准备异议处理方案——预测可能出现的异议，并使用 LAER 模型撰写回应框架。
10. 搭建演示环境——制定演示前检查清单：测试环境、加载示例数据、准备备用环境、应用客户专属品牌元素。

阶段 4：POC 与成交（如适用）

11. 确定 POC 范围——设定成功标准、时间线（通常为 5 周）和分阶段测试计划。从功能、性能、集成、易用性和支持等方面进行评估。得分须 >60% 才建议推进。
12. 促成交易——整合 POC 结果、演示反馈和竞争定位。根据交易阶段运用合适的成交技巧。

输出格式

按请求交付相应格式：需求访谈脚本（SPIN 阶段问题、资格判定标准、下一步安排）、演示脚本（按场景逐步编排并标注时间、各角色谈话主线、演示前检查清单、异议表）、RFP 回复分析（覆盖评分、缺口数量、是否投标建议）、竞争矩阵（包含加权得分的功能对比、差异化优势、薄弱点）、POC 计划（分阶段时间线、成功标准、评分卡）、异议处理文档（表格：异议、顾虑、回应、证明材料、后续跟进）或成交手册（决策标准、技巧、时间线）。

框架与最佳实践

发现沟通框架（30 min）

阶段	时长	操作
建立融洽关系并确认议程	3 min	确认议程和时间，快速建立融洽关系
了解现状的问题	7 min	了解对方当前的情况和工作流
了解问题的问题	8 min	深入了解痛点、发生频率和影响
了解问题影响的问题	5 min	探讨不解决问题的代价
了解解决方案价值的问题	4 min	让对方说出解决方案的价值
后续步骤	3 min	总结、确认是否匹配，并安排演示

演示脚本结构

演示前检查清单： 测试环境，加载示例数据，准备备用环境，测试屏幕共享，预先打开浏览器标签页，确认网络/VPN 正常，应用客户品牌元素。

参会者映射： 记录每位参会者的职称、在评估中的角色（决策者 / 支持者 / 技术评估者 / 终端用户）和主要关注领域。

环节	时长	内容
开场	5 min	感谢参会者，回顾沟通发现，确认议程
用例 1	7 min	结合业务背景演示主要痛点，并突出差异化优势
确认反馈	2 min	“这和你们目前的处理方式相比如何？”
用例 2	7 min	演示次要痛点
用例 3	6 min	展示他们意料之外的差异化优势或惊喜功能
集成演示	10 min	展示连接器设置、数据流和端到端工作流
管理与安全	5 min	RBAC、审计日志、SSO
问答	5 min	回答现场问题
结束	5 min	总结价值，并提出包含具体日期的后续步骤

演示原则： 先沟通了解，再进行演示，绝不反过来。使用对方的术语和数据。留出提问时间。分享你打造该功能的原因——相比逐项讲解功能，讲述起源故事更能引起共鸣。

RFP 投标 / 不投标框架

• 投标： 覆盖率 >70% 且必备项差距 <=3
• 有条件投标： 覆盖率 50-70% 或必备项差距 2-3
• 不投标： 覆盖率 <50% 或必备项差距 >3

异议处理（LAER 模型）

1. 倾听 — 让对方说完。不要打断或摆出防御姿态。
2. 认可 — “这很合理”或“我经常听到这样的说法。”
3. 探询 — 追问以了解真正的顾虑。
4. 回应 — 用证据回应真正的顾虑，然后确认对方是否认同。

类别	异议示例	应对策略
价格	“太贵了”	换个角度看 ROI。“不解决这个问题的代价是多少？”
时机	“现在不是时候”	找出真正的障碍。“需要发生什么变化？”
竞争	“我们已经在用 X”	针对对方的具体痛点说明差异化优势
决策权	“我需要和老板确认”	为支持者提供所需材料，帮助其推动决策
现状	“我们现有的方案能用”	量化隐藏成本。分享同行案例。
信任	“你们规模太小”	以证据取胜：客户、指标、投资者和团队

演示故障恢复

如果演示出故障：切换到备用环境，说明原本会展示什么，并提供录制内容作为后续跟进。如果问题打断演示节奏：表示理解，记录下来以便后续跟进，然后回到脚本。如果观众失去兴趣：暂停并询问“这是否满足你们的需求？”，然后跳到最相关的部分。

创始人的成交技巧

• 总结式成交： “我们已经确认，[痛点]造成了 [金额] 的损失，而我们的解决方案能够满足 [需求]。要推进下一步，还需要什么？”
• 时间线式成交： “你们希望在 Q3 前解决这个问题。倒推时间安排，我们需要在 [日期] 开始。”
• 试点式成交： “先针对 [用例] 开展小范围试点，证明价值后再逐步扩大。”
• 创始人式成交： “我会亲自确保你们的入门流程顺利进行。接下来的 30 天，你们可以直接和我合作。”

演示后续行动

在 24 小时内发送附有录制内容的感谢邮件。分享演示环境的访问权限。发送后续邮件，回答尚未解决的问题。安排下次会议。在 CRM 中更新演示记录和后续步骤。记录异议，以便更新竞争战术卡。

相关技能

• cold-outreach — 用于促成销售对话所需的会议
• proposal-generation — 演示成功后使用，用于创建正式提案、SOW 或合同

示例

提示词：“我明天要和一家金融科技公司的工程主管做演示。他们关注如何减少部署失败。”

良好的演示开场白：

“感谢你抽出时间，[Name]。上周你提到，你们团队每个 sprint 大约要花 8 小时处理部署失败和回滚。你说最大的痛点是这会拖慢发布速度，也让团队感到沮丧。这仍然是你们的首要任务吗？还是情况有所变化？

很好。我想向你展示三个解决部署可靠性问题的具体工作流。大约需要 25 分钟，并留出时间回答你的问题。这样可以吗？

我先从 [Similar Fintech Customer] 切换到我们之前是如何处理这个问题的说起……”

提示词：“我们收到了一家大型企业的 RFP。我们应该投标吗？”

良好的输出片段：

RFP Coverage Analysis:
- Overall coverage score: 68% (Conditional Bid range)
- Must-have gaps: 2 (within threshold)
- Recommendation: CONDITIONAL BID

Action items before proceeding:
1. Confirm planned roadmap items cover the 2 must-have gaps
2. Build differentiator narrative around your 3 strongest categories
3. Flag gaps to product team for timeline confirmation