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

一、用户管理

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

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

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

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

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 协议