【B端产品知识总结】系统消息提醒及消息推送设计思想

前言

一、简述消息通知

1、第一步盘点消息推送渠道

2、第二步消息推送项盘点

3、第三步确定消息通知内容和操作反馈

二、系统消息项通知梳理

1、明确消息推送渠道

2、盘点产品业务消息项

3、撰写通知内容与操作反馈

三、如何设计消息中心

⒈、设计消息中心入口（接收消息通知）

1）WEB端的消息中心设计

2）手机移动端的消息中心设计

2 、设计消息管理中心（发送消息通知）

1）业务规则下的消息管理中心

2）自定义的消息发送管理中心

四、如何实现消息中心

五、B端消息通知系统设计的注意点

前言

在B端产品中，比如协作平台OA、项目管理系统、CRM系统和电商系统，由于业务逻辑的驱动，需要在业务节点上进行代办或事务提醒，以辅助业务人员进行操作。例如，当有数据提交时，相关业务人员会及时收到消息推送，方便他们及时处理。

在设计消息推送时，我们需要根据系统的核心业务逻辑，确定消息提醒的优先级。高质量的信息推送对用户至关重要，因此需要控制消息的总量，确保重要消息的高触达率，并合理合并重要性较低的信息，避免消息过多导致信息冗余和用户干扰，从而让用户高效处理通知。

消息通知设计的主要目的是在正确的时间、以正确的方式将内容呈现给用户，提高产品的转化率和业务推进。C端产品和B端产品在这点上有共通之处，但也有区别。C端产品的消息推送更多关注用户留存和粘性，可能包含营销、广告等信息，用户往往对这些消息反感。而B端产品主要集中在业务场景中，需要系统地按照业务类型和消息优先级，通过不同渠道进行推送，确保B端用户能准确收到业务消息。

在设计时，我们需要站在B端产品不同角色的角度，排列消息的重要程度。尽管B端产品的消息通常都很重要，但如何合理分发和处理重要与不重要的消息，是B端产品经理的核心任务。

我们将探讨在B端系统中不同维度的消息推送设计与理念，如何设计一个灵活好用的B端产品消息推送中心。

一、简述消息通知

B端产品的消息通知的数量往往是由产品规模和产品业务相关的，一些小型的业务产品比如资产管理系统就很少或者没有消息通知的需求。一些强协同的小型产品往往却需要很多的消息通知内容，比如需要消息回复或工作台信息提示来达到协同的目的。所以说我们在设计产品的消息通知系统时，需要综合考虑产品定位和需求来设计适合的消息通知系统。

接下来我们用三步法，来梳理消息通知的基本流程

1、第一步盘点消息推送渠道

由于B端产品是为了服务于业务方，在业务方有限的成本控制内我们需要先确定好能有那些推送渠道进行对接，这样我们在后续进行消息推送的设计时，可以按照消息推送的优先级去匹配推送渠道。

现在主流的产品消息常用的推送渠道有站内系统通知、短信通知、邮件通知、微信公众号、小程序提醒、PUSH推送。我们在细分推送信息时可根据这些渠道的特点进行特定和组合式推送。

2、第二步消息推送项盘点

根据产品具体的消息推送项进行盘点，就是需要知道系统哪些推送消息项要推送给那些对象，主要包含：消息触发时间与条件、消息发送方、消息发送方

消息触发时间与条件：如按周期重复的时间点，或系统状态变更、用户操作结果等；
消息发送：可能是系统、第三方服务商，或者系统管理员再或者某个用户；
消息接收方：即接收方，可能是系统中的全部用户，也可能会根据权限划分推送到某个用户群组，或者是某个特定用户；在B端也会先分为客户端的用户和管理端运营的员工用户，需要明确。

3、第三步确定消息通知内容和操作反馈

接下来就需要确认消息发送的内容和操作的反馈，是包含各消息项的通知内容与操作反馈。目的是让消息内容能够有效地传达给用户，让用户能进行反馈和操作。

消息发送的内容分为固定消息文本和定制化消息文本。固定消息文本往往是程序员写死的一些消息提示和一些常规不变的消息内容。定制化消息文本是确定了消息推送项后基于业务会存在变化，可以让管理员对消息通知内容进行灵活的文本配置。我们在设计时尽量采用定制化消息文本的方案进行设计，如果开发资源不足情况下可使用固定消息文本。

注意：在B端产品的消息推送内容我们可以预先设计一些字段变量，让管理员进行灵活配置的消息文案。例如审批的通知，通知文案：A用户的服务器A_B资源进行了规格变更，需要您及时审核。我们可以将A用户的用户名称和服务器A_B的资源名称进行变量设置。但是需要注意一个特殊的消息渠道-短信。因为短信的消息推送是需要先跟服务商去确定消息内容的，所以短信的提送消息文案基本是固定的。

