编辑导语：在产品设计的过程中，B端系统与用户之间信息的交互十分关键。本篇文章笔者就以自身的工作经验，来给大家说一下如何进行B端通知提醒功能的设计，一起来学习一下。

在产品设计过程中，B端系统需要与用户进行信息的交互。

网上已经有较多的C端消息通知系统设计的文章，但是B端消息通知系统的设计，与C端还是有一些侧重点的区别。

本文就根据笔者自身的工作经验，来给大家介绍笔者对一下B端系统通知提醒功能设计思考。

一、通知提醒功能是什么

在开始进行B端通知提醒系统的设计前，我们有必要THINK IN UML，将通知提醒抽象成一个用例（use case），以方便后续具体的功能设计。

一个完整的用例定义由参与者、前置条件、场景、后置条件构成。

为方便大家理解，我们以煮饭这一个用例来解释用例中的参与者、前置条件、场景、后置条件。

• 参与者：驱动系统，用例是其愿望的体现，可以认为是“我”；
• 前置条件：启动用例的前提，即要煮饭，需要先有米；
• 场景：煮饭的方式有很多种，可以用铁锅也可以用电饭煲，场景是用例在不同条件下的处理方式；
• 后置条件：煮饭后，米变成了米饭，表示用例执行的结果。

那么通知提醒这个用例种，参与者或者说是业务主角（business actor）是OMS系统的用户吗？

在通知提醒这个用例下，显然不是。业务主角应满足以下三个条件：

1. 应是主动向系统发出的动作；
2. 拥有完整的业务目标；
3. 系统是为他而服务的。

同时，我们知道参与者通过可以是输入的一段指令，一笔订单，一个商品信息，不一定是一个有生命的人。

那么在通知提醒这个用例中，我们发现用户只是业务工人（business worker），在业务模型中是被动的去完成主角的目标的。

那么按照上述的条件，我们可以将【通知提醒】这一指令抽象为业务主角，其愿望或者说目的是为了保证业务正常的开展。

系统是为主角服务的，业务主角的确认深刻的影响了功能设计的权衡取舍，后面会详细介绍。

那么在这个用例中，前置条件、场景、后置条件怎么理解呢？

• 前置条件：提醒事件，如果没有提醒事件，则无法进行提醒；
• 场景：通知提醒的触达手段，B端系统中有多样化的触达手段，以适应不同的条件，这个后面会进行详述；
• 后置条件：通知提醒的结果，B端系统中通知提醒的结果和C端不同，B端通知的结果一般都是提醒事件的消失，而非提醒消息本身的已读。

提醒事件

一个提醒事件可以表述为：“当某物满足什么条件时需进行通知提醒”。

人驱动系统、事体现过程、物记录结果、规则控制运行，提醒事件是上游用例的结果或者说输出物。

所有的提醒事件都是围绕着“物”这么一个实体类开展的。

那么B端系统有哪些种类的提醒事件呢?

1. 系统正常作业过程中需要业务工人参与的事件

• 发货单在已创建状态时需进行通知提醒；
• 发货地址发生变化时需进行通知提醒；
• 顾客催单时需进行通知提醒；
• 在系统中预约完成的事项已完成时。

2. 系统作业异常时需要业务工人处理的事件

• 物流系统配送异常时需进行通知提醒；
• 根据预设条件发现数据异常时需进行通知提醒；
• 拣货超时时需要进行通知提醒。

3. 系统服务异常时需要业务工人介入处理的事件

• 服务器宕机时需要提醒；
• 接口服务异常时需要提醒。

4. 产品运营/客户方运营手动进行的信息分发需要业务工人知悉的事件

• 系统升级公告；
• 停止服务公告；
• 系统能力变更公告；
• 要求店员开启自动接单功能的公告。

当然，还有一些操作时的即时提醒，这些提醒只是用户操作用例中的一个需求点，不在B端通知提醒用例中，本文暂不涉及。

触达手段

一个触达手段可以表述为：“在什么地方（WHERE）、什么时机（WHEN）、以何种途径（HOW）、通知谁（WHO）、如何消费（WAY TO FININSH）”。

B端系统与C端系统在触达手段上是有一些区别的，差异如下：

1. 业务工人的细分角色较多，需执行差异化的触达策略

不同业务工人在企业内部的角色分工和所属组织架构的不同，信息焦点所属载体各不相同。

如运营人员可能并不会一直盯着OMS系统，但是一定保持着企业微信登录，那么就可以选择使用企业微信进行信息的触达。

又如店员可能并不是一直守在收银机旁，但是不会离开门店，这个时候可以使用声音提醒的方式；

不同的业务工人关注焦点不同，店员更关注哪些订单需要拣货了，而运维人员更关注系统是否稳定运行，故要将不同的提醒事件给相对应的角色进行提醒；

