簡介這套催收業(yè)務(wù)系統(tǒng)詳細設(shè)計說明書圍繞一諾銀華催收業(yè)務(wù)場景面向系統(tǒng)設(shè)計人員、Java開發(fā)工程師以及需要梳理催收系統(tǒng)整體架構(gòu)的技術(shù)管理者幫助讀者理解系統(tǒng)從需求到落地的完整設(shè)計思路。資源共749個文件壓縮包約25.27MB以Java技術(shù)棧為主71個java源文件與76個class編譯文件對應(yīng)后端業(yè)務(wù)模塊126個js、25個jsp和20個css構(gòu)成前端交互頁面39個xml與35個jar提供配置和依賴支持另有266張png及41個gif用于展示設(shè)計圖、界面原型和操作流程。該資源已有3417人學(xué)習(xí)下載。內(nèi)容從系統(tǒng)概況、功能需求、技術(shù)需求到實現(xiàn)環(huán)境均有明確定義并對軟件應(yīng)具備的功能、性能及其他有效性需求作出說明結(jié)合目錄中的案件信息類、客戶信息類、催收員操作類及催收列表相關(guān)文件可快速還原案件管理、客戶信息維護、催收任務(wù)處理等模塊的協(xié)作關(guān)系為二次開發(fā)、文檔編寫或系統(tǒng)重構(gòu)提供可落地的參考。1. 一諾銀華催收業(yè)務(wù)系統(tǒng)貸后催收從“人肉打電話”到“策略驅(qū)動作業(yè)”的分水嶺信貸業(yè)務(wù)放款之后真正讓運營團隊頭疼的往往不是獲客而是貸后催收案件堆積、分案靠手工、催收員憑感覺打電話、承諾還款沒人跟進、月底報表口徑五花八門。這些問題的共同根源是缺一套把“誰在什么時候、通過什么渠道、聯(lián)系哪個案件、催到什么狀態(tài)、下一步做什么”這些規(guī)則固化成系統(tǒng)的業(yè)務(wù)平臺。一諾銀華催收業(yè)務(wù)系統(tǒng)正是解決這個問題的核心作業(yè)系統(tǒng)它管的是從案件進件、分案、觸達、催記、質(zhì)檢到報表分析的完整閉環(huán)。本文面向信貸機構(gòu)貸后運營、科技團隊和準(zhǔn)備自建系統(tǒng)的從業(yè)者講清楚這類系統(tǒng)的模塊骨架、策略配置、外呼集成和最容易翻車的細節(jié)。2. 先從業(yè)務(wù)流拆系統(tǒng)催收案件從進件到回收的模塊骨架2.1 案件池進件、逾期檔案與案件狀態(tài)機催收系統(tǒng)的數(shù)據(jù)源頭是信貸核心系統(tǒng)。每天凌晨批處理把逾期案件推送到催收系統(tǒng)推過來的字段至少包含案件號、客戶姓名、聯(lián)系方式、產(chǎn)品類型、逾期金額、剩余本金、逾期天數(shù)、逾期期數(shù)、放款機構(gòu)、客戶經(jīng)理等。這些案件進入系統(tǒng)后不是馬上分給人而是先落在“案件池”里等待規(guī)則引擎做分案或分組。案件池要維護一張案底表核心是狀態(tài)機。常見狀態(tài)有待分案、已分配、催收中、承諾還款、已結(jié)清、轉(zhuǎn)委外、呆滯核銷。我在做類似系統(tǒng)時習(xí)慣在這張表上加一個“案件鎖定標(biāo)記”誰在跟進就鎖住避免同一案件被兩個催收員重復(fù)撥打。下面這段 SQL 模擬的是查詢一個案件池中今日應(yīng)跟進案件的操作SELECT c.case_id, c.cust_name, c.overdue_days, c.overdue_amt, c.cur_status, c.lock_flag, c.assign_user FROM collector_case_pool c WHERE c.overdue_days BETWEEN 1 AND 30 AND c.cur_status IN (ASSIGNED, COLLECTING) AND c.lock_flag 0 AND c.next_follow_date CURRENT_DATE ORDER BY c.overdue_amt DESC;這段 SQL 按逾期天數(shù)篩選出 M1 階段1-30 天的已分配案件只取今天需要跟進的按逾期金額降序排。邏輯說明案件池不是越早分配越好而是要讓催收員打開工作臺就看到“今天該辦的事”避免一個人天天盯著同一批老案件把高金額新案件晾在一邊。參數(shù)說明里最關(guān)鍵的是next_follow_date它由催收記跟進計劃自動回寫代表系統(tǒng)認(rèn)為該案件下一次聯(lián)系的最早時間。2.2 分案引擎為什么說分案是系統(tǒng)的命門分案引擎決定案件落到誰手里。常見的分案維度有逾期天數(shù)、欠款金額、風(fēng)險評分、產(chǎn)品線、客戶所在地區(qū)、催收員隊列、催收員等級。規(guī)則引擎按優(yōu)先級順序逐條匹配命中即止。業(yè)內(nèi)常用做法是把規(guī)則分成“互斥優(yōu)先級兩段式”第一段決定案件去哪個隊列第二段決定隊列內(nèi)部誰接單。assign_rules [ {priority: 10, desc: M3大額案件, condition: overdue_days 120 and overdue_amt 100000, queue: senior_queue}, {priority: 20, desc: M3 長賬齡案件, condition: overdue_days 90, queue: normal_queue}, {priority: 30, desc: M1 首催案件, condition: overdue_days 30, queue: newbie_queue}, {priority: 99, desc: 兜底規(guī)則, condition: true, queue: normal_queue}, ] def route_case(case): for rule in assign_rules: if eval(rule[condition]): return rule[queue] return normal_queue這段偽代碼說明了路由邏輯規(guī)則按優(yōu)先級從高到低掃描命中后不再看后面的規(guī)則。參數(shù)說明中最容易忽略的是最后一條priority: 99的兜底規(guī)則。實際運營中案件字段經(jīng)常有臟數(shù)據(jù)觸發(fā)條件可能匹配不到任何規(guī)則這時沒有兜底案件就會一直懸在案件池里成為“黑洞案件”。2.3 催收工作臺催記字段設(shè)計決定數(shù)據(jù)質(zhì)量案件分給催收員后每天作業(yè)都在工作臺完成。工作臺的核心是催記填寫這塊的字段設(shè)計直接決定后續(xù)報表能不能算準(zhǔn)。常見做法是把催記抽象成一次“聯(lián)系事件”而不是一段自由文本。我一般會設(shè)計這樣一張催記表字段說明填寫方式case_id案件號關(guān)聯(lián)案件池系統(tǒng)自動帶入contact_type外呼/短信/郵件/微信下拉選擇result_code接通/無人接/停機/客戶承諾還款/拒絕溝通下拉選擇promised_date承諾還款日期可選當(dāng) result_code 為承諾還款時必填memo催記備注文本限 200 字next_follow_date下次跟進時間選填留空按策略默認(rèn)計算這里有個坑如果催記允許自由填寫“下次跟進時間”一線催收員會為了“省事”把時間往后拖三天案件跟進頻率形同虛設(shè)。正確的做法是給next_follow_date一個默認(rèn)計算值比如根據(jù)案件階段自動算為明天的同一時段催收員可以選擇提前但禁止“順延到三天后”。這個細節(jié)直接影響承諾還款到期和案件回收節(jié)奏。2.4 報表底表別等月底再手工匯總催收系統(tǒng)的報表要從催記、案件狀態(tài)變更、還款記錄這三張表實時聚合出來而不是等月底讓運營手工匯總。底層一般做三層ods 原表、dwd 業(yè)務(wù)明細表、ads 指標(biāo)匯總表。DWD 層最關(guān)鍵的是把“聯(lián)系事件”和“案件狀態(tài)變更”聯(lián)成一張帶時間軸的事實表這樣每個案件的催收歷史可以回放方便后續(xù)策略調(diào)優(yōu)時分析。3. 策略引擎寫法分案規(guī)則、觸達頻次和催收計劃的條件配置3.1 策略元組把“怎么催”從人腦搬到配置文件催收策略本質(zhì)是一個元組觸發(fā)時機、執(zhí)行渠道、頻次上限、作業(yè)時段、執(zhí)行人角色。這五個元素放在一起就構(gòu)成了一條“策略”。策略與人的區(qū)別在于人催收憑感覺策略催收靠確定性的規(guī)則。常見做法是把 M11-30 天、M231-60 天、M361-90 天、M390 天以上分成不同階段每一階段配不同策略組合。比如 M1 首催策略的典型配置是逾期第 1 天短信提醒第 2 天電話觸達第 3 天如果未接再電話補一次第 4 天未聯(lián)系上就發(fā)一封催收函。M3 案件的策略則是直接由資深催收員跟進且每天最多外呼一次避免過度騷擾。策略引擎的核心價值是把這些原來靠班前會口頭交代的經(jīng)驗變成可以配置、可以回滾、可以驗證的代碼資產(chǎn)。3.2 一條策略的 JSON 配置示例策略配置我推薦用結(jié)構(gòu)化文件存儲方便在配置后臺做灰度發(fā)布而不用每次改邏輯就發(fā)版。下面是一段策略配置的簡化示例{ stage: M1, trigger: overdue_days 1 and overdue_days 30, work_time: {start: 09:00, end: 20:00}, channels: [ {channel: SMS, max_times_per_week: 2, seq: 1}, {channel: PHONE, max_times_per_week: 3, seq: 2} ], assign_role: newbie_queue, follow_up: {promise_due_remind: 1, auto_requeue_days: 3} }這里每個字段都對應(yīng)一個業(yè)務(wù)參數(shù)。work_time是作業(yè)時段白名單策略引擎在任何時間觸發(fā)都要過這道閘避免定時任務(wù)凌晨外呼。max_times_per_week是每周觸達上限這是防投訴和合規(guī)的關(guān)鍵參數(shù)。follow_up.promise_due_remind表示承諾還款到期前 1 天生成提醒任務(wù)auto_requeue_days表示承諾還款客戶逾期 3 天仍未兌現(xiàn)就自動回到案件池重新分配。這些值不是拍腦袋定的而是根據(jù)歷史催回率曲線逐漸校準(zhǔn)出來的。3.3 三個必調(diào)參數(shù)作業(yè)時段、觸達上限、承諾還款跟蹤窗口作業(yè)時段是第一個必調(diào)參數(shù)。很多機構(gòu)為了沖回收率把時段放寬到 21 點但實際接通率在 19 點后明顯的下降反而招來投訴。我的推薦做法是按產(chǎn)品客群單獨配置經(jīng)營貸客戶白天接通率高消費貸客戶晚間 18-20 點接通率高每個策略組掛不同的時段。第二是每周觸達上限。電話超 3 次、短信超 2 次后繼續(xù)觸達的邊際收益幾乎為零而投訴概率會大幅上升。這個上限要放在策略引擎最底層做總閘不能只寫在單條策略里。第三是承諾還款跟蹤窗口。很多人以為客戶答應(yīng)還款就結(jié)束了實際上承諾兌現(xiàn)率通常只有四到六成剩下的要靠到期提醒和逾期后快速回流。auto_requeue_days設(shè)得太長案件就涼了設(shè)得太短客戶還沒到還款日就又被打一遍體驗極差。這個參數(shù)建議從 2 天起步觀察兌現(xiàn)率曲線再慢慢調(diào)整。3.4 策略執(zhí)行路徑一次性跑批還是事件驅(qū)動策略引擎的常見運行方式有兩種定時批處理和事件驅(qū)動。定時批處理每天幾個時間點掃描案件池找出滿足觸發(fā)條件的案件執(zhí)行觸達動作。事件驅(qū)動的場景則是客戶還了款、承諾到期、案件被退回這類狀態(tài)變化需要立刻改寫下一步任務(wù)。實際系統(tǒng)里兩種都要但最容易翻車的是只做了定時批處理沒有做事件驅(qū)動。比如客戶承諾還款成功后系統(tǒng)不改狀態(tài)也不取消后續(xù)電話任務(wù)客戶一邊說還一邊繼續(xù)被催收員打電話投訴自然就來了。我一般會在案件狀態(tài)變更的入口寫一個事件回調(diào)把承諾還款、結(jié)清、轉(zhuǎn)委外這類重點狀態(tài)變更即時同步到策略引擎的任務(wù)表。4. 集成外呼與質(zhì)檢接通率、禁語監(jiān)控和錄音復(fù)核的落地做法4.1 外呼選型預(yù)覽式外呼還是預(yù)測式外呼催收系統(tǒng)的外呼通常不是拿手機直接撥而是通過話務(wù)網(wǎng)關(guān)做 SIP 接入坐席用軟電話登錄系統(tǒng)。外呼模式分兩類模式適用場景優(yōu)點缺點預(yù)覽式外呼大額、疑難案件坐席先看案件信息再撥號通話質(zhì)量高人均通話量低預(yù)測式外呼M1 大量小額案件系統(tǒng)自動撥號接通后轉(zhuǎn)給空閑坐席通話效率高存在“無聲呼叫”投訴風(fēng)險我的經(jīng)驗是催收系統(tǒng)先上預(yù)覽式外呼穩(wěn)定后再考慮預(yù)測式。原因是催收專業(yè)性強坐席需要先看催收歷史和客戶畫像再決定怎么聊“盲撥”一通再看來電信息容易惹惱客戶。如果一定要上預(yù)測式外呼有一個參數(shù)要盯住漏接率也就是系統(tǒng)撥通后坐席沒接起來導(dǎo)致客戶聽不到人說話的比例這個值超過 5% 就會積累成批量投訴。4.2 通話話單與案件關(guān)聯(lián)千萬別丟 business_id外呼接通后話務(wù)網(wǎng)關(guān)會回傳一條通話話單包含呼叫 ID、開始時間、結(jié)束時間、通話時長、錄音文件 URL、掛斷方向。設(shè)計話單表的時候一定要把 case_id 寫進去否則話單和案件就關(guān)聯(lián)不上質(zhì)檢、催記只能靠人工看錄音去補錄那是災(zāi)難。CREATE TABLE collector_cdr ( call_id VARCHAR(64) PRIMARY KEY, case_id VARCHAR(64) NOT NULL, agent_id VARCHAR(32) NOT NULL, call_direction VARCHAR(16), call_time DATETIME, duration_sec INT, hangup_cause VARCHAR(32), record_url VARCHAR(255) );這張表的設(shè)計要點case_id必須非空來源在坐席點擊“外呼”按鈕時由前端帶入而不是等話單回傳后反向匹配。hangup_cause用來區(qū)分客戶掛斷、無人接聽、坐席掛斷這對統(tǒng)計有效接觸率很重要。錄音文件 URL 要單獨存方便質(zhì)檢模塊按 call_id 拉取。4.3 禁語規(guī)則與質(zhì)檢抽檢先用關(guān)鍵詞篩掉明顯問題質(zhì)檢是合規(guī)的最后一道閘。全量人工聽錄音不現(xiàn)實業(yè)界普遍做法是“機器初篩 人工抽檢”兩層。機器初篩用關(guān)鍵詞匹配把命中禁語的錄音篩出來強制人工復(fù)核未命中的錄音按固定比例抽檢。下面是一個禁語檢測的簡單示例banned_words [威脅, 不還就抓, 爆通訊錄, 上門潑漆, 冒充公檢法] def check_record(record_text): hits [word for word in banned_words if word in record_text] if hits: return {result: REJECT, hit_words: hits, level: HIGH} return {result: PASS}檢測函數(shù)把通話轉(zhuǎn)寫文本拆成逐句判斷命中禁語直接打 HIGH 級告警并進入人工必檢隊列。這塊有個常見的翻車點關(guān)鍵詞列表只做了“全詞匹配”諧音、變體比如“抓人”寫成“帶人去喝茶”就漏了。但諧音規(guī)則不能一上來就加太多誤殺率會很高我的習(xí)慣是先做一整月的投訴工單分析把投訴集中出現(xiàn)的話術(shù)拆成關(guān)鍵詞詞根再小步添加。抽檢比例的分層做法是新坐席首月 100% 錄音抽檢普通坐席 10% 隨機抽檢金牌坐席 5% 抽檢。命中禁語的坐席臨時提高到 100% 抽檢直到連續(xù) 30 個通話無命中再降回原檔。這套規(guī)則能讓質(zhì)檢人力集中在風(fēng)險最高的人群上而不是平均用力。5. 系統(tǒng)落地避坑這五個坑是我見過投入產(chǎn)出最差的翻車點5.1 同一個案件被兩個坐席同時外呼現(xiàn)象客戶反映半小時內(nèi)接到兩個不同催收員的電話問他“你到底是哪個平臺的”坐席之間互相不知道對方打過。出現(xiàn)這類投訴基本可以斷定是案件鎖沒做好。原因分案引擎和催收工作臺之間沒有“正在催收”的狀態(tài)約束一個案件剛被分出去又被另一條規(guī)則命中或者案件狀態(tài)已變但前端頁面沒有刷新坐席重復(fù)發(fā)起外呼。解決在案件池表加lock_flag和lock_time坐席點擊外呼按鈕前先執(zhí)行一次“外呼資格校驗”校驗通過立刻設(shè)置鎖標(biāo)記。答錄機掛斷不計入已聯(lián)系但外呼動作本身要落日志。校驗的 SQL 里lock_flag 0這個條件永遠不能省。5.2 定時任務(wù)在凌晨批量外呼現(xiàn)象凌晨 2 點有客戶收到催收短信并來電投訴理由是“你們是不是機器出了問題”但真正原因是策略引擎的定時批處理沒有校驗作業(yè)時段。原因運營人員配置策略時只填了“逾期第 3 天觸發(fā)”沒有配置作業(yè)時段而定時任務(wù)啟動時按服務(wù)器時間執(zhí)行完全沒看客戶的當(dāng)?shù)貢r間。解決在策略引擎最外層加一個與地區(qū)綁定的時間窗口校驗函數(shù)——所有觸達動作執(zhí)行前必須先檢查客戶號碼歸屬地和當(dāng)前時間是否在策略允許時段內(nèi)不在就直接跳過并寫日志。這個校驗要放在所有策略共用的執(zhí)行入口不能只放在某一條策略里否則每加一條策略都可能漏。5.3 承諾還款到期后沒有人跟進現(xiàn)象客戶在催收電話里承諾當(dāng)月 15 號還款到了 16 號卻沒有任何人再聯(lián)系客戶逾期進入第二期催收員和質(zhì)檢都不知道這個案件出了什么問題。原因系統(tǒng)把“承諾還款”當(dāng)成一個靜態(tài)標(biāo)記只在催記里記了一行文字沒有生成后續(xù)的到期提醒任務(wù)和逾期回流任務(wù)。解決承諾還款必須落成一條結(jié)構(gòu)化數(shù)據(jù)包含案件號、承諾金額、承諾日期、狀態(tài)、操作人。承諾日期到期當(dāng)天上午系統(tǒng)自動生成一條“承諾還款核驗”跟進任務(wù)到期后若客戶未還款案件自動回到案件池由分案引擎重新分配。這套機制需要在案件狀態(tài)機的“承諾還款”狀態(tài)里加一個到期跳轉(zhuǎn)邏輯比讓催收員自己記要可靠得多。5.4 分案規(guī)則互相沖突導(dǎo)致案件被重復(fù)分配現(xiàn)象一個 M3 大額案件同時命中“M3 長賬齡案件”和“大額案件”兩條規(guī)則系統(tǒng)把它同時分給了兩個隊列結(jié)果出現(xiàn)雙人跟進。原因規(guī)則之間沒有設(shè)置互斥關(guān)系也沒有優(yōu)先級編號引擎掃描時所有條件同時成立就同時執(zhí)行。解決分案引擎的所有規(guī)則必須顯式配置優(yōu)先級并且命中即停不允許并行分發(fā)。同時在規(guī)則配置里加“規(guī)則組”概念同一組規(guī)則之間互斥跨組規(guī)則也按優(yōu)先級覆蓋。最關(guān)鍵的是規(guī)則條件里的字段要避免重疊區(qū)間比如“overdue_days 90”和“overdue_days 120”本身就存在包含關(guān)系后端要自動做沖突檢測并拒絕發(fā)布。5.5 質(zhì)檢抽檢比例一刀切導(dǎo)致質(zhì)檢員被錄音淹沒現(xiàn)象質(zhì)檢員每天聽 100 多段錄音積壓越來越嚴(yán)重最后只能聽頭 30 秒就打分禁語漏檢率反而高。原因質(zhì)檢規(guī)則沒有按風(fēng)險分層新坐席和金牌坐席同樣抽檢命中禁語和普通錄音同等對待資源被平均打散。另一個原因是沒有把機器篩選項前置很多錄音根本不需要人工聽。解決先機器篩一遍關(guān)鍵詞命中才進人工必檢隊列未命中的再按坐席分層抽檢。呼叫接通但 5 秒內(nèi)掛斷、客戶沉默超過 30 秒這類低質(zhì)量錄音也可以直接標(biāo)為“無效接觸”而不進抽檢池讓人工把時間省下來放在高價值案件上。6. 用回收率、兌現(xiàn)率和有效接觸率反向調(diào)策略一個可持續(xù)的自我糾正閉環(huán)催收系統(tǒng)上線三個月后策略調(diào)整就不再依賴拍腦袋了。我建議運營團隊每周固定看三個指標(biāo)并圍繞它們形成策略迭代閉環(huán)?；厥章拾窗讣谓y(tǒng)計首催回收率和總回收率分開算。首催回收率反映分案策略和的話術(shù)質(zhì)量總回收率反映整條作業(yè)鏈的累積效果。有效接觸率有效接觸定義為“接通且通話時長大于 30 秒”的外呼次數(shù)除以總外呼次數(shù)。這個指標(biāo)高說明電話號碼有效、時段配置合理。承諾還款兌現(xiàn)率客戶承諾還款金額與實際還款金額的比值。這個比值低于 40%說明催收員承諾引導(dǎo)過松需要回頭檢查催記模板里的“客戶還款能力確認(rèn)”環(huán)節(jié)。策略調(diào)整后怎么驗證一個有效做法是按案件號尾號做隨機分組把實驗組策略和對照組策略各跑兩周然后跑對比查詢SELECT g.group_name, COUNT(CASE WHEN r.repaid_flag 1 THEN 1 END) / COUNT(DISTINCT c.case_id) AS repayment_rate FROM assign_group g JOIN collector_case_pool c ON g.case_id c.case_id JOIN collector_repay_record r ON c.case_id r.case_id GROUP BY g.group_name;這個 SQL 的邏輯是把案件分成若干組用還款記錄判斷每個組的回收率再對比哪個策略組的回收率顯著更高。注意這里要做顯著性判斷樣本量小時回收率波動大至少要單組 300 個案件以上才有參考價值。我個人的習(xí)慣是每次改策略先用最近三個月的歷史案件做一遍回放把案件喂進新的策略引擎里模擬跑一遍看回收率會不會掉再決定是否灰度。這套“歷史回放 灰度驗證 指標(biāo)復(fù)盤”的做法能擋住絕大多數(shù)看似合理實則有害的調(diào)整。催收業(yè)務(wù)系統(tǒng)的價值不在于把產(chǎn)品功能做得花哨而在于讓每一條催收動作都能被記錄、被分析、被優(yōu)化。少一個靜默案件多一次有效觸達系統(tǒng)的收益就已經(jīng)值回投入。希望這篇文章能幫你的團隊少踩幾個坑把策略驅(qū)動的貸后作業(yè)真正跑起來。本文還有配套的精品資源點擊獲取