基于Wechaty的销售助理机器人--项目结项报告

摘要

经过两个月的迭代，销售助理机器人逐渐成为一款可用、实用的产品。此報告將梳理項目產出，項目實現、以及過程中碰到值得學習的問題。

影片

报告

一、已实现功能说明

總配置流程

1. 【管理者】執行【產品準備1】和【產品準備2】，得到【售前售後名單, 企業名稱，警報配置，2個Vika表單的ID】

2. 【技術人員】根據【售前售後名單, 企業名稱，警報配置，2個Vika表單的ID】執行【部署系統】，使系統上線，通知【管理者】，正式運行

功能模块1: 消息警报机器人

功能描述

1. 机器人在飞书推送不同等级的消息卡片，提醒销售久未回复的群聊，降低销售与管理者降低负担，并提高会话满意度。
2. 通过JSON文件配置细粒度配置消息卡片、警报周期等参数，并支持销售与售后分别配置。例如：
   1. 超时 5，10分钟推送绿、黄警报至飞书私人群
   2. 超时 20，30，40 分钟推送橙、红、紫警报至飞书私人群与公共群
   3. 超出 40 分钟后，每隔10分钟推送灰色警报，直到超时1000分钟

功能模块2: 通过Vika表格进行交互式会话与绩效管理

1. 实时更新今日活跃群信息
2. 多阶段群聊管理（售前、售后）
3. 可展示群聊的回复情况、以及超时回复时长
4. 可提示未被指派销售的群（容错）
5. 对于特殊情况，例如客户回复“好”的超时情况，管理员可以取消计时（容错）
6. 沉淀诸多会话管理指标，方便销售团队复盘
7. 可通过JSON文件配置更新频率

功能模块2-1: 群聊总表

1. 在群聊总表-群聊总表内管理所有群聊的状态
2. 销售交接售后时，将【负责人】改为售后名，将【群聊阶段】改为 after-sales，等待管理员确认
3. (每日) 在群聊总表-待核准列表，勾选【核准进入售后阶段】核准群聊
4. 在群聊总表-无负责人群聊列表内，在微信群查看是否没有负责人，并重新指派一个负责人与群聊阶段

功能模块2-2: 今日群聊

1. 在今日群聊-总表内，可看到今日活跃群
2. 对于超时回复的消息，可看到最后一句对话。可查看【最后说话者】、【最后一句话】，视情况勾选【消除未恢复记录】，以取消报警提示

• 例如：看到超时88 分钟的群聊，且客户回复‘好的’，可勾选【消除未恢复记录】

1. 等待1分钟内，系统将显示【已消除未回覆记录】，超时时间归零，飞书将中断推送该群超时提醒

1. 可在末尾的参数处，查看该群的各种指标。公式为：总回复数= （售前+售后+顾客+其他员工） 的回复数

功能模块3: 伙伴云可视化

从Vika下载生成的数据，从企业微信导入伙伴云，建立可视化图表，对每个销售的当日/当周回覆质量进行可视化。目前需要手动地导入、构建图表，还是需要花费比较多的时间。下一步将会透过API实时显示绩效表单出来。

二、实现

我們將系統解構成前端、puppet、後端代碼、以及數據庫。

首先，用戶和銷售每日會有許多新群與新消息，這些消息透過Wechaty捕獲，在sales-bot.js中統一存入msg_db，同時進行邏輯判斷，若有新建立的群，則會記錄在room_db內。

接著，update-vika.js 會實時抓取群聊數據與消息數據，計算當日所有活躍群的狀態，並即時顯示在Vika表格上。管理者可透過Vika查看所有群聊狀態、找到問題、並執行一些操作。當售前完成任務，透過Vika改變群聊階段與負責人，並交由管理者審核通過。這些對群聊狀態的改變，將由 vika-update-roomdb.js 檢查是否合法，若合法則更新數據庫，否則會顯示報錯的系統信息。

最後，vika-to-feishu.js 會實時抓取 vika 的群聊數據，負責將不同程度的超時回覆，轉成不同顏色的警示卡片，透過 Lark Puppet 接入飛書，根據嚴重程度推送到私人群或大群，使銷售與管理者掌握回覆的狀態。

若要改變銷售名單，則由開發者改變 default.json ，再執行 update-name.js，即可。若管理者希望改變消息推送的頻率、超時時長與對應的警報，也可以直接修改 default.json 並重啟系統。此外還有系統的諸多配置，也是從這裡修改。

挑戰

重構代碼結構 （非同步讀寫）

從項目結構中不難發現，模塊之間有多種交互。一開始我把所有功能都混在兩份代碼裡，複雜度變得很高，而且難判斷數據是否正確：如果使用者從Vika改動數據，那麼很可能會污染數據庫。所以我嘗試對代碼解耦，依據前端、後端、與數據庫的三個維度拆分各個模塊，最後成為上述的結構。最顯著的優勢是，每份代碼都變得很短。第二個大的優勢是，能看出某段代碼對某類數據，是讀還是寫的關係，這很大地保證了數據的一致性。第三個優勢是，這樣的設計可以為後續的拓展提供明確的指導，例如若我希望增加飛書推送的規則，我可以知道我要寫在哪裡、以及大概怎麼寫。

系統崩潰

在使用 wechaty 企業微信版本時，我在調用 API 後時偶爾會碰到這個 Bug，使得系統崩潰。這個問題很致命，因為當系統崩潰後，sales-bot 就無法收集新的群聊與消息，無法維護消息與房間的正確性。在後面的開發中，我在Vika 上顯示每個群聊與消息的狀態，使管理員可以捕捉到所有群聊的狀態，算是解決上述問題以及其他人為疏失所帶來的數據錯誤。但每日負責上千條消息的 sales-bot 若持續產生錯誤數據，必然會造成很大的人工成本，所以肯定需要有方法保證它能在崩潰後盡快上線。

