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

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

---

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

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

相關業務背景介紹

C4C在業務模組方面分成銷售和服務兩大塊，作為SAP的一款雲產品，每天要快速處理大量的且時效性很強的業務資訊。比如: 銷售模組需要實時挖掘銷售機會，服務模組需要對使用者提出的產品故障，進行快速實時的反饋和響應。

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的技術文章了，列表如下：

• C4C和微信公眾號整合系列教程

• SAP成都C4C小李探花：淺談Fiori Design Guidelines

• SAP S4CRM vs C4C, 諸葛亮和周瑜?

• SAP成都研究院C4C光明左使：SAP Cloud for Customer 使用SAP UI5的獨特之處

• SAP Cloud for Customer Extensibility的設計與實現

• 機器學習在SAP Cloud for Customer中的應用

• SAP移動應用解決方案之一：HTML5應用 + Cordova = 平臺相關的混合應用

• 打通C/4HANA和S/4HANA的一個原型開發：智慧服務創新案例

• SAP成都研究院大衛哥：SAP C4C中國本地化之微信小程式整合

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":