編輯導語：在電商系統中，訂單售後是整個平台系統最為重要的組成部分之一，好的售後産品能夠極大提升用戶對于整個電商産品的用戶體驗，提高口碑。産生售後的原因很多，處理平台本身的問題還有其他物流時效、配送員服務态度等因素，産品能做的就是設計一個高效的售後産品，可以快速響應用戶的售後申請。本篇作者就給我們分享了售後産品相關的内容，一起來看一下。

一、售後概覽

1. 售後原因與節點

首先我們來讨論一下為什麼需要售後。在前言中我們也說過了，有平台本身的原因也有其他因素的影響。比如我在電商平台上買了一個手機，我在訂單的不同節點中會産生不同的想法，從而産生售後的需求。比如提交訂單後我不想買了，這個時候就會産生退貨退款的想法。

又或者付款後，商品一周過去了還沒有發貨，也會産生退貨退款的想法。再比如收到手機後，發現拍照太假，也會産生退貨的想法。最後就是産品本身的質量出了問題，比如用了一周之後，手機話筒聽不到聲音了，也會想着申請換貨。所以，在訂單不同的節點，用戶會産生不同的想法，因此就會産生各種售後。所以，好的售後産品是客戶服務的核心模塊。

售後是針對訂單中的商品發起的，最常見的實物快遞類型訂單有四個狀态：待支付、待發貨、待收貨、交易成功。常見的售後類型有取消訂單、退款、退貨退款、換貨四種，維修類型的售後用的較少。

在訂單的不同節點，用戶可以發起的售後類型也不一樣，訂單待支付狀态下，用戶可以取消訂單；待發貨狀态下，用戶可以發起退款；待收貨與交易成功狀态下，用戶可以發起退款/退貨/換貨三種類型的售後。

需要注意的是，交易成功狀态下售後申請有時效限制，一般是7天或15天，超過後就需要用戶與商家自行商量了。用戶申請的售後會産生售後單，售後單與訂單相互獨立，對應的有不同的售後狀态，共用的初始狀态有待審核，結束狀态有售後成功或售後關閉，中間的狀态有待客戶發貨、待退貨入庫、待換貨出庫、待退款等狀态。

用戶下單後可以對訂單中的商品發起售後，支持對某一商品單獨售後或對訂單中的商品全部售後，根據不同的情況可以發起不同的售後類型。選擇商品和售後類型後，用戶需根據實際情況填寫申請信息，包括申請原因、描述、憑證等信息，若發起退貨類型售後則需填寫退貨地址，若發起換貨類型售後也需填寫換貨的售後地址。發起售後，客服審核完成則最終流轉至售後完成狀态或售後關閉狀态，至此，售後流程完結。

2. 售後處理

售後流程中有一個核心的環節—退款，在我之前寫的訂單相關的文章中就講到過訂單優惠的分攤，主要是涉及優惠活動、使用了優惠權益之後，就會涉及到商品實付款的計算。從下圖我們可以看出訂單經過一系列的優惠分攤後，應付款和實付款會有差異，差異的這部分就是優惠的金額。具體優惠分攤相關的内容可以查看我之前的内容。

不論是何種類型的售後，退款時會有一些共同的規則：

1. 商品金額，商品退款時隻退商品實付金額與支付時抵扣用的金币，使用的優惠券或促銷活動産生的優惠概不退還，即隻退商品的實付金額。
2. 運費，一般情況下發貨後運費默認不退。
3. 客服權限，客服擁有很大的自主權，可以修改退款金額，補貼運費。也可以根據用戶情況判斷責任。或者根據實際情況對用戶補償優惠券。即系統規則計算售後金額後，若用戶産生了疑異，客服會介入處理。

銷售訂單與售後訂單雖然相互獨立，但是也有一定的關聯。用戶可以對不同的訂單、不同的商品發起不同類型的售後，售後單獨立，訂單和售後單可以建立一對多的關系。同一個訂單可以發起多次售後，一個商品隻能對應一個售後，若有進行中的售後單，則不可對該商品再次發起售後。若原有售後單關閉，則可再次發起售後。

若發起的是退款類型的售後，則會生成一張對應的售後單和一張退款單，若發起的是退貨類型的售後，除了退款單還會生成一張退貨單用于商品的退換。如果商家有自研ERP或對接了第三方的ERP，發起退貨售後時，需要與ERP産生交互：如退貨需要生成退貨單（入庫任務），退貨入庫後才能退款。若沒有ERP，則無需該對接，由商家自行處理。

訂單的售後處理中，有一些可以注意優化的點，比如售後流程自動化，即可以由系統完成的事可以交由系統完成以提升效率，如根據售後單自動生成退貨單，這對于訂單量巨大的商家來說是一個非常重要的功能。第二是可以結合工單/IM系統，能夠更好地響應用戶的需求，直接與各個業務方直接對接。第三個是打通供應鍊，若涉及到與商品供應鍊相關的售後可以直接進行快速處理。

二、詳解售後流程與狀态

1. 售後詳情

