起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識從0-1搭建客服賠付域的功能架構
導讀：客服角色作為與消費者、供應商溝通的唯一橋梁，在整個電商行業中扮演著十分關鍵的角色，不論是從業務流程還是系統建設的角度，都應對客服崗位進行深度賦能，以此沉淀數據和挖掘數據。
01 購物場景
在消費者購買前或者購買后總是會發生各種各樣的問題，我們通過幾個常見的例子來看看：
場景一：張三買了一雙鞋，下單之后三天了都沒有發貨，氣呼呼地找到了客服，對客服一頓抱怨：“為什么不注明發貨時間？為什么發不了貨也沒有提示？”從此張三心里覺得這平臺發貨慢，有急需的東西的時候再也不來買了。
場景二：李四買了一件衣服之后，收到貨之后一打開，衣服都破了，于是在平臺操作了退貨，供應商收到了退款之后，知道自己的東西不行，直接操作了退款?？头耆恢腊l生了這樣一件事情，李四心里覺得這平臺的東西質量不行，以后買一些貴重的東西不來這買了。
可以看到的是這些列舉的場景涉及到了很多方面的問題，有物流端的、有供應商端的，也會有平臺本身的，要完善好這些問題，不是一朝一夕能夠輕易的解決的，無論是系統還是業務流程都需要不斷地的建立體系進行完善。但在運營的過程中會有很多的問題會發生，那難道在解決好這些問題之前，對于消費者的心智和留存就沒有別的方法來挽留了嗎？
答案當然是否定了，那就講到今天的主題：賠付。
02 賠付系統設計
明確了相關的業務場景之后，我們可以初步對賠付體系進行一個定位：無論是售前或者是售后都會涉及到對消費者利益的損失，那么在這個時候我們就可以把這些會產生侵害的環節設計到對應的賠付系統當中。所以我們可以初步設計出賠付的體系：
賠付模型
我們把賠付整體分成兩個大部分：第一部分：本域系統模型；第二部分：跨域協同；第一部分：本域系統模型先看一級流程圖。
一級流程
在整個賠付體系里涉及的對象有：賠付方案、賠付對象、賠付操作人員、賠付金額、賠付權限、賠付審批、賠付訂單、賠付售后單。
出于對場景的復雜性考慮，我們在后續的設計過程中應該考慮使用策略思維，通過單據和方案的匹配提高操作便利性和提高效率。另一方面通過對底層數據配置的方式完成多變場景的快速響應。
第二部分：跨域協作從模型的設計上會涉及到：供應商、財務、營銷、交易、BI等系統的改造，那么做好跨域的數據傳輸顯得十分重要，這樣才可以保證系統的協調性，我們可以通過梳理 協議的方式呈現：
跨域協同
基于以上我們基本對賠付整體產品框架的搭建已經完成，下面就針對具體的落地方案設計產品的產品方案：
03 賠付產品原型
基于面向對象的設計，因為場景的復雜性，直接設計為各個模塊互相獨立，相互關聯的方式，分為：
賠付管理：單據建立賠付單據，通過賠付單據和業務單據的管理，應用策略產生業務數據；
賠付單管理
賠付單新增
賠付策略：組合底層方案等數據，生成新賠付策略；
賠付策略
賠付方案：定義賠付金額，通過關聯場景使用；
賠付方案
賠付權限：定義角色的賠付上限，控制成本使用；
賠付權限
數據字典：定義基礎字段文本，無任何意義，各種地方調用。
數據字典
通過搭建各層數據，形成完成的數據結構，同時支持每層結構的新增和重新編輯之后再調用，從而達到系統擴展，快速響應的目的。
04 賠付數據監控
一切功能和場景的盡頭都是數據基于這樣的思想，我們在上線之前應該考慮好對應的數據監控方向：一是對上線功能的監控；二是對賠付數據的利用。
從而達到業務賦能數據，數據分析業務的目的。
05 結語
對于賠付的整個模塊來說，這只是一個簡單的起步，在各種場景補充進來后，擴展現有的結構，增加對象：如 供應商，等對象的參加到體系之后必然會對現有的結構產生沖擊。再比如增加賠付的方式也會對現有的結構產生沖擊，對于0-1的功能搭建，更重要的是對于結構健康性的考量給出相應的設計。
本文由 @化鹿 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議
- 目前還沒評論，等你發揮！
