back
loading skill details...
根据客户状态、上次沟通、时间节点和可补充价值,判断是否跟进、何时跟进以及跟进什么。
--- name: zayn-followup description: 根据客户状态、上次沟通、时间节点和可补充价值,判断是否跟进、何时跟进以及跟进什么。 --- # FOLLOWUP() ## 1. 基本信息 - Skill ID:`zayn-followup` - Display Name:FOLLOWUP() - Project:WorkFn - Author Prefix:zayn - 中文名称:客户跟进 - 所属分类:客户沟通 - 一句话用途:判断是否应该跟进、何时跟进以及跟进什么 - Version:`0.2.0` - Status:Draft for testing FOLLOWUP() 用于判断一个客户当前是否值得跟进、什么时候跟进、跟进什么,以及何时暂停投入。它不是自动催客户回复的工具。 ## 2. 解决的问题 1. 判断是否存在真实跟进理由 2. 判断现在是否是合适时间 3. 判断本次跟进能否提供新价值 4. 判断继续投入是否合理 5. 设计一个最小、自然、低压力的下一步动作 ## 与相邻 Skill 的区别 1. `FOLLOWUP()` 负责是否跟、何时跟、跟什么。 2. 客户表达需要深度理解时,先转入 `INTENT_DECODE()`。 3. 需要补齐需求时,转入 `CLARIFY()`。 4. 需要长期、非项目型关系维护时,转入 `RELATION()`。 5. `FOLLOWUP()` 可以给出跟进表达,但不代替尚未完成的价格、产品或订单判断。 ## 3. 适用场景 1. 报价后客户没有回复 2. 客户询价后消失 3. 老客户一段时间没有联系 4. 项目正在等待终端客户确认 5. 客户表示未来某个时间有结果 6. 客户持续查看库存但不回复 7. 客户过去有成交,现在需求减少 8. 客户只在找不到货时联系 9. 用户纠结今天跟、明天跟还是暂停 10. 需要判断跟进内容,而不是只写一句 `Any update?` ## 4. 不适用场景 1. 客户刚刚发来明确消息,需要即时回复,应使用 `REPLY()` 2. 需要判断一条询价是否值得报价,应使用 `RFQ()` 3. 需要检查正式报价内容,应使用 `QUOTE()` 4. 需要处理客诉,应使用 `COMPLAINT()` 5. 需要制定长期重点客户战略,应使用 `ACCOUNT()` 6. 客户已经明确拒绝且没有新信息 7. 用户只是想群发开发信 ## 5. 输入参数 输入包括必填参数和建议参数。历史记录、时间节点和客户行为必须区分证据强度,不得把浏览、点击等行为直接解释为采购意向。 ## 6. 必填参数 | 参数 | 说明 | |---|---| | `customer_background` | 客户背景 | | `last_contact_content` | 上次沟通内容 | | `last_contact_time` | 上次联系时间 | | `pending_item` | 当前未回复或待推进事项 | | `followup_goal` | 本次跟进目标 | ## 7. 可选参数 | 参数 | 说明 | |---|---| | `customer_history` | 历史合作、成交、询价、付款和售后记录 | | `quote_or_project_status` | 报价或项目状态 | | `customer_timeline` | 客户明确时间节点 | | `recent_behavior` | 客户最近行为 | | `new_value` | 可补充的新价格、新库存、新方案或信息 | | `channel` | 沟通渠道 | | `prior_followup_count` | 已跟进次数 | | `stop_condition` | 停止条件 | | `effort_required` | 后续投入成本 | | `risk` | 价格、交期、库存、售后、付款或合规风险 | ## 8. 证据优先级 判断跟进价值时,必须按以下顺序使用证据: 1. 成交记录 2. 订单记录 3. 付款记录 4. 发货记录 5. 售后记录 6. 询价记录 7. 报价记录 8. 有效沟通记录 9. 客户明确时间节点 10. 客户近期行为 11. Obsidian 客户记录 12. Excel 已有备注 13. 官网信息 14. LinkedIn 入口 15. AI 推测 不得因为客户浏览网站、查看库存或打开邮件,就直接判断客户有强采购意向。 ## 9. 判断规则 ### 第一步:判断是否有真实推进对象 确认当前跟进对象属于明确询价、明确项目、历史客户、潜在线索或纯粹无回复联系人。没有真实需求、历史证据或新价值时,降低跟进优先级。 ### 第二步:识别当前卡点 检查价格、库存、交期、比价、终端确认、预算、付款、技术确认、稳定供应商、暂无项目、供应能力信任以及我方没有提供新价值等卡点。 ### 第三步:判断是否有新价值 本次跟进至少应具备一项: 1. 新价格 2. 新库存 3. 新交期 4. 新替代方案 5. 新技术确认 6. 新付款方案 7. 与客户行业相关的真实信息 8. 对客户上次问题的明确回应 9. 到达客户之前明确约定的时间节点 没有新价值时,只能做轻量关系维护,不应连续催问。 ### 第四步:判断时间是否合适 考虑距离上次联系多久、客户时间节点、报价有效期、库存或价格变化、连续跟进次数和当前重新联系的合理理由。 ### 第五步:判断投入等级 只能选择: 1. 立即重点跟进 2. 正常跟进 3. 轻量触达 4. 等待节点 5. 暂停投入 6. 移出近期作战池 ### 辅助评分维度 可以参考真实需求证据、历史合作、时间紧迫度、新价值、回复概率、商业价值、投入成本和风险。评分不是绝对事实,输出评分时必须解释证据和依据。 ### 跟进表达规则 不推荐只发送 `Any update?`、`Did you check my quotation?`、`Please reply.`、`We are still waiting for your feedback.`,也不应重复同一份报价或在没有新信息时频繁催问。 推荐结构: 1. 简短承接上次沟通 2. 提供一个新信息或明确理由 3. 降低客户回复成本 4. 只问一个容易回答的问题 5. 给客户保留退出空间 ### 渠道规则 - Email:适合正式项目、报价更新、多项信息、附件和需要留痕的沟通。 - WhatsApp 或 WeChat:适合轻量确认、关系维护、简短询问、时间节点提醒和快速确认一个问题。 - LinkedIn:适合尚未建立稳定沟通、重新建立联系或补充沟通入口;不适合发送长报价或连续催促。 ## 10. 风险检查 1. 是否过度跟进 2. 是否只是在催回复 3. 是否没有新价值 4. 是否对低证据客户投入过多 5. 是否因焦虑而扩大任务 6. 是否应该先补充内部信息 7. 是否忽略客户明确给出的时间节点 8. 是否把不回复等同于没兴趣 9. 是否把查看库存、打开邮件等行为等同于采购意向 10. 是否缺少停止条件和下次判断节点 ### 客户池边界 1. 作战池只放近期能推进的客户 2. 不要一开始分析全部客户 3. 优先处理已有成交和询价证据的客户 4. 没有证据的客户可以留空或未判断 5. LinkedIn 只用于辅助没有成交和询价证据的客户 6. 不为了分类完整强行判断 7. 不因为客户浏览库存就自动升为高优先级 ## 11. 输出结构 正式输出依次包含: 1. 参数完整度结论 2. 参数状态表 3. 是否建议跟进 4. 当前跟进阶段 5. 推荐时间 6. 跟进目标 7. 建议角度 8. 可发送版本 9. 停止条件 10. 下次检查节点 只有在适合联系且最低运行条件满足时,才生成可发送版本。 ## 12. 禁止事项 1. 把不回复等同于没兴趣 2. 把查看库存等同于采购意向 3. 强行建议持续跟进 4. 为了显得积极而频繁催促 5. 忽略客户明确给出的时间节点 6. 对低价值客户投入大量找货和工程资源 7. 只输出话术,不给判断 8. 因用户焦虑而建议扩大客户池 9. 把 AI 推测写成客户真实状态 10. 强行把所有客户放入某一层级 ## 13. 信息不足时的处理 信息不足时,优先询问: 1. 上次联系时间 2. 客户最后回复 3. 是否有历史成交 4. 是否有明确询价 5. 是否有新信息可提供 6. 客户是否给过时间节点 7. 已经跟进过几次 如果仍然缺少证据,默认建议: ```text 先不做高投入跟进。 可保留为轻量观察或未判断。 ``` ## 14. 人工判断边界 1. 不覆盖用户已经确认的成交、订单、付款、发货、售后和沟通事实 2. 不把评分、行为信号或 AI 推测当作客户真实状态 3. 证据冲突时指出冲突并请求人工确认 4. 是否投入找货、工程、价格或售后资源,仍由有权限的人决定 5. 客户层级可以保留未判断,不为分类完整强行归类 6. 已明确拒绝且没有新信息时,不建议继续联系 7. 需要内部确认新价格、库存、交期或方案时,先确认再跟进 ## 15. 验收标准 一个合格的 FOLLOWUP() 输出必须: 1. 明确判断是否应该跟进 2. 说明判断依据 3. 区分真实证据和推测 4. 不因焦虑而建议频繁联系 5. 本次跟进有明确理由 6. 推荐动作足够小 7. 有停止条件 8. 有下一次判断节点 9. 不强行生成话术 10. 不把全部客户都塞进作战池 ## 16. 当前状态 ```text Version: 0.2.0 Status: Draft for testing ``` 本版本需要通过真实客户跟进案例继续验证和修正。 ## 参数解析流程 本 Skill 必须先解析用户输入并映射到参数表。 ## 参数状态表 正式分析前,必须输出参数状态表。 参数状态只能使用: ```text 已命中 部分命中 缺失 冲突 待验证 ``` 统一格式: | 参数 | 必需程度 | 当前状态 | 已获取内容 | 缺失或冲突影响 | |---|---|---|---|---| | 待按本 Skill 参数填写 | 待确认 | 缺失 | 无 | 待判断 | 参数状态表必须基于用户输入,不得凭空补充。 ## 最低运行条件 1. 能确认上次沟通发生了什么 2. 能确认当前卡点 3. 能说明本次跟进目标 4. 至少有一个合理跟进理由 未达到以上条件时,先输出参数状态表,说明缺失或冲突内容、重要性、影响和可直接补充的字段,然后停止正式分析。 ## 缺失参数处理 不得自动补全缺失参数,必须明确提示用户补充,并说明缺失参数、重要性、影响、补充方式及当前是否可以先做初步分析。 ## 冲突参数处理 不得自行解决冲突,必须保留不同来源、标记冲突、说明影响并提示验证。在冲突解决前降低分析置信度。 ## 待验证参数处理 待验证信息不得写成确定事实。供应商口头反馈、市场信息、预计库存、预计交期、公开资料、客户可能意图和 AI 推测等必须明确标记。 ## 停止条件 出现以下任一情况时停止正式分析或暂停跟进: 1. 上次沟通内容或时间无法确认 2. 当前卡点和跟进目标不明确 3. 没有合理跟进理由或可补充的新价值 4. 客户已明确拒绝且没有新信息 5. 已多次重复跟进但没有新增信息 6. 客户给出的明确时间节点尚未到达 停止时必须说明原因、需要补充的信息和下次检查节点。 ## 正式分析触发条件 只有达到最低运行条件,且关键缺失、冲突、证据来源、分析目标和风险边界已得到处理后,才进入正式分析。 ## 初步分析模式 参数不完整时,只能提供明确标注的初步分析: ```text 以下为初步分析,仍需补充关键参数。 ``` 不得把初步分析包装成确定结论。 ## 正式分析模式 参数完整并满足触发条件时,才可输出正式分析。正式输出前必须再次检查参数缺失、冲突、待验证信息、推测、人工判断、职责边界和用户真实目标。
don't have the plugin yet? install it then click "run inline in claude" again.