將 HubSpot CRM 整合進 Gmail，改變了一個銷售團隊的跟進方式
一位銷售主管使用 Manus 建構了一個自訂工作流,將 HubSpot 的詳細資訊整合到團隊已經在使用的工具中:Gmail 和 Slack。目標很簡單。當潛在客戶寄信給團隊時,銷售代表無需離開收件匣,就能弄清楚對方是誰、該公司是否已經在 HubSpot 中,以及這次對話是否與某個進行中的交易相關。
藉助 Manus,這位銷售主管建構了一個工作流,將合適的 HubSpot 詳細資訊更貼近地呈現在郵件旁。最終完成的系統將 HubSpot、Gmail 和 Slack 整合到一個工作流中。它可以在 HubSpot 中存在相關資訊時為 Gmail 郵件加上標籤,在 Gmail 中顯示有用的客戶資訊,並在企業級線索需要關注時透過 Slack 通知團隊。
專案源自一個日常的銷售難題
該專案始於一個實際的銷售問題:銷售代表在回覆郵件之前應該了解什麼?
例如,如果來自 acme.com 的 Priya 寄信給團隊,銷售代表需要快速了解她是否已經在 HubSpot 中、Acme 是否為目標客戶、是否有進行中的交易,以及誰在負責這層關係。這些訊號決定了回覆應該是快速處理、轉交他人,還是採用其他方式處理。
Manus 幫助將這個問題轉化為一個可用的資料層。HubSpot 已經在聯絡人、公司、交易和所有權記錄中儲存了這些資訊。挑戰在於辨識哪些欄位在回覆時真正重要,並讓它們在 Gmail 中可存取。
這將問題簡化為一組簡單的訊號:誰寄的郵件、他們屬於哪家公司、該公司是否已知、是否有進行中的交易,以及誰擁有該账户。這成為 Gmail 工作流的基礎。
Gmail 中的瀏覽器擴充功能與標籤
一個小的產品決策讓該工作流更易於銷售代表理解。Gmail 標籤並未被用作複雜的評分系統,而是作為一個簡單的訊號。
在這個虛構的模型中,標籤即訊號。當銷售代表點擊它時,瀏覽器擴充功能會開啟,顯示回覆前所需的基本線索或客戶詳細資訊。
例如,如果來自 Acme 的 Priya 寄信給團隊,而 Acme 已經存在於 HubSpot 中,該郵件會被相應地加上標籤。如果寄件者已是客戶,銷售代表可以基於更多账户歷史進行回覆。如果寄件者與某個進行中的企業交易相關,銷售代表可以優先處理回覆。如果寄件者所屬公司沒有負責人,團隊可能需要在回覆前分配負責人。
郵件被加上標籤後,銷售代表可以點擊標籤,在收件匣內開啟擴充功能並查看相關的 HubSpot 詳細資訊。
Slack 幫助團隊對重要線索採取行動
Gmail 幫助個別銷售代表以更充分的資訊進行回覆。Slack 則幫助團隊在重要線索需要關注時進行協作。
在這個工作流中,Manus 建構了一個 Slack 機器人,用於針對 HubSpot 中的企業入站線索傳送 Slack 通知。Slack 訊息可以告知團隊某家高匹配度的公司已主動聯繫,包含公司名稱、顯示可能的負責人,並引導大家回到相關的郵件對話或記錄。
例如,如果某個企業潛在客戶從目標账户寄來郵件,且尚未分配負責人,Slack 可以提醒團隊。這樣可以讓該線索對整個團隊可見,而不是被埋沒在某個人的收件匣中。
Slack 讓相同的潛在客戶資訊對更廣泛的團隊可見。高匹配度的潛在客戶可以在被遺漏之前被看到、分配並跟進。
其他團隊能從這個流程中學到什麼
該專案之所以成功,是因為 HubSpot、Gmail 和 Slack 被視為獨立的層。每一層都被單獨建構、獨立測試,然後組合成一個適合團隊現有銷售流程的工作流。
第一層是 HubSpot 資料模型。團隊必須確定在跟進時哪些欄位是真正有用的,例如聯絡人身分、公司匹配、負責人、交易狀態、潛在客戶來源、計劃和下一步。Manus 被用於辨識有價值的 HubSpot 欄位,並建立一個工作流其餘部分可以使用的同步資料庫
第二層取決於存取權限。在本案例中,團隊使用的是 Google Workspace,因此 Gmail 授權可以透過 Google auth 完成。這一點很重要,因為工作流需要權限來讀取郵件、將寄件者與從 HubSpot 衍生的資料庫進行比對,並根據自訂規則套用標籤。然後使用 Manus 根據這些規則自動為郵件加上標籤。
第三層是面向 Gmail 的體驗。在標籤生效後,Manus 被用於建構瀏覽器擴充功能,該擴充功能會顯示 HubSpot 風格的圖示,並在 Gmail 內載入相關的潛在客戶或客戶詳情。同一次建構還需要支援元件:主機外掛、登入網站和使用者授權流程。這些工作在 Manus 中作為獨立的一層處理,然後再與系統的其餘部分組合。
對其他團隊的實用建構建議是,先檢查存取權限層級,然後定義最低限度的有用欄位,測試標籤邏輯,再建構可見的介面。如果缺少任何一層,這種體驗對銷售代表來說要麼不可靠,要麼對團隊來說太難採用。
