電商產(chǎn)品退貨退款的那些事

簡之箐
43 評論 75304 瀏覽 555 收藏 8 分鐘
🔗 B端产品经理需要进行售前演示、方案定制、合同签订等,而C端产品经理需要进行活动策划、内容运营、用户激励等

接《訂單系統(tǒng)總結(jié)》章節(jié),上面所講的都是訂單的正向流程中的履單,逆向流程并沒有介紹,今天我們就主要說說訂單逆向流程這些事。

由于歷史原因,官網(wǎng)并未做訂單逆向流程,每天所有的退款都需要客服人員手動錄入系統(tǒng)處理,不但效率低,還容易出錯。因此這次做訂單系統(tǒng)規(guī)劃時(也考慮了逆向流程),主要從以下幾點介紹:

1. 訂單狀態(tài)機

逆向流程節(jié)點及其狀態(tài)確定,見圖:

總結(jié):訂單狀態(tài)的確定,我們當(dāng)時規(guī)劃的時候和研發(fā)同時開了三次會,最終確定;經(jīng)過就不多說了。主要說下訂單狀態(tài)確定思路吧。

我們當(dāng)時是先畫了一個訂單的主線流程圖,然后在訂單的主線流程圖每個節(jié)點開始考慮都會存在哪些狀態(tài);最終前臺確定了這六個狀態(tài),但后臺的訂單狀態(tài)可遠遠不止這些;基本上要比前臺的狀態(tài)多了一倍還要多;當(dāng)然會有這么多狀態(tài),也是因為交互的系統(tǒng)比較多導(dǎo)致;一般初期的電商系統(tǒng)這幾個狀態(tài)也夠用。

2. 退款場景

從狀態(tài)機中不難看出,退款發(fā)生的場景主要有以下幾類

  1. 未付款時,取消訂單;系統(tǒng)自動取消訂單一般會根據(jù)自身公司實際情況來決定;我們當(dāng)時是因為有占存的概念,因此暫定是30分鐘
  2. 已付款待發(fā)貨申請:因為公司的倉庫都是自己的,可以控制;因此可以根據(jù)實際情況來做攔單,同時客服審核后可直接退款
  3. 已付款且已發(fā)貨申請:這塊一般公司會根據(jù)自己的規(guī)則決定是否先行退款還是是收到退貨后再退,一般業(yè)務(wù)會根據(jù)實際情況處理售后。在此,既要考慮用戶體驗,又要考慮商品退貨風(fēng)險

3. 退款業(yè)務(wù)流程

其實,做后臺系統(tǒng),需求調(diào)研的時候,他們也說不出個一二三,除非經(jīng)驗比較深的,或許能提出一些信息點;很多時候是需要產(chǎn)品經(jīng)理主動給出一條思路進行引導(dǎo)的;經(jīng)過和相關(guān)部門的溝通,最終確定了業(yè)務(wù)流程,具體如圖:

用戶操作流程圖:

總結(jié):根據(jù)不同的訂單狀態(tài),顯示不同的退款類型入口。

一般對于退款申請,未發(fā)貨的訂單申請退款都可以整單申請退,邏輯上相對要簡單一些;如果是退款退貨,相對來說比較復(fù)雜

  • A. 無各種優(yōu)惠的時候 ,選擇某一商品申請退款,申請后按業(yè)務(wù)流程處理即可;
  • B. 訂單有優(yōu)惠的時候,選擇某一商品申請退款,則牽涉到退款金額的計算。

如:兩件商品A(20元)、B(80元),訂單共100元;提示滿90包郵;現(xiàn)在用戶申請退A商品,就牽涉到退款金額計算;是按比例退款,還是是按實際售價退;所有的金額計算要和相關(guān)業(yè)務(wù)部門溝通,根據(jù)實際情況來確定退款金額計算規(guī)則后執(zhí)行。

4. 后臺系統(tǒng)交互

經(jīng)過和其他系統(tǒng)的產(chǎn)品經(jīng)理溝通,最終的交互圖也確定了下來。當(dāng)然出具的這些流程圖需要根據(jù)公司的實際情況來設(shè)計規(guī)劃,提供的只是些可借鑒的圖

