外观
寄送修概述
概述
寄送修适用于客户需要把故障产品寄回服务中心或厂家维修、更换的售后场景。企业可以在服务请求中提供寄修申请入口，并把寄件、服务中心处理、返寄和客户签收串联为一条可跟踪的服务流程。
适用场景
寄送修主要解决以下问题：
- 终端用户从企业配置的服务号或小程序入口提交寄修申请。
- 系统根据客户地址和产品信息推荐寄回的服务中心。
- 企业已完成物流合作及系统对接时，终端用户可在提交服务请求时一键下单寄件。
- 服务中心和客户分别处理收件、返寄和签收，相关人员通过物流记录与服务进度了解当前环节。
寄送修依托服务请求运行。启用插件只是第一步，管理员还需要配置服务中心、终端用户入口、流程节点和服务进度；需要一键下单时，还要完成物流能力对接。
核心概念
| 阶段 | 主要处理人 | 主要动作 | 进入下一阶段的条件 |
|---|---|---|---|
| 提交申请 | 终端用户 | 提交寄修申请；已启用一键下单时可同时创建寄件物流 | 寄修申请已提交，产品开始寄往推荐的服务中心 |
| 维修件签收 | 工程师或流程中配置的其他角色 | 确认服务中心收到维修件；也可以按物流状态自动签收 | 维修件已签收，可进入企业配置的维修处理流程 |
| 维修件寄回 | 工程师或流程中配置的其他角色 | 维修完成后填写返寄物流信息，并通过物流下单接口下单 | 维修件已从服务中心寄出 |
| 客户签收 | 终端用户 | 确认收到修好的产品；也可以按物流状态自动签收 | 客户已签收，寄送修主链路结束 |
NOTE
系统预设的是 维修件签收、维修件寄回 和 客户签收 3 个寄送修应用节点。企业可以按实际业务增加其他流程环节，因此实际页面中的节点、处理角色和状态可能不同。
核心配置与作用
| 配置 | 作用 | 关键条件或限制 |
|---|---|---|
| 寄送修插件 | 在服务请求中启用寄送修能力 | 启用后仍需完成后续配置 |
| 服务中心 | 维护地址，并限定适用的产品范围和客户地址范围 | 系统使用客户地址和产品信息推荐寄回地址；原始资料未说明多中心同时匹配或无中心匹配时的处理规则 |
| 终端用户入口 | 在服务号或小程序中提供自助寄修入口 | 入口需要单独配置和发布 |
| 一键下单 | 让终端用户在提交服务请求时完成物流下单 | 属于可选能力，取决于企业与物流公司的合作及系统对接情况 |
| 寄送修流程节点 | 把签收、返寄、客户签收纳入业务流程 | 节点处理角色、自动签收条件及附加流程按企业配置执行 |
| 服务进度组件 | 展示服务请求当前所处节点 | 状态来自服务请求字段 服务进度（API Name：service_progress），支持自定义状态选项 |
需要注意的边界
- 寄送修不等同于现场上门服务，产品需要在客户与服务中心之间寄送。
- 一键下单不是启用寄送修后自动具备的通用能力。未完成物流合作或接口对接时，不应按一键下单流程验收。
- 自动签收依赖物流状态变化及对应流程配置。未满足条件时，需要由流程中配置的角色处理签收节点。
- 服务进度组件读取
service_progress字段。新增状态选项不代表流程节点会自动产生或自动流转，状态与流程之间的对应关系需要在测试请求中验证。 - 上游资料没有说明服务中心多重匹配、无匹配结果、物流下单失败和物流状态延迟时的系统处理方式，这些情况应结合企业实际配置验证。