二、系统消息项通知梳理

一个好的消息通知系统需要满足以下7个条件：

高稳定性：能够稳定运行，确保消息准确无误地发送，不会出现频繁故障或中断。

实时性强：及时将消息传递给目标用户，避免延迟导致信息失效。

精准投递：能够准确地将消息发送到目标对象，而不会出现错发或漏发的情况。

多渠道支持：比如支持短信、邮件、APP 推送等多种方式以满足不同业务需求和用户习惯。

可定制化：可以根据不同的场景和用户需求，灵活定制消息的内容、格式、发送时间等。

易管理性：系统后台管理要方便、简洁，便于运营人员进行操作和监控。

用户友好：能通过合理的消息发送途径、允许用户设置及合并相似信息接收和查看消息的界面简洁明了。

所以我们在设计产品的消息通知系统时需要将以上条件满足的越多越好。接下来我们讨论下怎样系统的去设计消息通知系统。

系统消息项通知梳理主要是根据系统业务需求和业务操作流程去整理那些节点需要去进行消息通知，以下是我们在梳理时要用到的一个标准的表单，这个表单可以帮助我们进行全面梳理，也可以和开发人员进消息项进一步明确。

1、明确消息推送渠道

我们在设计B端消息推送时一定要跟业务方确认好，目前有那些消息推送的渠道，事先将渠道进行对接。这样的优势是免去了我们在设计完后业务方这也没有那也没有的情况，导致设计方案进行变更。在一个是我们先获得了这些推送渠道后在进行设计时也会根据现在的渠道去分配不同的消息项，例如业务方没有短信推送的渠道，但是有邮件推送的渠道，我们在有验证码的消息项上可以放在邮件推送渠道上。

不同的通知方式会有不同的适用场景，下面是常用的消息推送渠道的特点和优劣势，我们可根据这些渠道的特点进行特定和组合式推送，对照下表结合第一步整理的重要性配置消息的触达渠道：

站内系统通知：

优势：直接在平台内部展示，用户打开平台就能看到，针对性强。
劣势：依赖用户主动登录平台，可能存在用户长时间不登录而错过通知的情况。
特点：与平台功能紧密结合，通常用于重要的系统消息、业务提醒等。

短信通知：

优势：实时性强，几乎能即时到达用户手机，用户查看率相对较高。
劣势：成本较高，部分用户可能会屏蔽短信。
特点：适合紧急、重要且需要用户及时知晓的消息，如验证码、交易提醒等。

邮件通知：

优势：可以详细阐述内容，适合发送信息量较大的通知。
劣势：打开率相对较低和查看周期长。
特点：常用于发送正式的通知、活动详情、账单等。

微信公众号：

优势：用户基数大，推送到达率较高，能展示丰富的内容形式。
劣势：受微信规则限制，如订阅号推送频率有限。
特点：适合做品牌推广、活动宣传等，可与用户进行一定互动。

小程序提醒：

优势：可适配微信/抖音/支付宝生态，用户触达方便，提醒效果较好。
劣势：依赖小程序的使用，对于未经常使用小程序的用户效果可能不好。
特点：通常用于与小程序相关的特定提醒，如订单状态等。

PUSH 推送（产品需要有相对的APP端）：

优势：能精准推送至用户移动设备，可定制化程度高。
劣势：手机上APP繁多消息内容也多可能导致用户忽略。
特点：适合各类定时类消息推送，如日报填写、审批提醒等。

2、盘点产品业务消息项

定位好产品业务后对系统盘点哪些需要进行消息通知，在盘点出的每个消息项都需要补充以下四个关键因素：

触发条件：结合产品核心场景梳理完整。可通过状态图或泳道图进行梳理。
通知来源：可能是系统、第三方服务商，或者系统管理员再或者某个用户。
通知对象：可能是全部用户，也可能是某个用户组/权限组或具体管理员/用户。由触发条件中的场景决定。
重要性：结合产品核心场景、业务需求进行消息重要性评级，可使用“高”、“中”、“低”的分类方式。

B端产品的核心业务往往很重要的，会存在复杂状态的任务流，我们可以先用表单分类进行消息项梳理，然后再按照业务流程图进行查缺补漏，避免一些消息类型的遗漏。例如电商类产品的购买流程，每个节点都有对应消息项。

3、撰写通知内容与操作反馈