5.原型圖和PRD

根據(jù)上述的流程圖大致清楚了列表及其功能點。也就可以逐步出具原型圖和PRD了。

原型和頁面不做過多介紹,其實都是按照上述的流程圖確定頁面和功能點后,按照實際需要來出具原型視圖,畢竟對于業(yè)務(wù)來說,這些他們最直觀了解產(chǎn)品的初衷。

客服退款審核列表

客服退款審核詳情

財務(wù)退款詳情

總結(jié)

1. 用戶填寫的退款申請,是需要區(qū)分是退款還是是退貨的。

  • 未發(fā)貨的退款—可以直接進行系統(tǒng)退款的
  • 而退貨,是需要查詢退貨登記中是否已簽收的
  • 只有已經(jīng)簽收的財務(wù)才會去退款,當(dāng)然,客服也可以根據(jù)實際情況來決定是否要提前給用戶退款

2. 如果公司無多個系統(tǒng),退款也就不會有多個系統(tǒng)復(fù)雜交互;做產(chǎn)品最終還是要根據(jù)公司實際情況考慮,而上面的流程,僅是我工作總結(jié)得一部分。

不洗勿噴,有不正確的地方,還請同行們指證。

 

作者:簡之箐,微信公眾號:簡之箐,5年互聯(lián)網(wǎng)產(chǎn)品經(jīng)理,曾擔(dān)任醫(yī)藥產(chǎn)品經(jīng)理和電商產(chǎn)品經(jīng)理,經(jīng)歷主導(dǎo)過電商平臺的系統(tǒng)整合規(guī)劃。

本文由 @簡之箐 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

題圖來自PEXELS,基于CC0協(xié)議

專欄作家

木北的產(chǎn)品成長路,微信公眾號:木北的產(chǎn)品成長路,人人都是產(chǎn)品經(jīng)理專欄作家,互聯(lián)網(wǎng)產(chǎn)品經(jīng)理,曾擔(dān)任醫(yī)藥產(chǎn)品經(jīng)理和電商產(chǎn)品經(jīng)理,經(jīng)歷主導(dǎo)過電商平臺的系統(tǒng)整合規(guī)劃。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

題圖來自 Unsplash,基于 CC0 協(xié)議

