本篇文章对网贷后台主要模块进行简要阐述，希望可以通过这篇文章，大家对于网贷后台涉及到的主要业务有大致的理解。
一、用户管理
做任何管理后台都要先明白所设计的功能是给谁用的，也就是这个后台的使用者是谁？他们使用的场景是什么？他们需要做哪些操作？怎么操作才最方便？
多问几个为什么，并去找出这些问题的答案，有助于你产品设计前考虑清楚业务的逻辑，并作为你为何这么设计的依据。
用户管理后台最常见的使用者是客服人员，当然还会涉及到一些其他人员，例如运营、渠道流量等，我们自己的用户管理后台目前主要是给客服使用的。
确认好了使用者，那么他们哪些场景下会需要使用这个系统？主要是以下两点：
用户来咨询问题，需要后台辅助查询；
回访特定客户，需要后台辅助查询。
确定好了场景，那么他们需要哪些操作？大致归纳几点：
系统客户查询锁定到某个客户；
客户查看某个客户的详情信息；
可以记录跟踪客户的问题；
可以筛选出某种类型的客户。
确定好需要做的一些操作，那么你要开始思考如何去做，才能帮助他们在系统中最快地查询到所需要的信息。本着能一步操作的绝不用两步，能两步操作的绝不用三步地原则。操作繁琐也会浪费很多的时间成本，毕竟客服咨询量大的情况下，将他们的操作步骤减少，将大大提升他们的工作效率。
假如一个客服每天接待客户200人，每个客户查询节省10秒钟的话，那么一天他们可以节省的时间为2000秒，也就是33分钟；假如客服团队有100人，那么整个部门就节省了3300分钟，也就是55小时。按照每人8小时制来算，那么就相当于每天可以节省了6.87个人力。数字真是一个神奇的东西，能让人直观看到你想要的东西。
关于怎么做才能操作上更便捷，这个需要你深入业务方，了解他们具体的业务场景，每天都会用到哪些功能，都会查询哪些信息，哪些是必查信息，哪些是偶尔会查询到的信息。千万别自己YY，因为你不是使用者，基于业务的需求去思考，才能做出符合甚至超出使用者预期的产品。
至于具体怎么做，还是自行去探索吧，业务至上，多听、多看、多问、多思考。
二、风控管理
风控可以说是网贷的心脏，保证流量的情况下，风控做的好直接决定这个产品的盈利能力。那么，要做好风控规则，需要一个强大的后台支持，所有规则做到灵活可配，才能不断做出策略调整，来规避已经发生的或者潜在的一些风险 。
首先，跟大家简单介绍一个风控后台涉及的模块及大致的流程。
从图中我们可以看出，风控后台大致会涉及的5个模块：
场景：触发风控规则的场景
指标：制定规则的条件源
规则：通过规则得出风控决策
接口：需要大量的第三方数据源支持
风控报告：结论的展现形式
下面我将每个模块具体的功能及职责再做详细的介绍，在做详细介绍前，我觉得我有必要把网贷平台借款的全流程展示给大家看下，当然每个平台的流程都会有或多或少的差异，只是方便大家理解文章后面的内容。
场景管理
一般来说场景的设置取决于业务的需求，场景存在的意义是将规则绑定在场景下，决定这个场景下遵循这些规则。常见的场景有：
注册/登录：这里的场景使用更多可以说是一个安全拦截，可以通过风控策略拦截掉一批非正常操作的客户。注册登录的时候就予以拦截掉，例如同一个设备注册过多账号或者同一个账号关联过多的设备，都可以认为是异常操作。
预审：这里的场景是综合客户填写的个人信息、工作信息、联系人信息、第三方数据等，根据规则结论决定客户是否能借款，能借多少金额。
信审预审：当客户获取到额度后发起借款，会再次对其借款资质进行审核。通过直接放款，拒绝进入人工复审。
场景管理后台设计会比较简单，主要就是设置下场景编码，为了后面规则设定时可以来绑定已生成的场景，进入这个场景，仅运行绑定在这个场景之下的规则。
指标管理
指标是来自自有数据及第三方的数据字段，配置规则时可任意选择已有的所有指标。
例如，“年龄”就是一个指标，指标都是提前录入到数据库的，数据库中指标都是根据各个数据接口进行分类存储的。所以前端指标的录入需要根据数据库-表-指标名进行录入，录入成功后，可用状态的指标在规则配置时可选择使用。
规则管理
前面说到风控是网贷产品的心脏，那么规则管理则是风控的心脏，所有规则的配置及修改都是通过这里完成。
规则的模式
规则模式一般有三种：结果模式、评分模式、额度模式。
结果模式：只输出一个结果，结果为通过、拒绝、人工审核。
评分模式：输出的是分数，也可以启用决策引擎输出结果+评分。
额度模式：输出的是可以借款的额度。
规则的组成
规则是由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组别里面对应的催收员；
已分配未催收完成的案件，支持再次分配，可能会涉及到分错人或者人员离职的情况，案件未流转到新的催收阶段，需要重新安排负责人员。
参考原型
我的案件
案件被分配后，各个信审员可以通过我的案件页面处理自己的订单。这里催收完成订单跟催收中订单，最好分开展示。催收员处理的时候，最需要关注催收中的订单，需要注意的是这里仅展示分配给自己的订单。
案件详情页需要展示内容：
当前逾期的订单信息，包括产品信息、金额信息等；
个人基本信息，了解个人情况以便更好的催收；
紧急联系人信息信息；
通讯录信息；
所需要的第三方信息等。
催收明细及录音明细类似于上篇文章信审讲到的，主要用于催收规范的监督，不再做过多赘述，可查看上篇文章。
催收业绩
催收员主要以催回率作为考核指标：
本篇文章先讲这么多吧，欢迎交流。