当我们梳理好消息项后，我们需要考虑合理的消息推送内容，B端的产品消息只需简明易懂将通知信息意思表达清楚，太俏皮的C端文案反而不太适合。有一个标准的公式可供参考：

因为什么？--发生了什么？--你可以做什么？

在写B端系统消息通知的内容时，需注意以下要点：

重点前置：不同消息页面不能一下展示所有的文本内容，所以一定要把重要信息放在最前面让用户快速知道消息的重点。
敏感信息：对于敏感信息，若涉及个人身份信息，如身份证号等，更要谨慎处理；
来源显示：非自有渠道要显示消息来源信息。
触发时间：消息发生时间对用户重要时要体现。

各渠道通知相关要点：

系统通知：重点信息突出显示，明确消息来源，若与时间相关要体现触发时间。

短信通知：

开头说明来源平台，如【品牌名】。
敏感信息可设置是否显示具体数值，默认显示需提前告知用户。
相关操作通过链接或路径指引，含详情链接设置短链。

邮件通知：

包含品牌元素。
使用产品官方网站邮箱后缀。
重要内容避免仅用图片形式。

微信公众号：根据微信规则变化及时调整撰写方式。

小程序提醒：简洁明了传达关键信息，来源显示清晰。

PUSH 推送（移动端）：

受系统要求限制格式，参考相关规范。
系统会自动补充应用 icon 与名称，文案不用包含。
发送频率适度，避免骚扰用户。

三、如何设计消息中心

消息通知的各个推送渠道中，短信、push推送（三方对接）的呈现由系统决定。我们在用户使用端往往需要设计消息中心去承载全量的消息列表。

由于B端系统大部分是WEB端的产品，但有的也伴有B端的移动端产品，所以我们会讨论B端系统的WEB端和APP端消息通知中心。

⒈、设计消息中心入口（接收消息通知）

1）WEB端的消息中心设计

WEB端常见的消息中心有导航栏图标入口、底部消息处理入口、工作台通知栏入口三种消息中心形式

a.导航栏图标入口

Web端的消息入口几乎全部都是设计在导航栏的右上角，这种方式可以在进入系统后通过显眼的图标位置加上数字徽章，可明确告知用户未读消息数量，起到及时提醒的作用。

对于消息数量相对较少的系统可以显示消息标题加内容的方式直接展示所有未读的消息，消息的Tab可以分为未读消息和已读消息。
对于消息数量相对较多的系统可以分合并消息类型进行展示，点击后直接进入消息中心进行查看操作。

b.底部消息处理入口

这种消息入口的设计适用于消息类型丰富、类型繁多和有消息回复协作的B端产品。这种设计可以让用户在系统中快速处理一些实时的待办问题，并支持一键清除已读消息或批量处理消息的功能，比如一些工单问题进度解决等。

c.工作台通知栏入口

对于工具类的B端产品，当业务数据通知信息有重要优先级的，在设计工作台会将消息中心放在工作台中，以便及时获取相关消息通知并查看。

WEB端消息中心的设计特点：

当用户点击消息中心入口后，通常会跳转至系统的消息中心页面。图例是一个简单的消息中心列表，我们可以按照系统的产品不同业务进行分类，来根据实际业务去设计消息中心。以下是设计WEB 端消息中心的一些特点：

布局清晰：采用合理的页面布局，将不同功能区域划分明确，让用户能快速找到消息相关部分。

直观展示：以列表等形式清晰呈现消息内容，包括消息来源、主题、关键信息等，便于用户快速浏览和筛选。

分类明确：根据消息的类型、重要性等进行分类，如系统通知、用户互动消息等，使用户能高效区分和处理不同类别消息。

实时更新：及时反映最新的消息动态，确保用户能第一时间了解到新消息。

交互友好：具备方便的操作按钮，如标记已读、删除、展开详情等，提升用户的操作体验。

信息突出：通过颜色、字体大小等方式突出重要消息或未读消息，吸引用户注意。

多端同步：与移动端等其他平台的消息中心保持同步，方便用户在不同设备上随时查看和处理消息。

可定制性：允许用户根据自己的需求对消息显示方式、分类规则等进行一定程度的定制。

2）手机移动端的消息中心设计

手机移动端常见的消息中心有顶部图标消息入口、底部Tab消息入口、侧边栏菜单消息入口、工作台卡片消息入口四种消息中心形式：

顶部图标消息入口：通常在消息量相对较少，且希望以较为简洁直观的方式提示用户有未读消息时较为适用。在此情况下，通过显眼的图标位置加上数字徽章，可明确告知用户未读消息数量，起到及时提醒的作用。

