本文从北京铁路局12.6事故出发，详细分析了“消息”和“指令”的定义，引出了B端即时通讯工具的核心特征，并介绍了B端即时通讯工具如何构建，最后列举了市面上典型的产品案例。痛定思痛，希望将事故的教训转化为具体的行动；并祝愿善良的人一生平安。

一、这是微信的过错吗

通过事故调查报告，官方将原因归结为“动车的调度指令只是通过微信群来发布，而没有盯控作业班组是否收到指令的反馈，导致指令漏传后、事故发生。”

这是微信的过错吗？微信是否应该为调度指令的漏传负责？

作为一款即时通讯工具，微信以“消息”这种内容形式承载了熟人之间社交的职能。但微信能承载“调度指令”这种类型的内容吗？这里先不回答这个问题，我们先来看一下“消息”和“指令”有什么区别。

1. 消息和指令的定义

在通讯场景里，消息可以定义为：“人与人”之间或者是“系统与系统”、“系统与人”之间用作信息交换的基本单位。而指令是上一级对下一级的指示或命令，或者是控制计算单元执行某一运算的代码。

二者既有相同点又存在着显著的不同，如下图所示，我们可以从消息和指令的“主体”、“内容”和“环境”三个维度来进行分析。

（“消息”和“指令”的对比图）

（1）主体

1）发送者：

“消息”的发送者可以是任何人（或系统），并无职位、性别、人种、年龄、尊卑等区别，体现了“众生平等”；

而“指令”的发送者往往是职位的“上级”、“控制者”、“主导者”、“决策者”，或流程的“上一级”。可以看到，在“发送者”的身份定义上，消息和指令是显著不同的。

2）接收者：

同“消息”的发送者类似，“消息”的接收者可以是任何人；

而“指令”的接收者往往是职位的“下级”、“跟随者”、“参与者”、或流程的“下一级”，二者也是显著不同的。

（2）内容

1）内容形式：

就内容上来讲，消息包含了文字、语音、照片、图片、视频、表情、符号……等等一切可能的形式；

而“指令”因为要求可解读可执行的特性一般只会有代码、文字、语音等有限的形式。

2）标准化、可执行性、无二义性：

“消息”对于是否标准化并无特定要求；

而“指令”则必须要求是标准化的，如制造业生产和装配场景使用的“标准作业程序（SOP)”。

“消息”对于可执行性并无太高要求，可以是可执行、看得懂、听得懂的，也可以不具有可执行性仅用来展示自我或表达情感；有时需要重复发送或者追加解释，甚至翻译之后才能看得懂。

而指令则必须要求可执行、无二义性，要求执行结果明确可测量。比如军队指挥员在传送语音指令时要把“0101，我是07”发音读成“洞妖洞妖，我是洞拐”这种清晰的不易产生误解的约定读法，而不能是“零壹零壹，我是零柒”这种容易混淆的读法（“壹”和“柒”在读音上不容易分清）。

（与外国小伙伴交流时，可以使用微信翻译。近期的一个加拿大国旗的梗，哈哈）

3）时效性：

“时效性”对于“消息”来讲属于Kano模型（注1）中的“期望型需求”，消息收取越及时，用户越满意，消息收取越不及时，用户则越不满意。但“满意”或“不满意”是位于情感需求的层级（马斯洛需求层次理论中的第三层级，注2），一般情况下不会产生致命影响；

而“指令”如果超出有效时限，则极有可能导致任务失败或作业失效，甚至有可能产生危险，所以指令的时效性必须是严格的。

4）可触达性：

同时效性要求一致，未收到消息时也会导致用户不满意，但是仍属于情感层面的影响，也可能会导致一些损失。

而如果没有收到“指令”，则会直接导致任务失败或作业失败，从而无法将任务或作业推进至下一环节。所以对于指令来讲，“可触达性”必须是“强制”需求。

5）反馈要求：

对于“消息”来讲，是否需要接收者给予反馈是基于具体沟通场景，可以要求，也可以不要求。

而对于“指令”来讲，必须在确认上一级指令正确执行后才能允许发送下一级指令，以保证后续指令顺次、有效执行，避免混乱和危险。

（3）场景

交互场景：

“消息”的交互场景一般发生在非正式沟通和交流的场景，可随时随地进行，并无约束；