首先，我先使用 Js 自己的 error catching 方法來捕捉錯誤消息，並在結束程序前從飛書提醒我。

但這還是需要人力來做。一個人不可能隨時看飛書消息，就算看到也不見得能即時重啟。所以接下來我繼續找自動重啟的方法。首先我嘗試使用 forever.js , 但在跑了他的 example 後我短時間沒有試成功。後來我們就嘗試把這份代碼放到 docker 上跑，讓它來自動重啟崩潰的代碼。另外 dockerizing 還帶來了其他的好處，像是提供一個穩定的運行環境，幫助後續的規模化。

# Dockerfile
FROM node:16
WORKDIR /root/bot
COPY . .
RUN npm i --registry=https://registry.npmmirror.com
CMD npm start

在這段 dockerfile 中，我們先將整個項目文件複製到container中，安裝依賴，再運行。但問題是每次都需要重新安裝 npm 包，這個時間非常長，多可以到 7,8 分鐘。

# Dockerfile
FROM node:16
WORKDIR /root/bot
COPY ./package.json ./package.json
COPY ./package-lock.json ./package-lock.json
RUN npm i --registry=https://registry.npmmirror.com
COPY . .
CMD npm start

一個解決的技巧是，先將package.json 與 package-lock.json搬運過去。若這兩份文件沒有改動，亦即沒有新的依賴，那就不需要重新安裝。但即便如此，當安裝了新依賴時仍然要忍受長時間的安裝。有沒有可能讓 node 只安裝多出來的依賴，而非全部呢？這是很值得思考的問題。

三、結果與問題分析

經過問卷與訪談，大部分銷售習慣直接從企業微信上回覆，從飛書接入警報只有少部分的時間幫助他們。另外，因為銷售的底層機制是，當客戶發送消息後開始計時，但當碰到客戶回覆「好的」或「OK」的結束語而銷售沒有回覆時，系統將不斷增加超時時間而不斷報警。因此我們增加了「取消超時」功能，讓管理者或銷售在碰到這種情況時關閉計時。

另外，銷售有時處於專注狀態，這時若要求即時回覆，將很大程度影響專注狀態。所以銷售機器人未來需要能根據狀態，來決定是否要計時。5分鐘警報的原意是，希望客戶發送的每句話都可以比較快地有回音，若需要1小時才能回覆的問題，也可以在5分鐘內先回覆這個狀態。但董森認為，回覆客戶「稍等」這類信息的總效益（客戶獲益-銷售成本）不見得是最高的，考慮到銷售時常是滿載的情況。

有趣的是，售前的董森和售後的榮生，他們每日回覆的消息量都遠超過其他的銷售和售後，也恰好在問卷裡反對過頻繁的提醒。

為何需要這麼快速、高效地回覆客戶？在與市場部的張佳、以及銷售總監祥宇討論後，了解到如果沒有即時回覆，很可能客戶就跑了。但這不只是回復快慢的問題，回覆的內容與策略也很重要。銷售需要判斷一個客戶是否比較可能買單，並把他們排在更高的優先級。另外，過了一段時間（例如7天）沒交流的群需重新跟進。可以看出，售前是非常關鍵與技巧性的銷售環節。這次銷售機器人只關注「回覆時長」，算是跑通一個基礎的框架，爲後續更智能的對話管理做鋪墊。

對於管理者而言，這個項目的意義在於解決一個很痛的點：若管理者希望查看某銷售或某群聊的狀態，需要手動翻找群聊信息，花費大量時間，更不用說能統計出績效了。在Vika上展示了所有群聊最關鍵的信息，像是多久沒回覆，對話上下文、總群聊、群聊階段等等，瞬間有一種打開視野的明亮感。另外從HR的角度，這些沈澱下來的數據，也可以作為定目標與績效的標準。

四、總結

銷售機器人是我的第一份實習工作。在這三個多月中，我根據一開始管理者給我的問題與產品需求，跑通基礎可用的系統，根據各種衍伸的問題不斷迭代，並更深入地了解銷售場景，最後得到一個可投產的基礎版本。這個經驗實在是非常寶貴，很感謝佳芮在去年10月底介紹我這個機會。在與佳芮交流時，能感受到很強烈對目標與產出的專注，以及對產品、業務、技術問題全面的把握。清華是很棒的mentor和朋友，在和他交流問題時，學到很多對bug的判斷與推理，對事項優先級的排序，以及對工具與方法的選擇。康龍作為一個小CEO給我很多的支持，幫助我的項目方向與佳芮的想法可以一致，讓我能更快解決問題；他和我同鄰，卻能一個人做那麼多事，並做得很成熟。思荷在我剛入職的時候給我許多經驗，讓我避掉了許多坑。和翔宇與佳哥討論銷售場景時，時常能有很深入的交流，收穫非常多。最後，在與銷售們交流產品問題時，時常能得到很豐富的反饋。總體而言，在句子互動看到大家很有熱情、很快速地成長，年輕的管理層驅動大家看到問題並不斷蛻變。同時也覺得創業公司的壓力非常大，時常看到同事很晚才下班。句子的技術團隊，很常遇到未知的突發狀況，然後靠大家神經繃緊一起解決。我覺得技術的team心臟真的要很大顆，因為肩上揹負一個巨大的、不斷運轉的系統。這也讓我看到「職場」與「學校」是多麼的不同。在學校只需要把作業提交即可，在職場需要對客戶、以及整套系統負責。這使我對創業公司的拼勁以及 working ethic 非常尊敬，希望未來可以成長成這樣的角色。