消息推送功能是软件产品不可或缺的一个功能。
相比TOC产品大多数APP的消息推送功能是为了提高用户粘性、提高产品活跃及达到营销的目的,强业务导向型产品的消息推送功能更大的作用在于提醒用户关注业务的流转和帮助用户去及时处理需要用户干预的事项。
基于这样的作用和目的,在设计消息推送功能时,应该考虑的问题有哪些?
既然业务性产品的消息推送是为了提醒用户业务的流转,那是不是每一个流转节点都需要提醒呢?是不是只要业务状态有了变更就提醒用户呢?显然是不是的, 如果每个节点都提醒,因为复杂的业务每天流转的节点很多,必定导致消息太多而骚扰到用户。因此对消息提醒节点的选择有两方面的考虑:
(1)业务操作人员
对他们来说,最关注不是业务流转到哪里了,而是业务是不是流转到需要自己处理的节点了。因此对这类角色的用户推送的消息应该是需要他们干涉和处理的节点才通知,其他节点他们进行业务处理时可查看即可。
(2)业务治理 人员
对治理 人员来说,不需要对业务进行实际的操作,但是需要关注业务进行的整体情况,并能及时知道业务流转出现的问题,因此对他们的推送应该是业务最终节点的汇总,以及业务流转异常的提醒,帮助他们掌控业务的总体情况和及时对异常进行决策处理。
PS:实际业务中用户的分类可能不止这些,但大体上无非是实操人员和治理 人员,可视情况细化分类,设计不同的消息推送。
(1)相同的业务归类推送
相同的业务指的是同一个业务很多单子,或者很多单子需要用户关注的点相同,这时候若不要求用户及时进行处理,就可以汇总起来做一到两次推送,提醒用户关注到这件事即可,没必要一个单子提醒一次,防止提醒的意思相同,引起用户的反感。
(2)紧急的业务及时推送
当然若是需要用户及时进行干预处理的,或者时效性比较短的就需要进行即时推送,否则因用户没有及时处理和关注而导致业务不能正常流转,就背离了消息提醒的初衷和作用。
用户接受到消息后的阅读和关注时间也就那么短短的几秒,这就要求消息的内容要在几秒内让用户理接收和理解,用户看到消息后需要进行下一步的处理和操作,若通过消息里的链接轻轻一点就能到达需要用户到达的位置,体验就会大大提升,因此,在设置消息内容时,注意:
消息内容短小精悍直达核心事件,幸免前后铺垫。
一定要附上操作链接,方便用户点击后即可到达处理界面,及时进行业务操作处理。
表明处理时效和后果,方便用户安排自己工作的优先级和对此项事务的紧急程度有推断 。
常见的消息推送渠道有:系统站内信、短信、微信、企业内部办公平台如钉钉、企业QQ、OA系统等、邮件、甚至电话等。不同的渠道提醒让用户关注消息的可能性不同,适合推送的内容不同。
1. 因无法保证用户 24 小时都在登录状态,就无法保证用户一定会关注到系统站内信或者可以说用户有极大的可能看不到系统站内信,因此这种渠道适合一些及时性、时效性要求低、但又希望用户去关注不关注有无关痛痒的内容,如公告通知、业务宣传等。
2. 相比站内信,用户关注到短信的可能就要高很多,除非用户手机关机了停机了或者临时 不在身边,一般情况用户都会关注短信,也因为如此,选择短信提醒时一定要注意消息推送的节点和频率,防止一开始对用户造成骚扰,后期不论多重要的消息用户都默认不看不关注。但短信对于复杂业务的适用来说,成本相对较高,若业务复杂,流转节点就多,需要提醒的节点和用户数量就多,费用自然就高。
3. 微信的时效仅次于短信,是很好的消息推送渠道,既没有消息推送费用,触达率也高,且符合用户查看消息的习惯,一定程度上提高用户的关注度。
4. 若是内部业务系统,企业内部办公平台无疑是消息推送的最佳渠道,一是因为办公平台就是用户用来处理工作事务的,提醒用户处理业务,幸免了打扰用户的私生活,二是公司办公平台作为公司内部办公的工具,正常工作日用户肯定都会使用,消息被关注到的可能性高。
5. 对于及时消息推送邮件渠道不是一个很好的选择,一般很少用到这一渠道。电话对用户的打扰和压力太大,故也很少会选择此类途径推送消息提醒。
对于业务性的产品做消息推送功能时,一定要注意时间段的问题。因为若业务的流转在夜间也在进行或者业务流转会在夜间自动进行(如自动脚本等),若没有设置消息推送的时间段,推送出发节点又是业务流转就推送,那么大半夜提醒用户,用户必定会抓狂和极度反感。
消息推送功能说大不大,说小又极其重要,做得好起到推动整个业务顺利进行的作用,做的不好,极容易让你的用户离你而去。因此我们在设计这个小功能时,应全面去考虑它,拆分它,使小功能起到大作用。