而“指令”则只会发生在任务执行、作业执行、部队通讯等正式场合。

从以上区别来看，“消息”和“指令”不管是从发生的主体、发生的场景还是从发生的内容上来看，基本上在每一个方面都有着本质的不同。把“消息”当作“指令”来发送会造成气氛紧张或显得过于正式（抑或有一种“拿着鸡毛当令箭”的即视感？）而把“指令”当作“消息”来发送则会导致业务混乱甚至发生危险。

2. 微信的定位

微信作为一款定位在C端的、拥有11.51亿用户量级（2019年Q3数据）的熟人社交类聊天工具，用户数无疑事关生死。

在用户体验设计上基于“生活场景”并迎合大多数用户的需求，无疑是微信产品设计的重中之重。而“指令”赖以生存的“业务场景”毕竟是小众场景，若根据“指令”的特征进行微信聊天场景的改造无疑会令绝大多数用户感到不适。

微信就是微信，温和、易用，专注于生活场景，人人平等。

3. 于是，我们可以总结出——

因长久的使用习惯培养了广大用户对微信的依赖，在沟通交流、信息共享的过程中忽视了生活场景和工作场景的不同，模糊了消息和指令的边界，那么一旦当场景发生了变化时，因微信的消息不可能自动转变成指令，则造成指令的漏传就成为了必然。

于是，迫切需要一款基于业务场景设计的B端的即时通讯工具，来解决业务场景通讯的问题，满足政府和企业业务上的真正需要。

二、如何解决问题

在解决问题之前，基于信息共享和工作协同的场景，我们就当前已存在的几种通讯工具做一下特性分析。工具选取：自动答录机、留言板、短信、通知、公告、BP机、QQ、微信、作业指导书、任务调度指令。

1. 象限分析

我们把以上工具放置在以“准确性”为纵轴、“即时性”为横轴的象限中，如下图所示。

（各工具在准确性和即时性坐标域中的位置分布）

可以看到，自动答录机、留言板对于“准确性”和“即时性”的要求均较低，而作业指导书和任务调度指令在具体业务执行的场景和过程中，对准确性和即时性的要求均为最高。而短信、通知、公告、BP机、QQ和微信处在相对中间的位置。

定位在B端的即时通讯工具因为与业务场景息息相关，对准确性和即时性的要求也必然较高。因此，B端的通讯工具在象限中的位置如下图所示：

（B端即时通讯工具所处的位置）

对B端即时通讯工具的要求：在消息的即时性上，需要能够达到QQ和微信的通用能力（QQ和微信培养了广大用户的使用习惯）；而在消息的准确性上，则必须较微信和QQ为高，且必须能够支持业务场景。

2. B端即时通讯工具的典型特征

基于上一节的结论，要求B端即时通讯工具既具有C端即时通讯工具的基础能力，又具有支持业务场景的典型特征。我们分别来看。

（1）在通用能力上与C端即时通讯工具保持一致

在支持的消息格式上，具有发送文字、语音、表情、视频、图片、文件的通用能力；具有@、截屏、引用、转发、多选等通用能力；在时效性上符合“即时”的特征。

（2）与工作场景深度融合，在任务创建、可触达性、可反馈性上满足强制性的要求

1）任务创建

与政府和企业的工作场景深度融合，支持在聊天的会话场景中一键快捷创建任务、日程、提醒等，支持消息快捷转任务。

为避免重要消息遗漏，支持重要消息设置定时提醒，或“随后处理”。

2）可触达性

通过查看“已读/未读”标记，可判断消息是否已被接收者阅读。对于长时间未阅读消息的接收人，可使用“DING”或“强通知”的方式追加提醒（注3）。更进一步，还可以将消息读取强化为消息回执，只有接收者发送了回执，才算确认已收到消息。

3）可反馈性

体现在工作流程的设计和推进上，只有在上一流程执行完毕后，流程才能推进到下一环节。

（3）信息高度汇聚，以避免信息过载导致信息遗漏的问题

1）信息识别

B端即时通讯工具要求具有所有业务信息的识别能力，这是由B端的业务属性所决定的。

