电商的售后业务影响到消费者的体验，需要考虑的问题如下：
一、主要业务点，分为必填和选填（必填是简化后的功能，能满足基本要求，但不完善，选填参考京东实现）
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、代码结构
1、退款业务单独建个类，封装微信、支付宝等退款逻辑，对外提供单一接口
2、可快速禁用接口退款功能，恢复线下退款功能
3、退款失败可能情况
1、 账户余额不足
2、退款金额大于订单金额