如何设计网贷管理后台？

本文简要介绍了网贷后台的主要模块。希望通过这篇文章，大家对网贷背景所涉及的主要业务有一个大概的了解。

一、用户管理

做任何管理后台，首先要了解设计的功能是给谁使用的，也就是这个后台的用户是谁？他们使用的场景是什么？他们需要做什么？怎样操作最方便？

多问几个原因并找出这些问题的答案，这将有助于您在设计产品之前清楚地思考您的业务逻辑，并将其作为您设计这种方式的基础。

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

确认用户后，哪些场景需要使用该系统？主要有以下两点：

用户来查询问题，需要后台辅助查询；

场景已经确定，那么他们需要采取哪些行动？大致可以总结几点：

系统客户查询锁定到某个客户；客户可以查看某个客户的详细信息；可以记录和跟踪客户的问题；它可以过滤掉特定类型的客户。

确定一些需要做的操作，然后你就得开始思考如何去做，以帮助他们尽快在系统中查询到他们需要的信息。本着一步操作不使用两步，两步操作不使用三步的原则。繁琐的操作也会浪费大量的时间和成本。毕竟在客服咨询量很大的情况下，减少他们的操作步骤，会大大提高他们的工作效率。

如果一个客服每天接待200个客户风控系统审核主要审什么，每次客户查询节省10秒，那么他们每天可以节省2000秒，也就是33分钟；如果客服团队有 100 人，那么整个部门节省了 3300 分钟，也就是 55 小时。按每人8小时制计算，则相当于每天节省6.87人力。数字是一种神奇的东西，你可以直观地看到你想要什么。

关于怎样做才能让操作更方便，这需要你深入到业务端去了解他们具体的业务场景，每天会用到哪些功能，会查询哪些信息，哪些是必查的，以及哪些是偶尔查询的信息。不要自己YY，因为你不是用户，你只能从业务需求出发，通过思考，做出满足甚至超过用户期望的产品。

至于怎么做，还是自己摸索吧，生意第一，多听，多看，多问，多想。

二、风控管理

风控可以说是网贷的核心。在保证流量的情况下，良好的风控直接决定了该产品的盈利能力。那么，要做好风控规则，就需要强大的后端支持，所有的规则都是灵活可配置的，这样你就可以不断地进行战略调整，规避一些已经发生或潜在的风险。

首先简单介绍一下风控背景所涉及的模块和大致流程。

从图中我们可以看出风控后台大致涉及五个模块：

场景：触发风控 规则场景指标：规则制定的条件来源 规则：通过规则进行风控决策 具体功能和职责将详细介绍。在详细介绍之前，我觉得有必要给大家展示一下网贷平台借贷的全过程。当然，每个平台的流程都会或多或少有所不同。 ，只是为了让大家更容易理解文章背后的内容。

场景管理

一般来说，场景的设置取决于业务的需求。场景的含义是绑定场景中的规则，决定在这个场景中遵循这些规则。常见的场景有：

注册/登录：这里的使用场景可以说是一种安全拦截风控系统审核主要审什么，可以通过风控策略拦截一批异常客户。注册登录的时候会被屏蔽。例如，如果同一设备注册了过多的账号，或者同一个账号关联了过多的设备，则可以认为是异常操作。预审：这里的场景是整合客户填写的个人信息、工作信息、联系方式、第三方数据等，根据客户是否可以借，可以借多少钱规则的结论。信用审核和预审核：当客户在获得额度后发起贷款时，将重新审核贷款资格。通过直接借贷，拒绝进入人工审核。

场景管理的后台设计会比较简单。主要是设置场景代码。为了后面设置规则，可以绑定生成的场景，进入这个场景，只在这个场景下运行绑定。的规则。

指标管理

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

例如，“年龄”是一个指标。指标预先录入数据库，数据库中的指标根据各个数据接口进行分类存储。因此，前端指标的录入需要根据database-table-indicator名称进行录入。录入成功后，可以选择可用状态的指标在规则配置中使用。

规则管理

如前所述，风控是网贷产品的核心，那么规则管理是风控的核心。所有规则的配置和修改都在这里完成。

规则模式

规则模式一般分为三种：结果模式、计分模式、配额模式。

结果模式：只输出一个结果，结果为通过、拒绝、人工审核。评分方式：输出为分数，也可以开启决策引擎输出结果+分数。配额模式：输出是可以借到的金额。

规则的组成

规则由 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组的case，那么点击分配的时候，选择的采集器也应该是对应采集组中的对应采集器S1组；已分配但未收集的案件，支持重新分配，可能涉及分配错人或人员离开时，案件尚未转入新收集阶段，需要重新安排责任人.

参考原型

我的情况

案例分配后，各种审阅者可以在案例页面处理您自己的订单。在这里，收集完成订单和收集订单最好分开显示。采集器在处理时，最重要的是要注意采集中的订单。需要注意的是，这里只显示分配给他们的订单。

需要展示案例详情页面的内容：

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

征集明细和记录明细与上篇信评中提到的类似，主要用于征集规范的监管。

收藏效果

收藏家主要以收藏率作为考核指标：

收案率=一定时期内完成的案件数/一定时期内收案的总案件数

收集的总病例数=周期内收集的病例数+周期内完成的收集数

本文先讲这么多，欢迎交流。