从零开始构建一套完整的业务系统

发表时间: 2024-01-12 11:05

本文将以催收系统为例,分享如何去设计一套业务系统。希望对你有所帮助。

最近开始接触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协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务