文章以物業(yè)客服的人工智能為例，從業(yè)務(wù)流程、語音收集、知識庫、設(shè)計四個方面分析了產(chǎn)品的需求，簡述了智能客服落地的全部過程。

寫完題目感覺起大了，其實感覺現(xiàn)在也還是個人工智障：)

一、前提

隨著人工智能的興起，機器人客服也開始成為互聯(lián)網(wǎng)公司在線服務(wù)的標配前置。我所在公司當前的業(yè)務(wù)范圍涵蓋物業(yè)和業(yè)態(tài)（電商、到家、廣告、保險等）多維的服務(wù)，原來APP端只接入了業(yè)態(tài)相關(guān)的在線，每天的會話量級只有幾百左右。

物業(yè)服務(wù)在公司呼叫中心的占比大約是業(yè)態(tài)服務(wù)量的幾十倍，因此業(yè)務(wù)方希望在APP端開通物業(yè)在線的功能，同時前置智能客服機器人，實現(xiàn)對呼叫中心話務(wù)量的分流，同時也滿足部分習慣使用在線進行交流的用戶的需求。

1.1 價值預估

通過下面的電話和在線的漏斗圖可以看到期望的攔截路徑。通過對工單頻次進行分析，已經(jīng)在電話端上線了高頻分類的IVR功能，日均可以實現(xiàn)30-40%左右的人工攔截量。

其中門禁、代收包裹電話自助功能用戶的使用黏性和評價都較高。對于在線服務(wù)，期望初期能分流20%的電話量，并逐步提升到50%。同時機器人能夠?qū)崿F(xiàn)40%左右的在線攔截率。

?電話漏斗圖

在線漏斗圖

1.2 實現(xiàn)路徑

先開通APP端物業(yè)在線服務(wù)積累用戶語料，從電話端引流到在線端，培養(yǎng)用戶通過在線進行物業(yè)咨詢和報事習慣。后續(xù)通過灰度發(fā)布，逐步開通各個社區(qū)的智能客服，實現(xiàn)機器人的7*24小時服務(wù)。

1.3 場景選擇

智能客服應(yīng)該優(yōu)先解決哪些問題，支持哪些交互方式，用戶有哪些高頻的問題和場景，這些需要通過對歷史的工單數(shù)據(jù)進行分析來提取。

從呼叫中心工單分類報表和APP端服務(wù)訪問頻次，我們提取出來四個高頻操作場景：訪問通行、園區(qū)報事、房屋急修（戶內(nèi)報事）、生活繳費。

物業(yè)咨詢相關(guān)的問題通過QA和FAQ來實現(xiàn)：

二、語料收集

物業(yè)相關(guān)的語料較為垂直，同時和自身的業(yè)務(wù)耦合較高，放棄了從公開語料庫獲取的思路，打算從積累的電話錄音和在線的語料中進行提取。

2.1 在線語料

獲取歷史的在線會話記錄，抽樣進行語料標注，作為測試集。

2.2 語音標注

呼叫中心記積累了百萬級別的通話錄音，通過語音轉(zhuǎn)寫和人工標注，作為語料喂養(yǎng)給NLP訓練使用。

（這部分成本較高，使用了科大訊飛電話專用版進行預轉(zhuǎn)寫，平均轉(zhuǎn)寫成本0.1元/條，人工標注成本3元/條。每次購買服務(wù)的時候都感覺心在滴血）

2.3 業(yè)務(wù)&AI產(chǎn)品編造

根據(jù)業(yè)務(wù)場景，編造部分語料進行機器人訓練。

三、 知識庫

前面已經(jīng)根據(jù)業(yè)務(wù)場景，梳理出機器人一期支持的場景為操作類和問答類，這兩種分類的區(qū)別度較大，分類設(shè)計知識庫維護后臺。

3.1?知識庫維護后臺

1) QA類型知識庫：

查詢

新建

2) 操作類知識庫：

查詢

新建

3.2?維護方式

業(yè)務(wù)可以通過Excel按照模板收集后，批量導入。也可以通過編輯后臺對單個知識進行新增和維護。

3.3?寒暄

由于用戶問法的發(fā)散性，機器人無法命中所有問題，如果出現(xiàn)無法識別的情況就反饋無法理解，對于用戶來說就像和智障（大誤）在交流，很快就回失去耐心。

通過寒暄庫可以提升機器人聊天的體驗，設(shè)置部分有意思的對話內(nèi)容，也能讓用戶感受到機器的幽默和溫暖。

畢竟，我們的slogon是：做有溫度的機器人。

