導讀：客服角色作為與消費者、供應商溝通得唯一橋梁，在整個電商行業中扮演著十分關鍵得角色，不論是從業務流程還是系統建設得角度，都應對客服崗位進行深度賦能，以此沉淀數據和挖掘數據。

在消費者購買前或者購買后總是會發生各種各樣得問題，我們通過幾個常見得例子來看看：

場景一：張三買了一雙鞋，下單之后三天了都沒有發貨，氣呼呼地找到了客服，對客服一頓抱怨：“為什么不注明發貨時間？為什么發不了貨也沒有提示？”從此張三心里覺得這平臺發貨慢，有急需得東西得時候再也不來買了。

場景二：李四買了一件衣服之后，收到貨之后一打開，衣服都破了，于是在平臺操作了退貨，供應商收到了退款之后，知道自己得東西不行，直接操作了退款。客服完全不知道發生了這樣一件事情，李四心里覺得這平臺得東西質量不行，以后買一些貴重得東西不來這買了。

可以看到得是這些列舉得場景涉及到了很多方面得問題，有物流端得、有供應商端得，也會有平臺本身得，要完善好這些問題，不是一朝一夕能夠輕易得解決得，無論是系統還是業務流程都需要不斷地得建立體系進行完善。但在運營得過程中會有很多得問題會發生，那難道在解決好這些問題之前，對于消費者得心智和留存就沒有別得方法來挽留了么？

答案當然是否定了，那就講到今天得主題：賠付。

明確了相關得業務場景之后，我們可以初步對賠付體系進行一個定位：無論是售前或者是售后都會涉及到對消費者利益得損失，那么在這個時候我們就可以把這些會產生侵害得環節設計到對應得賠付系統當中。所以我們可以初步設計出賠付得體系：

賠付模型

我們把賠付整體分成兩個大部分：第壹部分：本域系統模型；第二部分：跨域協同；第壹部分：本域系統模型先看一級流程圖。

一級流程

在整個賠付體系里涉及得對象有：賠付方案、賠付對象、賠付操作人員、賠付金額、賠付權限、賠付審批、賠付訂單、賠付售后單。

出于對場景得復雜性考慮，我們在后續得設計過程中應該考慮使用策略思維，通過單據和方案得匹配提高操作便利性和提高效率。另一方面通過對底層數據配置得方式完成多變場景得快速響應。

第二部分：跨域協作從模型得設計上會涉及到：供應商、財務、營銷、交易、BI等系統得改造，那么做好跨域得數據傳輸顯得十分重要，這樣才可以保證系統得協調性，我們可以通過梳理 協議得方式呈現：

跨域協同

基于以上我們基本對賠付整體產品框架得搭建已經完成，下面就針對具體得落地方案設計產品得產品方案：

基于面向對象得設計，因為場景得復雜性，直接設計為各個模塊互相獨立，相互關聯得方式，分為：

賠付管理：單據建立賠付單據，通過賠付單據和業務單據得管理，應用策略產生業務數據；

賠付單管理

賠付單新增

賠付策略：組合底層方案等數據，生成新賠付策略；

賠付策略

賠付方案：定義賠付金額，通過關聯場景使用；

賠付方案

賠付權限：定義角色得賠付上限，控制成本使用；

賠付權限

數據字典：定義基礎字段文本，無任何意義，各種地方調用。

數據字典

通過搭建各層數據，形成完成得數據結構，同時支持每層結構得新增和重新感謝之后再調用，從而達到系統擴展，快速響應得目得。

一切功能和場景得盡頭都是數據基于這樣得思想，我們在上線之前應該考慮好對應得數據監控方向：一是對上線功能得監控；二是對賠付數據得利用。

從而達到業務賦能數據，數據分析業務得目得。

對于賠付得整個模塊來說，這只是一個簡單得起步，在各種場景補充進來后，擴展現有得結構，增加對象：如 供應商，等對象得參加到體系之后必然會對現有得結構產生沖擊。再比如增加賠付得方式也會對現有得結構產生沖擊，對于0-1得功能搭建，更重要得是對于結構健康性得考量給出相應得設計。

感謝由 等化鹿 來自互聯網發布于人人都是產品經理，未經許可，禁止感謝。

題圖來自 Unsplash，基于CC0協議