該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。

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

    來自江蘇 回復(fù)
  2. 商品發(fā)貨了,然后買家拒收,寄回來的郵費由買家承擔(dān),應(yīng)如何設(shè)置呢

    來自湖北 回復(fù)
    1. 你說的是什么樣的場景下發(fā)貨拒收的呢?如果是用戶下單成功后商家發(fā)貨拒收,就需要在自己的系統(tǒng)退款規(guī)則中去設(shè)置,是否是買家承擔(dān)運費,來扣減運費后進行退款;主要還是要看是在什么環(huán)節(jié),什么場景下做的退款,根據(jù)實際的場景再去分析如何設(shè)置的問題!

      來自北京 回復(fù)
  3. 第一張圖建議不要 用黃色背景色白色字體,這種搭配是看不清的

    來自廣東 回復(fù)
  4. 部分退貨部分退款怎么辦

    回復(fù)
    1. 不是有訂單狀態(tài)、退款單狀態(tài)嗎?只是有關(guān)聯(lián)關(guān)系。

      來自上海 回復(fù)
    2. 可以參考我的文章

      來自北京 回復(fù)
  5. 請問如果是 審核不通過 下一步操作應(yīng)該是什么

    來自上海 回復(fù)
  6. 有個問題想問你一下,如果一筆訂單多個商品,有一個商品在待發(fā)貨狀態(tài)下申請退款,被拒絕了,拒絕理由是已發(fā)貨;當(dāng)用戶收到了貨之后,是否有入口發(fā)起退款退貨入口

    來自浙江 回復(fù)
    1. 根據(jù)公司的實際業(yè)務(wù)場景來決定要不要留退款退貨入口。一個是發(fā)貨中的退款,一個是售后問題;

      來自北京 回復(fù)
  7. 你的實退金額是默認的還是可以更改的,如果是因為你的商品質(zhì)量問題,那退回的商品的運費誰來承擔(dān)?我覺得你的后臺應(yīng)該增加一個是否退運費的功能

    來自浙江 回復(fù)
    1. 運費能不能退和公司業(yè)務(wù)流程、制度有關(guān)??梢愿鶕?jù)公司的實際情況來決定要不要增加運費修改的功能

      來自北京 回復(fù)
  8. 流程圖搞的好復(fù)雜

    來自上海 回復(fù)
  9. 有個問題,退款需要財務(wù)審批,那退款的狀態(tài)是不是應(yīng)該就是:待退款、待審批、退款中、退款完成(已退款)、退款關(guān)閉 共5個狀態(tài)呢?

    同時財務(wù)審批的時候?qū)徟鷨螒?yīng)該會需要的狀態(tài)是:待審批、審批中、審批完成(同意/不同意)呢?

    希望解答下,這樣子是否合理?謝謝 ??

    來自北京 回復(fù)
    1. 對,可以這樣設(shè)定哦?。。?/p>

      來自北京 回復(fù)
    2. 請問待審批和審批中有什么區(qū)別呢?

      來自江蘇 回復(fù)
    3. 審批如果是多級審批,可以有審批中這個狀態(tài);如果不是,可以沒有這個狀態(tài)的。具體的你要根據(jù)自己公司的實際業(yè)務(wù)需要來決定。

      來自北京 回復(fù)
    4. 好的謝謝,才看見 ??

      來自江蘇 回復(fù)
    5. 是的,作者回答的比較正確,如果有多級審批人,是會有審批中這個狀態(tài)的。

      來自北京 回復(fù)
  10. 產(chǎn)品小白遇到過的問題,敬請不吝賜教 ??

    1,判斷庫存有無是否應(yīng)該由平臺配合運營半自動化進行,且應(yīng)該在買家下單之前,直接在付款之前就將交易友好中斷,
    2,關(guān)于已付款待發(fā)貨狀態(tài)下退款是否需要進行審核,而是直接退款;
    3,多件訂單且有運費情況下單件退貨運費是否分拆,且如果涉及到優(yōu)惠券和積分是否需要分拆退還;

    來自北京 回復(fù)
    1. 1. 判斷庫存買家下單會做判斷,因為有些平臺是全渠道營銷,倉庫實際庫存和系統(tǒng)庫存的更新時間差問題導(dǎo)致發(fā)貨時發(fā)現(xiàn)庫存不足
      2. 對于已付款待發(fā)貨狀態(tài)下的退款可以根據(jù)實際業(yè)務(wù)場景不做審核,直接退款
      3. 多件訂單且有運費情況下單件退貨運費會根據(jù)實際的業(yè)務(wù)來進行分拆,優(yōu)惠券和積分可以分拆退還,以可以不退還的;具體要看公司業(yè)務(wù)。

      來自北京 回復(fù)
  11. 拆單,部份發(fā)貨,分潤,手續(xù)費,大額,時間差異這些都要考慮

    回復(fù)
    1. 對,這些都是需要考慮的。這些點會根據(jù)公司的實際情況按公司計算實際的退款金額

      來自北京 回復(fù)
  12. 1、上面好像沒有售后換貨流程。
    2、上面的流程售后好像都是以訂單為單位進行售后,如果訂單內(nèi)部分商品售后、多次售后,這些情況都是這么處理的。
    能稍微也介紹下么,謝謝。

    來自浙江 回復(fù)
    1. 是的。售后的這塊沒有做過多介紹。因為每個公司的業(yè)務(wù)流程都不一樣,處理方式也會有一些差別。
      至于你說的售后可以從以下幾點考慮
      1. 破損補寄:客服登記補貨原因后生成工單,庫房補寄處理
      2. 換貨:
      錯發(fā)—兩種處理方式;
      不需要將錯發(fā)貨品寄回庫房,直接客服登記生成工單,庫房補寄
      用戶將錯發(fā)貨品寄回,填寫寄回快遞單號;庫房收到貨后做換貨退回入庫,庫房補寄
      用戶買錯要求退貨,將換貨貨品寄回,庫房補寄,將寄回貨品做退回入庫
      3. 漏發(fā)
      庫房訂單貨品漏發(fā),客服登記生成工單,庫房補寄
      4. 分批發(fā)貨
      一筆訂單多個貨品,部分貨品有貨,部分需要用戶等;可先將有貨貨品先行發(fā)出;無貨商品來貨后庫存更新,庫房再次發(fā)貨等
      總結(jié):售后大致這些,當(dāng)然還會存在其他的情況,這里不做過多說明。如果想要更細致的了解,后期會專門出具相關(guān)文章說明。
      說明:其實關(guān)于售后,最主要還是要看公司的實際業(yè)務(wù)流程,來策劃實際的售后系統(tǒng)功能。

      來自北京 回復(fù)
  13. 狀態(tài)機很清晰,可是我現(xiàn)在還不分不清狀態(tài)機和流程的實際區(qū)別 ??

    來自海南 回復(fù)
    1. 多看,多想,多畫,多總結(jié),慢慢就清晰了。一個新的事物都是逐步從不清晰到清晰的

      來自北京 回復(fù)
    2. 個人感覺流程就是把狀態(tài)機中描繪的東西更加細化一點,更加具體一點,具體是怎樣去操作這些步驟的~@簡之箐 是這樣嗎?

      來自北京 回復(fù)
  14. 文章總體寫的方向是對的,但是有幾個地方可以進階討論下:(我就想到啥說啥了)
    1.大部分中小型電商系統(tǒng)會將RMA放在OMS或者ERP中,而不是單獨處理,實際上RMA的處理方案是非常復(fù)雜的;
    2.關(guān)于退款的金額計算方面,是比較復(fù)雜的,一般會有兩種,分?jǐn)偡ê头此惴ǎ罢咭子诶斫?,后者更為精,并且要考慮單個訂單多次退貨的情況;
    3.訂單的處理,建議不要將退貨放在訂單狀態(tài)上,如果這樣設(shè)計,會導(dǎo)致在業(yè)務(wù)獨立,擴充的時候產(chǎn)生無法擴充的囧狀,實際訂單會發(fā)生這么集中單據(jù),1.(前臺)訂單;2.拆單訂單(如果有拆單);3.物流單(一般貴WMS管理);4.售后單,建議分開處理,然后建立單據(jù)中心(這是目前金蝶和天貓的做法),來進行對外封裝。
    4.退貨的情況實際上非常復(fù)雜,尤其是在做跨境或者海外的情況,會有物流中丟包,實際上這也涉及到退貨(這塊比較復(fù)雜,實際上會有多發(fā),少發(fā),錯發(fā),丟件,物流退稅等很多情況),對于這塊的處理,需要同時兼顧,訂單,WMS庫存,財務(wù)賬目和ERP的整體數(shù)據(jù)。
    5.另外,退貨不建議直接跟財務(wù)交互,不過文中的實際業(yè)務(wù),看起來WMS,是沒有從ERP中獨立出來的(不知道為啥,一般電商WMS非常重要),而是RMA與WMS交互,WMS和財務(wù)或者ERP交互,這樣保證WMS與財務(wù)系統(tǒng),物、錢是一直的。
    6.WMS中對于退貨,實際上也是比較難處理的,因為有一些東西的價值太小,實際回收商品的金額 可能還不如一個物流的錢高(當(dāng)然,這是免物流退貨的情況),所以要考慮虛擬退貨的情況;
    7.WMS中對于售后這塊的處理是做逆向單,但是逆向單同時要兼顧換貨單,這塊也比較復(fù)雜;
    8.另一個,不屬于本文的探討范圍,實際也可以發(fā)散考慮的,退貨翻新的問題,或者重新上架,這塊從業(yè)務(wù)上說屬于售后服務(wù)業(yè)務(wù),但是系統(tǒng)處理上屬于WMS和SCM的處理范圍,要考慮RMA,WMS,SCM,ERP,訂單商品的整個交互。

    來自廣東 回復(fù)
    1. 分析的真好。學(xué)習(xí)了,非常感謝?。?!
      第一點:分開處理是因為業(yè)務(wù)需要,現(xiàn)在的業(yè)務(wù)處理退款單,財務(wù)需要多個系統(tǒng)切換查詢,因此統(tǒng)一將退款單據(jù)集中最終放到財務(wù)系統(tǒng)處理;
      第二點:退款金額的計算確實比較繁雜,需要細化
      第三點:退貨狀態(tài)和訂單狀態(tài)是分開的,會生成不同的單據(jù),可能是狀態(tài)機未表現(xiàn)清晰
      第四點:您上面提到的少發(fā),漏發(fā)錯發(fā)等情況,由于時間倉促,所以未做過多的描述。這塊是計劃放在售后系統(tǒng)中細說
      第五點:我們的倉儲是和WMS系統(tǒng)再一起的,歷史原因,公司系統(tǒng)比較繁雜您提到的這些現(xiàn)在基本上都在ERP中,導(dǎo)致ERP現(xiàn)在運作很慢,因此在逐步往出遷
      第六點:您說的這種情況,我們現(xiàn)在確實存在,但是目前都僅僅只是做了一個記錄統(tǒng)計,實際的流程并未形成閉環(huán)
      第七點:非常贊同您的觀點,確實是比較復(fù)雜
      第八點:退貨翻新 這應(yīng)該和電商行業(yè)屬性有關(guān),可能更集中在數(shù)碼類,電器類等;對于藥品,不存在翻新問題。

      很開心能收到您的分享,學(xué)習(xí)了。非常感謝?。?!

      來自北京 回復(fù)
    2. 真厲害,方便留微信嗎?以后得多像您學(xué)習(xí)?。?!

      來自北京 回復(fù)
    3. 沒有接觸過電商,將所有縮寫查了一遍,好厲害

      來自北京 回復(fù)
    4. ?? 被各種虐出來的 不過現(xiàn)在想想那幾年還是值得的

      來自廣東 回復(fù)
  15. 非常不錯

    來自浙江 回復(fù)
    1. 謝謝!??!有更好方案的,歡迎指證。

      來自北京 回復(fù)
  16. 對與退貨退款,庫存這塊具體是怎么處理呢?

    來自北京 回復(fù)
    1. 有退貨的,收到貨物后會做退貨入庫,商品可銷售庫存增加;

      來自北京 回復(fù)
    2. 嗯嗯,我在這方面還是個新人,以后多多交流~

      來自北京 回復(fù)
    3. RMA通知WMS生成逆向收貨單,倉庫收到之后做逆向入庫單,收貨和入庫匹配,增加售后好料或者壞料區(qū)庫存,然后看需不需要翻新,如果需要進SCM,翻新之后重新上架。

      來自廣東 回復(fù)
    4. 順便看了你上面的回復(fù),很受教,多謝。

      來自北京 回復(fù)
  17. 看過你寫的好幾篇文章了,有不少都是我目前也正遇到的問題,感謝!

    來自上海 回復(fù)
    1. ??

      來自北京 回復(fù)
  18. 結(jié)論呢?

    來自江蘇 回復(fù)
专题
42891人已学习17篇文章
谈到互联网产品,我们不得不谈的就是它的盈利方式,这也是产品人经常会被问到的问题。
专题
12364人已学习12篇文章
本专题的文章分享了系统首页设计指南。
专题
33889人已学习17篇文章
让我们来扒一扒跨境电商的风险和机遇|从业者必看
专题
16746人已学习16篇文章
ERP是一种以系统化的方式,将企业内部所有的业务流程和数据进行整合和管理的软件系统。本专题的文章分享了ERP系统设计指南。
专题
15744人已学习13篇文章
B端运营应该是产品商业化的最终结果。本专题的文章作者结合自身B端运营经验,进行B端实操项目方法论分享。