從0到1構建電商平臺之售后系統:退貨退款

28 評論 23161 瀏覽 217 收藏 18 分鐘

售后類型基本可以分為四種情況:僅退款(未收到貨)、退貨退款(已收到貨)、換貨、補寄。這篇文章僅討論退貨退款的情況,我將從申請售后、退貨退款單狀態與操作、退貨分支流程、涉及其他版塊等4個維度來講解。

申請售后

首先,申請售后時需要選擇申請原因、填寫問題描述、上傳憑證圖片等三項操作,提交之后就會生成一條售后單記錄,然后進入后臺,待工作人員進行操作。

這其中最重要的就是申請原因。因為電商法規定“買家在簽收商品之日起七天內(按照物流簽收后的第二天零時起計算時間,滿168小時為7天)發起申請售后退換貨”,當用戶選擇申請原因為“七天無理由退換貨”時,用戶的主動權將會大得多,只要不是用戶自身的問題,如造成商品損壞影響二次銷售,商家是必須同意的。但是是否支持七天無理由退換貨是跟著商品走的,有些商品支持有些不支持,所以在添加商品時需要選擇。

由于我們公司做不到像淘寶的自有物流系統能及時抓取簽收信息反饋,就給了用戶10天(預計3天物流配送+7天無理由退貨),自發貨10天之后用戶將不能選擇該申請理由。

退貨退款單狀態對應操作

1. 用戶端狀態對應操作

審核中(修改申請、撤銷申請)、待買家發貨(填寫物流單號、撤銷申請)、待商家收貨(無)、已完成(無)、拒絕中(修改申請、撤銷申請)、已關閉(無)

2. 后臺狀態對應操作

待審核(通過、拒絕)、待買家發貨(無)、待商家收貨(確認收貨、查看物流)、待商家退款(確認退款、查看物流)、已完成(查看物流)、已拒絕(無)、已關閉(無)

如上圖,用戶端和后臺的退貨單狀態除了“待商家退款“都能一一對上(不像訂單那樣復雜,因為一個售后單只會對應一個商品),而用戶端省略“待商家退款“的目的主要是從用戶考慮,一是簡少用戶的認知成本,二是緩解用戶的焦慮。

而后臺為什么要有這一狀態是因為對商家來說,收貨是商品部干的事,退款是財務干的事,不同部門的權限不一樣,當然如果要做細一點,甚至可以財務有一套審批的流程(審批、打款等操作由財務和出納等角色操作),這里不做展開。

需要說明一點,當商家點擊通過時應該出現一個確認地址彈窗,也就是商家添加的退貨地址。該彈窗的目的是為了選擇一個退貨地址發送給用戶,同時也提醒商家退貨地址是否更改了。

退貨分支流程

其實退貨的正向流程很簡單就像上圖一樣不同的操作會變更不一樣的狀態,而復雜的是各種各樣的分支流程,這時就需要系統進行限制。

首先需要明確一點的就是用戶對訂單中某一商品申請售后,系統會凍結整個訂單的金額,而該條售后單未完結之前(處于已完成或已關閉狀態),商家將不能對該筆訂單的金額申請結算。比如用戶的某個訂單內買了A商品2件和B商品,只對A商品的其中一件進行申請,此時整個訂單金額都會進行凍結(為什么凍結整個訂單而不是僅該商品,在財務一章中會解釋)。

凍結訂單金額和加各種限制都是為了保障用戶和商家的利益。

1. 用戶端限制

(1)申請售后時間限制

首先,確認收貨分為用戶主動確認收貨和系統自動確認收貨,而一般自動確認收貨的時間規則我們是這樣定的,自商家發貨日起10天自動確認,比如淘寶是快遞簽收日起7天自動確認,但是淘寶有自己的物流系統,而我們做不到這一點,所以加上3天的物流時間(當然可以根據不同的商品屬性來設置不同時間)。

當確認收貨之后,再開始計算申請售后的時間,一般是15天,過了15天用戶將不能申請售后

(2)超時未處理限制

整個退貨流程需要用戶做的有兩步:

  1. 商家通過售后申請后,需要用戶回寄商品并填寫物流單號;
  2. 商家拒絕時,需要用戶修改申請并提交或撤銷申請。

