如何设计一个网贷管理后台?

产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下>

本篇文章对网贷后台主要模块进行简要阐述,希望可以通过这篇文章,大家对于网贷后台涉及到的主要业务有大致的理解。

一、用户管理

做任何管理后台都要先明白所设计的功能是给谁用的,也就是这个后台的使用者是谁?他们使用的场景是什么?他们需要做哪些操作?怎么操作才最方便?

多问几个为什么,并去找出这些问题的答案,有助于你产品设计前考虑清楚业务的逻辑,并作为你为何这么设计的依据。

用户管理后台最常见的使用者是客服人员,当然还会涉及到一些其他人员,例如运营、渠道流量等,我们自己的用户管理后台目前主要是给客服使用的。

确认好了使用者,那么他们哪些场景下会需要使用这个系统?主要是以下两点:

  1. 用户来咨询问题,需要后台辅助查询;
  2. 回访特定客户,需要后台辅助查询。

确定好了场景,那么他们需要哪些操作?大致归纳几点:

  • 系统客户查询锁定到某个客户;
  • 客户查看某个客户的详情信息;
  • 可以记录跟踪客户的问题;
  • 可以筛选出某种类型的客户。

确定好需要做的一些操作,那么你要开始思考如何去做,才能帮助他们在系统中最快地查询到所需要的信息。本着能一步操作的绝不用两步,能两步操作的绝不用三步地原则。操作繁琐也会浪费很多的时间成本,毕竟客服咨询量大的情况下,将他们的操作步骤减少,将大大提升他们的工作效率。

假如一个客服每天接待客户200人,每个客户查询节省10秒钟的话,那么一天他们可以节省的时间为2000秒,也就是33分钟;假如客服团队有100人,那么整个部门就节省了3300分钟,也就是55小时。按照每人8小时制来算,那么就相当于每天可以节省了6.87个人力。数字真是一个神奇的东西,能让人直观看到你想要的东西。

关于怎么做才能操作上更便捷,这个需要你深入业务方,了解他们具体的业务场景,每天都会用到哪些功能,都会查询哪些信息,哪些是必查信息,哪些是偶尔会查询到的信息。千万别自己YY,因为你不是使用者,基于业务的需求去思考,才能做出符合甚至超出使用者预期的产品。

至于具体怎么做,还是自行去探索吧,业务至上,多听、多看、多问、多思考。

二、风控管理

风控可以说是网贷的心脏,保证流量的情况下,风控做的好直接决定这个产品的盈利能力。那么,要做好风控规则,需要一个强大的后台支持,所有规则做到灵活可配,才能不断做出策略调整,来规避已经发生的或者潜在的一些风险 。

首先,跟大家简单介绍一个风控后台涉及的模块及大致的流程。

从图中我们可以看出,风控后台大致会涉及的5个模块:

  1. 场景:触发风控规则的场景
  2. 指标:制定规则的条件源
  3. 规则:通过规则得出风控决策
  4. 接口:需要大量的第三方数据源支持
  5. 风控报告:结论的展现形式

下面我将每个模块具体的功能及职责再做详细的介绍,在做详细介绍前,我觉得我有必要把网贷平台借款的全流程展示给大家看下,当然每个平台的流程都会有或多或少的差异,只是方便大家理解文章后面的内容。

场景管理

一般来说场景的设置取决于业务的需求,场景存在的意义是将规则绑定在场景下,决定这个场景下遵循这些规则。常见的场景有:

  • 注册/登录:这里的场景使用更多可以说是一个安全拦截,可以通过风控策略拦截掉一批非正常操作的客户。注册登录的时候就予以拦截掉,例如同一个设备注册过多账号或者同一个账号关联过多的设备,都可以认为是异常操作。
  • 预审:这里的场景是综合客户填写的个人信息、工作信息、联系人信息、第三方数据等,根据规则结论决定客户是否能借款,能借多少金额。
  • 信审预审:当客户获取到额度后发起借款,会再次对其借款资质进行审核。通过直接放款,拒绝进入人工复审。

场景管理后台设计会比较简单,主要就是设置下场景编码,为了后面规则设定时可以来绑定已生成的场景,进入这个场景,仅运行绑定在这个场景之下的规则。

指标管理

指标是来自自有数据及第三方的数据字段,配置规则时可任意选择已有的所有指标。

例如,“年龄”就是一个指标,指标都是提前录入到数据库的,数据库中指标都是根据各个数据接口进行分类存储的。所以前端指标的录入需要根据数据库-表-指标名进行录入,录入成功后,可用状态的指标在规则配置时可选择使用。

规则管理

前面说到风控是网贷产品的心脏,那么规则管理则是风控的心脏,所有规则的配置及修改都是通过这里完成。

