这个月,【服务号消息折叠】灰度测试开始了,这也是【压倒】我们最后的一根稻草。
当然我们没有倒,只是让我们下定决心彻底放弃微信生态,彻底转向自有APP的发展方向。
------------------下面是我们如何一步步被逼到离开微信生态的----------------------
我们是一家普通的不能再普通的垂直领域saas开发商,开发的软件是给B端用户管理、分享自己的产品信息和轻度的crm管理。
其实本质就是向B端提供基于微信小程序的产品图片/视频分享的能力,并利用小程序的个人信息授权机制,帮助我们用户的管理者可以更方便的知道自己员工和客户的对接情况。
这么个业务需求,负责的说:是不需要APP的。
所以一开始,我们就基于微信的生态来考虑和规划产品,完全没想过要APP。
可最后,我们又怎么能想到,一个原本不需要APP的业务,会被一步步的逼到必须要自有...不,确切的说是要完全转到APP的路上呢?
初版APP的诞生:
因为微信支付【按月扣费】功能,几乎极端的审核门槛。
我们是一个收费软件,一开始由于体量不大,采用按年支付。
但当业务发展到一定规模后,我们发现对于垂直领域的B端项目,按年支付非常不利于项目现金流的管理,会出现每年有1-3个月收入暴增,而其它几个月几乎是0收入,这是非常不健康的状态。
和财务探讨后我们决定改为【订阅制】,以便让项目现金流逐月稳定。
众所周知的原因,在微信生态你只有微信支付可选,但当我们去了解相关功能时,却发现微信支付【自动扣款】的门槛是一个我们不可能达到的标准:要求【过去X天,微信商户号有累积xxxx笔订单】(xxxx这个数字可能我记错了,但就是一个垂直领域软件不可能达到的数字)。
而转头一看另一个蓝色的支付软件,只要公司经营资料正常即可直接开通相关能力。
这促成了我们第一版APP的诞生,纯粹只是为了能正常按照我们的业务需求开展业务。
其实,到这里我们还是觉得微信有自己的规范和理解,我们也愿意遵守,无非是用uni再写一遍的事嘛。
时间很快来到了第二版APP的诞生,以及为我们立下汗马功劳的微信小程序端....停止更新.......
升级APP:
因为微信小程序不再允许拉起APP+小程序不再允许一键获取昵称、头像
我们原来的业务逻辑是:用户通过服务号接收系统的推送通知(一个轻量级的saas软件能推送什么呢?全部都是B端用户内部的通知啊!),点击推送卡片后拉起小程序查看详情,如果能在小程序内完成的操作就在小程序完成,不能完成的(比如...会员到期续费),就拉起APP。
然后,微信不允许从小程序拉起APP了,只允许从app拉起小程序后,再返回APP。
这次变动导致了一个奇怪的结果:
-如果我的用户已经从APP里拉起了小程序,那他为什么还要去小程序里操作?直接在APP里操作不就完了??
-如果他通过服务号卡片拉起的小程序不能支持他完成所有的操作,他又为什么要进小程序?不能直接打开APP吗?
(这里我们特别疑惑的是:明明在开发者账号中我们绑定了关联的app,公众号,小程序,都在同一个主体下。完全可以允许同一开发者,同一主体下的小程序拉起自己的app,为什么要搞一刀切呢?)
这种情况下,我们剩下的解决方案只有2种:
第一、让我们的小程序能够有所有的功能。
第二、直接强化APP,放弃小程序。
正在我们犹豫不觉得时候,微信小程序的又一次规则改动,促成了我们强化app的路线,因为:小程序用户头像和昵称不再允许一键授权,必须用户手动设置,同时还必须允许用户不设置。
这不是好不好用的问题了,简直就是蠢不蠢的问题。
(微信的昵称和头像本来就是用户自己设置的公开信息,居然会被认为这是隐私信息)
请做出这个决策的微信产品经理好好想想...我一个toB的产品,是有团队成员概念的,当强制允许所有注册用户可以不设置头像昵称也能正常登录、使用时,我开发者怎么判断这个用户?我的B端用户怎么判断他团队里的这个人是具体哪个员工?
是不是这么个理?
停用小程序,转向app,是我们唯一的选项。
服务号里的卡片信息也不再拉起小程序,而是一个简化版的h5,用以实现一键拉起app。
但到此为止,我们还是比较依赖微信生态的,因为系统内的通知我们还是依赖服务号消息推送给用户,每个app注册用户也会引导他们去关注我们的服务号,所以即便有自己的app,我们通知功能做的也很弱。
直到......
现在.....服务号消息被折叠了
这一点社区里已经骂开了,这事到底对不对相信官方和其他开发者心里都有自己的衡量标准。
而站在我们的角度:服务号已经丧失了通知用户消息的能力,我们必须强化自己的app通知中心,以便帮助我们的用户正确及时的收到重要信息。
这时我发现,当我连服务号消息都不需要的时候,我还留在微信生态干嘛呢?
同时引导我们的app用户去关注一个根本无法及时获取通知的服务号,意义又在哪里?
最后
我们当然没有微信那么牛,但大家都是做产品的,是不是要信奉一个基本的产品理念:确定性。
我无法想象一个没有确定性的软件、生态或者社群,能够让用户愿意使用、跟随和支持。
很显然,我在微信生态中已经拿不到原来的确定性了,反而处处小心,生怕明天起床官方又来一个通知,导致我们现有功能失效或出现问题。
也许是我的产品观太狭隘,我们也确实没有做过规模10亿以上的产品和生态,不具备了解微信这些决策背后的故事。
但我作为一个普通开发者,不希望每次在评估重大功能时,还要去考虑微信会不会哪天突然翻脸把我们依赖的一些组件或规则改了导致辛苦开发的功能不可用。
我也不希望我的用户和我投诉问题时,我只能回答:这是微信规则调整的影响,我们实在无能为力,我们向您道歉。
我更不希望每次出现意料外的bug,翻遍了自己的代码找不到原因,最后发现是微信的调整。
.......
我们感谢微信生态,毕竟一开始是基于微信生态把业务起步的
但现在我们很遗憾,只能说一句:再见
服务号算是彻底废了,没有继续开发的必要了,相信很快就会出平替的产品
小程序和服务号一步步被微信放弃,多少商家平台受影响;服务号消息折叠这个事更蠢,你制裁商家也就罢了,毕竟店大欺客我们也理解,都是依赖微信爸爸恰饭的我们不敢犯坑只能忍辱苟活。可是消息折叠直接导致C端用户错过了很多重要通知,完全影响了C的体验啊!微信已经骄傲到连C的体验都不care了吗?真想扒开微信产品经理的脑子看一看,除了屎尿屁就不能装点别的吗
真是一家独大,随心所欲!有没有哪家大能看看,开发个平替,内存小的,别聊着聊着几十个G删不掉的,我肯定换!
真心理解你,开发一个产品本就不易。因为媒介的问题本就束手束脚,虽然说要时刻应对变化,但是这样的变化对间接依存的产品开发来说太难了。
哎,这多天了,我尝试了好些迂回办法解决服务号折叠后消息通知不起眼甚至被吞的问题,我都觉我自己瞎折腾。但就是这样领导还让我写应对措施方案,我咋写?我看现在没几个人会想得到吧,真要自闭了。。。
有想到解决办法的人,和我说说吧,汇报方案里记你一功!!!
对呀,这个办法我试过,但交易提醒推送,桌面快捷方式不会红点提示。不提示用户就不知道有新推送。就感觉很鸡肋用起来,唉
紧急呼叫!服务号被折叠尽快取消
深度好文,说出了所有服务商和开发者的心声,可惜微信的业务和产品是不会看见的
太难了。。服务号自动从自动免打扰以后,就削弱的不行,好不容易建立 起来的生态体系,眼看要崩塌了。
“大家都是做产品的,是不是要信奉一个基本的产品理念:确定性。
我无法想象一个没有确定性的软件、生态或者社群,能够让用户愿意使用、跟随和支持。
很显然,我在微信生态中已经拿不到原来的确定性了,反而处处小心,生怕明天起床官方又来一个通知,导致我们现有功能失效或出现问题。
”
说得好!
垃圾玩意,小孩子用我卡消费,点进去信息不仔细看都看不到,那个脑缺想出来的玩意???
在微信生态里越来越难存活了,接口、功能都砍没了