底部 Tab 消息入口：一般在产品需要将消息功能作为重要且常用的模块展示，且希望用户能便捷切换到消息界面时较为适用。在此情况下，利用底部固定位置的优势，方便用户随时进入，同时通过数字徽章显示未读消息量，增强用户对消息的关注度。

侧边栏菜单消息入口：常常在产品需要在不影响主界面布局完整性的同时，提供一个相对隐蔽但可随时呼出的消息入口时较为适用。在此情况下，通过侧边的方式展现，既保持了界面整洁，又能通过数字徽章提示未读消息数量，让用户可按需查看。

工作台卡片消息入口：一般在产品的工作台上需要将消息以较为突出且融合的方式展示时较为适用。在此情况下，以卡片形式呈现消息，可使消息与其他工作内容有效结合，同时数字徽章直观显示未读消息数量，便于用户快速了解消息状态。

移动端消息中心的设计特点：

当用户点击消息中心入口后，通常会跳转至消息中心页面。鉴于消息具有很强的即时性特点，所以一般会按照时间维度进行有序排列，这样能让用户清晰地了解消息的先后顺序和时效性。在消息中心的常见设计主要有两种：消息TAB类型消息中心和列表消息中心。

Tab类型消息中心：适用于根据产品业务特点进行消息分类，不同类型的消息划分到不同的 TAB 中

方便用户快速定位到特定类型的消息，提高查找效率。
对于消息类型丰富、复杂的产品，可以更好地组织和分类消息，减少用户筛选成本。
能使界面更加清晰有序，用户可以根据需求选择特定 TAB 进行查看。

列表消息中心：将所有消息以列表形式呈现，按照时间顺序或特定规则排列。

对于消息数量相对较少的系统可以保持界面简洁。
对于消息数量相对较多的系统可以分多类合并一级消息通知入口展示，再进入二级消息列表进行消息查看。

2 、设计消息管理中心（发送消息通知）

当我们根据消息项的盘点可以整理出系统所有的消息通知场景和类型，这时我们可以进行消息管理中心的设计，消息中心有两个维度的消息推送，一种是按照业务规则设计进行直接触发消息通知或定时触发消息通知。另一种就是由系统管理员进行实时填写通知内容进行直接发送和定时发送。

1）业务规则下的消息管理中心

以下是消息管理中心的设计标准：

消息通知模板定义
- 提供可视化的编辑界面，允许管理员创建、编辑各种消息模板，可自定义和编辑消息通知内容。
- 支持动态参数嵌入，以便根据具体业务数据生成个性化消息。
消息推送规则设置
- 定义不同业务场景触发消息的条件和逻辑。
- 能够设定定时消息的发送时间和频率，例如活动预约等。
- 可基于时间节点、周期等进行灵活配置。
推送渠道配置
- 一种消息类型可选择多种推送渠道，如系统通知、邮件、短信组合发送等。
- 一种消息类型针对不同渠道配置不同的消息文本。
接收对象设置
- 根据平台有多端分类可以将消息通知按业务端分类，例如B2C系统分为用户端消息通知和中台端消息通知。
- 可以根据特殊场景指定具体的用户、用户组、角色等作为消息接收方。
- 支持批量设置和精细筛选。
消息状态跟踪
- 实时显示已发送消息（通知记录）的状态，如已读、未读等。
- 可提供统计报表，分析消息的送达率、阅读率等。

消息管理中心原型设计方案1：

此种设计方案适用于一种消息类型需要与多种消息推送渠道融合，并且可以根据消息通知类型在不同的消息渠道进行单独的设置，主要体现在：

灵活性高：能够针对每种消息类型与多种推送渠道进行精细化的融合配置，满足不同场景需求。
适应复杂业务：满足多种消息类型和多种推送渠道的复杂组合需求。
个性化：每个消息渠道都可以进行独立的消息推送内容和相关设置，提供了更加个性化的消息推送服务。
冗余性强：便于维护和更新，一旦有新的推送渠道加入，可以快速集成

消息管理中心原型设计方案2：

此种设计方案是目前常用的设计方案，可适用于追求简便性和高效性系统管理，其方案优势在于：

简洁直观：以列表方式展示，方便进行配置操作，具有较好的易用性。
高效配置：可设置一种消息文本配置兼容多种消息推送渠道的发送，降低了配置的复杂性和工作量。
易于管理：整体布局较为清晰，对于大量消息规则的管理较为方便，提高了管理效率。

2）自定义的消息发送管理中心

这种设计是根据业务方有自主通知的消息发送需求，比如节假日的放假通知和相关重要活动通知。这类需求没有固定的业务规则，偏向于实时通知消息。为了满足这些需求，我们需要设计一个灵活、高效的消息发送管理系统