仍以微信为例，若多个“工作群”掺杂在所有重要的和不重要的群当中，如果群的数目巨大，则必然引起信息过载、效率低下的问题。从海量消息中筛选出需要回复的消息将会变得异常困难；而且一不小心还可能发错。尴尬事小，若引起同事、老师、上司不满，让老师“刮目相看”、“领导找喝茶，那就压力山大了。

（我和直属领导共同群聊的个数，以及包含“收到”二字的群聊天搜索记录）

2）待办中心

信息识别出来之后，需要有一个中心化的平台（“待办中心”或“通知中心”），以便将所有需要个人处理的事务汇聚于此；减少搜索、集中处理、避免遗漏。

“待办中心”必将成为用户处理业务相关事务时，第一个想到的入口。

（4）多工具集成

为满足业务随时创建、随时处理，业务全程跟踪的需求，需要B端产品支持必要的应用和工具，如：项目管理、日程管理、任务管理、流程工具、表单工具、文件管理等等；按政府或企业业务场景的不同，工具的需求会有所不同。

3. B端即时通讯工具核心能力构建

介绍完核心特性，我们尝试以线框图的方式展示构建B端即时通讯工具所需要的核心能力。分为三个模块：聊天场景与工作场景相融合、待办中心、应用中心。

（1）聊天场景与工作场景相融合

要求在聊天会话场景中可以快速创建日程，或者将消息一键转任务。如下图中在右键菜单中“转任务”和在“+”号菜单中“创建日程”。

（图：聊天会话场景“一键创建任务/日程”）

在单人会话场景中可感知消息“已读”或“未读”；在群会话场景中可查看所有“已读”和“未读”人员列表。未读消息可以通过强通知方式再次通知，如下图单人会话场景中右键菜单“强通知”和群聊场景中未接列表可选择“继续通知未接联系人”。

（图：聊天会话场景 已读/未读标识、转强通知能力）

（图：聊天会话场景未接列表、再次强通知，辅助短信发送能力）

（2）待办中心

将所有需要处理的事务类和通知类消息进行汇聚，并可按重要性和紧急性分类、按已处理和未处理进行分类。

（图：待办中心，所有待办事务及业务通知消息高度汇聚）

（图：当待办事务下钻时，可查看“处理人”、“优先级”等细节的信息，并可按“待办”和“已办”分类）

（3）应用中心

包含业务执行所必需的工具，如：日程、任务、项目管理等等，以适用于不同的业务场景。

（图：应用中心，包含各业务所需工具应用）

除以上核心能力外，我们再来看一下还可以有哪些扩展能力。

4. B端即时通讯工具扩展能力构建

除发起者可感知并主动创建的任务之外，仍有可能或因工作失误等人为因素导致部分任务应该创建但实际上没有创建的情形；是否有一种方法可感知此类场景并自动弥补呢？比如“场景智能化”，让我们打开脑洞，设想如下：

场景智能化

按：场景发现->真伪识别->业务创建->业务实施->能力升级步骤逐个分析。

1. 场景发现：在聊天会话的场景中，通过语义分析和交互分析，自动识别出疑似应该创建任务而没有创建任务的场景；
2. 真伪识别：通过主动提醒的方式，由用户判断当前是否应该创建此任务；
3. 业务创建：若为真，则由系统自动创建或者由用户手动创建一个新任务；
4. 业务实施：业务创建后的实施过程；
5. 能力升级：根据业务执行的结果，将本次关键字语义标记为“真”或者“伪”，并辅以概率权重。

随着样本量增多，通过机器自我学习的方式，场景的识别能力也会不断增强；并期望最终节省掉用户参与真伪识别的第2个节点；实现场景高度智能化。

通过以上能力构建，我们已基本上了解了如何构建一个B端的即时通讯工具。

5. 市面上B端即时通讯工具举例

以下是市面上比较典型的B端即时通讯工具，IM的通用能力就不介绍了；我们主要看一下业务场景的功能特征。选取的代表有：企业微信、钉钉、织语CCwork、Slack。

（1）企业微信

在会话场景，企业微信支持消息是否触达的标识、支持消息一键转任务基础的能力；日程和待办放置在“消息”菜单的二级入口中。如下图所示。

（企业微信的“未读”标识及“未读”统计，以及聊天场景“消息转待办”）

（企业微信“日程/待办”的二级入口）

（2）钉钉

