去见客户前的 20 分钟，打开 Claude。
输入："帮我分析一下xxxx，看看怎么卖给他们。"
三分钟后，Claude 给了一份看起来很完整的回答：公司背景、可能痛点、推荐话术、下一步行动。于是便出发了。
会议上，对方采购追问了三个数字。全都找不到出处。
大多数人以为用 Claude 做销售分析，就是问一下。
这类一次性回答，有三个地方会伤人。
一，它更像脑暴，不像可复用的销售资产。今天问完，明天拿到一条更新信息、一张截图，原来的分析很难被精确更新。
二，它容易把不确定写得很确定。没有来源的数字、没有验证的痛点、没有证据的决策人，写得像板上钉钉。客户一追问，就答不上来。
三，它很难直接进入销售动作。销售真正需要的，是拜访前能快速读完、开会时能直接照念、会后能继续补充的作战资料，不是一篇漂亮报告。
我的感受是，第二个最要命——当场答不上来，比找不到更新入口更伤关系。
所以我后来做了一个 Claude Code Skill。
目标不是让 Claude 写一份客户分析报告，而是把客户名和零散销售材料转成一套结构化、可追溯、可迭代的销售分析笔记。
原来备一个客户，流程是这样的：查找客户背景、列出手头资料、准备分析计划、制定销售策略。
听起来有条理。但实际跑起来，每一步都要在不同地方找东西，整理完还要手动拼成一份能用的文件。从拿到客户名，到知道该说什么了，整条链太长，而且每次都要重走一遍。
更麻烦的是，这套流程的产出没法复用。下次再碰同一个客户，或者有新材料进来，还是从零开始。
这篇文章就拆一下这套工作流。
输入：公司名 + 手头有的材料
销售一开始不需要准备完整资料。
只要给 Claude 一个公司名，再补充手头已有的信息就行：
客户：华东优选
官网：https://example.com
国家/地区：中国
我猜测的行业：电商
规模线索：App 下载量比较高，最近在招客服主管和风控岗位
已有材料：官网、招聘 JD、几张 App 差评截图
我想判断：应该从消息触达、客服效率，还是风控切入？
这类输入的关键不是完整，而是诚实。
知道什么写什么，不知道就留空。Claude 的任务不是立刻把空白补满，而是先识别哪些信息足够判断，哪些需要追问，哪些必须查证。
输出：5 份销售笔记，不是一篇报告
这套工作流每次生成一组 Markdown 笔记，放在同一个客户文件夹里：
1. 索引
2. 客户档案
3. 业务痛点与产品匹配
4. 数据话术库
5. 销售策略
销售不用在一篇长分析里来回翻。
想快速了解客户，看索引。确认公司背景、规模、决策链，看客户档案。搞清楚该卖什么、为什么卖，看业务痛点与产品匹配。准备会议话术，看数据话术库。决定下一步推进动作，看销售策略。
销售分析不是一次完成的，会随新材料不断变化。拆成 5 份笔记之后，每次只更新相关部分，不用重写整篇分析。
完整工作流：6 个步骤
Step 1：先澄清，不硬写
第一步是收集材料，并把材料清单反馈给用户确认。
如果客户是普通终端企业，比如电商、金融、本地生活、物流、租赁平台，可以直接进入行业识别。
但如果客户是软件商或系统集成商，就不能直接分析它自己的痛点。这类公司往往不是终端使用方，而是渠道方、项目方或交付方。
这时必须先问：
这家软件商主要服务什么下游行业？
例如电商、金融、物流、政府、地产、餐饮、本地生活等。
下游行业决定了后续所有分析方向。
卖给软件商，话术通常不是"解决你的客服问题"，而是"帮你给下游客户提供新的能力，提高项目单价、扩大方案范围或增加中标概率"。
Step 2：识别行业，加载对应剧本
第二步是行业识别。
把常见 B2B 销售场景拆成几个行业剧本：
软件商 / 系统集成商
电商
租赁 / 不动产
金融 / 加密 / 保险
外卖 / 打车 / 物流 / 本地生活
其他 / 不确定
Claude 根据信息判断客户属于哪个行业。判断不出来就走通用框架，不强行归类。
这里有一个小但重要的设计：Claude 必须告诉用户它识别成了什么行业，不能静默跳过。行业判断一旦错了，后面的痛点、ROI、话术都会跟着错。
Step 3：判断规模，决定 ROI 参数
第三步是规模评估。
把客户粗略分成 Tier 1 到 Tier 4：
Tier 1：小型客户
Tier 2：中型客户
Tier 3：大型客户
Tier 4：巨型客户
规模不是为了贴标签，而是为了决定后面的 ROI 参数。
同样是电商客户，日订单 500 单和日订单 10 万单，切入方式完全不同。前者更关心低成本启动和快速验证，后者更关心稳定性、合规、风控、跨团队协作和系统集成。
如果规模不确定，Claude 不能编。要么向用户确认，要么把缺失信息写成待补充项。
Step 3.5：联网查证，查不到就留 todo
如果当前API支持联网，Claude 会主动检索三类信息：
1. 规模数字：GMV、日订单、日活、融资金额、员工数
2. 真实信号：招聘岗位、App 差评、本地社媒吐槽、媒体报道、注册信息
3. 公司背景：管理层、上市状态、牌照、近期关键事件
这里的重点不是查得越多越好，而是每条关键事实都要能回到来源。
一个合格的销售分析，不应该只有：
该客户近期业务增长较快，客服压力较大。
而要尽量写成：
根据 2025 年招聘页面，该公司正在招聘客服主管和风控运营岗位，说明其客服处理与风险识别能力可能正在扩张。
来源：URL
年份：2025
原文片段：……
如果找不到来源，就不要把它写成事实，而是写成：
> [!todo]
> 待补充：客户近期订单规模、客服团队人数或投诉量数据。
> 建议来源：销售访谈、客户内部数据、公开采访、招聘信息。
宁可留下 todo，也不要编一个看起来顺滑的结论。
Step 4：生成 5 份结构化笔记
确认行业和规模之后，开始生成 5 份笔记。
索引给销售一个全局视图：
客户一句话定位
核心判断
优先切入方向
内部笔记导航
客户档案沉淀背景信息：
公司业务
市场区域
规模判断
决策链地图
外部信号
待补充信息
业务痛点与产品匹配把客户问题和我方产品连起来：
行业典型痛点
该客户可能存在的痛点
已有证据
推荐产品
匹配原因
风险与限制
数据话术库提供可直接用于会议的材料：
ROI 推导
核心数据论据
销售可照念话术
客户追问时的回答
需要避免的说法
销售策略把分析转成动作：
主推产品顺序
进门话术
关键确认问题
风险与应对
下一步行动建议
Step 5：输出补充清单，告诉销售下一步该找什么
生成笔记之后，Claude 不会在对话里复制整套笔记全文，而是输出一份精简的补充清单：
高优先级待补充：
1. 日订单量或月订单量
用途：校准 ROI 推导
建议来源：客户访谈、内部 CRM、客户公开采访
更新位置：数据话术库 / ROI 推导
2. App 差评截图
用途：验证用户通知失败、退款争议或客服响应慢的问题
建议来源：App Store、华为应用市场、小米应用商店、黑猫投诉、小红书
更新位置：客户档案 / 外部信号
3. 当前客服处理流程
用途：判断是否适合从客服效率或自动化通知切入
建议来源：售前会议提问
更新位置：业务痛点与产品匹配
这一步不是只告诉销售分析完了，而是告诉销售接下来最值得补哪几条信息。
Step 6：新材料进来，定点更新
销售分析最常见的情况是：第一次材料不完整。
可能隔天销售补了一张截图：
我找到了华东优选的 App 差评截图，很多用户在抱怨收不到订单通知。
或者补了一条新闻：
这家公司刚完成新一轮融资，准备扩张到华南市场。
这时 Claude 不应该重新生成一整套笔记，而是读取已有 5 份笔记，找到相关段落，做定点更新。
如果新材料改变了判断，还要说明级联影响：
这条融资信息会影响：
1. 客户规模档位：可能从 Tier 2 调整到 Tier 3
2. 销售策略：从低成本试点转向区域扩张支持
3. ROI 参数：需要重新校准订单量和跨市场运营成本
这就是我认为 Claude 做销售分析最有价值的地方。
不是一次性生成，而是持续维护。
ROI 推导：帮销售开口，但不伪装成精确测算
销售分析里经常需要一个数字。
但很多 AI 生成的 ROI 很危险，因为它会把假设写成结论。
我的做法是让 Claude 使用一个明确的示意模型：
日订单量
× 产生通信交互的比例
× 转化为投诉 / 风险事件的比例
× 每起事件处理成本
= 日损失
× 365
= 年损失
× 降低比例
= 年节省
这类数字的作用不是替客户做财务审计，而是帮销售建立一个讨论框架。
所以每次输出 ROI 时，都要标注：
以下为示意值，基于行业经验估算，建议用客户真实数据校准。
在销售会议里，ROI 话术的正确用法不是说：
你们一年一定能省 300 万。
而是说：
如果我们先用一个保守模型，把日订单量、投诉率和单次处理成本放进去，会看到通知失败和客服处理带来的损失可能已经足够大。我们可以在下一步用你们的真实数据把这个模型校准一遍。
这样既有商业冲击力，又不会显得不负责任。
反幻觉约束：让 Claude 知道什么时候不能说
这套工作流里最重要的设计，不是行业模板，也不是 ROI 计算，而是反幻觉约束。
销售材料会被客户技术团队、采购团队、业务负责人反复追问。一个编出来的数字、一个不存在的客户案例、一个夸大的产品能力，都可能直接伤害信任。
所以给 Claude 加了几条硬规则：
1. 具体数字必须有来源
2. 决策人姓名不能编造
3. 招聘、差评、融资、媒体报道必须有 URL 或截图
4. ROI 必须标注为示意值
5. 产品卖点必须严格引用已有资料
6. 客户案例不能虚构
7. 软件商必须先追问下游行业
8. 生成给销售看的正文里不能暴露内部文件名和 skill 术语
9. 禁止使用"100% 解决""完全杜绝"等绝对化措辞
10. 推荐产品顺序必须和后文方案一致
背后的原则只有一句：
Claude 可以推理，但不能伪装成知道。
没有证据，就写 todo。只是估算，就明确说是估算。是典型角色，就写"可能涉及的角色"，不编具体人名。
对销售来说，这反而更有用。一份诚实标注不确定性的分析，比一份看起来很完整但经不起追问的报告更可靠。
Software House 的特殊分支
我单独为软件商和系统集成商设计了一个分支。
这类客户不是典型终端客户。直接分析它自己的业务痛点，通常会跑偏。真正应该分析的是它的下游客户。
例如，一家系统集成商服务的是银行客户，那么销售策略就要围绕银行的风控、通知、合规、客户沟通来设计。
这时卖点也会变化。不是：
我们帮你降低客服成本。
而是：
我们可以帮你把这项能力打包进银行客户的整体解决方案里，让你的方案覆盖更多业务场景，并提高项目价值。
ROI 也不是成本节省，而更接近新收入机会：
新增方案模块
× 可打包项目数量
× 单项目增量报价
= 潜在新增收入
所以只要 Claude 判断客户可能是软件商或系统集成商，就必须先问清楚下游行业，再继续分析。
这个分支我没有在所有行业都跑过，边缘情况可能需要微调，不确定通用框架能 cover 所有 SI 类型。
提示词：实际会用的 5 组
- 启动客户分析
/ky-client-analysis
分析客户 <公司名>。
我目前掌握的材料如下：
1. 官网：
2. 所在国家/地区：
3. 我猜测的行业：
4. 规模线索：
5. 已知业务：
6. 销售备注：
7. 我最想判断的问题：
请先确认你识别出的行业和规模档位。
如果信息不足，请列出需要我补充的问题。
如果有不确定内容，请写成 todo，不要编造。
- 只有公司名时
/ky-client-analysis
帮我分析客户 <公司名>。
我目前只有公司名，没有其他材料。
请先判断你需要哪些信息，并在可联网的情况下检索公开资料。
所有具体数字和外部信号都必须附来源。
查不到的内容请写成 todo。
- 补充新材料
我补充一条新材料：
客户：<公司名>
材料类型：App 差评 / 招聘信息 / 新闻 / 融资 / 官网说明 / 销售访谈
来源：
原文片段：
我的判断：
请更新已有客户分析笔记，只修改相关段落。
如果这条信息会影响行业判断、规模档位、ROI 参数或销售策略，请说明级联影响。
- 拜访前 10 分钟速读版
基于当前这套客户分析笔记，请帮我生成一份拜访前 10 分钟速读版：
1. 客户一句话定位
2. 最可能打中的 3 个痛点
3. 推荐优先讲的产品顺序
4. 开场破冰话术
5. 需要客户确认的 5 个问题
6. 不能说或需要谨慎说的内容
- 生成会议话术
请基于当前客户分析，生成一版销售会议话术。
要求：
1. 先用客户业务背景开场
2. 再引出 2-3 个可验证痛点
3. 用示意 ROI 模型建立讨论框架
4. 推荐产品时不要夸大能力
5. 最后给出下一步推进建议
6. 如涉及具体数字，请说明来源或标注为示意值
一个简化案例
假设客户是中国区域电商平台华东优选，手头材料很少：
客户：华东优选
行业：电商
地区：中国华东
材料：官网、App 差评截图、招聘客服主管和风控运营的 JD
销售目标：判断应该从哪里切入
Claude 先识别它是电商客户，再根据材料判断可能痛点：
可能痛点 1：订单通知、物流通知、促销通知触达不稳定
可能痛点 2：客服压力上升，投诉处理成本增加
可能痛点 3：交易风险、退款争议、异常订单识别需求增强
生成销售策略：
第一优先：消息触达与通知可靠性
第二优先：客服效率和投诉处理
第三优先：风控与异常交易识别
ROI 话术不说"你们一年能省多少钱"，而给出一个讨论模型：
如果每天有 20,000 笔订单，其中 15% 需要至少一次通知或客服交互；
假设其中 2% 因通知失败、状态不清晰或沟通延迟转成投诉；
每起投诉处理成本按示意值 20 元人民币计算；
则可以估算当前沟通失败带来的潜在处理成本。
以上为示意值，建议在下一步会议中用客户真实订单量、投诉率和客服成本校准。
最后，提醒销售补充：
1. 真实日订单量
2. 客服团队人数
3. 投诉主要类型
4. 当前通知渠道
5. 是否已有风控或客服系统
这就是一套可推进的销售分析，不是那种看起来很懂的 AI 报告。
用 Claude 做销售分析，真正重要的不是一次输出多长，而是遵守一套稳定的工作流：
先澄清，再分析。先识别行业，再套用剧本。先判断规模，再推导 ROI。有来源才写事实，没来源就写 todo。生成之后还能继续更新。
这样 Claude 才不是临时文案助手，而更像一个销售分析系统。
它把客户背景、业务痛点、产品匹配、ROI 推导、会议话术和下一步行动沉淀下来。销售本人仍然负责判断、验证、推进关系。Claude 可以把最耗时、最容易遗漏、最难复用的部分标准化。
这样才是 AI 的用武之地。
