目前流程：         组织者点击创建群聊→勾选添加的人员→所有成员进入群聊圈，创建完毕！         存在问题：1、不管受邀成员是否愿意进入，都无条件先进去了，不想留再退出。（相当于：有人请你吃饭，你无条件拒绝，只能先到饭桌，看看菜品，不想吃再走）。2、进入后是非静音状态，若是深夜岂不是先吵醒再说？          所以，这样的功能应该来说还不够人性化，个人的应有权益有所欠缺。于是建议修改就成为：组织者点击创建群聊→勾选添加的人员→系统推送给被邀请用户（需要用户确实通过才进入群聊），创建完毕！          或者在聊天设置里添加进群是否需要确认功能，也就是跟添加好友一样，可以设置需要确认与否。

今天一位用户反馈服务号发出的服务器告警提醒全部被折叠到【服务号消息】了，影响很大，因为折叠后用户没能收到实时通知提醒，无法及时做出响应和处理。 由于身边的人都没能找到开启了【服务号消息】的微信，无法了解最新的体验，但该用户表示找了很久没有找到可以把服务号消息设置为恢复原状的入口。 建议：希望微信可以加入一项功能，允许用户手动操作，针对指定服务号设置为消息不进入【服务号消息】，使得用户可以恢复某些服务号的接收消息体验。 谢谢。 [图片] [图片]