如果用戶不進行操作,一般會給到7*24小時,時間截止后將會自動關閉售后單,用戶只能重新申請。

(3)修改申請次數限制

用戶可以進行修改申請并提交的操作在“審核中”和“拒絕中”都有,但是這里說的需要做限制是在“拒絕中”這一狀態。比如用戶被拒絕后,重復在7天時間結束之前修改申請并提交,商家也一直拒絕,那就可能會出現該筆訂單金額一直凍結中,商家無法結算。

為了防止用戶的惡意行為所以需要做一個限制,比如用戶最多只能申請3次,第3次被拒絕后只能申請平臺客服介入解決。當然,如果不加次數限制,也可以有時間限制,就是只有在可以申請售后時間內才能修改申請并提交;比如1號確認收貨,16號之前能申請售后,17號時就不能修改申請了,同時售后單自動關閉。

(4)申請售后次數限制

接著上面說的,如果用戶被拒絕后,撤銷了該退貨單,又重新申請,也有可能進入循環中,所以在申請售后這里也需要做次數限制。

這個次數限制肯定是在申請售后時間這個大前提以內,但這樣做的目的就是防止用戶惡意提交,對商家造成騷擾,當然這個限制可加可不加。

總結一下,在申請售后這里做的判斷有:首先判斷該訂單該商品有無進行中的售后單(包括換貨),有則不能申請;該商品如果有成功的退貨單,且之前退貨單中的申請數量小于該商品購買數量時可以申請,否則將不能;該商品的處于已關閉狀態的售后單是否小于三條,是則可以申請,大于等于三條時,只能申請平臺客服介入解決。當然這些限制都有一個大前提,該訂單處于售后時間內,超過則都不能申請。

2. 商家端限制

(待審核)超時未處理:用戶提交售后單,如果商家超時未處理,比如時間限制為7*24小時,將自動審核通過,并通知管理后臺的客服人員及時聯系商家。

待商家收貨/待商家退款)超時未處理:用戶回寄之后,此時商家該進行的操作有2步,確認收貨和確認退款,如果此時商家超時未進行操作,同樣將由管理后臺的客服人員介入,甚至可以給到客服和財務人員直接退款的權限(當然這要考慮公司章程和部門組織架構)。

當然,還可能出現的情況就是,比如用戶發回空包裹或亂填物流單號或發回的商品出現破損之類的,這時就需要商家申請客服介入的功能。

涉及其他版塊

一個退換貨會涉及到的其他版塊有商家、商品、財務、營銷等,這些版塊之間可能會存在一些數據的聯動,所以需要考慮進去。當然這些版塊主要是后臺的數據,用戶端的感知并不大。

1. 商家

一般平臺會對每個商家有一個評分,和一套獎懲制度。

評分的目的可能更多的影響用戶端,評分高的商家下的商品出現在用戶面前的幾率更大,不管是搜索結果排名更靠前還是猜你喜歡等流量入口展示。而退換貨肯定會影響評分,比如用戶申請原因選擇為“七天無理由”時可能不計入分數,而選擇為質量問題,或商家服務態度問題而不想要了,這肯定會影響該商家評分的降權。

獎懲制度更多關乎于平臺與商家的聯動,這個就要根據公司不同時間段的業務需求來制定了,比如因質量問題退貨占比高于多少的商家,需要罰多少錢,或一些特定活動不能參加。

2. 商品

退貨涉及到與商品的聯動有2個維度,該商品的分數庫存

上面說的是商家的評分,但是每個商品肯定也會有自己的一套計分規則,這樣搜索引擎從數據庫里拉商品出來后才會有一個先后順序的展示。而退貨則會影響降權,這里面的計算規則很復雜,而且也得根據公司當前的業務目的來制定,這里不做展開。

用戶下單并支付后就會扣除該商品的庫存,成功退貨后也將還原庫存。當然也得看該商品是否被刪除或者該sku是否已刪除。

3. 財務

訂單中的金額信息與退貨會產生關聯的有運費、金幣抵扣、實際支付金額、結算金額。

(1)運費

首先,得判斷回寄商品的運費該由哪方承擔和是否該退用戶支付的運費,所以就得判斷是用戶自身的原因還是商品的原因(我們平臺還未介入運費險)。

