
售后问题通常带有订单状态、时间限制和责任判断,同一句退换货规则并不适用于所有订单。售后知识库如果只保存简短结论,AI容易忽略条件,给出超出店铺政策的承诺。
配置时要把政策来源、适用条件、所需材料和转人工节点写完整,让AI负责解释流程,而把结果确认交给有权限的人。
一、破损申请的完整处理
买家收到破损商品时,第一条回复先确认订单和破损部位,并说明需要的照片,不要直接承诺“马上全额退款”。资料齐全后,AI可以生成问题摘要并创建售后任务;退款金额、是否补发以及责任归属由有权限的人员确认。
二、售后场景要拆开写
| 场景 |
先确认什么 |
AI可以做什么 |
必须转人工的情况 |
| 未发货取消 |
订单状态 是否已出库 |
说明申请入口 收集订单号 |
已拣货 例外费用或无法取消 |
| 破损错发 |
签收时间 图片 商品和包裹 |
说明材料要求 建立售后记录 |
责任争议 补偿和退款金额 |
| 主观退货 |
市场规则 期限 商品状态 |
解释标准流程 |
超期 特殊品类或例外审批 |
| 质量与质保 |
购买时间 故障表现 使用条件 |
完成基础排查和资料收集 |
安全问题 多次故障或赔偿诉求 |
售后知识条目中最重要的不是政策结论,而是条件。期限、订单状态、商品状态、所需证据和例外路径缺少任何一项,都可能让同一句“可以退”变成错误承诺。
三、确认售后政策的正式来源
先以店铺当前公布的退换货、退款、质保和取消规则为准,再核对平台要求与当地市场差异。历史话术只能作为问题样本,不能直接替代正式政策。每条知识应标记生效时间,政策更新后及时下线旧版本。
四、上线前核对这些设置
| 配置环节 |
具体做法 |
验收标准或边界 |
| 按售后场景分别建条目 |
未发货取消、已发货退货、商品破损、错发漏发、质量问题和主观不满意的处理条件不同,应分别维护。 |
一个条目解决一个场景,写明买家需要提供的信息、客服下一步动作以及可能进入人工审核的条件。 |
| 把时间和状态条件写清楚 |
售后规则常依赖签收时间、订单状态和申请原因。 |
知识内容不能只写支持退货,还要说明在什么期限内、商品需要保持什么状态、是否需要图片以及费用如何确认。缺少关键条件时,AI应先追问而不是直接判断。 |
| 限制退款和赔偿承诺 |
退款金额、补偿方案、运费承担和例外处理通常需要权限判断。 |
AI可以说明一般政策、收集订单号和问题证据,并生成供人工参考的摘要,但不应在无法核实责任时承诺具体结果。转人工后应完整传递已收集的信息。 |
| 区分市场店铺和商品规则 |
同一品牌在不同平台或国家可能使用不同退换期限,有些特殊商品还存在不可退条件。 |
知识条目应绑定市场、店铺和商品范围。无法确认买家来源时先识别订单,避免把一个市场的政策套用到另一个市场。 |
| 准备异常和争议处理路径 |
出现安全问题、强烈投诉、平台申诉、重复退款或买家与系统记录不一致时,应停止自动给出结论。 |
知识库要说明如何转交、需要保留哪些证据以及由谁复核,让高风险问题尽快进入人工流程。 |
五、用历史售后会话做复测
抽取处理成功、被驳回、需要补充材料和最终升级投诉的真实案例,检查AI能否区分条件并正确转人工。上线后重点观察人工改写、买家重复解释和错误承诺,优先修复影响退款与责任判断的知识。
六、开始配置前先确认三件事
- 确认售后政策的正式来源:先以店铺当前公布的退换货、退款、质保和取消规则为准,再核对平台要求与当地市场差异。
- 按售后场景分别建条目:未发货取消、已发货退货、商品破损、错发漏发、质量问题和主观不满意的处理条件不同,应分别维护。
- 把时间和状态条件写清楚:售后规则常依赖签收时间、订单状态和申请原因。
七、相关阅读