电商项目系列文档(四):售后的设计(退换货)
电商的售后业务影响到消费者的体验,需要考虑的问题如下:
一、主要业务点,分为必填和选填(必填是简化后的功能,能满足基本要求,但不完善,选填参考京东实现)
1、申请售后对象:订单为单位,不能选择数量(必填)、订单中某个商品为对象,可选择数量(选填)
2、用户申请售后时机:已支付未发货/已收货(必填)、除退款后任何情况都可以申请售后(选填)
3、售后流程:用户申请/取消<-->客服通过/拒绝<-->物流通过/拒绝<-->财务通过/拒绝
二、售后流程:
a) 用户退换货流程
a1) 用户申请退换货,流程跳转到b
a2) 用户撤销申请,流程结束
a2) 用户撤销申请,流程结束
b) 客服流程
b1) 客服通过退换货,流程跳转到c
b2) 客服拒绝退换货,流程跳转到a,用户再次审核
c) 物流流程:物流流程加入主要是防止已发货的订单被退款
c1) 物流通过退换货,流程跳转到d
c1) 物流通过退换货,流程跳转到d
c2) 物流拒绝退换货,流程跳转到b
d) 财务流程
d1) 财务通过-->退款,流程结束
d2) 财务拒绝,流程跳转到c
三、用户申请售后填写项目:
第一步:
1、服务类型:换货、退货、维修
2、申请数量:可小于购买数量
3、申请凭证:有发票、无发票(非必填,无发票需要扣除相应税点)
4、检测报告:已有检测报告、尚无检测报告
5、问题描述
6、上传图片:最多三张、每张不超过5张,支持JPG、BMP、PNG(非必填)
第二步(大部分信息可从购买信息中取默认值):
第一步:
1、服务类型:换货、退货、维修
2、申请数量:可小于购买数量
3、申请凭证:有发票、无发票(非必填,无发票需要扣除相应税点)
4、检测报告:已有检测报告、尚无检测报告
5、问题描述
6、上传图片:最多三张、每张不超过5张,支持JPG、BMP、PNG(非必填)
第二步(大部分信息可从购买信息中取默认值):
1、商品返回方式:送货至自提点/快递到京东/上门取件
联系人、联系电话、上门取件还需填写取件地址、取件时间等
联系人、联系电话、上门取件还需填写取件地址、取件时间等
2、确认收货信息(售后处理完成后商品返还):收货地址(省市区、街道、详细地址)
四、其它注意事项
1、退换货的运费问题
a) 订单未发货时取消退运费
c) 订单已发货后退换货退不退运费和公司政策相关
2、售后流程反复
a)、用户申请后,自己取消,再申请
b)、用户申请后,被客服驳回,用户再申请
c)、客服通过后,被物流驳回,客服驳回到用户端或再次审核通过
d)、物流通过后,被财务驳回,物流再审核
3、用户取消售后申请场景
a )用户申请后,又取消了申请
b) 客服同意后,用户取消了申请
c) 物流同意后,用户取消了申请
d) 财务退款后,用户不能取消申请
4、其它
a) 售后最小单位是商品,而非订单(初期可以订单为售后单位)
b) 售后可以选择商品数量,比如购买了5个商品,只需要退换货其中的2个(可能有质量问题或已损坏)
五、数据表的设计
1、售后流水信息表(运维查看)
编号、服务单号、订单号、用户编号、商品编号、商品数量、操作类型(用户申请、客服审核通过、客服审核拒绝、物流审核通过、物流审核拒绝、财务审核通过、财务审核拒绝)、业务操作人(用户申请为用户编号、客服审核为客服编号)、操作时间、业务操作描述(如用户申请原因、客服拒绝原因)、备注、IP
2、售后流水信息表(用户查看)
说明:用户需要看到售后的审核流水概况,比如审核通过,系统内部流程可能流转了客服、物流、财务、仓储等,但是对于用户看到的就是审核通过
表结构:编号、服务单号、经办(人或系统)、经办时间、经办描述
3、订单售后信息表
说明:订单的业务庞大,可将部分业务拆分,比如物流信息、退换货信息、支付信息等,以退换货信息为例,如果考虑到一个订单可以分成多次退换货,那么该表和订单表就是N:1的关系,否则是1:1。表中的信息为退换货业务最后一次操作的信息,并非流水记录
表结构:服务单号、订单号、商品编号(SKU)、商品数量、状态(如审核通过、审核不通过等)、内部状态(用户审核通过、客服审核不通过等)、申请人编号、申请时间、问题描述、审核人编号、审核人业务类型、审核留言、审核时间、评价时间、评价内容
注意事项:
1、重新申请售后会生成一个新的服务单
2、根据服务单去查询运维、用户的审核状态和流程
2、根据服务单去查询运维、用户的审核状态和流程
六、退款信息
1、每次退款无论成败都记录流水日志,日志表设计需兼容微信、支付宝、银行卡等类型
2、代码结构
1、退款业务单独建个类,封装微信、支付宝等退款逻辑,对外提供单一接口
2、可快速禁用接口退款功能,恢复线下退款功能
3、退款失败可能情况
1、 账户余额不足
2、退款金额大于订单金额