相比较而言，钉钉的功能要丰富许多，除了基础的触达标识和一键转任务之外，消息还可以转“日程”、“稍后处理”，或者采用“DING”的方式进行未读消息的强通知提醒。

“DING”的方式强化了业务场景中可触达性的需求，为钉钉功能中较有特色的闪光点之一。

（钉钉的“未读/未确认”标识，以及聊天场景快捷处理“消息转任务/转日程/稍后处理/DING”）

钉钉的待办中心入口放置在底部栏一级菜单中单独的“DING”功能页，包含了日程、DING、任务三个子页面。如下图所示。

（钉钉的待办中心入口：DING）

除了以上标准的功能外，钉钉还支持“临时待办”的处理，包含“@我”的消息、我‘特别关注”的联系人的消息、以及我标记为“稍后处理”的消息，并将以上汇聚在一级消息窗口的上部黄金位置，以便于用户可优先观测到并优先处理。如下图中（左）所示。

对于管理员，支持管理类型消息的汇聚，如下图中（右）所示。

（钉钉的“临时待办”处理入口，以及管理类型消息汇聚入口）

（3）织语CCwork

织语CCwork具有与钉钉相类似的能力。聊天会话场景有是否触达的标识，可查看未读消息列表。聊天消息可以一键“转任务”/“转日程”，或者发起“强通知”。

（CCwork的“未读”标识，以及聊天场景消息“转任务”/“转日程”/转“强通知”）

CCwork的“通知中心”以及“统一待办”入口，放置在一级菜单“工作看板”中，汇聚特征明显。

（CCwork的“统一待办”入口和“通知中心”汇聚页）

（4）Slack

国外软件Slack号称“邮件杀手”，集成了聊天、工具、文件整合、统一搜索的功能。支持已读/未读，消息转行动。Slack的愿景是将所有的工具、所有的通知都整合在Slack当中，打造成以IM为核心的统一工作站。（这也是国内B端即时通讯工具统一的战略目标）

（Slack：为消息添加Action）

（Slack：会话转行动）

（Slack：工具集成）

使用邮件来处理企业事务的典型缺点：异步、低效、格式过载，偶尔还会受到垃圾邮件的骚扰。而使用基于业务场景的B端即时通讯工具，业务处理随时在线，无疑是未来企业办公的必然趋势；邮件的消亡只会是时间问题。

行文至此，相信大家对于B端即时通讯产品已经有一个初步的了解了。

总结

2019年3月21号，中央明确提出2019年为“基层减负年”。如何为基层减负，不能只是喊口号，而应该从信息建设层面引入适用于职场场景的B端工作台和即时通讯产品；避免C端产品的信息过载和信息爆炸，真正地为基层减负。同时培养在业务场景中使用业务产品工具的习惯，提高规范性和安全性。

最后提一嘴：狠杀职场歪风，避免形式主义。

结束。

注释

1. Kano模型

KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。

根据不同类型的质量特性与顾客满意度之间的关系，狩野教授将产品服务的质量特性分为五类：基本（必备）型需求、期望（意愿）型需求、兴奋（魅力）型需求、无差异型需求、反向（逆向）型需求。

其中期望型需求也称为意愿型需求。是指顾客的满意状况与需求的满足程度成比例关系的需求，此类需求得到满足或表现良好的话，客户满意度会显著增加，当此类需求得不到满足或表现不好的话，客户的不满也会显著增加。

——来自百度百科

2. 马斯洛需求层次理论

马斯洛需要层次理论是亚伯拉罕·马斯洛于1943年提出，其基本内容是将人的需求从低到高依次分为生理需求、安全需求、社交需求、尊重需求和自我实现需求。

马斯洛需要层次理论是人本主义科学的理论之一，其不仅是动机理论，同时也是一种人性论和价值论。其中第三层次“情感和归属的需要”包含“友情”、“爱情”、“性亲密”；表现了人人都希望得到相互的关系和照顾。感情上的需要比生理上的需要来的细致，它和一个人的生理特性、经历、教育、宗教信仰都有关系。

——来自百度百科

3. “DING”、“强通知”

分别是阿里钉钉和织语CCwork的增强类型的消息提醒方式；通过短信、电话、闪屏等强交互方式打断用户当前正在进行的事务，提醒用户查看发送者认为更为紧急的消息。

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

题图来自Unsplash，基于CC0协议