之后产品经理组织了部门老大和产品、运营进行讨论，运营为了KPI并不愿意筛除这部分用户，因此我们达成一致去推动风控安全部门在底层解决这个问题。但结果不尽人意，风控老大同意了，但账户安全那边不同意，这个问题依旧需要解决。后来跟产品经理商量后，出了下面这个方案:

　　在填写卡号页面提醒用户银行预留手机号和银行绑定手机号必须一致。

　　在填写卡信息页面，如果用户账户有绑定手机号，就直接读取出来并且无法修改，并在此提示用户两个手机号必须一致;如果没有绑定手机号，只提醒必须一致即可。

　　如下图:

　　这样的提示既维持了原有的交互，没有将流程变得更加复杂，也起到了告知作用。唯 一的担忧是过多的提示可能会降低页面转化率，但5月16日-5月25日的切流效果分析数据表明:

　　添加银行卡页面切流用户的的平均转化率为52.68%，总体用户的平均转化率为51.41%，基本维持稳定。

　　填写卡信息页面切流用户的平均转化率为82.43%，总体用户的平均转化率为82.74%，基本维持稳定。

　　五.开通失败补发红包

　　同时在6.0版本，运营提出为了用户开户失败后二次支付的成功率，给这部分用户补发快捷红包，UI稿如下图:

　　5月11日-5月18日的切流效果分析数据表明:

　　用户在收银台申请失败后返快捷红包有助于提高用户继续支付的比例，且提高用户选择快捷支付的比例。

　　具体分析:

　　在用户申请失败后的1小时内，返红包用户继续完成支付比例明显高于不返红包用户。

　　返红包用户中使用快捷支付的用户占比明显高于不返红包用户，且比例高出近20%;因而，申请失败后返快捷红包有助于用户继续完成支付，同时更吸引用户选择快捷支付方式进行支付。

　　阶段收尾

　　从项目上线至今，截止到现在开通用户已有一千多万，大约90%的用户是在收银台进行开通的;且唯品金融的支付成功率为xx%，而收银台的整体支付成功率为xx%左右, 高出了近10个点。至此，收银台开通唯品金融需求暂告一段落。

　　总结

　　很有幸全程参与了这个大项目，在方案不断优化的过程中也引发了我在工作方面的一些思考:

　　每个部门都有自己的立场和目标，运营部门有明确的KPI，风控安全有自己的安全原则，而我们UED部门为用户体验负责。大家都需要多站在对方的立场上考虑，互相沟通、妥协，寻找平衡。

　　关注和分析数据和客诉，并根据相关反馈来优化方案。自己在这个项目中的数据分析是比较稚嫩的，比如有些分析取的时间长度不足,不明白自己想要什么数据而产生了反复的沟通，这些都需要不断进步。

　　不是每个需求都能让数据提升，可以降低客诉也是成功的。多关注客诉，倾听用户的心声。

　　最后，这是我 5月-7月之间的漫长项目记录，现在这个项目的发展已经又有很大不同，仅用此来记录当时的方案、周旋的过程、协调的结果。