從0到1設計一套業務系統(以催收為例)
本文將以催收系統為例,分享如何去設計一套業務系統。希望對你有所幫助。
最近開始接觸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、觸達場景的間隔和頻率。對于外呼和寄信兩種場景,時間間隔和頻率要提前控制好,控制不好可能引起客訴。
以上,就把催收系統的設計流程講完了。希望可以幫助到你~
專欄作家
狐檬,公眾號:小狐學產品,人人都是產品經理專欄作家。專注互聯網金融領域,具有千萬級互金產品和運營經驗,擅長做業務增長。
本文原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務
- 目前還沒評論,等你發揮!