退款例外审批

要解决的问题

一线客服和主管经常遇到一类棘手请求：客户诉求明显超出退款或补偿政策覆盖范围，比如已过售后期要求全额退款、政策未定义的安抚方案、金额超出单次审批上限。这类个案无法走标准流程，但总得有人把「为什么要破例、破例的成本和风险是什么」说清楚，交给主管或财务加签。

问题在于，这些信息通常散落在聊天记录、工单备注和口头沟通里。申请人写一句「客户很不满，希望特批」，审批人却看不到政策缺口在哪、有没有类似先例、批了会不会形成示范效应。来回确认几轮，一次例外申请能拖上好几天。

技能如何工作

这个技能把例外个案收拢成一份结构化的对内审批说明（Markdown），固定包含七个字段：申请摘要、政策缺口、金额与成本、已知先例、风险、建议决策、待确认事项。空白模板见 references/exception-brief-template.md。

工作分三步：

• 澄清：按字段逐一确认信息。订单/个案 ID 可脱敏；客户诉求与已发生事实不得编造；必须先给出常规政策结论，说明「标准路径为什么不够」；金额形式可以是退款、优惠券或赠品等。
• 整理：金额只使用用户给出的数字，不自行估算或补全；先例无证据时写「未提供先例，待确认」，绝不虚构公司先例或损失金额；风险只描述可观察后果（客诉升级、成本增加、示范效应），不渲染恐吓；建议决策提供批准、部分批准、驳回、升级法务或财务四个选项，最终由人拍板。
• 输出：生成可直接进入审批流的 Markdown 文档。

适用边界

几个容易误触发的场景需要明确区分：

• 政策内的标准退款分流应使用退款个案说明类技能，本技能不写「是否可退」的常规对照。
• 需要发送给客户的安抚话术不在范围内，本技能只产出对内文档，不做 customer-reply-draft。
• 发票异常、票账差异归因不在范围内。
• 不连接支付或电商后台，不会自动打款，也不出具法律意见。

常见用法是在 AI 助手里直接说：「用退款例外审批，写这个超政策补偿的审批说明」。