规则的模式

规则模式一般有三种:结果模式、评分模式、额度模式。

  1. 结果模式:只输出一个结果,结果为通过、拒绝、人工审核。
  2. 评分模式:输出的是分数,也可以启用决策引擎输出结果+评分。
  3. 额度模式:输出的是可以借款的额度。

规则的组成

规则是由N个表达式组成的,表达式是由条件跟结果组成,条件由指标+特殊字符+赋值组成,结果根据规则模式产生不同的结果。

表达式的关系

  • 结果规则下关系有:全部通过则通过、任一通过则通过;
  • 评分模式下关系有:取最大值、取最小值、全部相加;
  • 额度模式下关系有:取最大值、取最小值、全部相加。

规则排序

由于有些第三方数据指标是涉及费用,所以如果免费的数据指标已经产生拒绝的结果,则不用再触发后续的规则。这个情况就可以针对规则做个排序,可以决定优先跑哪些规则。这样就可以按照规则排序跑规则,一旦出现拒绝的结果,则不再跑后续规则。

规则配置参考原型

内部逻辑较多,不再一一阐述。

调用接口管理

调用接口管理相对也比较简单,主要是配置第三方接口调用的周期,周期一般是每次或者固定天数周期。

风控报告

每个用户,触发每个场景后,输出一个结果,就要对应生成一个风控报告。首先是场景下规则及规则结果的汇总,然后是每条规则下表达式及表达式结果的展示,这个一般是风控人员有查看需求。

三、信审管理

首先简单介绍下信审具体是干什么的,上节说的是风控管理后台,其实风控跟信审都是做信息及借款资质审核的。风控是机审的过程,信审是人工审核的过程,也就是一些机器规则无法判断的客户,需要人工来复核信息及借款资质。

那么,很明显,这个就是服务信审员来审核进入人工的借款订单的一个系统,更简单来说也可以将它理解为一个工单系统。

还是先抛个流程图给大家,方便理解下信审的业务逻辑,只有先理解了业务,才能知道系统如何做,如下图所示。不过不同平台信审流程会存在一定差异,我这里展示只介绍只有初审跟复审两个环节时的流程。

下面就针对订单池、订单分配、订单处理这几个模块跟大家讲解下设计中需要注意的一些事项。

订单池

机审判断进入信审的订单,会统一进入订单池进行管理,管理员可以通过这里进行订单的分配,这里有以下几点注意事项。

  • 针对订单池进行分组,分为初审跟复审;
  • 处理订单的信审员要根据初审跟复审组去分组,在哪个组决定了处理哪个组的案件;
  • 只有初审通过的订单才需要进入复审待分配的订单池;
  • 复审通过的订单触发放款按钮。

订单分配

订单分配方式可以有多种,最智能的当然是可以自动分配订单了,产品0-1的过程一般不会做自动分案,需要等1-N的过程陆续迭代。

先说下人工分配吧,人工分配订单也需要注意一些业务逻辑。

  • 可选择分配人为该组别人员;
  • 可选择分配人为在线状态人员;
  • 分配支持单独分配跟批量分配;
  • 已分配未处理完成订单支持再次分配,可能会存在分错或者需要他人协助处理的情况。
  • 处理完成的订单要移出分配池,减少查看处理订单上的复杂度。

参考原型

自动分案的逻辑大致如下图,较为复杂,会耗费比较长的开发周期,不多说了。

订单处理

分配完成的订单,信审员需要有个专门查看自己订单的界面,只需要专注处理自己的订单即可。

需要注意到的几个业务逻辑有:

  • 案件的状态:待分配、待审核、审核中、审核通过、审核拒绝;初审、复审都会涉及到这些状态。
  • 审核记录的登记入口。
  • 审核会涉及到电话呼出核实,需要有话机系统的支持。
  • 审核内容:个人基本信息、工作信息、身份证及人脸识别、联系人信息、风险信息等等,具体要查看哪些建议跟业务部门确认。

以上是业务订单处理上所需的系统支持,任何部门的工作都是需要制定自己的考核标准,信审员的日常工作效率及业绩情况也是需要追踪的。

所以,就需要一些数据呈现或者是业绩报表的统计,来衡量业务能力的好坏。一般来说有这几个考核指标:审批规范监督、审批效率统计、审批业绩统计。

审批规范监督

业务方自行制定了自己的审批流程,一般会需要针对执行者进行监督检查,通常会设置专门的质检岗位,质检审查会审核信审员的沟通记录情况、处理时效性、监听外呼录音等。