以下是自定义的消息发送管理中心的设计标准：

提供便捷的消息创建和编辑功能。提供文本编辑器，支持富文本编辑；支持添加图片、链接和附件；支持模板保存和使用。
支持多渠道消息发送并且支持选择发送对象，如所有用户、特定用户组或自定义用户列表。
支持消息的定时发送和即时发送。
提供发送历史记录和统计功能，支持按日期、渠道、发送对象等条件进行筛选和搜索。
提供用户管理和权限控制，例如各个部门只能看到各部门的发送的通知。

四、如何实现消息中心

我们从技术实现角度来看一下如果实现消息中心系统

消息中心的总体架构可以分为以下几个主要部分：

消息来源
消息池
消息中心分发
消息盒子
接收人

各部分详细阐述：

1、消息来源

说明：消息来源是指消息的初始生成点，可能是各种业务系统、报表系统等。每当有通知需求时，这些系统会向消息中心发送请求

请求信息：包含消息ID、请求时间、接收对象ID、消息内容（标题+正文）、提醒方式等。

数据表：将这些请求信息存储在一个数据库中，形成待发送消息列表。

2、消息池

说明：消息池是用于临时存储需要发送的消息。它的主要作用是保存消息内容、发送时间等信息。

技术实现：

存储技术：可以使用Mysql、Redis、Kafka、RabbitMQ等技术进行存储。

消息队列：消息池可以采用消息队列（如Kafka、RabbitMQ）来确保消息的顺序和可靠性。

数据库：Mysql可以用于持久化存储，Redis可以用于快速缓存读取。

3、消息分发

说明：消息分发模块是消息中心的核心，负责将消息从消息池发送到接收人。消息分发可以分为实时推送和定时推送两种模式。

实时推送：

应用场景：支付成功、验证码等需要立即通知用户的消息。

实现方式：系统收到请求后，立即从消息池中获取消息内容，并通过通知系统（如系统通知、短信、邮件服务等）发送给接收人。

定时推送：

应用场景：活动预约、运营活动预约通知等。

实现方式：系统根据消息的发送时间，在预定时间从消息池中获取消息内容，进行推送。

4、消息盒子：

说明：消息盒子用于保存用户的所有消息记录，包括未读消息和已读消息。

场景：消息盒子需要管理消息的状态，确保用户能够看到未读消息，并在查看后将其状态改为已读。

5、接收人

说明：接收人是消息的最终接收者。接收人可以是用户、用户组或自定义的用户列表。

设置：

接收对象ID：每条消息在生成时会指定接收对象的ID。

外部通知：部分需要提醒或时效性较高的消息，会通过系统（如短信、邮件等）辅助消息及即时触达。

五、B端消息通知系统设计的注意点

1、B端业务系统接收人设置

由于员工岗位的变动，后台需要设置灵活好用的接收人维护界面，可以自由的添加、删除多个消息接收人。

2、什么类型的消息不要纳入消息通知系统

需要注意的是，虽然通知的完备性很重要，但某些消息在前期梳理时就需要从清单中剔除，包括：

单纯问候类消息，如“好久不见”等；
不需要用户知道的消息，如系统后台数据更新等。

3、要平衡通知量

一个好的消息系统需要能有效触达的同时不过分侵扰用户。这就要求我们对系统实际运行中可能会出现的通知量进行预估，并适量调整通知方式，让重要的消息能够更有效及时地触达到用户。

一定要按照强度越强通知数量越少的关系调整消息项。

4、合并重复消息

对于出现频率较高，且用户不需及时了解每条消息的消息项，可以通过合并消息的方式减少通知的数量。

合并主要有两种方式：合并流程过往节点信息和合并同类消息。

合并流程过往节点消息：对于一些流程类通知，若用户在响应或查看前，流程已经进入到下一阶段，历史节点的信息已经无需了解时，可合并过往流程节点的消息。如淘宝在展示物流时，针对同一订单的物流，仅保留最新的一条。
合并同类信息：对于同类型消息过多，且用户不需要一一查看，只需在用户有需要的时候提供入口查看完整内容时，自动合并同类型的消息，减少对用户的打扰。如Instagram在展示用户动态信息时，会合并同一天同一类型的消息。

5、智能推送

有条件的系统可根据用户行为分析及用户画像，进行智能推送。如基于用户画像按类型推送运营类消息，基于用户接受消息数量，判断是否合并消息推送等。

6、渠道间消息项的延续与统一

出于信息持续性的考虑，触达渠道之间有部分关联关系在制定消息触达渠道时需要注意，如：