Grok Bot 官方案例：自家銷售團隊把報價與審核交給共享代理

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Grok Bot 的開發方 SpaceXSI 在 2026 年 10 月 27 日做了一件少見的事：把自家銷售團隊怎麼用 AI 代理的完整做法，寫成文章放在 x.ai 官網上。三個共享代理（Shared Bots）分別接手客戶研究、報價準備與非標準條款審查，串起 Salesforce、通話紀錄工具 Gong、報價系統 CPQ 與合約平台 Ironclad。這份案例真正值得細讀的地方有兩個：官方怎麼畫「代理能做什麼、不能做什麼」的那幾條線，以及整份文件刻意不碰的東西，任何一個效益數字。

Pin

開發方先拿自己的銷售團隊當展示場

先交代時空背景。10 月 27 日，x.ai 新聞頁刊出文章《Your next sales teammate should be a Grok Bot》，署名 Iris Wang、Joe Robertson、Micheal Sihavong 與 Palmi Angelova 四位作者。同一天，Grok Bot 官方帳號 @bot 在 X 上發文宣傳，這則貼文的時間戳換算成台北時間是 10 月 28 日凌晨 1 點 17 分。

案例的主角是 SpaceXSI 自己的業務團隊。SpaceXSI 是 Grok 與 Grok Bot 背後的公司，x.ai 頁尾的正式署名是 SpaceX Super Intelligence LLC。換句話說，這不是付費客戶的見證，而是開發方拿自己的組織當參考實作，把內部怎麼部署代理攤給外界看。對照 TechMoon 先前追過的 Grok Bot 軌跡會更清楚：x.ai/bot/guides 曾連發九篇官方指南、頁面署名還是 SpaceXAI 的時期，那次的主題是一個人怎麼管理一群代理；之後 Grok Bot 經歷提速與連接器更新，模型線上 Grok 4.7 也在 9 月下旬發布，一路走到這次把整個銷售部門搬上檯面。委派的單位從個人變成團隊，這是這份案例在產品演進上的位置。

先分清楚「共享」兩個字在這裡的意思。案例寫得明白：業務團隊一開始是每個業務自己建代理，做客戶研究、開會前準備、管理自己手上的交易進度。這樣能解決個人的問題，但每個人累積的設定不一樣，流程一改，大家要各自重調，好的做法也散在不同人的代理裡。於是團隊換了組織方式：把某個職務最常用的規則與知識整理成同一份設定，讓全隊使用同一個代理，而維護它的是最懂這份工作的那一批人。流程改變時，維護者改一次，所有使用者同步拿到更新後的做法，不必再各自調整。

還有一個容易被讀漏的細節：共享代理不等於共用對話。官方描述裡，每位業務跟同一個共享代理之間是私人對話，代理取用共同的業務知識，但以該使用者本人的權限行動。你的對話不會攤給全隊看，你沒有的權限也不會因為代理是共用就憑空出現。「共用的是頭腦與規則，不是身分與鑰匙」，這句話可以概括這個設計。

知識怎麼進到代理裡，官方也有交代：透過共享技能（shared skills）與內部真相來源的連接，讓所有代理用到同一份最新的規則，而不是各憑各的記憶。這個說法背後的工程假設值得注意：代理的可靠性建立在「內部文件本身夠新、夠清楚」上，文件品質就是上限，代理只是執行者。

三個代理怎麼分工：從通話紀錄一路接到合約文件

三個共享代理各守交易週期的一段，合起來剛好覆蓋從找客戶到簽約的流程。

Pin

Account Intel Bot 負責客戶研究與會後整理。有趣的是它的工作項目是怎麼選出來的：SpaceXSI 的 GTM 工程團隊先讓 Grok Bot 分析 Salesforce 的活動紀錄，找出最值得自動化的工作，結果發現業務在客戶通話後花很多時間更新商機資料。團隊於是給代理工具做這些更新，並教它何時、如何更新的內部規則。先看紀錄再決定自動化什麼，而不是憑感覺挑功能，這個順序本身就值得抄。

它也能主動出擊。開會前，Account Intel 可以依帳戶歷史準備簡報；會議結束後，讀 Gong 的通話逐字稿，找出必要的 Salesforce 更新並處理，再草擬一封跟進郵件交給業務過目。業務還能把這些流程排程自動執行，讓準備與收尾工作不用每次重新下指令。注意官方的措辭是草擬給業務審閱：面向客戶的文字目前一律要人看過，這條線在下一節還會出現。

Quote Bot 接手報價。業務可以要求它準備多種產品組合與折扣並陳的方案，代理把報價輸入 Salesforce，在 Grok Bot 的對話介面裡並排呈現，業務在同一個畫面比較選項，不必自己鑽進 CPQ 工具。報價確定後，Quote Bot 提交審核、追蹤狀態，需要例外處理就轉給 Deal Bot；通過之後它能在 Ironclad 產生訂單文件、下載可執行的合約，並草擬寄給客戶的郵件。官方對這段流程的價值總結是：業務可以在一個對話裡完成大部分工作，不用在多個系統之間切換、等其他團隊回覆。控制點也寫得明白：改動 Salesforce 之前，Quote Bot 會先呈現預覽，請業務確認後才動手。

Deal Bot 支援的是 Deal Desk 團隊，也就是審查例外、決定公司願意接受哪些交易條件與風險的單位。Quote Bot 遇到特殊價格或非標準條款時把工作交給它，它對照公司已同意的政策與合約文字，準備讓交易往前走的修改建議；也會整理業務從 Slack 提交的需求，把請求轉給對的跨部門負責人，並查法務是否已經起草過類似條款。需要人類判斷的決策，它準備好建議後請 Deal Desk 專員點頭才繼續，大部分例行的整理與路由工作自己消化。

