SAP成都研究院飛機哥: SAP C4C中國本地化之微信聊天機器人的集成

時間 2019-12-27

標籤 sap 研究院飛機 c4c 本地化微信聊天機器人集成欄目 C&C++ 简体版

原文原文鏈接

今天的文章仍然來自Jerry的老同事，SAP成都研究院的張航(Zhang Harry)。關於他的背景介紹，請參考張航以前的文章：SAP成都研究院飛機哥：程序猿和飛機的不解之緣。下面是他的正文。前端

你們好，我是來自SAP成都研究院C4C開發團隊的Harry。今天給你們帶來一個SAP C4C中國本地化的案例分享，這是咱們成都C4C開發團隊目前正在進行中的一個具備前瞻性的原型開發：經過C4C、微信、和基於Recast.AI的聊天機器人進行集成，提高C4C的工單處理能力。 node

這個原型開發以前我也在SAP成都研究院內部分享過，這是當時會議的宣傳海報。很是感謝個人同事，S4CRM團隊的Liu Zoe和最懂個人汪哥幫我量身設計了這張以F35戰鬥機爲背景的海報。算法

相關業務背景介紹數據庫

C4C在業務模塊方面分紅銷售和服務兩大塊，做爲SAP的一款雲產品，天天要快速處理大量的且時效性很強的業務信息。好比: 銷售模塊須要實時挖掘銷售機會，服務模塊須要對用戶提出的產品故障，進行快速實時的反饋和響應。json

SAP解決方案和社交渠道集成的價值在於，經過該方式，用戶能夠隨時方便地接入系統，同時系統的反饋信息也能實時快速地反饋給用戶，這樣系統和用戶之間的交互效率和用戶體驗就大大提升了。小程序

另外一方面，工單處理(Ticket)是服務模塊裏面重要的功能之一。客服人員天天有數量巨大的工單須要處理，面臨很大的壓力，同時，系統對用戶提出的緊急的產品故障，須要快速實時地作出正確的處理和反饋。所以，工單處理模塊必需要保證高速性和高有效性。微信小程序

咱們團隊完成的原型開發，在第一階段實現了C4C工單處理流程和微信的集成：用戶能夠經過關注微信公衆號，來經過微信渠道快速發佈產品故障信息，同時，咱們處理的結果、解決方案也能夠經過微信，快速、實時地反饋給用戶。這種方式利用了微信的渠道優點，提升了工單處理的速度。服務器

而聊天機器人的集成，幫助咱們提高了工單處理模塊的另外一個能力：高有效性。儘管客服人員天天會有不少工單須要處理，然而根據實際的客戶經驗，這些工單裏面，大部分問題都有一些共同特色：處理起來比較簡單，處理的邏輯不復雜，只須要客服人員稍微指導一下，客戶本身就可以解決掉。 微信

這些問題的一些典型例子有，客戶沒有看懂說明書，或者產品設計不合理，誘導用戶進行了錯誤操做，再或者是一些很常見的問題。架構

雖然這些問題單個處理起來花不了太長時間，可是數量一多，也會消耗客服人員大量的時間和精力來處理。

在這種背景下，成都C4C開發團隊提出了一種解決方案：引入智能聊天機器人，經過機器人內嵌的NLP(Natural Language Processing)天然語言分析能力，分析用戶提出的問題。識別出用戶提出問題裏面的關鍵因素：

什麼產品出了問題？
該產品具體出了什麼問題？

而後利用這些關鍵因素，去後臺知識庫找到對應的解決方案，反饋給用戶，智能指導用戶解決問題。

該方案的優勢是：理想狀況下，會有很大數量的處理複雜度較低的客服工單被機器人自動處理掉了，客服人員面臨的工單數量上的壓力變小，能夠把精力放在真正須要人工處理的那些複雜度較高的工單上。

實現效果展現

在C4C端，咱們作了一個UI風格和微信很是類似的聊天界面，目的是方便客服人員在C4C系統裏面，和正在使用微信端的用戶進行聊天。界面和交互方式模擬微信，目的是爲了讓客服人員用起來更加習慣，方便上手。