那么需要展示到后台的内容有:

  • 沟通记录明细,展示记录内容、审批结果、拒绝原因等等;
  • 录音记录明细,可用来监听录音;
  • 处理时效统计,分配时间到订单关闭时间的时长统计。

审批效率统计

  • 每个信审员每天审核订单量;
  • 每个信审员每天审核一个订单的最短时间、最长时间、平均时间(时间计算是从分配成功到处理完成);
  • 每个信审员每天审核订单结果的统计,通过数量、拒绝数量等等;
  • 整体数据的统计,每天审核订单数量,通过数量、拒绝数量等。

审批业绩

审批业绩是考核信审员的最重要的参考数据,其中最重要的是逾期率,良好的资信审核能力,可以进一步降低贷后产品逾期率,一般会统计以下几个指标:

  • 放款笔数:复审通过后,即会放款,那么这个成功放款的订单同时统计到初审员及复审员的放款量里面;
  • 正常结清笔数:到期前正常结清,未发生逾期;
  • 逾期笔数:到期未还款或者部分偿还都算逾期;
  • 到期笔数:按照到期时间统计所有到期数据。

逾期率=统计周期内总逾期数量/统计周期内总到期数量

四、催收管理

前面三小节分别介绍了用户管理、风控管理、信审管理的内容,按照顺序自然迎来了贷后催收管理板块。

催收顾名思义就是催促收回逾期资金,风控跟信审是贷前去尽量避免逾期的,在尽量规避风险的原则下,也要考虑放款率,这两者之间要取平衡。所以出现逾期可以说是正常的现象,只要在可预期范围内都可以接受,国内一般逾期率在10%以内属于较好水平。

逾期之后为了进一步降低平台损失,所以就需要贷后催收团队,将已经发生逾期的资金尽力陆续追回。

催收管理其实跟信审管理可以都看作是一个订单处理系统,根据业务逻辑来设计案件的流转。

老套路,先把业务逻辑放出来给大家看下,方便后续的理解。一般来说,会根据产品的期限来配比催收阶段,如果是短期的产品,一般是按照天来设置催收阶段。

  • S0:-2-0天,到期前的提醒还款组;
  • S1:1-7天,负责逾期7天内的案件催收组;
  • S2:8-15天,负责逾期8-15天的案件催收组;
  • S3:16-30天,负责逾期16-30天的案件催收组;
  • S4:31天及以上,负责逾期31天及以上案件的催收组。

如果是较长期限的产品,一般是按照月来划分的,例如M0、M1、M2、M3、M4等等。

案件流转

本节的重点在于介绍案件流转的逻辑,其他都比较简答,可能就几句话带过了。

以短期产品为例,案件的流转逻辑如下图所示:

复杂的逻辑都在案件流转这里,如何流转、如何分配及案件的状态变更都要考虑清楚。其实,上面的流程图已经很清晰了,重点说下中间可能涉及到的一些逻辑及状态。

  • 需要根据到期时间推算具体进入哪个案件池;
  • 一旦重新进入案件池,案件的状态需要变更为未分配的状态,需要重新被分配;
  • 重新分配的案件负责人需要变更为最新催收员的姓名;
  • 一旦结清的案件后续不需要再流转,自动移除案件池,并且该状态更新为催收完成;
  • 当进行案件分配的时候,可选择分配的催收员为对应催收小组里面的人,例如我筛选出来S1组别的案件,那么点击分配时,可选择的催收员,也应该是S1组别里面对应的催收员;
  • 已分配未催收完成的案件,支持再次分配,可能会涉及到分错人或者人员离职的情况,案件未流转到新的催收阶段,需要重新安排负责人员。

参考原型

我的案件

案件被分配后,各个信审员可以通过我的案件页面处理自己的订单。这里催收完成订单跟催收中订单,最好分开展示。催收员处理的时候,最需要关注催收中的订单,需要注意的是这里仅展示分配给自己的订单。

案件详情页需要展示内容:

  • 当前逾期的订单信息,包括产品信息、金额信息等;
  • 个人基本信息,了解个人情况以便更好的催收;
  • 紧急联系人信息信息;
  • 通讯录信息;
  • 所需要的第三方信息等。

催收明细及录音明细类似于上篇文章信审讲到的,主要用于催收规范的监督,不再做过多赘述,可查看上篇文章。

催收业绩

催收员主要以催回率作为考核指标:

催回率=某一段时间内催收完成案件数/某段催收总案件数

催收总案件数=周期内在催案件数量+周期内催收完成的数量

本篇文章先讲这么多吧,欢迎交流。

 

作者:南先生,公众号:I am 南先生

本文由 @南先生 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 别给他们做吧…

    回复
  2. 老铁在做东南亚现金贷吗?可以加个微信交流下。jun2011

    回复