寒暄庫這塊使用了圖靈機器人，可以方便的定義問法和回答，還支持天氣等查詢的功能。

四、設(shè)計

4.1 交互方式

針對當前的業(yè)務(wù)場景，一期做了簡化，不支持富文本，樣式只支持文本，鏈接和操作類。后期規(guī)劃增加地址卡片等視圖。

1. 文本
2. 鏈接
3. 操作
4. 反饋

反饋的功能很必要，相當于在線客服中的評價，因為AI后臺只能識別出用戶問題是否命中了具體的回答，但不知道回答有沒有解決用戶的訴求。

加入反饋的功能，可以讓用戶進行自主的反饋。

反饋占用一定的頁面空間，理論上所有的回答全部加上反饋最好，但是這樣對于用戶的交互體驗上就會大大降低。

因此需要業(yè)務(wù)人員分析哪些問題不確定需要反饋，一次會話中不超過3次的反饋為宜。

4.2?頁面設(shè)計

確定基準色：

視覺給出兩版色彩稿，冰藍色和橙色。冰藍代表機器和智能的冷酷感，橙色是APP主色調(diào)，溫暖。

經(jīng)過調(diào)研后大家最后選取橙色進行UI設(shè)計，保持和主APP色調(diào)一致，同時體現(xiàn)出溫度感（Slogan默默的招手）。

根據(jù)原型和UED的同事溝通機器人的目的和期望的形象。在定義上我們希望用戶能直接意識到是和機器人在交互，而不是誤導用戶在和人工客服對話。

所以在頂部展示了機器人的頭像，點擊可以進入到介紹頁。

Q：是否展示頭像？

A：使用用戶頭像，用戶感知上更加友好，但是聊天框會較短。APP端產(chǎn)品給出用戶自定義賬戶頭像的比例比較低。通過和設(shè)計同學溝通，對比有無頭像兩版設(shè)計稿，最終選取不使用用戶頭像的設(shè)計方案。

Q：輸入方式是先語音還是先文本？

A：希望引導用戶使用語音作為第一交互方式，同時普通話短句的文字識別率達到90%以上，采用先語音的方式。用戶可以切換鍵盤輸入。

Q：用戶語音輸入之后，是展示轉(zhuǎn)寫結(jié)果等待確認還是直接發(fā)送？

A：直接發(fā)送，減少交互步驟數(shù)。缺點是轉(zhuǎn)寫錯誤無法修改，對于后臺自動糾錯能力要求比較高。為什么不保留語音，因為機器人交互的后臺最終還是通過文字進行識別，語音對于AI是沒有意義。

Q：人工客服入口如何設(shè)置？

A：人工客服的入口過于明顯，會導致用戶跳過機器人直接使用人工客服，無法起到機器人分流作用。人工客服入口過深，用戶無法找到人工入口，機器人無法解決用戶問題時導致用戶體驗急劇下降。采用方式：右上角常駐轉(zhuǎn)人工入口圖標，但是不使用文字說明，減少直接曝光度。用戶交談過程出現(xiàn)3次無法識別，會話內(nèi)容提示轉(zhuǎn)人工。

下面的問題留個大家思考，最后的實現(xiàn)方式上，我們也因為資源等問題做了不同程度的取舍，有機會在細談這部分：

• Q：如何定義會話？
• Q：如何展示聊天會話的時間？
• Q：語音輸入的長度限制？
• Q：歷史會話如何加載？

4.3?異常情況處理

• 弱網(wǎng)環(huán)境提示
• 服務(wù)器長時間無返回提示
• 無錄音和麥克風權(quán)限提示

五、埋點和效果回收

智能客服需要不斷的迭代優(yōu)化，知識庫也需要不斷的補充和修改，因此需要對命中效果和用戶反饋做統(tǒng)計，支撐后續(xù)業(yè)務(wù)部門和機器人產(chǎn)品對于智能客服的不斷優(yōu)化。

這部分展示通過后臺的數(shù)據(jù)庫進行分析統(tǒng)計，沒有前端頁面，不做過多介紹。

通過關(guān)鍵詞正則匹配-NLP模型匹配兩層命中，上線前在訓練集達到了100%的準確率和召回率，測試集綜合能有70%以上的準確率。

六、成果

這篇主要講了整個智能客服落地的全部過程，其中有對業(yè)務(wù)和競品的思考，也有受限于資源的妥協(xié)。后面有時間再拆分詳細講其中的某些點。

本文由 @還酹江月 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash ，基于 CC0 協(xié)議