# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Manus (@ManusAI) · 平台：X (Twitter) · 日期：2026-06-04

> 原始來源：https://x.com/ManusAI/status/2062186859036631246

## 中文摘要

# 透過 HubSpot 驅動的 CRM 整合 Gmail，徹底改變銷售團隊的跟進方式

一位銷售主管利用 Manus 建立了一個自訂工作流程，將 HubSpot 的詳細資訊整合到團隊日常工作的環境中：Gmail 與 Slack。

目標很單純。當潛在客戶寄信給團隊時，業務代表不需要離開收件匣，就能知道對方是誰、該公司是否已存在於 HubSpot 中，或是這場對話是否與現有的待處理專案有關。

透過 Manus，這位銷售主管建立了一個工作流程，將正確的 HubSpot 詳細資訊直接呈現在郵件旁。這套完成後的系統將 HubSpot、Gmail 與 Slack 串聯成單一工作流程。它能在 HubSpot 存在相關資訊時為 Gmail 郵件加上標籤，在 Gmail 內顯示實用的帳戶資訊，並在企業級潛在客戶需要關注時，透過 Slack 通知團隊。

## 專案始於一個日常的銷售難題

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780540778766-iaHJ4TuL0b0AApuPgjpg.jpg)

這個專案源自一個實際的銷售問題：業務代表在回覆郵件前，應該要掌握哪些資訊？

舉例來說，如果來自 acme.com 的 Priya 寄信給團隊，業務代表需要快速了解她是否已存在於 HubSpot 中、Acme 是否為目標帳戶、是否有待處理的專案，以及誰負責維護這層關係。這些訊號決定了回覆的速度、是否需要轉派，或是採取不同的處理方式。

Manus 協助將這個問題轉化為可用的資料層。HubSpot 本身就儲存了跨聯絡人、公司、專案與負責人紀錄的資訊。挑戰在於辨識出哪些欄位在回覆當下真正重要，並讓這些資訊能在 Gmail 內被存取。

這將問題簡化為一組簡單的訊號：誰寄了這封郵件、他們屬於哪家公司、該公司是否已知、是否有進行中的專案，以及誰是該帳戶的負責人。這成為了 Gmail 工作流程的基礎。

## Gmail 中的瀏覽器擴充功能與標籤

一個小小的產品決策，讓業務代表更容易理解這個工作流程。Gmail 標籤並非作為複雜的評分系統使用，而是作為一個簡單的訊號。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780540778736-iaHJ4TwiybkAAjFGajpg.jpg)

在這個虛擬的模擬圖中，標籤就是訊號。當業務代表點擊它時，瀏覽器擴充功能會開啟，顯示回覆前所需的基礎潛在客戶或客戶詳細資訊。

舉例來說，如果來自 Acme 的 Priya 寄信給團隊，且 Acme 已存在於 HubSpot 中，該郵件就會被貼上相應標籤。如果寄件者已經是客戶，業務代表可能會在回覆中加入更多帳戶歷史紀錄。如果寄件者與某個進行中的企業專案有關，業務代表可能會優先處理該郵件。如果寄件者所屬的公司沒有負責人，團隊可能需要在回覆前指派人員。

一旦郵件被貼上標籤，銷售代表就能點擊標籤，並在收件匣內開啟顯示相關 HubSpot 詳細資訊的擴充功能。

## Slack 協助團隊針對重要潛在客戶採取行動

Gmail 協助業務代表以更充足的資訊進行回覆，而 Slack 則協助團隊在重要潛在客戶需要關注時進行協調。

在這個工作流程中，Manus 建立了一個 Slack bot，針對來自 HubSpot 的企業級潛在客戶發送 Slack 通知。Slack 訊息可以告知團隊有高潛力的公司聯繫了我們，並包含公司名稱、顯示可能的負責人，並引導人員回到郵件串或相關紀錄。

舉例來說，如果企業級潛在客戶從目標帳戶寄信過來，且尚未指派負責人，Slack 就能提醒團隊。這讓潛在客戶對整個團隊而言是可見的，而不是被埋沒在某個人的收件匣中。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780540778887-iaHJ4TzURbYAAfFdjjpg.jpg)

Slack 讓整個團隊都能看見相同的潛在客戶資訊。高潛力的潛在客戶在遺漏之前，就能被看見、指派並進行跟進。

## 其他團隊能從這個過程中學到什麼

這個專案之所以成功，是因為將 HubSpot、Gmail 與 Slack 視為獨立的層級來處理。每一層都是獨立建置、單獨測試，最後再組合成符合團隊現有銷售運作模式的工作流程。

第一層是 HubSpot 資料模型。團隊必須決定哪些欄位在跟進當下是真正有用的，例如聯絡人身分、公司匹配、負責人、專案狀態、潛在客戶來源、方案與下一步。Manus 被用來識別有價值的 HubSpot 欄位，並建立一個工作流程其餘部分可以使用的同步資料庫。

第二層取決於存取權限。在這個案例中，團隊使用 Google Workspace，因此 Gmail 授權可以透過 Google auth 進行。接著使用 Manus 根據這些規則自動標記郵件。

第三層是面向 Gmail 的體驗。在標籤功能運作後，Manus 被用來建置瀏覽器擴充功能，在 Gmail 內顯示 HubSpot 風格的圖示並載入相關的潛在客戶或客戶詳細資訊。同樣的建置也需要支援組件：host plugins、登入網站以及使用者授權流程。這些工作在 Manus 中被視為獨立層級處理，最後再與系統的其他部分整合。

給其他團隊的實務建置建議是：從檢查存取層級開始，接著定義最少量的實用欄位，測試標籤邏輯，最後再建置可視化介面。如果缺少任何一層，對業務代表來說，體驗就會變得不可靠，或者對團隊來說太難以採用。

## 試用 Connectors

立即試用 Connectors，並透過 Manus 可直接存取的資料層，為你的建置工作注入強大動力。

## 標籤

Agent, 自動化, 其他, Manus, HubSpot, Slack