关于模板消息和订阅通知。我们有两个建议。 第一，保留目前模板消息。在现有的模板消息基础上，可以新增客户关闭接受模板消息的功能。即使客户不想接受模板消息，可以再不取消关注的情况下，关闭接受这个服务号的模板消息就可以。而不是一刀切全部下线模板消息。新增让客户可以不接受模板消息的功能，个别客户不想接受的情况下，继续可以关注公众号，使用此公众号提供的其他功能。 第二，即使下线模板消息，改用订阅通知的话，建议不是按行业是否长期订阅，而是按模板的应用场景，可以长期订阅。比如排队叫号的模板，系统预警模板，不可能只是政务医疗等领域使用，各行各业都需要，但是也不可能让客户每次订阅。比如系统预警，第一次发送客户没留意通知，也没有打开界面再次订阅。难道下次有需要预警的情况，就不能继续发送？或者让客户订阅时完全自己选择就好了，客户根据通知的情况，自己选择只接受一次或长期。按现在按行业一刀切划分太不合理。

    在《微信服务号订阅通知灰度测试：模板消息之变》中，笔者分析了消息通知方式改变对大家产生的影响，弊大于利。     基于被“用户体验感”挟持的大前提下，不管微信团队是否执意要对策略做出调整，大家都需要未雨绸缪，合理的面对并解决这个风险，以免措手不及。     这篇内容，将会为大家分享笔者结合自己的产品，总结出改造的设计方案。分享前，先为大家解释一下订阅通知所涉及到的名词、订阅和推送通知的方式。 一、名词解释     一次性订阅：指用户订阅一次，服务号可不限时间地下发一条对应的订阅通知；     长期订阅：指用户订阅一次，服务号可长期多次下发通知，长期订阅通知仅向政务民生、医疗等公共服务领域开放。 二、订阅通知的方式 [图片]     目前微信只开放了两种可以进行消息订阅的途径，具体流程如下。 [图片]     1.文章订阅     可以在服务号发布的文章中，插入订阅通知组件，用户点击进行订阅。     每篇文章最多插入10个订阅通知组件，每个组件最多包含5条通知，每个组件不能同时包含一次性订阅和长期订阅，文章推送后用户才可点击订阅。 [图片]     2.网页订阅     可以在服务号绑定的安全域名中，通过微信JS-SDK调起订阅通知界面。     目前没有组件数量和订阅通知数量的限制，但每个组件不能同时包含一次性订阅和长期订阅，并且实际效果需要真机调试，无法用开发者工具模拟。  三、推送通知的方式     通知的推送流程，与模板消息推送流程基本一致，只是将验证[是否已关注服务号]改变成了，验证[是否已订阅通知]。 [图片] 四、通知中的区别     在用户订阅消息后，已关注和未关注服务号，收到消息通知的表现形态有区别，具体表现形式为： 1.已关注     已关注服务号的用户，和以往下发位置相同，直接推送到服务号内。 [图片] 2.未关注     未关注服务号的用户，会直接下发到服务通知，和小程序的通知入口一致。 [图片]    以上就是笔者对订阅通知功能的理解，下面我将会为大家分享产品改造方案。    由于不同产品的交互和业务逻辑不同，所以订阅通知的改造和实现过程仅供参考，具体实现方案还需要根据自身行业做出调整。 五、设计前言     本次是以一款G2C产品为例，产品功能通过服务号+小程序实现。C端用户在关注服务号并注册小程序的前提下，在小程序中触发需要通知的事件后，会在服务号中，同时给C端用户和G端用户推送通知。     因为一些业务需求的原因，C端用户必须要关注服务号。在1年前设计产品时，笔者根据此原因，并结合小程序通知需要G端用户订阅的前提。本着减少用户操作次数，并且服务号会定期群发文章供G端用户学习的想法，选择了通过服务号下发通知的设计方式。     应用场景举例(请勿带入现实生活)：C端用户小赵在关注服务号并注册小程序(注册时获取了手机号码)后，G端用户会收到服务号注册成功的通知。同时开发者后台实时根据小赵的手机号码探测网络中的风险。当小赵的隐私信息泄露后，会通过服务号给小赵和G端用户推送通知，告知存在信息泄露风险。     在互联网中，有类似场景的行业还有很多，甚至有一些产品是单服务号实现业务，对模板消息是具有强依赖性的，那么应该如何进行改造设计？ 六、用户特征分析     在设计需求之前，笔者首先思考了产品面向的用户群体的特征，一共有两类。 1.C端用户     特点：对产品依赖性不强；     存量用户：基本不会重新进入服务号订阅通知；     新增用户：基本会订阅通知，但订阅留存率可能较低；     原因：产品是由G端用户进行推广，推广时现场教C端用户如何操作，但事后C端用户基本不会再次打开。所以增加服务号订阅通知流程，对新增用户基本无影响，但存量用户的订阅没有保障。 2.G端用户     特点：工作原因，对产品依赖性高；     要求：自己能收到通知，C端用户必须关注服务号并且可以全部收到通知。 七、确定设计边界    分析用户特征，确定产品用户需求后，需要明确设计边界，防止设计时违背用户需求。     1.C端用户     产品使用方式：依旧采用关注服务号+注册小程序的方式；     消息通知：无论是存量用户还是新增用户，都必须可以收到通知。     2.G端用户     产品使用方式：在满足对C端用户要求的前提下，可以接受任何方式，但应尽量简便；     消息通知：必须可以收到通知。 八、文档分析     确认用户特征和设计边界后，阅读微信开放文档，寻找是否有可以额外利用的点。     在“订阅通知接口-用户操作订阅通知弹窗”中可以发现，用户在订阅/取消订阅通知时，微信都会向开发者服务器发送通知。     注：微信开放文档是动态文档，所以在阅读此文时，要注意自行查看文档，避免因微信单方面更新文档而造成信息差。     参数如下： [图片] 九、设计思路     在经过以上分析后，产品的改造设计思路已经基本明确了。下面采用将C端用户和G端用户拆分开方式，给大家分享我的解决方案。请自行进行差异设计。 （1）C端用户     1.存量用户     首先，通过分析用户特征得知，C端存量用户并非100%不会重新进入服务号订阅通知。     为了保证C端存量用户在想要主动订阅时，能够有一个可订阅的入口。在将模板消息改造为订阅通知后，我们应该在服务号中提供一个便于查找、操作简便的订阅入口。例如，可以将能够订阅消息的文章或H5悬挂在服务号菜单中。     如果用户忠诚度较高，不会因为文章群发而出现大规模取关的话，在改造后可以通过群发文章来提高订阅转化率。     笔者所负责的产品用户忠诚度偏低，属于静默类型，所以不计划通过群发文章提醒存量用户进行订阅，仅在文章和H5中悬挂注册入口和订阅入口。     2.新增用户     在分析用户特征时，笔者有提到这款产品的C端用户来源是G端用户现场推广引导注册。在根据自身业务流程做出调整后，对新增用户影响较小。     模板消息正式被微信团队替换为订阅通知后，也没有其他解决方案能够绕过订阅模式。所以在做调整时，要尽可能的保证减少用户为订阅做出的额外操作次数。例如，笔者在某通快递小程序，仅查询物流动态就需要进行2次消息订阅，很令人不舒服。     我们在做设计功能时，可以考虑将验证是否订阅通知作为使用功能的条件，但并不适用于所有行业。例如，在用户下单时，验证是否订阅了发货通知，如果没有订阅就不允许下单。这种办法虽然可以提升订阅率，但显然也会影响成交率，请谨慎使用。     3.补偿机制     在解决完可以主动订阅的用户的问题后，我们还需要考虑如何对未订阅的用户发送通知。     在这款产品中，不会收到通知的有存量未主动订阅的用户、新增拒绝订阅的用户、订阅后自行取消订阅的用户。     笔者采用的方式是，发送通知前验证用户是否订阅消息，如果没有订阅，就对用户发送手机短信。     同时在短信中，可以结合小程序的“UrlScheme.Generate”能力，实现在短信的URL链接中跳转小程序。     在设计改造方案时，笔者查询了大量资料，得知互联网中有一些能力可以实现URL链接跳转到微信并访问指定H5页面，但此行为违反微信运营规定，所以没有采用。 （2）G端用户     在进行特征分析的时候，我们提到G端用户因为工作原因，只能遵守产品规则。但在改造时仍然需要考虑，因为用户体量大，必然会出现因为操作失误而未订阅的用户，所以无论选择哪种方案，都应该增加与C端用户相同的“补偿机制”。     笔者在改造G端用户的通知接收方式时，考虑了两种解决方案。     1.服务号通知     给G端用户提供一个单独的在服务号进行订阅的入口。但G端用户原有业务是依托小程序进行实现的，所以在服务号中通过文章或H5的方式进行订阅都存在问题。     文章：G端用户为内部用户，如果对外暴露文章形式的订阅入口，在C端用户误操作时，对C端用户不够友好；     H5：G端用户依托小程序开展业务，单独开发H5页面提供订阅能力对G端用户来说操作麻烦，并且不利于开发者进行维护。     笔者个人认为，微信生态中，H5的使用体验没有小程序好，并且为了节省项目成本，所以不考虑将小程序业务改为H5实现。     2.小程序通知     将G端用户的通知订阅方式彻底改变为小程序订阅的方式。因为笔者所在行业属于政务类，可以申请到长期订阅的通知模板，在改为小程序订阅后，G端用户只需要订阅一次，就可以长期接收消息通知。     按照这种方式进行改造后，G端用户基本可以完全脱离服务号，仅使用小程序就能开展工作。     经过笔者预估，如果采用这种改造方式，会降低G端用户对服务号的关注率。在“设计前言”中有提到，服务号会定期群发供G端用户学习的文章，所以改造后还计划在小程序中增加浏览文章的功能，但是否增加此功能，还需要在改造后观察服务号文章的阅读数据是否下降。 （3）另外     考虑到改造成订阅通知的形式后，运营人员可能会考虑通知送达率，我们可以结合“文档分析”中的参数，在运营后台中增加一些统计指标。     例如，每条通知的累计订阅数量、留存订阅数量、取消订阅数量，同时可以结合用户数预估通知的送达率。 十、总结     以上就是笔者在本次微信计划调整通知策略的事件中，所做出的产品改造方案。     建议在微信明确下线模板消息前，尽量不要安排研发人员进行备用版本的开发，在调整尚未明确之前，安排研发实现无疑是一种浪费人力成本的做法。但作为项目管理者或产品经理，应该在发现风险时，准备多种方案。     最后，希望微信团队能够充分考虑调整策略对服务商、开发者产生的巨大影响，做出合理的决定。 作者：氟西汀，公众号：氟西汀终究还是没了 学艺不精，欢迎批评。如想交流产品设计方案，欢迎留言。 未经授权禁止转载