接上你的工具
把 HubSpot 接給 AI 代理
CRM 會過時，不是因為它設計得差：而是因為填寫它是沒人願意做的活兒。 一個接到 HubSpot 的代理讀取並更新紀錄、活動、檔案與行銷內容——透過 HubSpot 的官方介面，而且嚴格限於接入它的那位使用者的權限之內。讓這件事變得可治理的，正是最後這一點。
1. 代理在 HubSpot 裡做的事
連接器走的是 HubSpot 的官方伺服器，這就保證了範圍遵循 HubSpot 的規則，而不是我們的規則。
- 紀錄。 讀取並更新聯絡人、公司與案子——變過的地址、離職的窗口、案子實際推進到的階段。
- 活動。 記下發生了什麼：那通電話、那次催辦、收到的答覆。這是永遠缺席的一部分，因為它是事後才補的。
- 檔案與行銷內容。 找回一份資料，查看或備好掛在 HubSpot 上的內容。
2. 代理繼承您的權限，絕不更多
這是核心的機制，值得在接入之前弄明白。
接入是以其權限必須被遵守的那個 HubSpot 使用者來完成的。因此代理沒有自己的權限：它以這個人的權限行事。這個帳號看不到某條管線，代理也看不到。這個帳號不能刪除，代理也不能。
實際的後果是令人愉快的：您沒有新的權限體系要學。 您透過選擇用哪個 HubSpot 使用者接入，來決定一個代理的範圍——常見做法是建一個權限刻意收窄的專用使用者。團隊裡的每個人也可以接自己的帳號，只授予自己的權限。
接入此外還要求點明所涉的入口與物件類型：代理從不籠統地「接到 HubSpot」。
3. 什麼仍留在核可之下
HubSpot 被歸入分量較重的連接器，預設設定也反映了這一點：凡是寫入或刪除的動作，執行前都要人工同意——除非您明確放寬。
實際上，多數團隊最後會在更新一筆紀錄或補記一次活動上放寬——風險小而每天都有得益——並在有拘束力的事情上保留核可：改動案子階段、改動金額、刪除。這是個穩妥的取捨，而且是一個動作一個動作地設定，不是一刀切。
和往常一樣，每個代理的花費在呼叫模型之前就已封頂：額度用盡，呼叫就不會發生。
4. 時間久了會有什麼變化
在 CRM 上，第一個月證明不了什麼。見分曉的是第十二週。
- 第 1 週。 最近碰過的紀錄被補齊，缺漏的活動被記下。CRM 所說的和實際發生的之間的落差，開始縮小。
- 第 3 個月。 管線映出現實。這是頭一回可以靠著它來做決定，而不是「去問跟這單的人」。
- 第 2 年。 歷程變成了資料：哪些案子在推進，哪些睡著了，哪些跟進有結果。這些在一個填了一半的 CRM 裡，一樣也讀不出來。
不承諾任何數字化的收益。可以確定的是，一個被維護住的 CRM 勝過一個功能繁多的 CRM——這是另文展開的主題。
5. 常見問題
要不要建一個 HubSpot 應用程式？
認證用的應用程式只為 nullbot 建一次；之後每個人在接入時選擇自己的 HubSpot 帳號並授予自己的權限。因此沒有需要按使用者重做的設定工作。
代理能在我不知情的時候改動一筆交易嗎？
預設不能：寫入與刪除的動作在執行前都要人工核可。而且即便在無害的動作上放寬了這道核可，一切仍留有痕跡——在 nullbot 的紀錄裡，也在 HubSpot 自己的歷程裡，後者會自行記下誰改了什麼。
能把一個代理限制在單一管線裡嗎？
可以，而且有兩條互相疊加的路：接入要求點明入口與物件類型，而代理所連的那個 HubSpot 使用者本身也帶著自己的限制。建一個權限刻意收窄的專用 HubSpot 使用者，是最簡單也最好讀的辦法。
如果我們用的是別的 CRM 呢？
Pipedrive、Close、Attio 與 Folk 同樣在型錄裡；若您一個 CRM 也沒有，nullbot 自帶一個。道理不變：代理在您這邊作為基準的那個工具裡工作，而不是另建一個終將同樣過時的並行資料庫。
延伸閱讀
接著讀：由代理維護的 CRM、接入 Stripe，或全部可用的連接器。