当保险APP已成往事
移动互联网的节奏有点儿快，快到了一个时代只有三年。
保险APP时代终结
2015年应该是保险APP的元年。因为从那年开始，真正像模像样儿的保险APP才开始粉墨登场并开启了移动保险交易的时代。
这才三年不到，如果任何公司或者创业者还计划着打造一款保险APP的话，《鼎印三言》就得泼点儿冷水了。
保险APP已成往事，我们可以为往事干杯，但最好不要重复往事，否则不堪回首。2018年是保险微信小程序的元年。
自从2017年1月微信小程序问世短短一年多之后，小程序的月活用户数已经超过4亿。更重要的是小程序应用数量超过100万个。百万量级让微信开始具备了比较强的操作系统属性。腾讯并不需要花钱去雇佣几十万的程序员帮他写程序，无数的商家自掏腰包雇佣程序员或者第三方供应商开发自己的小程序。
根据腾讯2018年一季报，微信用户增长到了10.4 亿。这已经大幅超过了2017年底中国7.53亿的手机网民规模。强者恒强，微信一定会成为第一个“社交型操作系统”。
受用不起的保险APP
过去三年里，我们真金白银地投资过保险APP和2018年开始的保险小程序。通过这些身体力行的实践和经验教训，我更愿意把未来的赌注全部押在保险小程序上，而不会再在保险APP上再投资一分钱。
不是因为保险APP不好，而是开发不起、部署不起、推广不起和使用不起；还因为开发太慢、推广太慢和使用太慢；更因为APP太过繁琐、太重、太啰嗦；最重要的是保险业务过于复杂，需要先交流再交易，而保险APP不容易实现交流与交易的一体化完美体验。
只是在微信小程序出现和成熟以前，APP模式也许是唯一的选择。但是今天我们多了这个更便宜、更快捷、更省事、更应景儿的替代模式。
向保险APP说再见不是我的突发奇想，而是经过以下四个方面认真分析和考量之后的结论。
成本考量
金融科技从业二十多年，我当然不会仅以开发成本作为保险APP vs. 保险小程序的唯一尺度。实际上我们考虑一个应用系统的成本至少要包括下面四个维度：
设计成本
做一款保险APP，我们今天至少要针对iOS和安卓两个平台。而且还要考虑不同的尺寸规格以及两个系统不同的设计要求。
而小程序只需要考虑如何在微信环境下。至于如何适配不同的操作系统则是微信平台要去做的工作。
这样一来，在保险APP的产品设计阶段至少要比保险小程序多花一倍的成本。
开发成本
同理，做APP怎么也要有两个前端开发团队，一个负责iOS，一个负责安卓。这两队人马技术体系上大相径庭，基本没有交集，互相难以借力和协同。
而微信小程序就简单得多了，一个开发团队就可以搞定。
另外，无论iOS也好还是安卓也罢，一个APP都是一套完整的应用软件。因此对于开发人员的要求也是不低的，每个团队里至少得有一个高级程序员。
而微信小程序对程序员的要求没有那么高，很多现成的组件可以直接使用。大部分情况下并不需要“技术大咖”就可以开发出不错的小程序。
那么简单一算，保险APP的开发成本就至少要多200%不止。
测试成本
关于保险APP的测试，我们是有痛苦的经历的。软件这个东西，永远不要相信什么“理论上没问题”，因为到了实践中到处都是坑。
iOS的测试其实还算简单，毕竟操作系统比较统一。但是到了安卓系统上的测试，噩梦可就开始了。各种安卓手机首先就要买上十几部，各种品牌、各种大小型号。
大部分驻扎在北上广深的开发队伍最不能理解的是身边的同事用得好好的APP，为啥到了四五线城市就频繁闪退和形形色色的bug。因为他们不了解，在那些城市几百元的智能手机才是主流，而这些手机在北上广深都买不到。
微信小程序在测试上要省事得多。首先微信能运行吗？如果可以，问题就解决了80%。至于那些低端手机的兼容性问题，腾讯的技术团队早就帮忙搞定啦。
所以测试成本保险APP比小程序要多至少300%！
部署成本
没有亲自推广过保险APP的人通常会忽视推广部署成本。一般保险APP都是给保险代理人用的。不过代理人的能力和素质参差不齐，尤其是到了县级地区。
对于一个只有初中文化程度的中年人来说，安装一个保险APP并不是个简单的事情。iOS上要先打开“App Store”。天啊，什么爱普死多？到了安卓则有过之而无不及，下载应用的地方在不同的手机上还不一样。
互联网讲究的就是成本低。结果你会发现安装保险APP就要投入很多人力，很多时候还要地推人员现场辅导安装。
这个在微信小程序则简单了许多。有微信吗？点右下角的“发现”，再点最下面的“小程序”，在最上面的“搜索小程序”框里输入保险小程序名称，看到了吗？直接点一下，Bingo！
保险APP推广部署这部分经常被忽视的成本其实是巨大的，甚至都无法用百分比来表示。更可怕的是，很多时候由于安装的问题，大量的用户其实都放弃去尝试我们辛辛苦苦开发的保险APP。
速度考量
设计开发速度
保险APP从设计到开发完成至少要2-3个月，这应该只是最基本的核心功能具备的情况。小程序要快得多，1个月左右就可以快速上线。
推广部署速度
上面我们已经说了安装部署APP有多麻烦。即使我们不考虑地推一个一个地支持，仅是计算安装一个APP的时间就已经比找到一个小程序要长得多。
使用速度
使用保险APP最常用的动作是转发一个产品给客户，而通常的转发网络渠道都是微信。从保险APP转发给客户微信的步骤至少要比从保险小程序的转发多两步。
体验考量
谈到体验，很多人一定会质疑。原生APP的体验要好的多，可以做出无比炫酷的效果。看看那些游戏APP，再看看微信小游戏“跳一跳”，逼格简直是天壤之别。
至简至美
其实这就是现在很多保险APP体验设计误入歧途的理念。移动应用的体验应该是朝着一个至简至美的方向，而不是在小小的屏幕上追求琳琅满目的图标。
记得我们投资有线电视网的时候就批评过机顶盒遥控器的设计。一个遥控器上恨不得有40个按钮。老奶奶不戴上老花镜都换不到中央一套看“新闻联播”。这实际上是当年被客户投诉最多的话题，更是设计者的耻辱。
Less is more，少即是多。
商业应用
商业应用不是游戏，不需要那么绚丽多彩和炫酷体验。商业应用要的就是直奔主题，以最简单直接和顺畅的方式把业务做完。
如果只是为了那种华而不实的体验而强调原生保险APP优势，其实是得不偿失的。
受限是福
小程序框架设定了很多限制，但是这种受限是开发者的福音更是投资人的福气。
就这么多控件可以选择，就这么几种方式可以编程，就这么几兆的内存可以使用。这种限制让我们更会认认真真地选择到底哪些才是核心功能，哪些才是必要的能力。
就像我们不会在创业公司账上放太多现金一样。钱多了就会异想天开，就会肆意妄为。
看看上面这款保险小程序就知道了，小程序提供的基本能力也绝对是足以应对很多复杂业务处理的需求的。你能想到的其实都可以实现。
业务考量
今天我们对保险APP的认知差不多都是交易导向的框架思维，认为互联网保险业务要不就是短期意健险的在线购买，要不就是车险的在线比价。在这个框架下，一个产品链接的转发就成了保险核心交易的重要环节。
先交流再交易
但是保险不仅仅是短期意健险，也不仅仅是车险报价，更多的是复杂的产品和服务，是那些需要反反复复交流才可以达成交易的业务。要先交流再交易。
而微信环境就是为交流而生。事实上，目前保险代理人也是先在微信里和客户交流后，才转到保险APP去转发链接回到客户微信，客户也是在微信里跳转到H5进行交易。
这样就存在一个麻烦和风险。交流和交易在两个地方，既不能同步，也不能充分记录。保险APP只有交易记录而无法留存代理人和客户之间的交流过程。简单的产品销售问题不大，对于复杂的业务就显得不够完善了。但是我们又不能要求客户也去像安装淘宝APP一样安装一个保险APP。现在监管部门都在推动双录流程，交流的痕迹留存也许在未来是非常重要的需求。
不过这个问题在微信小程序里是可以解决的。在微信环境里，交流和交易可以容易地整合在一起。客户在这里收到的不是一个产品链接，而就是保险小程序。客户和代理人在这里交流也在这里交易。比如客户如果对上面的安华农险的产品有兴趣，可以直接和安华农险的客服围绕这个产品开始交流，继而处理交易。
想一想，我们连买一套餐具都可能和淘宝店主用“淘宝旺旺”反反复复地讨价还价，更何况是保险这么复杂的业务呢？
事实上，越是复杂的业务越要把交流作为核心交互。只要交流充分了，交易就会随之而来。而微信小程序简直就是为以交流为主的业务而生的。
用完即走
保险是超低频应用。这也是为什么客户就算下载了某个保险APP也不会经常使用。真到该使用的时候呢？呵呵，密码忘了。
对于这种一年就用一两次的应用为什么要吃力不讨好还花钱地开发保险APP呢，甚至还要客户为了一次简单的操作而进行复杂的安装步骤呢？
微信小程序岂不是正好适合这种场景？就像微信之父张小龙对小程序的定位：
“用完即走”。而后，张教父又在一次公开场合对“用完即走”做了补充：“走了还会回来”。
用完即走的本质是任何一个工具都是帮助用户完成一个任务，越高的效率越好。当我们完成一个任务以后，我们当然希望用户能做别的事情，而不是一定耗在一个工具里。
而用完即走和走了还会回来，其实并不矛盾。相反只有当一个用户在一个工具里用得很愉悦，用得很高效，他才会下一次回过头来使用这个工具。
别指望用户会下载并记住保险APP。调查表明一个手机用户经常使用的APP只有不超过七个。就连iOS的设置里都有一项功能可以自动在资源紧张的情况自动卸载不常用的APP，保险APP显然就在此列，可见用户对APP预设的带宽是多么的有限。
给保险小程序起个容易记的名字，然后发给客户的时候立刻就能用，或者客户想用的时候一搜就找得到。然后用完即走，然后想用再回来。而不是启动App Store，然后等着漫长的安装，然后就没有然后了。
现在，已经有100万款小程序上线了。那么你还计划开发一款新的保险APP吗？