首先，當用戶打開公共號聊天窗口時，機器人客服會致歡迎詞，並提示用戶按照必定格式輸入產品故障信息，方便聊天機器人識別。

下圖便是客戶在本身手機上的微信應用裏同C4C微信機器人進行交流：

當系統成功識別出用戶提出的產品故障信息時，就會找到對應的解決方案，包裝之後，經過社交渠道反饋給用戶。

那麼系統是如何自動進行產品故障和其解決方案的匹配呢？除了在C4C UI開發一個上面描述的模擬微信的聊天窗口和前端相關邏輯外，咱們還部署了一個獨立於C4C系統的第三方服務器, 基於node.js架構，稱爲Agent Server，用於攔截和處理來自C4C, 微信和聊天機器人的請求，實現相關的路由算法和處理邏輯。

在Agent Server上，咱們部署了一個數據庫，實現了相應的數據搜索邏輯，稱爲知識庫(knowledge Base)，用來管理和存儲工單處理的關鍵信息，包括：

產品型號信息
各種產品典型故障信息及其默認的解決方案

當用戶輸入信息包含合法的產品故障信息時(好比包含有產品型號，或者產品故障信息的具體描述), 經過Recast.AI識別出來後，會嘗試去上述介紹的Agent Server上的知識庫去查詢相關的解決方案。若是可以找到解決方案，聊天機器人直接將其回覆給客戶，引導客戶本身解決問題。

當機器人識別到用戶輸入的關鍵信息有問題，好比輸入的產品型號有誤，故障信息描述不許確，機器人也會在聊天窗口提示用戶從新輸入正確信息。

若是機器人沒法找到相應的解決方案，或者實在沒法識別用戶輸入語言裏面的有用信息，會提示用戶，切換到人工處理模式，同時向C4C後臺發送提示信息，提示客服人員接手處理。當客服人員在聊天窗口輸入信息時，工單處理模式自動切換到人工模式。

技術實現

用戶輸入的天然語言是「扁平化」的文本信息，輸出是C4C經過微信反饋給用戶的問題處理結果和解決方案，其展示形式可能會多種多樣：簡單的文字信息、或者是內嵌的連接、或是帶有圖片，word文檔，pdf文檔等附件，供用戶選擇。

上述業務需求的技術實現流程經歷了三個階段：

第一階段，NLP天然語言建模。用戶輸入的扁平化的文本信息，系統是沒法直接識別的，這些文本信息包含了多個維度的信息，好比: "我剛買的iphoneX 開不了機了"。其中「iphoneX」和「開不了機」，分別表明了產品信息和故障信息兩個維度的特性。NLP建模過程，就是把純文本里包含的這些信息分門別類提取出來，再映射到不一樣維度上，造成一個多維度立體化的數據模型。具體體現咱們這個原型開發裏，就是一個json格式的數據。

下面給出了Recast.AI訓練的截圖，經過訓練，使得AI可以把扁平化的輸入文本，分析出正確的Entity, 即生成正確的多維度信息。

關於Recast.AI的更多使用細節，能夠參考Jerry的文章：使用Recast.AI建立具備人工智能的聊天機器人。

第二階段，把第一階段傳來的立體化、模型化的信息，由系統進行分析，識別出關鍵信息。根據關鍵信息，去知識庫檢索，拿到須要回覆的信息。若是取不到關鍵信息，或者用戶輸入的信息有問題，由相關的邏輯組合成適當的信息做爲缺省回覆。

第三階段，把處理的結果和解決方案，組裝成知足微信信息要求的格式，反饋給用戶。

將來的功能進一步擴展的探討

目前咱們完成的這個原型開發，主要目的是爲了驗證技術可行性和最簡單的業務原型展現。若是須要把這個原型轉化成C4C產品，不管從產品功能仍是技術實現，都須要進一步的細化和完善。下面是咱們未來會進行進一步研究和探索的方向。

