起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何基于自然語言，優化美團外賣客服機器人產品？
客服機器人承接的是上游服務的問題，自身業務需求是對問題的自動化處理，向下游輸出的是用戶反饋信息的整合。那要如何基于自然語言，優化美團外賣客服機器人產品？
產品設計概述：
客服機器人在應用層隸屬于智能客服范疇，從業務流程上看，智能客服是APP端上業務與人工客服的中間層。APP端上游分發的服務出現了問題，用戶通過智能客服進行咨詢投訴反饋，如果解決不了問題，再將用戶及問題引導到人工客服進行處理。
整體上看，客服機器人承接的是上游服務的問題，自身業務需求是對問題的自動化處理，向下游輸出的是用戶反饋信息的整合。
所以產品設計上，會從三個方面概述：如何承接上游業務、自身業務設計、如何向下游輸出。同時會簡要的概述如何設計后端產品，對前端的機器人進行更好的輔助。
整體的框架設計如下：
前端產品
1. 承接上游業務
外賣業務由于時效性較高（餐品的質量問題、配送時效問題等）、參與的角色較多（用戶、騎手、商家、平臺），所以出現糾紛或者異議的情況會很多。
此外，由于外賣衍生的垂類業務較多（優惠券、準時達等），用戶一次性接受較為困難，所以用戶可能會咨詢客服相關的知識問題，了解不同的細分垂類業務。
如果所有的用戶都到人工客服咨詢問題，會造成兩個問題：
- 客服進行量大，增加人工客服成本，同樣的問題，客服可能會一遍一遍的回答不同的用戶，造成資源的浪費；
- 用戶等待時間較長，人工客服資源有限，都進線咨詢，等待客服接線的時間就變得很長，用戶體驗較差。所以為了承接上游業務產生的兩類問題（服務問題、咨詢問題），設計一款客服機器人，幫助用戶解答問題。
2. 機器人自身業務
2.1 咨詢問題
針對用戶對于產品的使用困惑，比如說：不知道優惠券如何使用，我們可以針對這類咨詢問題。用戶進入人工客服，期待的結果也只會是客服告知使用優惠券、優惠券中心的入口在哪兒怎么查看等。
我們可以設計一問一搭的QA問題，或者常見問題分類進行展示。兩者的區別在于用戶主動和用戶被動，QA形式，更多的是用戶通過打字或者語音的方式輸入，機器人后臺識別問題之后進行回答。
而FAQ展示，是用戶看見了FAQ問題分類的大類，認為里面可能有想要的解答，就點擊進去尋找問題小類，最終找到答案。
兩種交互方式的示意圖如下：
兩種模式應該并存，讓有不同使用習慣的用戶都可以按照自己的方式找到問題的答案。雖然兩者交互上存在差異，但是后臺的支持，都是相同的。都是通過知識庫來支持兩者，具體的知識庫建設后面會提到。
2.2 服務問題
對于服務問題，可以根據歷史的數據，整理出熱點的top問題，再根據每一個top問題，梳理客服處理問題的流程，再從算法層面借助這樣的流程形成規則，然后對用戶的問題進行服務。
這里做一個大膽的猜測：“騎手提前點擊送達”會是一個常見的問題。
這個場景在我點外賣的過程中經常會遇見，騎手為了不超時送達，提前點擊了已送達。用戶遇到不公平的對待，肯定會咨詢客服反饋。但我們還是按照之前的咨詢問題來看待，未免不能通過引導很好的解決問題。因為引導的話語，無非是讓用戶進入到人工客服進行咨詢。
但我們可以假象一下人工客服的處理流程，用戶進線投訴騎手提前點擊送達，客服首先進行安撫，隨后確認訂單，之后進行核實，最后將核實的結果及處罰的措施告知用戶，并給出相應的賠償。
這一套流程我們可以通過整理形成一套流程，再通過算法的接入形成一個規則，以多輪交互的形式在機器人幫助用戶解決問題。
具體的交互形式如下：
左圖為美團外賣的現狀，沒有判斷問題的流程復雜程度，只給出了大段的話術引導，易讀性差且用戶的成本變得很高，右圖為理想的改進版本，只需用戶逐步的按照規則提示，就可以快速的完成投訴。
這種服務問題的建設，在優化了用戶體驗、減少用戶操作成本的同時，也可以對外輸出能力。比如：針對騎手提前點擊送達的問題，系統的判斷環節可以輸出為借口，為人工客服服務，這一部分會在后面詳細闡述。
2.3 機器人整體風格
機器人的整體風格，可以從上下游承接的關系進行設計。上游出現服務問題或者咨詢問題，進入到機器人詢問。那么機器人就應該對這兩類問題進行主動的發問，減少用戶感知的成本。
而我們通過“騎手提前點擊送達”這個場景判斷，服務問題不能用簡單話術引導，原因是需要不斷地確認用戶的信息（用戶訂單、訂單狀態等），而外賣的服務問題或者投訴，與訂單的耦合很大，所以我們可以在進入到機器人的時候就彈出訂單，并給出已經擁有的服務問題多輪交互，滿足用戶的服務問題訴求。
同時，針對于用戶進行咨詢問題的訴求，可以配置大類的問題，引導用戶點選，逐步的找到問題答案。
改版后的機器人首頁如下：
機器人首頁推薦出最近一筆訂單，下方配置的是具有多輪交互的場景問題，滿足用戶的服務問題。右側是常見問題，配置的是大類的問題，用戶點擊后可以逐步展示細分分支，最終得到答案，滿足用戶的咨詢問題。
3. 下游輸出
機器人的交互形式，不會被所有的用戶認可，部分用戶更習慣傳統的人工客服模式，認為人工更值得信賴。當用戶從機器人轉入人工的時候，如果可以盡可能多的帶入信息，就可以免去客服與用戶最初的信息核對流程，可以減少用戶的等待時間，并降低客服平均每單服務時長。
同樣的，信息的獲取，也應該根據問題的類型分為兩大類，服務問題及咨詢問題。如果是服務問題，還需增加一步選擇訂單的步驟，讓客服在接起的時候，就知道更多的用戶信息。如果是咨詢問題，選擇完大類問題之后即可接入人工客服。
示意圖如下：
后端產品
1. 知識庫
機器人能夠回答用戶的問題，無論是一問一答的QA，還是具備多輪交互的服務問題，后臺的支撐都是知識庫。在前端頁面展示的，是用戶輸入問題，機器人彈出對應的答案，在后臺的流程比前端展示的要復雜的多。
首先，通過語義識別的技術對用戶的語句進行分詞處理，然后將關鍵詞在知識庫中搜索，如果匹配到對應的知識點，再將知識點對應好的答案彈出。知識點對應的答案，是人工通過對業務的認知，進行編寫的。
這里的知識庫，我理解應該通過知識圖譜的方式進行數據的管理，即每個知識之間是有關聯性的。之前提到的FAQ模式，首先展示出大類的問題，再逐步的細分，最后彈出對應的答案。
在后臺數據層面，可以很好的理解成樹狀結構，樹狀結構模型可以自上而下的對問題進行分類整理，葉節點就是問題最終的答案。所以我們再通過后臺數據結構來看FAQ與QA模式的差異，無非是首先進入這個樹狀結構的位置的差異。
- FAQ的進入位置，可能更靠近根節點，走到葉節點的路徑就長一些；
- QA的模式，由于用戶的輸入更明確，分詞之后的語義識別使得進入的位置更靠近葉節點，走到葉節點的路徑也就更近。
而服務問題的結構，加入了節點的詞性定義。知識點的詞性不再都是名詞，更多的加入了主謂語、主被動等詞性。知識庫的圖譜結構可以較好地支持機器人的回答。同時，可以在知識庫的基本能力之上進行賦能，可以作為標準知識對人工客服輸出，作為人工客服的回答標準。
這樣的做法有兩個好處：
- 減少了人工客服查詢規則的時間，提升服務效率；
- 人工側與機器人側統一答案，避免造成負面影響。
2. 智能輔助平臺建設
“騎手提前點擊送達”這個服務問題，我們提到了，可以將判責的環節作為能力輸出。
算法可以生成模型，根據騎手的點擊送達的位置與用戶接餐的位置，進行系統的判斷，加入規則之后輸出為模型。人工客服只需要輸入騎手的基本信息，就可以調用判斷，智能高效的幫助用戶，否則人工客服可能就得點擊各種系統，查看騎手的當時位置，過程繁瑣。
同樣的，這種智能輔助平臺的建設，也會有知識庫建設的好處：
- 減少了人工客服查詢規則的時間，提升服務效率；
- 人工側與機器人側統一答案，避免造成負面影響。
3. 工單系統
工單系統對于整體客服層面的建設有著至關重要的作用，無論一個用戶的問題由機器人解答，還是由人工客服解答，亦或由機器人流轉到人工客服。當我們后續對此case進行review的時候，我們需要工單系統的輔助。
此外，人工工單量和機器人工單量也可以作為后續的KPI考核指標進行評估，從宏觀角度審視兩者孰好孰壞。
#專欄作家#
Mitsuizq，微信公眾號：畫圖碼字實習生，人人都是產品經理專欄作家。關注AI領域。
本文原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
- 目前還沒評論，等你發揮！