代理能做什麼、不能做什麼，官方畫了三條線

這份案例最值得搬走的部分，是它的治理骨架。官方連問題都先定義好：代理要接下服務整個團隊的職務，就得對三件事做仔細的決定，代理該知道什麼、能做什麼、什麼時候需要人介入。文章接著把答案攤開，整理起來是三條線。

Pin

第一條線是權限跟著人走。每個共享代理以使用者本人的權限行動，敏感動作再疊加額外限制。你有權查看某個客戶，代理才看得到；你不該有的管理權限，不會因為透過共享代理做事而出現。這條線把「機器做事」與「權限膨脹」脫鉤，代理再勤勞，它能碰的東西就是使用者本人能碰的東西。

第二條線是動作範圍。團隊設了頻率限制，避免代理一次性造成大規模的非預期變更；特定動作保留給專責代理，誰也不能越界。官方給的例子很直白：業務不能用 Quote Bot 同意自己的折扣。需要 Deal Desk 層級權限的審查與例外，一律留在 Deal Desk。有意思的是 Deal Bot 的定位反過來讀也成立：它持有業務沒有的 Deal Desk 權限，可以直接處理需要該團隊權限的報價變更。這是「服務代理的權限比使用者高」的公開範例，配套措施是它對需要人類判斷的決策只能準備建議、請專員確認後才繼續。一個代理權限較低、另一個較高，中間靠「動作保留給專責角色」接起來，這比單純說「AI 有權限限制」精確得多。

第三條線是人工判斷。官方原文直接引錄：「For now, we require human review whenever we can’t clearly define the criteria for a decision, or when a shared Bot prepares customer-facing communications.」翻成白話就是兩個觸發條件：規則寫不出來的決定不交給代理；要寄給客戶的東西一定要人看過。前者承認模型的極限，後者守住對外的臉面。官方也說，隨著他們衡量代理產出的品質、對決策建立信心，預期會給共享代理更多責任，但這是預期，不是取消人工審核的承諾。

三條線之外還有一個容易被忽略的設計：問責戳記。每一筆經 Deal Bot 處理的 Salesforce 審核，系統裡都會蓋上三樣東西：這次的決定、決定的理由，以及它支援的負責人（官方用的縮寫是 DRI，directly responsible individual）。代理做的決定越多，這種能回頭查「誰做了什麼、為什麼」的紀錄就越重要。工作可以委派，責任不會因為委派而消失，戳記是把責任釘在流程裡的具體做法。

整份案例沒有任何效益數字

對照一般供應商的 AI 導入案例，這份文件有個罕見的空白：全文沒有任何時間節省、營收或正確率的數字。官方沒有說業務每週省下幾小時，沒有說交易週期縮短多少，也沒有說代理更新客戶資料的正確率多高。想把這份案例拿去說服自己公司「導入就會省錢」的人，在文件裡找不到任何彈藥；反過來說，官方選擇只講設計不講戰果，也讓這份案例更像內部文件的公開，而不是行銷素材。

官方的姿態也相對收斂。文章自述還在早期階段（We’re still early in building out this system），三個共享代理之外還有 Competitive Intel Bot 負責維護競爭情報、Sales Training Bot 支援新人訓練與技能發展，整個業務部門還有更多個人代理在不同人手上使用。未來的方向寫得客氣：共享代理會承擔更多責任、彼此之間協調更多工作，最終畫像是人專注在客戶與需要判斷力的決策上，由最懂每份工作的人建造並維護的專責代理，接手支援性的大部分工作。要提醒的是，這篇文章是公司對自身流程的單方說明，沒有第三方驗證，其他團隊能不能複製，得用自己的工具與業務規則重新檢驗。

想跟著做的團隊，先回答三個問題

如果讀者想把這套做法搬進自己的團隊，與其問哪個代理好用，不如先對著那三條線檢查自己的流程。

你打算交出去的工作，判斷條件寫得出來嗎？Account Intel 更新商機欄位能運作，是因為何時更新、如何更新有內部規則可教。自己流程裡那些「看情況」「憑經驗」的決定，就是官方定義裡必須留給人的部分，交出去之前得先把規則寫清楚，寫不清楚的就繼續留著。對外溝通誰簽核？案例裡從跟進郵件、報價確認到訂單文件產生，每一步都經過人看過或確認，這條線畫得比多數公司的現況保守，也代表官方自己對生成文字的信任還沒到全自動的程度。審核紀錄留了什麼？如果現在的 CRM 操作查不到決定與理由，加上代理只會讓黑箱更大，問責戳記該在代理上線前就設計好。

台灣團隊還多一層資料面的考量。這套流程把通話逐字稿、客戶資料與合約內容餵給代理，對應到本地的個資法與客戶同意條款，錄音能不能進代理、逐字稿能保留多久，都要先過自己的法務這關。最後是供應條件：這份案例沒有觸及 Grok Bot 的定價、供應地區與企業方案細節，x.ai 頁面上只有免費試用、下載 macOS 版與聯絡銷售團隊的入口，台灣能不能用、要多少成本，案例裡沒有答案，動手前得自己向官方確認。

這篇案例的價值不在展示代理多能幹，而在示範一個組織怎麼有紀律地把工作交出去：先畫權限，再限動作範圍，對外與難以定義的決定留給人，然後每一筆都留下能回頭查的紀錄。這套骨架不挑工具，哪天換成別家的代理也照樣適用。後續值得回頭看的時間點有兩個：SpaceXSI 什麼時候公布效益數字，以及人工審核的範圍什麼時候第一次縮小，那會是比任何宣傳稿都誠實的進度指標。