2. SAAS化的B端业务繁杂，千人千面,需支持触达方式的配置

使用同一套系统的客户，由于业态不同和组织架构的不同，业务工人接受信息传递的载体，以及接受到提醒的方式也不同，需支持配置，以适应千人千面的业务场景。

配置的设计可参考笔者的这篇文章：干货总结：我对B端系统配置功能设计的思考 | 人人都是产品经理 (woshipm.com)

3. 一切为了业务的正常开展

在B端系统中，B端的用户在核心的业务用例中，担任业务工人的角色，例如门店人员必须及时拣货，否则系统无法完成订单履约业务。

为满足业务的正常开展，我们可采取的设计思路如下，即使一些在C端产品上会被认为用户体验很差的受手段：

• 多种触达方式并用：根据业务工人角色，可以通过将系统内提醒和系统外提醒并行的方式，组合使用，覆盖业务工人所属的时间和空间缝隙；
• 循环触达：当提醒事件未消失时，即时用户已确认收到了提醒，在一段时间后，也应再次循环提醒；
• 触达升级：当业务工人未反馈已知晓时，向业务工人所属组织结构的上级提醒，进行触达的升级；
• 强制阅读：强制要求阅读N秒，且在阅读完成前无法做其他业务，以保证业务工人确实已经阅读相关提醒；
• 强制反馈：要求业务工人必须点击确认已收到消息；
• 操作指引性的触达文案：例如“请前往xx系统xx模块，对xx单据做xx操作”，以减少业务工人因不熟悉系统功能而无法进行操作的问题。并可在文案中嵌入链接以直接跳转到相应页面。

当然以上手段不是绝对的，需要我们根据具体的提醒事件灵活裁剪设计思路。

那么我们可以知道B端的触达手段有以下特点：

• 触达途径稳健：适用多种途径手段保证消息确实给到了相应用户，同时要求用户必须明确反馈自己已知悉此消息；
• 消费方式严格：大部分B端提醒消息并不是标记已阅就可以消费的，必须得提醒的事件不成立时，才会真正消费提醒；
• 重时效性：以O2O订单为例，顾客支付完成后，如门店在5分钟内未接单则系统会自动取消订单，故消息的触达必须及时，否则业务无法正常开展；
• 重准确性：触达到用户的信息必须准确，准确还体现在一致性上，即通过触发方式传递给用户的信息，必须和用户主动在系统中查询的信息一致，不能遗漏或信息差异。

4. 注意平衡消息量

在保证提醒效果的前提下，需要平衡好消息的提醒数量，方法有以下几种：

1）消息的分级与降级提醒

• 将触达手段分为强、中、弱提醒强度等级，根据提醒事件选择合适等级的提醒手段，强等级的提醒不应频繁使用；
• 同时可将一个消息先强等级提醒，然后在循环触达过程中选择较低强度的途径进行降级提醒，如订单拣货消息可以先通过声音提醒，接着通过文字滚动循环提醒。

2）消息合并提醒

• 合并方案1： 按照作业方式提醒：有多笔发货单且还未被提醒，则应只提醒一次即可，此时不应每笔单据都提醒一遍；
• 合并方案2： 按照单据聚合提醒：一个单据如果先创建后立即接单，如果此时新订单的消息未提醒，则应直接提醒订单需拣货的消息。

那么B端有哪些触达手段呢，笔者做了当前我们系统中触达手段的整理，可能并不完整，供大家参考：

二、应用实例：以系统内通知提醒设计为例

那么文章的最后，给大家分享一下，我做发货单系统内提醒功能时的设计流程吧。

1. 整理业务流程

可以通过简单的流程图，来梳理期望实现的通知提醒的效果。

2. 接着可以按照标准化的文档，收集整理需求点，下面给一个我在用的整理模板：

3. 补充说明一下提醒文案的设计：

• 信息脱敏：提醒文案中不应将单据中的敏感信息提供出来，如顾客的姓名电话等；
• 重点突出：如果是系统通知，则应展示通知的重要性和时间节点，如果是订单，则应突出展示所属平台以及需要作业的时间，需根据具体业务确定；
• 角色明确：如一个提醒要同时发给多个用户角色，则应标注清楚是哪种角色需要重点关注此信息；
• 操作清晰：明确告知在什么时间去哪个系统哪个模块对哪个单据做什么。

4. 当然接下来我们还需要整理相关页面，优化交互体验。

功能开发完成后注意交付——跟进——复盘——迭代，这些不再累述。

三、结语

B端系统消息通知设计与C端消息通知设计有很多共通之处。

但是也略有差别，需要在设计过程中注意判断，不可生搬硬套。

本文由 @kathic 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。