上文我們提到了售後類型主要有取消訂單、退款、退貨、換貨、維修五種類型，我們暫不讨論最後維修這種售後類型。

首先是取消訂單，在訂單待支付狀态下可以發起。分為客戶主動取消或被動取消，主動取消是用戶提交訂單後未支付貨款，此時可由用戶主動發起取消訂單；被動取消是指用戶提交訂單未付款的狀态下，系統一般會設置一個自動關閉的時間以防止用戶惡意占單，且設置自動取消的機制可以防止用戶不付款産生的未完結訂單。

在訂單待發貨、待收貨、交易成功三種狀态下均可發起退款類型的售後。未發貨與已發貨狀态下發起退款售後對應的流程會有差别，未發貨狀态下發起售後需要由系統判斷倉庫發貨狀态攔截發貨，若攔截成功則自動同意退款，若無法攔截則由客服人工介入。已發貨狀态下退款則需客服介入審核，滿足條件再通過退款。

一般的退款流程是用戶發起售後，由客服審核，若拒絕退款則流程結束，售後狀态為售後關閉。若客服同意退款，則會生成對應的退款單，若需财務人員同意還需增加财務退款确認的步驟，确認後則退款完成，售後狀态為售後成功。

需要注意的是，為了節省人力提高審核效率，我們可以設置一些退款審核自動化的流程，比如支付後一定時間内（如30min）自動審核通過。還可以設置一些退款自動化的流程，比如若無需财務人員介入，直接調用接口在原支付單号發起退款即可。

除了訂單狀态，售後還伴随售後狀态的流轉，用戶發起退款售後申請，若拒絕退款則售後狀态結束，售後狀态為售後關閉。若同意退款則流轉至待退款狀态，退款後則售後結束，售後狀态為售後成功。

在訂單待收貨、交易成功兩種狀态下均可發起退貨類型的售後。一般的售後流程是用戶申請退貨，由客服審核，若拒絕退貨則需填寫拒絕理由，本次售後流程結束，售後狀态為售後關閉。若客服審核同意退貨，則等待用戶提交退貨信息，包括選擇退貨地址并填寫物流單号。

用戶提交退貨信息後，則自動生成退貨單，若商家接入了ERP系統則會在ERP系統中創建退貨入庫單，等待商品退貨入庫且确認商品實物與用戶描述一緻時，退貨單流轉為完成。退貨單完成後，會生成對應的退款單，若需财務人員審核則需增加财務人員審核确認的步驟，審核同意後則退款完成，售後流程結束，售後狀态為售後成功。

需要注意的是，在退貨入庫流程時需要由客服介入，若退回商品和描述不符則進入客服介入流程，與客戶協商售後方案。若同意協商方案則修改售後金額，若不同意協商方案則退貨商品，關閉售後訂單。

同樣的，退貨流程也同時伴随着售後狀态的流轉。用戶發起退貨售後申請，若拒絕則售後狀态結束，售後狀态為售後關閉。若同意則等待客戶退貨，客戶填寫退回信息後流轉至待退貨入庫的狀态，确認退貨後進入待退款狀态，财務人員審核同意後則售後結束，售後狀态為售後成功。

需要注意的是，在待客戶退貨或待退貨入庫兩種狀态下，都需設置時效限制，一般是7天或14天，若超時未反饋或超時未入庫則會自動關閉售後訂單，進入售後關閉狀态。

在訂單待收貨、交易成功兩種狀态下均可發起換貨類型的售後。一般的售後流程是用戶發起換貨申請，由客服審核，若拒絕換貨則需填寫拒絕理由，本次售後流程結束，售後狀态為售後關閉。若客服審核同意換貨，則等待用戶提交換貨信息，提交信息後可生成退貨單。

若商家接入了ERP系統則會在ERP系統中創建退貨入庫單，等待商品退貨入庫且确認商品實物與用戶描述一緻時，退貨流程結束。此時ERP系統會自動生成換貨出庫單，倉庫人員憑借出庫單發貨，發貨後整個換貨流程結束，售後狀态為售後成功。

我們可以發現換貨類型的售後就是在退貨售後的基礎上，增加訂單發貨的流程，可以簡單理解為是這兩種類型的業務的相加。

同樣的，換貨流程也同時伴随着售後狀态的流轉。用戶發起換貨售後申請，若拒絕則售後狀态結束，售後狀态為售後關閉。若同意則等待客戶退貨，客戶填寫退回信息後流轉至待退貨入庫的狀态，确認退貨後則可生成換貨出庫單等待換貨出庫，換貨出庫成功後則售後結束，售後狀态為售後成功。

需要注意的是，在待客戶退貨或待退貨入庫兩種狀态下，同樣需設置時效限制，一般是7天或14天，若超時未反饋或超時未入庫則會自動關閉售後訂單，進入售後關閉狀态。

2. 售後關鍵點

除了各個售後主流程的設計，售後産品的設計中還有幾個值得注意的關鍵點。

