简介这套催收业务系统详细设计说明书围绕一诺银华催收业务场景面向系统设计人员、Java开发工程师以及需要梳理催收系统整体架构的技术管理者帮助读者理解系统从需求到落地的完整设计思路。资源共749个文件压缩包约25.27MB以Java技术栈为主71个java源文件与76个class编译文件对应后端业务模块126个js、25个jsp和20个css构成前端交互页面39个xml与35个jar提供配置和依赖支持另有266张png及41个gif用于展示设计图、界面原型和操作流程。该资源已有3417人学习下载。内容从系统概况、功能需求、技术需求到实现环境均有明确定义并对软件应具备的功能、性能及其他有效性需求作出说明结合目录中的案件信息类、客户信息类、催收员操作类及催收列表相关文件可快速还原案件管理、客户信息维护、催收任务处理等模块的协作关系为二次开发、文档编写或系统重构提供可落地的参考。1. 一诺银华催收业务系统贷后催收从“人肉打电话”到“策略驱动作业”的分水岭信贷业务放款之后真正让运营团队头疼的往往不是获客而是贷后催收案件堆积、分案靠手工、催收员凭感觉打电话、承诺还款没人跟进、月底报表口径五花八门。这些问题的共同根源是缺一套把“谁在什么时候、通过什么渠道、联系哪个案件、催到什么状态、下一步做什么”这些规则固化成系统的业务平台。一诺银华催收业务系统正是解决这个问题的核心作业系统它管的是从案件进件、分案、触达、催记、质检到报表分析的完整闭环。本文面向信贷机构贷后运营、科技团队和准备自建系统的从业者讲清楚这类系统的模块骨架、策略配置、外呼集成和最容易翻车的细节。2. 先从业务流拆系统催收案件从进件到回收的模块骨架2.1 案件池进件、逾期档案与案件状态机催收系统的数据源头是信贷核心系统。每天凌晨批处理把逾期案件推送到催收系统推过来的字段至少包含案件号、客户姓名、联系方式、产品类型、逾期金额、剩余本金、逾期天数、逾期期数、放款机构、客户经理等。这些案件进入系统后不是马上分给人而是先落在“案件池”里等待规则引擎做分案或分组。案件池要维护一张案底表核心是状态机。常见状态有待分案、已分配、催收中、承诺还款、已结清、转委外、呆滞核销。我在做类似系统时习惯在这张表上加一个“案件锁定标记”谁在跟进就锁住避免同一案件被两个催收员重复拨打。下面这段 SQL 模拟的是查询一个案件池中今日应跟进案件的操作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 按逾期天数筛选出 M1 阶段1-30 天的已分配案件只取今天需要跟进的按逾期金额降序排。逻辑说明案件池不是越早分配越好而是要让催收员打开工作台就看到“今天该办的事”避免一个人天天盯着同一批老案件把高金额新案件晾在一边。参数说明里最关键的是next_follow_date它由催收记跟进计划自动回写代表系统认为该案件下一次联系的最早时间。2.2 分案引擎为什么说分案是系统的命门分案引擎决定案件落到谁手里。常见的分案维度有逾期天数、欠款金额、风险评分、产品线、客户所在地区、催收员队列、催收员等级。规则引擎按优先级顺序逐条匹配命中即止。业内常用做法是把规则分成“互斥优先级两段式”第一段决定案件去哪个队列第二段决定队列内部谁接单。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: 兜底规则, condition: true, queue: normal_queue}, ] def route_case(case): for rule in assign_rules: if eval(rule[condition]): return rule[queue] return normal_queue这段伪代码说明了路由逻辑规则按优先级从高到低扫描命中后不再看后面的规则。参数说明中最容易忽略的是最后一条priority: 99的兜底规则。实际运营中案件字段经常有脏数据触发条件可能匹配不到任何规则这时没有兜底案件就会一直悬在案件池里成为“黑洞案件”。2.3 催收工作台催记字段设计决定数据质量案件分给催收员后每天作业都在工作台完成。工作台的核心是催记填写这块的字段设计直接决定后续报表能不能算准。常见做法是把催记抽象成一次“联系事件”而不是一段自由文本。我一般会设计这样一张催记表字段说明填写方式case_id案件号关联案件池系统自动带入contact_type外呼/短信/邮件/微信下拉选择result_code接通/无人接/停机/客户承诺还款/拒绝沟通下拉选择promised_date承诺还款日期可选当 result_code 为承诺还款时必填memo催记备注文本限 200 字next_follow_date下次跟进时间选填留空按策略默认计算这里有个坑如果催记允许自由填写“下次跟进时间”一线催收员会为了“省事”把时间往后拖三天案件跟进频率形同虚设。正确的做法是给next_follow_date一个默认计算值比如根据案件阶段自动算为明天的同一时段催收员可以选择提前但禁止“顺延到三天后”。这个细节直接影响承诺还款到期和案件回收节奏。2.4 报表底表别等月底再手工汇总催收系统的报表要从催记、案件状态变更、还款记录这三张表实时聚合出来而不是等月底让运营手工汇总。底层一般做三层ods 原表、dwd 业务明细表、ads 指标汇总表。DWD 层最关键的是把“联系事件”和“案件状态变更”联成一张带时间轴的事实表这样每个案件的催收历史可以回放方便后续策略调优时分析。3. 策略引擎写法分案规则、触达频次和催收计划的条件配置3.1 策略元组把“怎么催”从人脑搬到配置文件催收策略本质是一个元组触发时机、执行渠道、频次上限、作业时段、执行人角色。这五个元素放在一起就构成了一条“策略”。策略与人的区别在于人催收凭感觉策略催收靠确定性的规则。常见做法是把 M11-30 天、M231-60 天、M361-90 天、M390 天以上分成不同阶段每一阶段配不同策略组合。比如 M1 首催策略的典型配置是逾期第 1 天短信提醒第 2 天电话触达第 3 天如果未接再电话补一次第 4 天未联系上就发一封催收函。M3 案件的策略则是直接由资深催收员跟进且每天最多外呼一次避免过度骚扰。策略引擎的核心价值是把这些原来靠班前会口头交代的经验变成可以配置、可以回滚、可以验证的代码资产。3.2 一条策略的 JSON 配置示例策略配置我推荐用结构化文件存储方便在配置后台做灰度发布而不用每次改逻辑就发版。下面是一段策略配置的简化示例{ 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} }这里每个字段都对应一个业务参数。work_time是作业时段白名单策略引擎在任何时间触发都要过这道闸避免定时任务凌晨外呼。max_times_per_week是每周触达上限这是防投诉和合规的关键参数。follow_up.promise_due_remind表示承诺还款到期前 1 天生成提醒任务auto_requeue_days表示承诺还款客户逾期 3 天仍未兑现就自动回到案件池重新分配。这些值不是拍脑袋定的而是根据历史催回率曲线逐渐校准出来的。3.3 三个必调参数作业时段、触达上限、承诺还款跟踪窗口作业时段是第一个必调参数。很多机构为了冲回收率把时段放宽到 21 点但实际接通率在 19 点后明显的下降反而招来投诉。我的推荐做法是按产品客群单独配置经营贷客户白天接通率高消费贷客户晚间 18-20 点接通率高每个策略组挂不同的时段。第二是每周触达上限。电话超 3 次、短信超 2 次后继续触达的边际收益几乎为零而投诉概率会大幅上升。这个上限要放在策略引擎最底层做总闸不能只写在单条策略里。第三是承诺还款跟踪窗口。很多人以为客户答应还款就结束了实际上承诺兑现率通常只有四到六成剩下的要靠到期提醒和逾期后快速回流。auto_requeue_days设得太长案件就凉了设得太短客户还没到还款日就又被打一遍体验极差。这个参数建议从 2 天起步观察兑现率曲线再慢慢调整。3.4 策略执行路径一次性跑批还是事件驱动策略引擎的常见运行方式有两种定时批处理和事件驱动。定时批处理每天几个时间点扫描案件池找出满足触发条件的案件执行触达动作。事件驱动的场景则是客户还了款、承诺到期、案件被退回这类状态变化需要立刻改写下一步任务。实际系统里两种都要但最容易翻车的是只做了定时批处理没有做事件驱动。比如客户承诺还款成功后系统不改状态也不取消后续电话任务客户一边说还一边继续被催收员打电话投诉自然就来了。我一般会在案件状态变更的入口写一个事件回调把承诺还款、结清、转委外这类重点状态变更即时同步到策略引擎的任务表。4. 集成外呼与质检接通率、禁语监控和录音复核的落地做法4.1 外呼选型预览式外呼还是预测式外呼催收系统的外呼通常不是拿手机直接拨而是通过话务网关做 SIP 接入坐席用软电话登录系统。外呼模式分两类模式适用场景优点缺点预览式外呼大额、疑难案件坐席先看案件信息再拨号通话质量高人均通话量低预测式外呼M1 大量小额案件系统自动拨号接通后转给空闲坐席通话效率高存在“无声呼叫”投诉风险我的经验是催收系统先上预览式外呼稳定后再考虑预测式。原因是催收专业性强坐席需要先看催收历史和客户画像再决定怎么聊“盲拨”一通再看来电信息容易惹恼客户。如果一定要上预测式外呼有一个参数要盯住漏接率也就是系统拨通后坐席没接起来导致客户听不到人说话的比例这个值超过 5% 就会积累成批量投诉。4.2 通话话单与案件关联千万别丢 business_id外呼接通后话务网关会回传一条通话话单包含呼叫 ID、开始时间、结束时间、通话时长、录音文件 URL、挂断方向。设计话单表的时候一定要把 case_id 写进去否则话单和案件就关联不上质检、催记只能靠人工看录音去补录那是灾难。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) );这张表的设计要点case_id必须非空来源在坐席点击“外呼”按钮时由前端带入而不是等话单回传后反向匹配。hangup_cause用来区分客户挂断、无人接听、坐席挂断这对统计有效接触率很重要。录音文件 URL 要单独存方便质检模块按 call_id 拉取。4.3 禁语规则与质检抽检先用关键词筛掉明显问题质检是合规的最后一道闸。全量人工听录音不现实业界普遍做法是“机器初筛 人工抽检”两层。机器初筛用关键词匹配把命中禁语的录音筛出来强制人工复核未命中的录音按固定比例抽检。下面是一个禁语检测的简单示例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}检测函数把通话转写文本拆成逐句判断命中禁语直接打 HIGH 级告警并进入人工必检队列。这块有个常见的翻车点关键词列表只做了“全词匹配”谐音、变体比如“抓人”写成“带人去喝茶”就漏了。但谐音规则不能一上来就加太多误杀率会很高我的习惯是先做一整月的投诉工单分析把投诉集中出现的话术拆成关键词词根再小步添加。抽检比例的分层做法是新坐席首月 100% 录音抽检普通坐席 10% 随机抽检金牌坐席 5% 抽检。命中禁语的坐席临时提高到 100% 抽检直到连续 30 个通话无命中再降回原档。这套规则能让质检人力集中在风险最高的人群上而不是平均用力。5. 系统落地避坑这五个坑是我见过投入产出最差的翻车点5.1 同一个案件被两个坐席同时外呼现象客户反映半小时内接到两个不同催收员的电话问他“你到底是哪个平台的”坐席之间互相不知道对方打过。出现这类投诉基本可以断定是案件锁没做好。原因分案引擎和催收工作台之间没有“正在催收”的状态约束一个案件刚被分出去又被另一条规则命中或者案件状态已变但前端页面没有刷新坐席重复发起外呼。解决在案件池表加lock_flag和lock_time坐席点击外呼按钮前先执行一次“外呼资格校验”校验通过立刻设置锁标记。答录机挂断不计入已联系但外呼动作本身要落日志。校验的 SQL 里lock_flag 0这个条件永远不能省。5.2 定时任务在凌晨批量外呼现象凌晨 2 点有客户收到催收短信并来电投诉理由是“你们是不是机器出了问题”但真正原因是策略引擎的定时批处理没有校验作业时段。原因运营人员配置策略时只填了“逾期第 3 天触发”没有配置作业时段而定时任务启动时按服务器时间执行完全没看客户的当地时间。解决在策略引擎最外层加一个与地区绑定的时间窗口校验函数——所有触达动作执行前必须先检查客户号码归属地和当前时间是否在策略允许时段内不在就直接跳过并写日志。这个校验要放在所有策略共用的执行入口不能只放在某一条策略里否则每加一条策略都可能漏。5.3 承诺还款到期后没有人跟进现象客户在催收电话里承诺当月 15 号还款到了 16 号却没有任何人再联系客户逾期进入第二期催收员和质检都不知道这个案件出了什么问题。原因系统把“承诺还款”当成一个静态标记只在催记里记了一行文字没有生成后续的到期提醒任务和逾期回流任务。解决承诺还款必须落成一条结构化数据包含案件号、承诺金额、承诺日期、状态、操作人。承诺日期到期当天上午系统自动生成一条“承诺还款核验”跟进任务到期后若客户未还款案件自动回到案件池由分案引擎重新分配。这套机制需要在案件状态机的“承诺还款”状态里加一个到期跳转逻辑比让催收员自己记要可靠得多。5.4 分案规则互相冲突导致案件被重复分配现象一个 M3 大额案件同时命中“M3 长账龄案件”和“大额案件”两条规则系统把它同时分给了两个队列结果出现双人跟进。原因规则之间没有设置互斥关系也没有优先级编号引擎扫描时所有条件同时成立就同时执行。解决分案引擎的所有规则必须显式配置优先级并且命中即停不允许并行分发。同时在规则配置里加“规则组”概念同一组规则之间互斥跨组规则也按优先级覆盖。最关键的是规则条件里的字段要避免重叠区间比如“overdue_days 90”和“overdue_days 120”本身就存在包含关系后端要自动做冲突检测并拒绝发布。5.5 质检抽检比例一刀切导致质检员被录音淹没现象质检员每天听 100 多段录音积压越来越严重最后只能听头 30 秒就打分禁语漏检率反而高。原因质检规则没有按风险分层新坐席和金牌坐席同样抽检命中禁语和普通录音同等对待资源被平均打散。另一个原因是没有把机器筛选项前置很多录音根本不需要人工听。解决先机器筛一遍关键词命中才进人工必检队列未命中的再按坐席分层抽检。呼叫接通但 5 秒内挂断、客户沉默超过 30 秒这类低质量录音也可以直接标为“无效接触”而不进抽检池让人工把时间省下来放在高价值案件上。6. 用回收率、兑现率和有效接触率反向调策略一个可持续的自我纠正闭环催收系统上线三个月后策略调整就不再依赖拍脑袋了。我建议运营团队每周固定看三个指标并围绕它们形成策略迭代闭环。回收率按案件批次统计首催回收率和总回收率分开算。首催回收率反映分案策略和的话术质量总回收率反映整条作业链的累积效果。有效接触率有效接触定义为“接通且通话时长大于 30 秒”的外呼次数除以总外呼次数。这个指标高说明电话号码有效、时段配置合理。承诺还款兑现率客户承诺还款金额与实际还款金额的比值。这个比值低于 40%说明催收员承诺引导过松需要回头检查催记模板里的“客户还款能力确认”环节。策略调整后怎么验证一个有效做法是按案件号尾号做随机分组把实验组策略和对照组策略各跑两周然后跑对比查询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 个案件以上才有参考价值。我个人的习惯是每次改策略先用最近三个月的历史案件做一遍回放把案件喂进新的策略引擎里模拟跑一遍看回收率会不会掉再决定是否灰度。这套“历史回放 灰度验证 指标复盘”的做法能挡住绝大多数看似合理实则有害的调整。催收业务系统的价值不在于把产品功能做得花哨而在于让每一条催收动作都能被记录、被分析、被优化。少一个静默案件多一次有效触达系统的收益就已经值回投入。希望这篇文章能帮你的团队少踩几个坑把策略驱动的贷后作业真正跑起来。本文还有配套的精品资源点击获取
