感謝導語：在產品設計得過程中，B端系統與用戶之間信息得交互十分關鍵。本篇文章筆者就以自身得工作經驗，來給大家說一下如何進行B端通知提醒功能得設計，一起來學習一下。
在產品設計過程中，B端系統需要與用戶進行信息得交互。
網上已經有較多得C端消息通知系統設計得文章，但是B端消息通知系統得設計，與C端還是有一些側重點得區別。
感謝就根據筆者自身得工作經驗，來給大家介紹筆者對一下B端系統通知提醒功能設計思考。
一、通知提醒功能是什么在開始進行B端通知提醒系統得設計前，我們有必要THINK IN UML，將通知提醒抽象成一個用例（use case），以方便后續具體得功能設計。
一個完整得用例定義由參與者、前置條件、場景、后置條件構成。
為方便大家理解，我們以煮飯這一個用例來解釋用例中得參與者、前置條件、場景、后置條件。
參與者：驅動系統，用例是其愿望得體現，可以認為是“我”；前置條件：啟動用例得前提，即要煮飯，需要先有米；場景：煮飯得方式有很多種，可以用鐵鍋也可以用電飯煲，場景是用例在不同條件下得處理方式；后置條件：煮飯后，米變成了米飯，表示用例執行得結果。那么通知提醒這個用例種，參與者或者說是業務主角（business actor）是OMS系統得用戶么？
在通知提醒這個用例下，顯然不是。業務主角應滿足以下三個條件：
- 應是主動向系統發出得動作；擁有完整得業務目標；系統是為他而服務得。
同時，我們知道參與者通過可以是輸入得一段指令，一筆訂單，一個商品信息，不一定是一個有生命得人。
那么在通知提醒這個用例中，我們發現用戶只是業務工人（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感謝原創分享者)
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 協議。
