从退货需求，到申请回执。
接收售后退货需求，根据客户及商品信息自动生成并提交退货申请；查询待办任务、退货进度和退货详情。
原单核验
授权客户和店铺、售后单号、申请或待处理状态及时间范围。
退货申请
接收客户退货申请，根据客户、商品信息发起退货，生成正式退货单，提交申请；支持查询单据详情。
进度跟踪
正式退货或售后单号、提交状态、单据详情和异常原因。
把原单核验、退货申请与进度跟踪衔接起来。
面向渠道业务、经销商服务与交易管理人员。
日常工作中的四个卡点
AI团队如何衔接这些工作
从不同任务起点，找到合适的协作方式。
点击切换，查看具体指令与结果。
由渠道退货查询执行师承接
查询并抓取系统中新增申请的售后单据列表。
由渠道退货申请执行师承接
接收客户退货申请，根据客户、商品信息发起退货，生成正式退货单，提交申请；支持查询单据详情。
沿着业务顺序，完成渠道退货申请。
各节点按权限和当前业务状态衔接。
核对业务条件
原订单DD20260920001；SKU-A可退10件，本次退2件、金额100元；质量原因。
退货详情查询
查询并抓取系统中新增申请的售后单据列表。
退货申请
接收客户退货申请，根据客户、商品信息发起退货，生成正式退货单，提交申请；支持查询单据详情。
核对结果与依据
退货申请提交不代表退款已完成。
正式退货或售后单号、提交状态、单据详情和异常原因。 累计退货量≤原单可退量；退货申请提交不代表退款已完成。
对接哪些系统，交换哪些信息。
建议对接方案 · 按系统职能配置
数据、业务动作与结果来源
读取退货售后列表、详情和退款状态；创建退货申请、提交并查询状态。
读取原订单、商品、数量及实付金额；校验客户、原订单、可退商品及数量。
保存退货凭证。
本场景的业务条件
原订单DD20260920001；SKU-A可退10件，本次退2件、金额100元；质量原因。
累计退货量≤原单可退量；退货申请提交不代表退款已完成。
每一步，保留必要的核验与依据。
让数据、权限、状态与业务结果对应。
业务归属
核对客户、会员、仓库或组织等业务对象，只处理当前用户可见范围。
关键条件
累计退货量≤原单可退量。
业务边界
退货申请提交不代表退款已完成。
处理前核验
取数期间与有效状态保持一致；执行操作前复核权限、单据状态及用户确认。
结果追溯
退货申请提交不代表退款已完成。
复核口径
按同一对象、期间和状态统计，保留结果明细；比率分母为0时不计算比率。
2位数字员工，分工清晰。
渠道退货申请团队
渠道退货查询执行师
查询并抓取系统中新增申请的售后单据列表。
渠道退货申请执行师
接收客户退货申请，根据客户、商品信息发起退货，生成正式退货单，提交申请；支持查询单据详情。
业务人员确认客户、单据、金额与操作意图；审批和资金操作按已有授权办理。
订单、渠道、资金及审批系统保存业务单据、执行记录和当前状态。
清楚的能力范围，明确的业务交接。
本团队支持
- 退货详情查询：查询并抓取系统中新增申请的售后单据列表。
- 退货申请：接收客户退货申请，根据客户、商品信息发起退货，生成正式退货单，提交申请；支持查询单据详情。
衔接条件与职责边界
- 累计退货量≤原单可退量。
- 退货申请提交不代表退款已完成。
用具体指标，衡量业务价值。
示例基线 → 建议目标
售后查询准确率
抽检一致查询数÷抽检查询数。 按自然月；同口径取数。
退货申请一次成功率
首次提交成功申请数÷首次提交申请数。 按自然月；同口径取数。
以上基线用于业务场景示例，目标用于配置和评估；按各指标注明的期间、对象及分母核验。
落地前，需要准备什么？
把业务数据、规则、接口和责任人准备清楚，让场景顺利进入实际业务流程。
验收时，核对这些具体结果。
建议按以下样本与阈值核验，逐项记录测试结果。