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