一款完整的产品都会涉及到前后台系统的服务设计，但在实际工作中，信贷产品经理在这两块上会有所侧重。为了让大家对不同岗位的边界更加清晰，作者介绍了主要系统的产品定位和设计思路，希望对你有所启发。
一款完整的互联网产品一定有前端服务设计也有后端系统设计，是前后端系统联动的设计体系。信贷产品经理在实际工作中会有所侧重。前端也称为 C 端，更多强调服务闭环和体验完整性；后端也称为 B 端，更多强调效率达成和解决实际业务问题。
在产品项目推进的过程中，很多项目都是跨系统、跨团队的大项目，随着产品经理对业务的深入，其角色会变为项目的主PM，需要对前端流程和后端系统有充分认知，可以就整体项目之中涉及的系统和对应的职责边界进行快速决断。
每一家互联网金融企业都会有很多的后台系统，名字千差万别，但是解决的问题都是一样的。在《互联网金融产品经理必读》一书中提到一个观点，如今许多企业都会在内部成立业务数字化系统的项目组，集中搭建一批中后台系统，赋能业务发展。
信贷业务中常见的中后台系统有信贷核心系统、分发路由系统、产品管理及定价系统，客户数据资产系统、客户经营系统、小流量配置试验系统、千人千面界面配置系统、营销权益系统、业务数据分析系统等。
除此以外，还有助贷机构 CRM 管理系统负责助贷机构的信息管理，支付清结算系统负责资金划出及资金清分工作，风控系统负责风控策略和风控规则的决策管理等。每一个系统都有专门的产品经理来负责，系统逻辑较为复杂，专业性较强。
为了让大家在实际工作中能快速了解不同系统的核心职责和能力边界，提高工作效率，下面介绍主要系统的产品定位和设计思路。感兴趣的读者可以在实际工作中以此知识为基础，结合具体项目需求深入学习。
信贷业务开展的过程中，借据管理是基础能力。核心系统的主要职责是借据信息的存储和管理、分期计划和息费计算及交易流水管理。
①借据。借据是用来标识客户的一次借款，每个借据都有全局唯一的借据号。借据包含各项息费金额、借款日、借据状态等基础信息。
②分期计划。借据会根据产品规则包含多个分期计划，如 3 期、6 期、
12 期、24 期、36 期等。每个分期计划都有各自息费对应的应还、已还以及分期状态等信息。
③交易流水。交易流水用来唯一标识客户的一次交易行为，如放款、还款、退款等。每一种交易行为对应一个交易码。同时交易行为对应的息费金额等信息的变化过程都会被系统记录和保留。
当业务流程涉及放款、还款、退款、降贷、展期、缩期、息费减免等事项时，信贷核心系统都会针对业务变化，实时调整借据信息。同时，核心系统还负责执行各类跑批任务，跑批任务主要分为罚息计算、借据拆分、退还款清分、出各类对账文件（总账文件、放款明细文件、分期计划文件、借据变更文件等）等。
信贷核心系统是业务最底层的能力建设，也是偏金融业务范畴的系统，信贷核心系统会与风控系统、支付系统、账务系统等后端系统紧密配合。
从产品定位来看，信贷核心系统属于偏后台的数字化系统框架体系。这类系统往往由通晓信贷专业知识和金融业务底层耦合逻辑的 B 端产品经理负责规划设计。
信贷放款需要资金支持，目前的信贷业务，除了使用自营资金承接外， 更多的资金来源需要依靠合作金融机构的资金池。每家平台都会接入几家甚至几十家的合作金融机构。
客户在平台申请一笔贷款后，系统就会匹配一家或多家出资方进行资金承接，在承接匹配的过程中，会出现借款方（客户） 和出资方因为种种原因无法匹配的情况，例如客户的资质和风险评分与出资方的风控要求不匹配，或者出资方的资金不足，出资方系统临时维护等，这时候平台就需要进行快速调整，将这个客户分配给其他机构进行承接问询，找到合适的出资方进行后续的授信、用信、放款等流程，这个过程就称为回收再分发，即先回收、再分发。
为了方便大家理解，后面会用“客户”指代借款方，用“机构”指代出资方。在实际系统项目设计过程中，产品经理和研发经理也经常会使用“客户”和“机构”这两个词来进行日常沟通。
分发路由系统的核心定位是资产（客户）与资金（机构）的精准匹配， 考虑因素包含盈利性、承接率、均衡度和合规政策等。整个分发的逻辑是一个综合判断实时调整的动态过程，属于策略产品设计的范畴，是一个持续迭代的最优策略结果的输出工作。
分发过程包括机构筛选、机构排序和机构轮询。机构筛选主要根据客户的定价等因素筛选合适的承接机构，然后根据资金计划均衡度进行机构排序，排序后进行机构轮询来决定最终可以承接的机构。整个过程对处理时效和承接率有明确的指标要求。
同时分发系统还承接机构拒绝后的客户的回收处理逻辑，将被拒绝的客户重新分配给其他机构，如果客户再次被拒绝且没有找到其他机构承接，则用信失败。系统最终可以根据经营策略进行调配和转移，将客户分配导流给第三方的贷超平台进行资产承接。
简单地说，导流模式就是我自己服务不了的客户，通过贷超产品分给其他外部合作伙伴进行接盘。站在客户体验角度来看，整个流程需要做到信息明示和自愿选择。
回收再分发从系统流程来看，主要分为授信回收再分发和用信回收再分发两类。客户在平台申请授信时，会首先经过平台的自有风控系统的初筛， 然后问询机构的盈利性及风控等要求进行授信 Offer 的输出。
在过程中，平台会问询多家机构的风控系统，得到最终的承接机构，此过程会存在一定的等待耗时，此类属于负向体验折损，尽量让客户减少等待的感受。如果遇到机构维护等异常情况，还会进行缓冲池的兜底设计，将客户暂时放入等待队列而不直接给出最终的失败状态结果。
在业务开展过程中，为了最大化地减少前序流程的转化折损，提升转化率和承接率，目前很多的互联网金融平台都优先采取用信分发的模式，授信时先使用自有风控系统和自营资金进行资质判断和流程承接，在实际用信时再分发给合适的出资机构进行承接，对于客户资料不全的情况，下发对应补件信息引导客户进行资料补充，客户看到的前端流程就是用信补录页。
从客户体验的角度来看，回收再分发的次数不宜过多，最理想的状态就是用信分发的次数只有一次，一次性选择一家出资机构进行匹配，规避切换机构的负向体验感知。所以分发策略的智能化和准确度就显得尤为重要。
有了负责借据管理的核心系统、负责资金分发的分发路由系统，还需要管理产品定价。产品管理及定价系统主要分为两部分：产品管理模块和产品定价模块。
产品管理模块主要负责产品线的创建维护，产品的金融实体要素、定价码管理的信息维护（前面提到的信贷产品金融实体六要素的相关配置能力就是这个模块来承接），同时负责业务八项息费等基础信息的配置。例如某金融平台有现金贷、企业贷、教育贷三款产品，这三款产品就是三条产品线，创建产品线后再进行金融实体要素和定价信息的相关配置关联。
定价管理模块维护了信贷业务线的定价码信息，包括定价码的创建、查看、编辑、生效、失效等操作。
产品定价模块的核心职责包括定价存储、定价查询、调整定价三部分。定价存储服务是对客户的固定价格信息、临时价格信息、临时额度信息进行存储；定价查询服务用于查询客户的定价码
日利率、还款方式、定价因子 1、PNO2、LPR、APR、IRR 等信息；调整定价则负责针对指定定价码、指定幅度、指定最大日利率等不同方式调整定价。
客户的最终 Offer 价格是风控系统决策的，价格信息写入定价系统以便存储和后续调用查询。定价系统的结果会用于前端页面的展示，例如试算页中的借款期限、日利率、年利率、可支持的还款方式等各类信息的计算和字段结果信息都需要定价系统的大力支持。
前端产品经理负责页面表达框架设计，定价系统产品经理负责平台功能，提供实时查询试算接口和对应结果输出的能力。
名词解释：
*内容节选自《互联网金融产品经理必读》
本文由@降峰-小山 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。