本文將以催收系統為例，分享如何去設計一套業務系統。希望對你有所幫助。

最近開始接觸B端的業務，本文將給大家分享：以催收系統為例，如何去設計一套業務系統。

我把設計催收系統，分三部分：梳理業務流程——>確定業務對象——>拆解設計功能

01 梳理業務流程

跟C端產品類似，在設計產品前必須要先了解用戶需求。對催收業務來說，其實就是了解催收人員平時的SOP。催收簡單的SOP如下：

1、入催：首先，催收人員需要確定哪些單需要催，哪些單不需要催，這是催收的第一步，也比較好理解。

2、催收策略：不同逾期階段、逾期金額的催收單，或者不同資質的客戶，催收策略有所不同。比如逾期1天，發個短信提醒客戶就可以，用戶可能是忘記還了；比如逾期超過10天，再給用戶打個電話，明確告知逾期有什么壞處，建議早點還款。以上都屬于內部催收，當內部催收無法催回來，則采取外部催收，也就是委案。有時候外部催收也催不回來，那只能將案件再退回來，也就是退案。當然，實際的催收策略沒有這么簡單，還有其他因素決策。

3、催收行動：催收行動是催收策略產生的線下行動。比如，外呼肯定需要人去打電話，外呼名單需要策略輸出；比如，委案需要人去跟催收公司溝通（如果催收公司沒有系統對接的話），委案名單需要策略輸出。

4、數據跟蹤：采取催收行動后，催收人員需要追蹤催收效率和成效。數據方面一般會看

1）逾期總體數據：每個逾期賬齡的數、額、比，即 借據數量，逾期金額，逾期占比

2）賬齡遷移率：遷移率=下一個逾期階段的逾期金額/上一個逾期階段的逾期金額

3）外部催收成效：催收回款/委案金額

02 確定業務對象

業務對象是貫穿整個流程的主鍵，所以在設計系統前必須明確業務對象。舉個例子，貸前的業務對象是申請單，貸中的業務對象是借款訂單，貸后還款的業務對象是借據。很明顯，貸后催收的業務對象就是催收單。

接著，確定訂單狀態。既然有訂單，肯定就有生命周期，有狀態流轉。需要注意狀態之間是單向流轉，還是雙向流轉，流轉的優先級是怎么樣的。

最后，確定訂單屬性。訂單屬性一般有客戶信息、借據信息、申請信息等，這些是催收人員要看的信息，尤其是客戶信息，是催收時必須知道的。

03 拆解設計功能

第三階段，設計功能，已經變得很簡單了。前面的流程和對象確定，已經完成了一半。只要根據流程，去抽象功能就可以了。顯而易見，根據業務流程，催收單的功能設計有：

1、催收單：管理催收單狀態，查看催收詳情

2、催收策略：可能是策略引擎、可能是人工配置的規則、可能是模型

3、催收行動：由策略產生的待辦，包括外呼名單、委案名單、退案名單等

4、審批管理：當遇到重要操作時，一般會采取審批流程，只有審批通過才能繼續往下走

5、派單管理：當遇到催收團隊較大時，催收行動需要做手動派單或自動派單，將人、單匹配成功，使催收效率最大化。如果團隊較小，則不需要派單，內部建立SOP即可

6、權限管理：一個催收團隊，一般會有三個角色：manager 、maker、checker，按照角色去分配權限即可

7、數據看板：催收后的數據跟蹤，比如前面講到的逾期數據、遷移率、催收成效，還有每個催收人員的業績等。

04 其他補充

B端系統明顯比C端的邏輯復雜，所以這次我也踩了很多坑。下面，把我的踩坑心得分享出來：

1、可操作的終端不止一個?？赡艽嬖诙鄠€客戶端、多個后管、多個業務系統，一旦輸入有觸發邏輯，就有可能影響到對象的變量。另外，還要注意時間變量，會有逾期和利息計提；

2、用戶的行為千變萬化。用戶可操作，可不操作，可操作一部分?？赡茌攲?，可能輸錯?？赡懿僮髁撕蠡?，可能沒操作后悔，產品經理需要把這些提前想周全；

3、數據生成邏輯。如果數據每日都產生，需要考慮新覆蓋舊，還是新舊都保留；

4、觸達場景的間隔和頻率。對于外呼和寄信兩種場景，時間間隔和頻率要提前控制好，控制不好可能引起客訴。

以上，就把催收系統的設計流程講完了。希望可以幫助到你~