从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、触达场景的间隔和频率。对于外呼和寄信两种场景，时间间隔和频率要提前控制好，控制不好可能引起客诉。

以上，就把催收系统的设计流程讲完了。希望可以帮助到你~

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！