3

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

 2 years ago
source link: https://wechaty.js.org/2022/02/10/sales-assistant-final/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

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

一、已实现功能说明

總配置流程

  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分钟
1.webp

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

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

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

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

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

  1. 在今日群聊-总表内，可看到今日活跃群
  2. 对于超时回复的消息，可看到最后一句对话。可查看【最后说话者】、【最后一句话】，视情况勾选【消除未恢复记录】，以取消报警提示
  • 例如：看到超时88 分钟的群聊，且客户回复‘好的’，可勾选【消除未恢复记录】
2-2.1
  1. 等待1分钟内，系统将显示【已消除未回覆记录】，超时时间归零，飞书将中断推送该群超时提醒
2-2.2
  1. 可在末尾的参数处，查看该群的各种指标。公式为：总回复数= （售前+售后+顾客+其他员工） 的回复数
2-2.3

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

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

image-20220212000332848
image-20220212000104323

我們將系統解構成前端、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 並重啟系統。此外還有系統的諸多配置，也是從這裡修改。

image-20220212011240626

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

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

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

crash

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

image-20220211115312363

但這還是需要人力來做。一個人不可能隨時看飛書消息，就算看到也不見得能即時重啟。所以接下來我繼續找自動重啟的方法。首先我嘗試使用 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 非常尊敬，希望未來可以成長成這樣的角色。


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK