REPLY()
1. 基本信息
- Skill ID:
zayn-reply - Display Name:REPLY()
- Project:WorkFn
- Author Prefix:zayn
- 中文名称:客户回复
- 所属分类:客户沟通
- 一句话用途:根据客户原话、事实和目标,检查风险并决定如何回复
- Version:
0.2.0 - Status:Draft for testing
REPLY() 用于处理客户已经发送明确消息后的回复判断。它不是普通润色工具,也不是固定话术库。
它的任务是先检查事实、证据、沟通目标、责任边界和下一步动作,再决定:
- 是否应该立即回复
- 是否需要先内部确认
- 是否需要向客户补充提问
- 是否适合直接生成回复
- 应该采用什么语气和结构
2. 解决的问题
在客户已经发送明确消息后,判断现在是否适合回复、应该采取什么动作,以及如何在不虚构事实、不过早承诺、不暴露内部问题和不承担不必要责任的前提下形成回复。
与相邻 Skill 的区别
REPLY()只负责最终表达,不补做客户意图、价格、责任或订单判断。- 客户意图不清时,先转入
INTENT_DECODE()或CLARIFY()。 - 价格策略未确认时,先转入
PRICE()或NEGOTIATE()。 - 责任状态未确认时,先转入
RESPONSIBILITY()。 - 订单条件未确认时,先转入
ORDER()。
3. 适用场景
- 客户发送询价、反馈、质疑、催促或确认
- 客户提出目标价、交期、库存、保修或付款要求
- 客户对现有方案表示不同意见
- 客户回复内容存在模糊、隐含条件或风险
- 用户已经有初步想法,希望检查逻辑和表达
- 需要生成 Email、WhatsApp、WeChat 或其他渠道回复
- 需要判断是否存在过早承诺、证据不足或责任暴露
4. 不适用场景
- 尚未收到客户消息,只是准备主动开发
- 需要判断是否应该跟进客户,应使用
FOLLOWUP() - 需要分析一条询价是否值得投入,应使用
RFQ() - 需要做完整报价检查,应使用
QUOTE() - 需要处理客诉责任认定,应使用
COMPLAINT() - 需要进行内部汇报或向上沟通,应使用
REPORT() - 事实尚未确认,且用户要求直接承诺结果
5. 输入参数
输入包括必填参数和建议参数。所有输入必须区分已确认事实、待确认事项和用户期望,不得把缺失值或推测补成事实。
6. 必填参数
| 参数 | 说明 |
|---|---|
customer_message | 客户原话或完整上下文 |
confirmed_facts | 已确认事实 |
reply_goal | 本次回复目标 |
commitment_boundaries | 不可承诺边界 |
channel | Email、WhatsApp、WeChat 或其他渠道 |
output_language | 输出语言 |
7. 可选参数
| 参数 | 说明 |
|---|---|
customer_relationship | 客户关系和合作背景 |
project_stage | 当前项目阶段 |
tone | 正式、自然、简洁、坚定或缓和 |
length | 期望长度 |
questions_needed | 是否需要提问 |
next_step_needed | 是否需要推进下一步 |
forbidden_expressions | 禁止表达 |
available_solutions | 可提供方案 |
prior_reply | 用户原本准备发送的内容 |
urgency | 是否紧急或存在截止时间 |
8. 证据优先级
判断时必须按以下顺序使用证据:
- 客户原话
- 已确认的订单、报价、付款、发货和售后记录
- 采购、工程、财务或管理层的明确确认
- 当前项目文件和正式文档
- 用户明确说明的事实
- 历史沟通记录
- 市场信息
- 官网或公开信息
- AI 推测
不得用低等级证据覆盖高等级证据。AI 推测只能标记为可能性,不能写成确定事实。
9. 判断规则
第一步:识别客户真正关心的问题
不要只按客户字面逐句回复。识别客户主要关心的是价格、交期、库存、成色、配置、兼容性、保修、付款、风险,还是是否值得继续推进。
第二步:区分信息状态
将所有信息分为:
- 已确认
- 待确认
- 推测
- 不应对外表达
第三步:检查沟通风险
执行第 10 节的全部风险检查。
第四步:决定回复动作
只能从以下动作中选择:
- 直接回复
- 先补充信息后回复
- 先内部确认
- 先向客户澄清
- 暂时不回复
- 只做轻量确认
- 明确拒绝并说明边界
第五步:生成表达
只有在事实足够、边界清晰时,才生成可直接发送的回复。
渠道规则
- 结构完整、语气正式、重点清楚
- 可以适度补充背景
- 结尾有明确下一步
WhatsApp 或 WeChat
- 更口语化、更短
- 一次只推进一个重点
- 避免长段解释
- 不机械复制 Email
- 更轻量
- 不直接堆大量产品信息
- 先建立沟通入口
- 避免强推销
英文表达要求
- 不使用任何破折号
- 不使用过度正式或生硬的商务套话
- 不使用绝对化表达,除非事实已确认
- 不使用
we promise一类高风险承诺 - 不使用
the problem is caused by us一类责任认定,除非已确认 - 避免长句
- 优先使用自然、直接、可信的美式商务英语
- 不把内部角色冲突或采购困难直接告诉客户
10. 风险检查
必须检查:
- 是否过早承诺
- 是否把预计写成确定
- 是否把供应商口头反馈写成有货
- 是否暴露内部采购、工程或管理混乱
- 是否替公司承担不必要责任
- 是否替客户做了未经确认的判断
- 是否显得焦虑、催促或防御
- 是否承诺了无法控制的时间
- 是否忽略客户核心问题
- 是否缺少明确下一步
11. 输出结构
正式输出依次包含:
- 参数完整度结论
- 参数状态表
- 回复策略
- 风险提示
- 正式回复版本
- 更简洁版本
- 需要人工确认项
初步分析模式不得输出看似可直接发送的最终版本。
12. 禁止事项
- 无中生有
- 自动补全未确认事实
- 替用户承诺价格、库存、交期、保修或付款条件
- 把客户猜测写成客户真实意图
- 把市场推测写成事实
- 暴露内部采购、工程、供应商争议
- 强行生成 Email 和 WeChat 两个重复版本
- 为了显得完整而写得冗长
- 在信息不足时给出确定结论
- 覆盖用户已经确认的人工判断
13. 信息不足时的处理
关键参数缺失时,先输出:
当前无法稳定生成回复
然后列出:
- 缺失的事实
- 为什么这些事实重要
- 建议向谁确认
- 是否可以先发送临时回复
- 临时回复的安全边界
安全的临时回复可以只确认已经收到客户信息并说明正在核实,但不得承诺具体价格、库存、交期、保修或付款条件。
14. 人工判断边界
- 不覆盖用户已经确认的事实和人工判断
- 不替采购、工程、财务、管理层或客户作出未经确认的决定
- 不进行未经确认的责任认定
- 需要超出用户权限的承诺时,必须先内部确认
- 证据冲突时,指出冲突并请求人工选择,不自行覆盖高等级证据
- 市场信息、公开信息和 AI 推测不得替代订单、报价、付款、发货、售后或内部明确确认
15. 验收标准
一个合格的 REPLY() 输出必须:
- 回应客户真正关心的问题
- 不把推测写成事实
- 不过早承诺
- 不暴露内部问题
- 不承担不必要责任
- 有明确下一步
- 符合沟通渠道
- 语言自然
- 可以解释为什么这样回复
- 信息不足时敢于不生成完整话术
16. 当前状态
Version: 0.2.0
Status: Draft for testing
本版本需要通过真实客户沟通案例继续验证和修正。
参数解析流程
本 Skill 必须先解析用户输入并映射到参数表。
参数状态表
正式分析前,必须输出参数状态表。
参数状态只能使用:
已命中
部分命中
缺失
冲突
待验证
统一格式:
| 参数 | 必需程度 | 当前状态 | 已获取内容 | 缺失或冲突影响 |
|---|---|---|---|---|
| 待按本 Skill 参数填写 | 待确认 | 缺失 | 无 | 待判断 |
参数状态表必须基于用户输入,不得凭空补充。
最低运行条件
- 客户原话或上下文明确
- 本次回复目标明确
- 事实与待确认事项已区分
- 不可承诺边界明确
未达到以上条件时,先输出参数状态表,说明缺失或冲突内容、重要性、影响和可直接补充的字段,然后停止正式分析。
缺失参数处理
不得自动补全缺失参数,必须明确提示用户补充,并说明缺失参数、重要性、影响、补充方式及当前是否可以先做初步分析。
冲突参数处理
不得自行解决冲突,必须保留不同来源、标记冲突、说明影响并提示验证。在冲突解决前降低分析置信度。
待验证参数处理
待验证信息不得写成确定事实。供应商口头反馈、市场信息、预计库存、预计交期、公开资料、客户可能意图和 AI 推测等必须明确标记。
停止条件
出现以下任一情况时停止正式分析:
- 客户原话或上下文无法识别
- 回复目标不明确
- 事实与推测无法区分
- 不可承诺边界缺失
- 关键价格、库存、交期、责任或订单状态存在冲突
- 前置专业判断尚未完成
停止时必须说明原因、缺失或冲突字段、补充方式,以及应转入的相邻 Skill。
正式分析触发条件
只有达到最低运行条件,且关键缺失、冲突、证据来源、分析目标和风险边界已得到处理后,才进入正式分析。
初步分析模式
参数不完整时,只能提供明确标注的初步分析:
以下为初步分析,仍需补充关键参数。
不得把初步分析包装成确定结论。
正式分析模式
参数完整并满足触发条件时,才可输出正式分析。正式输出前必须再次检查参数缺失、冲突、待验证信息、推测、人工判断、职责边界和用户真实目标。
评论
加载中…