編輯導讀：電商購物中，經常會有對商品不滿意的情況，這種交易糾紛無法避免。這時候就需要建立交易糾紛系統，糾紛處理系統（OP）是一個for平臺集中處理投訴單的地方，本文作者對糾紛單在平臺客服處理階段的優化處理方式展開分析，希望對你有幫助。

一、交易糾紛處理系統是什么

電商場景下，由于商品品控和商家服務的層次不齊，糾紛投訴是一件不可避免的事情。糾紛處理系統（OP）是一個for平臺集中處理投訴單的地方。

本文不討論糾紛的全流程，僅討論糾紛單在平臺客服處理階段的優化處理方式。

二、為什么要做階段劃分

糾紛單流轉到客服處理階段，前置情況往往是雙方未和解或是超時未處理的狀態，這個時候，需要客服根據用戶和商家提供的憑證，來判斷這個case是誰的責任，以及需要誰做出補償動作。

因為這一階段涉及舉證、判責、核實憑證等操作，流程較復雜，故對客服操作階段做劃分，旨在通過標準化的方式，保證糾紛單的處理效果，提高糾紛單的處理效率，提升用戶&商家的糾紛體驗。

2.1 降低客服的學習成本

電商場景下交易糾紛的細分場景紛繁復雜。即使不討論case的多樣性，僅僅在某一糾紛單的維度，客服操作流程也很長，需要客服理解和操作的部分很多，這花費了客服很多時間去熟悉流程。

如果客服需要處理其中的一環，那么準確性和效率都會提高很多。同時，隨著處理次數的增加，客服對這一環節也會越來越熟悉，準確性和效率進一步得到提升。

學習曲線

2.2 降低客服的操作成本

由于客服對某一階段很熟悉，隨著糾紛單量的變大，帶來的規模效益可以明顯降低成本。

規模效應

2.3 降低客服的轉換成本

由于客服處理階段涉及多個環節，單一客服處理造成客服在不同部分之間操作和轉化技能，造成不必要的轉換成本浪費。

如果客服只處理某一階段，那么就能省去大腦在不同階段間切換的成本，從而提高效率與效率。

三、怎么做階段劃分

講了這么多鋪墊，標準化的落地是這個part。

糾紛處理系統的標準化總共分為4個階段，不同階段的客服處理人員不同，每個客服專注做一個階段。客服在這里的所有操作均為點擊已配置好的標準化選項，無需主動編輯字段。

3.1 客服接手節點 隱藏狀態

糾紛單客服接手操作節點的前置狀態是待客服接入，后置狀態為待客服處理，即進入糾紛操作的第一階段，同時，客服接手的操作者與第一階段的操作者為同一人。

之所以設置客服接手這個環節，是因為在糾紛處理系統的前期，還沒有分流的策略，這一part將會在本文第4部分講到。

關于隱藏狀態，這個狀態是for待用戶/商家補充憑證等不需要客服操作的狀態下，糾紛單不出現在糾紛處理系統，節省客服瀏覽時間。同時每一個階段都是對上一階段的QC（質量檢查），具體這些狀態將會在下文提到。

3.2 真·第一階段：選擇糾紛現狀 首次判斷是否需要補充憑證判斷商品品類 糾紛現狀，包括用戶與商家是否和解/超時未處理，以及雙方已提交的憑證描述。判斷是否需要補充憑證，如需要，則向用戶/商家/雙方發起補充憑證；如不需要，則直接點擊進入判責階段。

3.3 真·第二階段：判斷是否需要二次補充憑證

第一階段選擇完糾紛現狀 發起舉證后，糾紛單進入第二階段，即被第二個客服撈起（本階段及下面的階段無客服接手節點）。

由于這個環節存在循環舉證的可能性，故整個糾紛處理的大多數人可能會集中在這個環節。

判斷是否需要二次補充憑證，如需要，則向用戶/商家/雙方發起補充憑證；如不需要，則直接點擊進入判責階段。

3.4 真·第三階段：判責

來到這一階段，糾紛單的來源可能是第一、第二階段，客服在這里，依據前置客服推動帶來的用戶/商家憑證，進行判責。如無法判責，則返回第二階段。

客服根據前置階段雙方的憑證，選擇判定商責、客責、雙方有責、雙方無責。

責任歸屬判定完成后，糾紛進入下一階段：核實賠付。

3.5 真·第四階段：核實賠付

面對來自第第三階段的糾紛單，他們的責任可能是廣義商責（包括商責、雙方有責）和廣義客責（客責、雙方無責）。

對于廣義商責，需要商家退款或者用戶退貨后商家退款。這里的資金流可能是線上系統自動劃扣（商家賬上余額充足），亦可能為線下打款后上傳憑證（商家賬上余額不足）。不論是否通過上線還是線下退款，客服在這步都需要核實商家退款是否屬實。對于廣義客責，客服可判斷是否需要使用客訴費進行平臺賠付，用于安撫用戶的情緒。在核實完退款憑證/客訴費賠付后，客服將糾紛單流轉至隱藏狀態，使得完結的糾紛單離開糾紛系統。

四、未來優化方向4.1 對于糾紛處理本身：優化糾紛整體流程

分析糾紛單狀態，優化操作框選項。

這個系統是否work的一個重要因素為選項框內的業務選項是否適配糾紛場景。這里的選項設置，直接影響客服操作的效果和效率。大量case的積累有助于平臺對選項內容做調整，兼容多場景糾紛。

分析糾紛類目 客服操作，優化用戶&商家側糾紛流程。

通過分析不同類目糾紛單的舉證次數及舉證內容，可以在用戶&商家前端優化提示提交最能幫助處理case的材料，使得糾紛單無需進入第二階段，甚至無需客服操作，直接和解。

糾紛單自動分流，實現客服處理的千人千面。

糾紛處理的千人千面，即根據同一客服在不同階段、不同類目、不同糾紛發起場景下的用戶滿意度，對其有針對性地推送相關標簽的case，讓專業的人干專業的事。

4.2 對于平臺治理業務：拉通鄰近業務

分析糾紛類型，支持商品品控建設。

任何平臺治理的業務，我相信其核心都是商品品控。糾紛的高效處理，能夠倒逼商家提升自己的品控，從而提升整個平臺的品控，使得平臺層面的整體的糾紛原因從「商品質量問題」等對用戶損傷較大的類型轉移至「商家未履行贈品承諾」等損傷較小的類型。

拉通平臺治理措施，支持其他業務。

大家都知道，糾紛是平臺治理中一項極其基礎的兜底業務，故所有業務的問題都有可能會流轉到糾紛環節。基于此，糾紛更是能夠看到其他業務在平臺、用戶、商家三方的表現，同時，糾紛結果也能為其他業務基礎的數據支持。

以上，產品新人的簡單思考，不當之處，還望各位大佬指正。

本文由 @咔喔Archer 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議