有兩個方案:

  1. 由系統介入,通過申請原因來判斷,比如七天無理由退貨就是用戶承擔,商品質量問題就是賣家承擔,此時就比較復雜,可能會存在商家先把貨款提走后用戶再申請退貨的情況,這樣就會在保證金里扣除運費(詳細會在財務一章中解釋);
  2. 是賣家和用戶在線下自行協商。

個人認為,如果由系統來介入感覺好像對商家更強制一點,對用戶更有保障一點,但是賣家肯定會鉆空子,比如告知用戶不要選擇哪些申請原因,這樣反倒對用戶是一種騷擾,倒不如更開放一點,讓雙方更自由的溝通。

接下來說該多少退用戶支付的運費。先解釋一下,運費是由運費模板計算而來,且又分為按重量計算和按件數計算(先不討論按體積計算,使用的太少)。

比如按重量計算該運費模板為首重2kg,首價10元,續重1kg,續費3元;某一sku重量為0.7kg,那買1~2件需付運費10元,3~4件需付10+3元,5件需付10+3+3元,6件需付10+3+3+3元,這樣算出來的運費就是不規則的。問題就出現了,當我買6件,需付運費19元,那當我申請退貨1件,應該退多少運費,申請3件,又應該退多少。

按照運費模板的計算來退顯然不合理,有一個方案就是按平均數,比如退3件退的運費就是19/6*3元,或者固定退多少元,比如你付了10元運費只退5元,付了20元只退10元,其實都并不是那么合理,可能我暫時未想到更合理的方案,有方案的大佬歡迎在評論區大家一起交流!

所以基于退運費金額的問題,我更偏向于上一段的第二個方案,就是賣家和用戶在線下自行協商,退多少運費由你們自行商量決定。

最后是回寄運費的問題。如果確實是商品的問題,用戶支付多少回寄運費是不知道的,而系統唯一能計算的就是根據運費模板,但是肯定也存在不準確的地方,比如商家和快遞公司談好后,付的運費比用戶付的要少。所以,最好的方案就是商家和用戶進行協商。

順帶提一句,如果平臺有滿減運費的功能,可能存在的風險就是,比如用戶買2件包郵,申請未收到貨僅退款,那就可能會對商家造成損失。所以退款的時候可以做扣除運費后再退的功能。

(2)金幣抵扣和實際支付金額

用戶可以通過我們平臺的一些途徑獲得金幣,類似京東的京東可以用作購買商品的補貼。用戶在提交訂單的時候就會把金幣按一定比例分攤到各個商品頭上,比如A、B、C三個商品售價分別為20、30、50元且分別購買2件,你有20元金幣,就可分別抵扣4、6、10元,所以當對A商品其中一件申請退貨時,將會退還你現金18元和2元的金幣。

(3)結算金額

是指平臺抽傭后商家能結算的金額,比如商品售價100,平臺抽傭5元,商家能結算95元。當用戶成功退款之后將在可結算金額中扣除這一部分結算金額。

然后說一句,為什么售后和訂單沒有關系。如果看過之前我寫的訂單系統就知道我之前設計的是售后單和訂單之間的狀態各自獨立,互不干涉。比如一個訂單中只有一個商品,只對這個商品發起售后時,訂單狀態發生改變,比如叫“退款中”,那這樣還說得過去;但是當一個訂單中存在多個商品或多個購買數量時,如果一部分商品發起了售后而一部分沒有發起,那就不好說了。所以最簡單的方案就是訂單和售后單狀態相互獨立。

所以,訂單的后續操作如確認收貨、評價等和售后狀態沒關系,自動確認收貨時間倒計時與該訂單中是否存在售后單也互不影響。

因為我們平臺暫未涉及優惠券,滿減(如滿200減50)等營銷功能,本篇就不做展開,主要是我還沒做過這些功能,可能對立面的一些細節想得不夠全面,反而對各位造成誤解。

以上就是我對退貨系統的解讀,如果有不合理或者其實有更好方案的地方,歡迎各位大佬指出,同時提出意見!

之前我寫過訂單系統的三篇文章,收到一些反饋,有評論說我寫得太詳細可以精簡一些,也有說我就是應該寫得這么細別人才看得懂。我也在反思,如果僅僅是為了閱讀量可以把標題寫得唬人一點,為了點贊量可以把內容精簡一些讀起來更順暢一些。但是我寫文章的目的之前也說過,一是為了復個盤,二是為了和大家討論,發現我寫得不合理的地方。其實還有一點是我自己的感觸,才做電商的時候很懵逼也踩過很多坑,我希望盡量把這些踩過的坑都寫出來,希望能給人一點參考作用。

