记一次B端产品CRM的改版
这篇文章主要是复盘之前做的一次系统改版。
这篇文章主要是复盘之前做的一次系统改版。时间已经过去一年，回过头来看，当初那个非常tough的项目，带给我的成长和收获也是巨大的。
去年我刚刚接触To B系统，对业务还不甚了解，就突然接到了系统改版的任务，迷茫且慌张，但还是硬着头皮上了。幸好。
现在重新梳理项目，于是有了这篇文章。
这次改版的系统（以下简称为Borrow系统）主要负责借款的流转，整个流程包括：进件（即提交客户基本资料）→风控审核→签约→放款。（具体见下图）
这次改版是所谓的“设计主导”，也就是说，没有需求方来主动下达任务，而是由设计师去主动发掘改版需求，提出改版目标并探究其必要性。所以，首先要通过调研来确定改版目标。
我的调研方式主要包括：
1.与产品经理沟通了解产品概况；
2.在现场观察用户的使用情况，并进行一对一访谈；
3.查阅系统的历史演变过程，并了解与之有数据交叉的其他系统。
我主要对以下几个方面进行了调研：
用户
首先要搞清楚，到底是谁在使用这个系统。
通常我们面对的系统，都是满足某一类用户的需求，用户在系统里的工作流也是确定的。
但是我发现，在Borrow系统中，有几类不同的用户都在使用。主要为：分公司门店的线下客服（以下简称门店客服）与电销中心的电销（以下简称中心电销）。
除此以外，还有少量的其他用户，比如主要服务其他业务线的兼职电销也会阶段性地做这部分业务，比如线下销售也偶尔会在系统里查看相关数据。
通过进一步跟产品经理沟通发现，在这些用户中，线下客服是使用数量最多，且贡献价值最大的用户（为公司赚钱最多）；其次为电销中心的电销。所以我决定此次改版，将线下客服定为主要用户，同时考虑电销的使用。忽略其他群体。
工作流与工作目标
确定主要用户后，我就申请到分公司做现场调研：现场观察用户的日常工作和使用系统的情况，并针对发现的问题作一对一访谈。
因地理条件所限，我选择了同城的门店客服进行线下调研；对中心电销采取了线上采访的方式。（如果条件允许，建议大家申请出差到核心用户身边进行现场调研，收获真的很大。）
门店客服：
门店客服的工作主要由三部分组成：M1阶段的催收（逾期一个月以内的借款的催收），进件（将销售提交的纸质资料录入系统），签约（当录入系统的借款通过审核，走到签约环节的时候，需要来到门店进行线下签约）。其中，与Borrow系统产生交互的部分主要是进件。
想要做出用户喜欢使用的系统，就要知道用户的工作目标，最直接的体现就是“钱”。为此，我仔细询问了门店客服的工资绩效，发现：门店客服的绩效是直接与签约量挂钩的，签约客户的逾期会影响绩效；而进件只是一个基本工作任务，不计入考评。
然而不合理的是，“进件”作为不计入考评的任务，却因系统的不便，占用了门店客服大量的时间。由此，我决定，将“进件流程”的改版，作为整个大改版的切入点。这样的话，在缺乏强有力推动的现实制约下，花少量人力，去解决一个痛点，更容易增强业务方对改版的接受程度。（业务方对技术部发起的改版并不都是支持的态度，这涉及到业务方和技术部对产品期望不同，下一部分将会进一步阐述。）
需要注意的是，在线下的业务中，门店各自保持着相对的自由度，譬如不同的绩效考评方式，不同的签约条件等。所以在后期，我们又专门挑选了几家逾期率最低的几家门店，进行了一对一采访。
中心电销：
与门店客服相比，中心电销的工作更多地在“借款前”这个阶段，比如对意向客户进行产品介绍，比如辅助意向客户完成借款流程。而且因为与门店客服负责的业务不同，中心电销也不涉及“催收”的工作。
中心电销的主要工作是：每天被分配到一定的客户，然后依次拨打电话，了解客户意向以及推荐借款产品，并协助完成借款流程。其中，中心电销会通过手动筛选客户来优先联系“高质量客户”（这属于电销为了业绩的个人行为）。
中心电销的绩效主要也是看最终的放款量（即签约量），会考虑通时通量以及语音质检结果，但不是主要因素。
产品期望
不同的角色对于产品的期望是不同的，而权衡不同角色的期望，最终决定改版的目标，就是我们调研阶段最重要的任务。
从技术的角度出发，我们更希望系统能够体现技术的价值，比如，通过一些自动化行为，替代部分一线业务人员的机械劳动；但是业务方却并不想自己的人员被削减。类似这样的改版除非是有强大的来自上层的压力去推，否则非常容易因为业务方的不配合而失败。
所以，在前面提到的，用一个引起痛点的小模块的改版来赢得业务方的信任，后续再进行更大的改动，是非常重要的。
通过访谈和观察，我了解到：
产品经理对Borrow系统的期望是，在满足业务需求的基础上，可以提供通用的解决方案，早日将系统Saas化；
业务方leader的期望是，加强数据报表的建设，能直观准确地得到各个环节之间的转化率，以便及时调整策略；得到员工相关的多维度信息，更全面客观地评价员工的工作情况，合理安排人员、分配任务。
一线业务同学的期望比较琐碎，我提炼了一下，大概就是高效（优化交互流程，减少不必要跳转）、准确（减少误操作的概率）、流畅（系统响应速度加快）的系统。
产品经理的期望相对理想化，我认为应该当作纲领一下去看，是不能偏离的方向；而业务同学的期望，正是我们改版的着眼点。
最终，“高效“，”准确”，“流畅”，“数据”，成为了我们这次改版的四个关键词。
历史演变
在改版动工之前，关注系统的历史演变情况，能帮我们有效避免不少前人走过的坑。
如果公司内部有良好的文档留存习惯，在公司的wiki上，应该能看到不少关于项目的历史纪录。比如历史版本变更记录，历史需求文档，每一季度的产品map，甚至还有一些重大改版的复盘讨论。
即使没有较多的有效文档留存，也可以通过与产品经理和项目核心成员的聊天中，挖掘一些历史修改信息。
通过了解系统的历史，能对如何开展改版有更客观的认识，对遗留太久太深的历史问题，要逐渐改变而不是推翻重来；而另外一些我们以为很不合适的方案，可能已经是经过数版改动而妥协的方案，刚愎自用，任性推新，反而会造成人力财力的浪费。
另外，了解相关联的其他系统，了解在整个业务中，不同系统的权责划分，能够让我们站在更高的高度上去思考问题。另外，当我们当前系统的数据无法支持设计目标时，也可以寻找对应系统的负责人去寻求帮助。
改版流程
在改版过程中，我以“进件流程”为切入点，做了一次控件的优化。例如：输入框，针对输入内容显示做优化，比如银行卡按四位数一个空格的标准显示；输入框根据输入字符数或基本格式（比如身份证号，手机号等有基本格式的字符）增加前端判断，前端可以判断的，直接报错，以免进入流程，浪费时间；上传文件交互优化，减少点击次数等。
这部分改动较小，但是对操作者的帮助较大。上线后快速赢得比较好的反馈。
后期我们又进行了更深入的信息架构的优化，以及核心工作流的优化。但是因业务方向变动，最终这部分被剥离出业务，成为了飞机稿。