一是關于超時的處理，一般都會設置售後單超時關閉的機制。各節點都要有限時機制，保證售後處理時效，不論是由商家還是客戶原因引起的。另外，不僅是服務成本，售後過程中也會涉及到結算，也關系到訂單數據的統計，所以在這些流程中都需要設置一定的時限。

二是系統打通，售後一面需與訂單系統打通，方便查看售後對應的訂單信息。另一面需要與後端的ERP、WMS等系統打通，以實現退貨、換貨全流程的自動化，快速響應用戶的售後需求，打造更好地用戶售後體驗。

三是與客服&工單系統打通，以上小節的售後過程為例，在售後審核階段需要及時與客服溝通，确認真實情況。而在售後的收獲階段，若沒問題可以及時确認進行退款，若出現問題則可經由客服及時聯系客戶進行處理。除此之外，還可與工單系統打通，方便不同内部人員之間的流轉，比如客服、供應鍊、倉庫、财務等人員。

四是協商過程展示，系統可以記錄售後過程中的每一步狀态，展示用戶、商家、平台、系統等角色的動作，記錄關鍵售後信息方便後續的追溯。

3. 售後與供應鍊

在上一小節售後相關的介紹中，我們講解了若商家有對接ERP（進銷存）系統，售後需要與ERP系統産生交互。售後對接ERP系統主要是為了解決實物流的信息化，減少人工環節，針對訂單量較大的商家可以大大提高處理的效率。

主要是退貨、換貨環節需要涉及到與ERP的對接。針對退貨類型的售後，需要通過退貨入庫單來連接整個流程。針對換貨類型的售後，可以通過換貨入庫單、換貨出庫單來連接整個流程。

以換貨為例，我們可以用我之前在庫存篇介紹的分層模型去看這個流程。用戶在銷售層發起換貨，客服審核同意後由調度層生成換貨任務與退貨入庫單，待用戶将需換貨的商品退回至倉庫後，倉庫層憑借退貨入庫單檢查退貨商品并确認入庫，調度層接收到入庫成功的消息後一方面将此信息傳給銷售層，将售後訂單的狀态更改為待發貨。

另一方面，調度層需生成換貨出庫單，倉庫層憑借換貨出庫單去進行發貨的操作，換貨成功後，售後流程結束，銷售層的售後狀态變更為售後成功。

三、售後與訂單的聯結

前面我們詳細分析了售後的流程與售後狀态的流轉，這一小節我們來詳細說說售後與訂單的聯結。

總的來說，訂單狀态與售後狀态的流轉是相互獨立的，但是在售後狀态結束（售後成功）才會影響訂單狀态。

從商品維度來說，訂單詳情頁的商品會根據售後的狀态來展示商品售後狀态。售後狀态為退款中、換貨中、退貨中時，商品可以展示售後進行中狀态；售後狀态為已退款、已換貨、已退貨時，商品可以展示售後成功狀态；若售後被拒絕則商品可以展示售後關閉狀态。

這裡有一個二次售後的情況，一般情況下為了避免人效的浪費，我們會限制二次售後的情況：對一個商品來說，若售後關閉，則可再次發起售後。若商品對應的退款、退貨售後單已成功，不可再次發起售後。同樣的，換貨類型的售後一般也不支持二次售後。

當訂單中的全部商品發生售後時，才會影響訂單狀态。售後狀态與訂單狀态的關聯，總體的原則是當訂單中的商品全部退款時，訂單狀态才會變更為交易關閉，其他情況下訂單狀态不變。需要特别說明的是，一般情況下待發貨狀态時隻能申請全額退款，否則在待發貨狀态下退款不能交易關閉。

訂單的售後也會影響到訂單的結算。一般在平台電商中，用戶購物支付的貨款不會直接進入商家賬戶，而是先進入平台賬戶再結算至商家賬戶。

入賬節點是訂單完成（确認收貨）或者售後完成；結算周期一般有日/周/月三種，根據業務不同會有不同的結算周期；結算時間是T 1或者更長；費用方面，平台一般會收取技術服務費，費率與平台和品類相關，除此之外還有平台補貼與積分抵扣；訂單結算金額=實付金額 平台活動補貼-平台服務費。

四、總結

總結一下本文内容，主要有三部分的内容：掌握售後整個流程、詳細分析售後流程與狀态、分析售後與訂單的關聯。

1. 掌握售後整個流程：掌握各種售後類型（取消訂單、退款、退貨、換貨），了解每種售後類型對應的售後處理流程。
2. 詳細分析售後流程與狀态：對售後過程中不同類型的售後流程與狀态進行了詳細的分析，并探讨了售後與供應鍊的關聯。
3. 分析售後與訂單的關聯：分析了從商品和訂單兩個維度來看訂單與售後的聯結。

在電商系統中，售後系統是必不可少的模塊，售後系統的好壞會非常直觀地影響用戶的整個購物體驗，因此設計一個合理的售後系統是每一位電商産品經理應該要掌握的内容。

以上就是售後模塊所有的内容了，下一期，我将分享電商平台中的商家服務模塊相關的内容，盡請期待。

作者：書豐，公衆号：書豐産品記

本文由 @書豐 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部