電商的售后業務影響到消費者的體驗，需要考慮的問題如下：
一、主要業務點，分為必填和選填（必填是簡化后的功能，能滿足基本要求，但不完善，選填參考京東實現）
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、退款金額大於訂單金額