我眼中的信贷产品类的账单

一、业务背景

1. 什么是信贷产品类账单

• 所以信贷账单本质上来讲，是先有个账单，这个账单有账期的概念，里面记录了用户这个账期内的应还的总金额以及这个总金额的构成（即：应还金额发生的所有交易：贷款、分期、计息等）

2. 业务现状

在用户视角下，查账还款是用户访问信贷产品的核心目的，账还额，贯穿整个产品生命周期的核心服务

• 业务视角下，查账以及依靠查账带来的流量之后做的商业化，是信贷产品商业化的基础，账单的用户体验是稳用户底盘的基石
• 以花呗为例，支付宝整个财年围绕账单的更新迭代也印证了这一点

• 第一块主要集中解决账单中万求问题
• 第二块通过丰富衍生服务，提升用户粘性的同时，保障信贷产品健康稳定的向上发展

3. 业务痛点

• 同样以花呗为例

• 如何从产品视角来思考当下解决万求问题的优先级？
• 借助 KANO 模型：

• 根据上述分类，很容易的可以判断出，解决万求类需求属于 ，因此，解决万求问题是当下信贷产品账单的头等大事

二、业务目标

• 信贷产品整体目标是保地盘，以花呗为例，花呗 + 信用购 4.2 亿用户、促活、以及支付余额，到账单产品侧，主要两大目标：
  • 人工万求下降 30%「保底盘」
  • 消费账户用户数3亿「促活」

三、业务上准备做什么达成目标

• 在万求问题上，除了常规 case by case 的需求迭代外，产品侧期望打造一个全链路、全场景、全渠道的的服务型数字人链路，并结合用户云、端行为特征重构当下「人找服务」的传统客服模式
• 重构之后，一方面能够精准识别用户疑惑并给予解答，另一方面 ，有机会将「必备属性」向「期望属性」转变

• 在消费账户访问这一目标，则主要丰富衍生服务的玩法
  • 以花呗账单助手为例，以每月消费挑战活动为支点，通过账单助手皮肤、花呗金等虚拟权益吸引用户，提升产品心智，促进用户访问

四、前端应对方案

• 从过程看万求如何产生：

• 因此，只需要在用户上升至人工客服前，能够 的判断出用户存在的困惑，即可消除潜在万求
• 同时，虽然账单体验问题占整个信贷大盘 1/4，但在其他链路中，用户也一样存在不同的问题和困惑
• 因此需要提供一套 数字人服务生产链路，但其中存在以下两大难点：

难点一：如何精准识别用户疑惑？

1. 在传统的「圈人、投放」模式下，由于是提前针对用户画像的特征做分析并提前归类，向不同的客群投放不同内容，来满足各类差异化诉求，但这在万求上似乎行不通，主要是因为用户在 产生的疑惑这是实时状态，这是传统圈人模式下无法感知的
2. 「精准」这件事情只有更好、没有最好

难点二：如何将数字人服务规模化投产于不同产品链路？

• 要将服务规模化，构建一套稳定、好用的工程链路是必不可少的一环
• 而一套稳定、好用的工程链路的打造，除了需要足够丰富的场景、持续的投入外，是一个好的架构设计

解法：主动服务

• 通过数据和算法精准识别客户问题及需求，主动向客户发起服务，并提供对应解决方案，且能够通过数据跟踪客户行为和带给客户的实际价值

• 为什么需要主动服务？

• 用户价值

1. 主动触达沉默的大多数用户，不只是求助的 2%
2. 先于用户发现问题，先于用户解决问题

五、总结

• 业务前端在业务的理解上没有天然的优势，这导致在业务理解的深度上往往无法和后端同学比，这也限制了前端在业务技术上的深度挖掘的潜能
• 但随着近年，端智能、3D等技术的兴起，前端或能开启一片新的天地，不过如何更大程度的保障前端的技术方案与业务不会水土不服？这当然有很多组织、分工上的保障机制，但从自身出发，提升个人业务理解仍是绕不开的话题，从业务中来，到业务中去～