“给客户回一下”看似是小事，却最容易在忙的时候出错：退款时效写错、权限范围说大、没有问清订单号就承诺处理。让 AI 从空白起草整封回复，语气通常很好，事实却不一定可靠。更稳妥的做法是先把高频工单拆成可审核的回复组件，再让 AI 组合和个性化。
从真实工单里找“重复任务”
不要先按产品菜单分类。抽取近一个月已解决工单，先按用户想完成的任务归组：找回账号、修改发票、导出数据、取消订阅、邀请成员、查询物流。每组保留十条左右原始案例，标记最终解决方式、必须询问的信息、不能承诺的内容和需要转人工的条件。
同样叫“退款”的问题，是否已发货、是否过试用期、付款渠道是什么，都会改变答案。宏的价值不是写得统一，而是先把这些分支放在客服看得见的位置。
一个回复组件包含什么
- 确认句：复述用户问题，不假设原因。
- 条件问题：订单号、账号、时间、版本或截图等必要信息。
- 已确认步骤：只写已有政策或帮助中心支持的操作。
- 边界：时效、资格、权限和例外情况。
- 转交规则：何时交给账务、技术或人工客服。
把每个组件链接到政策页、产品文档或内部 SOP。政策改动时，更新一个来源即可，而不是在几十段话术里搜索旧日期。
让 AI 填空，不让它创造政策
你是客服回复助理。根据用户消息和以下已批准回复组件，生成简洁回复。只能使用组件中的政策、时效和能力；信息不足时先提出必要问题，不要猜测订单状态或承诺结果。若触发转交条件，说明已转交给哪个团队和用户接下来会收到什么通知。输出前列出使用了哪些组件和仍需人工确认的信息。
ChatGPT 或 Claude 可用于草拟与分类。输入前应删除密码、银行卡、证件、完整订单数据和敏感投诉细节；客服系统中的最终回复仍由有权限的人发送。
每周抽查，而不是等投诉发生
每周抽 20 条 AI 辅助回复，检查四件事：是否引用了过期政策；是否漏问关键条件；是否把可能写成确定；是否把本该升级的工单留在一线。把错误归回组件，而非只改一封邮件。若同一问题连续出现，就补产品文档或优化流程，不要只把话术写得更长。
AI 最适合减少重复表达，不应成为新的承诺来源。组件有来源、回复有边界、异常有转交，客服速度和准确性才能同时提升。
把一个“退款问题”拆成可执行分支
不要做一段“您好，退款会尽快处理”的万能宏。先列出进入条件：付款渠道、购买日期、是否已使用服务、是否已发货、是否是续费、是否有重复扣款。每个条件对应已批准的下一步。例如用户只说“扣费了”，第一条回复应索要订单号和扣款截图；客服不能先承诺退款，也不能让用户在公开回复里发送完整银行卡信息。
组件可以写成：触发条件 → 必问字段 → 可说事实 → 禁止承诺 → 升级团队 → 完成信号。这样新人知道什么时候使用，质检也能检查一封回复究竟错在政策、判断还是语气。
给组件加字段模板
- 意图：取消订阅 / 重复扣款 / 发票修改。
- 用户需要提供：订单号、账号邮箱、购买渠道；只在安全工单渠道收集。
- 批准事实：官方政策链接、处理时效区间、可执行步骤。
- 边界：不可退款情形、需要人工审核的例外、不要使用的绝对措辞。
- 升级：账务、风控、技术支持；升级后由谁在何时通知用户。
当政策更新时，负责人更新组件版本并标注生效日期。AI 起草时必须使用最新版本；旧组件不能只靠“大家记得别用了”。
质检不只看满意度
每周抽样时同时记录首次回复时间、一次解决率、错误升级率、政策引用错误数和用户再次追问率。满意度低不一定是语气问题，可能是流程本身需要资料太多；满意度高也不代表回复准确。把错误类型回写到组件后，才会越用越稳定。
上线前检查清单
- 每个宏是否有政策来源和生效日期？
- 是否明确了信息不足时先问什么？
- 是否写清不能承诺的价格、时效、资格或结果？
- 异常、投诉和敏感信息是否有安全升级路径？
- 客服是否能看到 AI 使用了哪些组件并可编辑最终回复？