本文從北京鐵路局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端即時通訊工具擴展能力構建除發起者可感知並主動創建的任務之外，仍有可能或因工作失誤等人為因素導致部分任務應該創建但實際上沒有創建的情形；是否有一種方法可感知此類場景並自動彌補呢？比如「場景智能化」，讓我們打開腦洞，設想如下：
場景智能化
按：場景發現->真偽識別->業務創建->業務實施->能力升級步驟逐個分析。
場景發現：在聊天會話的場景中，通過語義分析和交互分析，自動識別出疑似應該創建任務而沒有創建任務的場景；真偽識別：通過主動提醒的方式，由用戶判斷當前是否應該創建此任務；業務創建：若為真，則由系統自動創建或者由用戶手動創建一個新任務；業務實施：業務創建後的實施過程；能力升級：根據業務執行的結果，將本次關鍵字語義標記為「真」或者「偽」，並輔以概率權重。隨著樣本量增多，通過機器自我學習的方式，場景的識別能力也會不斷增強；並期望最終節省掉用戶參與真偽識別的第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協議