更加豐富、多樣化的用戶反饋信息：目前的原型開發，對用戶提出的問題，智能機器人只能用簡單的文本信息進行迴應。
將來在給用戶反饋的信息類型上，能夠進一步向更加多樣化和人性化方向擴展。好比：給用戶的回覆信息也能夠是像word,pdf或者圖片這樣的格式，更好地幫助指導用戶操做。或者經過帶有連接，或者可執行按鈕的反饋信息，用戶點擊後，能夠進入更加詳細信息的幫助頁面，指導用戶一步一步動態操做。
實現機器到人工的智能化切換：當前的原型開發, 一旦在知識庫裏檢索不到產品故障對應的解決方案、或者Recast.AI沒法獲取足夠的關鍵信息時，就簡單地發出請求，提示人工客服接手，屬於"一刀切"式的異常處理方式。
將來，能夠考慮進一步豐富異常處理方式，實現智能化切換到人工模式。當系統找不到合適解決方案時，至少可以根據已有信息，和系統裏經過人工客服處理過的歷史數據進行挖掘，分析哪些技師適合處理此類問題，再把分析結果推送給客服人員。
知識庫信息更加豐富。產品解決方案的知識庫的設計是一個很複雜的需求，當前的原型開發出於快速展現的須要，使用了最簡化的產品知識庫，只能根據產品型號和問題類型兩個必需要素進行簡單定位，存儲的內容只有文本類型的解決方案。
將來產品知識庫的設計須要考慮到多重場景下多重解決方案的精肯定位。好比，引入更多的查詢要素，且不一樣的要素還能夠設置不一樣權值，不一樣要素呈現層級關係，上層要素定位的解決方案能夠被下層複用。查詢要素和對應解決方案，也能夠呈現多對多的關係。

由於我於2007年就進入SAP成都研究院並從事SAP Business ByDesign相關開發工做，這些年來我也有幸見證了SAP C4C的誕生，發展和壯大。在ByDesign這個基礎技術平臺上，經過開發不一樣的業務功能模塊，衍生出了突出CRM這個行業垂直解決方案的C4C，和突出端到端總體化解決方案的ByDesign標準產品。

巧合的是：我文章開頭海報中F35戰鬥機的實現方案和SAP C4C產品有殊途同歸之處。正好我本身也收藏了一架比例爲1：72的F35C的模型，拿出來給你們分享一下：

和大名鼎鼎F22「猛禽」同樣，F35也是美國第四代先進戰鬥機，綽號「閃電2」， 21世紀纔開始生產和裝備，和強調高精尖和技術優點的F22不一樣，F35一開始研製採用了不少下降風險、成本的方式，好比拉攏多個夥伴國家，共同開發，技術共享和共同生產等。帶來的好處就是：下降了技術風險，生產成本和後續維護成本。

另外一方面，面臨的挑戰是：做爲一款多國家共同研發多用途戰鬥機，必需要適配多個國家、多個軍種，和各式各樣的使用場景。

同SAP C4C是基於SAP Business ByDesign平臺衍生而成同樣，F35也在一個基礎平臺的基礎上，經過加裝不一樣功能組件，衍生出三種子型號，以適應不一樣的使用場景：

1. F-35A：傳統的陸基起降型，加裝的功能組件最簡單，成本最低，主要在美國和其它國家的空軍服役。

2. F-35B：垂直起降型，機身中間加裝了能向下噴氣的升力風扇，同時發動機帶有矢量噴管，可以90度向下噴氣，實現了垂直起降。這種型號的F35能夠部署在，像日本「加賀」級，英國的「伊麗莎白」級這樣的中小型航母上，或者美國海軍陸戰隊的「黃蜂」級、「美國」級這樣的兩棲攻擊艦上。

3. F-35C：航母艦載型，也是我照片裏面的模型的機型：機翼帶有摺疊功能，能夠節約在航母上部署的空間，而且安裝有增強的起落架和降落用着艦鉤。

F35C在美國海軍服役，部署到「尼米茲」，「福特」級這樣的大型航母上。

今天關於SAP C4C和微信集成的創新案例就分享到這裏，感謝你們閱讀。

更多閱讀

SAP成都研究院的C4C開發團隊的同事們已經寫過不少關於C4C的技術文章了，列表以下：