相關閱讀

從0到1構建電商平臺之訂單系統(3):處理訂單

從0到1構建電商平臺之訂單系統(2):支付訂單

從0到1構建電商平臺之訂單系統(1):提交訂單

 

本文由 @橘鉆 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 一個訂單中同一個商品購買多個,部分數量退貨退款,這種如何處理呢,目前淘寶和京東貌似都沒做同一商品讓用戶自行填寫部分數量的退貨功能

    來自江蘇 回復
  2. 如果2個商品,1個是已經收貨要退貨退款,1個是未發貨狀態要退款,用戶2個都不想要了,可以一個按鈕統一申請退款嗎,還是要每個商品單獨申請退款和退貨退款

    來自上海 回復
  3. 寫的很詳細,很喜歡這種講述風格,舉得例子也很好很詳細;
    不過有個疑問,為什么一個訂單,有一個商品在售后中的時候,就不能再申請售后了,每個售后單不也是獨立的嗎,一個訂單包含A、B兩個商品,A商品在退貨退款中,B商品可以申請退款中或換貨嗎?

    來自貴州 回復
  4. 你好~請問一下你文章的流程圖是用什么軟件畫的?用戶端和后臺之間的連接虛線是用什么功能畫的呀~

    來自廣東 回復
  5. 首先看到這樣的文章感覺非常棒~ 有個小小的疑惑,目前無論電商模式的淘寶、天貓、京東,還是到店模式的美團(團購業務)最后都是把訂單和售后單分開,且相互有關聯,這個本質上是為什么要分開?求大神分享一下看法。感謝~ 我目前的理解是有兩方面,第一,電商場景,單子面向的人群不一樣,訂單面向的是發貨部門,售后單面向的是客服部門,這塊到店業務,我沒找到原因,第二,單純為了做分類(有點站不住腳)~

    來自北京 回復
    1. 你說的第一點是對的,像我們公司發貨是倉管,售后是客服處理,把售后單用一個單獨的列表陳列,這樣就可以只給客服售后單列表的權限,對大公司來講也是一種降低風險的方式;從產品設計上來講,把訂單和售后分開也是為了降低耦合度,兩個板塊只通過如訂單ID來關聯,但互不影響;還有一點就是一個訂單會對應多個售后單,如果放在一起會很雜亂

      來自重慶 回復
  6. 一個售后單只會對應一個商品,這塊設計是出于什么考慮。用戶不能針對訂單中多個商品一并申請退貨退款么?求大神解答

    回復
    1. 可以針對多個商品一并申請售后,淘寶的你可以試試;一個售后單對應多個商品在邏輯上是沒問題的,但是我覺得像淘寶這種申請方式可能是為了提高用戶申請的操作門檻,降低退貨率

      來自重慶 回復
  7. 寫的很不錯,先贊一個
    有個小疑問,針對自營平臺,請問如果商家收貨后只給他同意和拒絕的選擇(他的同意和拒絕是針對商品驗收是否合格),退款操作在平臺財務進行,有什么弊端嗎

    來自廣東 回復
    1. 暫時我沒想到有什么弊端;像淘寶是一樣的,商家確認退款后,系統自動退回給用戶,進來多少就退回多少(部分退款加優惠折扣這種情況,在訂單處就已經算清楚每個商品的實付金額),和你說的是一樣的,不需要商家去打款;當然可以根據業務需求,設計商家審核退款這一步,防止退款金額過大的情況,這一步是為了預防有些用戶專門整商家,付了款又退回,導致商家的損失

      來自重慶 回復
  8. 請問為什么需要退運費呢,運費只是支付給物流公司的,用戶退貨退款,不應該把支付給物流公司的運費也退給用戶吧

    來自北京 回復
    1. 如果是商家問題,用戶不用承擔運費,這時需要退運費的

      來自江蘇 回復
    2. 是的,你在淘寶一家店買衣服,給你發一件破的衣服,那你當然想退款和運費咯,畢竟商家的原因導致你等這么多天還不能有結果已經不爽了,這時還要你承擔運費肯定覺得不合理

      來自重慶 回復
  9. 待發貨狀態申請售后,商家拒絕用戶的申請后,這時候在訂單列表,該單商家還能繼續發貨嗎?

    來自廣東 回復
    1. 看公司業務的需求,如果待發貨狀態的訂單,用戶端的按鈕是取消訂單,那就不存在拒絕申請了
      如果是申請售后,且被拒后,這時售后單是拒絕中狀態(不是已關閉狀態,用戶可以修改申請后重新提交,也可以主動撤銷或超時未提交之后成為已關閉狀態),可以用戶的售后單成為已關閉狀態才能發貨,這樣做的目的是完全尊重雙方,你們要達成一致之后才發貨,但可能存在耗時較長的情況,畢竟不是當面溝通
      也可以未發貨狀態用戶申請售后,商家只能同意不能拒絕,這樣做和取消訂單的區別是,需要商家去同意,相比用戶單方取消起到強提醒的作用

      來自重慶 回復
  10. 有沒那種退貨的,比如餐飲,點了一堆菜,退了一個,又退,多次退,可能其中涉及到 當時點了5個有優惠,那退貨這優惠怎么解決呢

    回復
    1. 在最初生成訂單時就要把優惠分攤好,這樣便于后期退貨

      來自江蘇 回復
    2. 是的,一般來說有優惠的訂單在生成時就會把優惠金額按比例分攤到不同商品上,退的話也好退
      在生成這個優惠券或者套餐時也可以限制,使用的訂單最多能退幾次

      來自重慶 回復
  11. 這個系列已經結束了嗎?非常專業,非常喜歡,期待更多這樣的!

    來自湖南 回復
    1. 哈哈,謝謝

      來自重慶 回復
  12. 學習了,寫得很詳細!后面應該會用到先提前儲備下

    回復
    1. 謝謝

      來自重慶 回復
  13. 關于運費部分,可通過快遞鳥上門取件API接口實時返回與快遞員確認的重量和運費金額,通過快遞鳥上門取件API也可返回快遞單號,不用用戶填寫物流單號,也可以實時獲取該物流單號的軌跡狀態, 1-已攬收, 2-在途中, 201-到達派件城市, 202-派件中, 211-已放入快遞柜或驛站, 3-已簽收, 311-已取出快遞柜或驛站, 4-問題件, 401-發貨無信息, 402-超時未簽收, 403-超時未更新, 404-拒收(退件), 412-快遞柜或驛站超時未取等狀態,電商可根據這些狀態做判斷。

    來自湖南 回復
  14. 有個疑問,商家收到貨后能不能拒絕退款的,“待商家收貨”這一步只能讓商家“確認收貨”嗎?如果用戶寄回來的貨有問題怎么處理呢?

    來自廣東 回復
    1. 1.商家收到貨后不能拒絕退款,如果把這個功能做出來,商家直接自己就能拒絕退款的話,就相當于給商家開放了這權限,不能保證商家不會去鉆這個空子,動不動就拒絕了;如果這時平臺要去監控哪些商家拒絕了,就相當于增加了平臺工作人員的工作量;所以商家只要同意了用戶的退貨申請,要么只能給用戶退款,要么就申請平臺介入,比如確實用戶寄個空包裹或者人為損害了商品
      2.為什么要有“待商家收貨”這一步驟的目的在于,可能一些商家是有多個部門的,比如收貨是業務部,退款是財務部,考慮到這些部門的權限可能是不一樣的,所以就多一步出來;如果一些商家沒有這么多部門,多點這一步其實也不會增加多少工作量
      3.回寄的商品有問題就申請平臺介入,理由上面說了;其實我們當時這樣做的更多考慮在于,權限放給外人的越少越好,你不知道別人會拿著這些權限來干嘛,比如回寄的商品其實是運輸途中損害的,商家就直接不退款了,可能我們就會損失這個用戶了;確實出現了這樣的原因,我們公司也會出錢來貼給用戶,所以這也得看公司的規定

      來自重慶 回復
  15. 寫得很好,很清晰,場景都有描述得很清楚了,感謝!

    來自廣東 回復
    1. 哈哈,謝謝

      來自重慶 回復
  16. 多放點圖

    回復