Grok Bot Galaxy 第三天（第 4/40 段）

🧑‍🏫 這支影片在示範怎麼用 Grokbot 組一支「AI 小團隊」，幫你處理日常工作。第一個例子是讓 bot 自動看收件匣、整理待辦，再分派給其他 bot；第二個例子是讓 bot 從規劃到寫程式，做出一個業務審核名單用的 app。如果你每天被訊息淹沒，或想用 AI 做小工具卻怕指令下不好，這支很值得看。

• 35:39 講者自稱生產力狂熱者，五年多來一直在打造自己的工作系統；在 RevOps、MarOps 這類職位，很多工作其實是利害關係人管理
  ↳ 講者花了五年多打磨自己的工作方法。他做的是 RevOps／MarOps，也就是管業務和行銷流程、工具的營運職。這類工作很多時間在做 stakeholder management，意思是跟各方相關的人協調溝通。
• 35:39 痛點：訊息從很多地方湧入，很難理清頭緒，也難判斷哪些才是真正的高優先事項
  ↳ 訊息從 email、行事曆、聊天工具四面八方湧進來。真正難的不是訊息多，而是分不清哪件事現在就得做、哪件可以晚點再處理。
• 35:39 用 Grokbot 可以設定 bot 監看所有收件匣，判斷訊息與行事曆項目哪些是真正的任務，哪些只是 FYI 或可以放心忽略
  ↳ Grokbot 是影片示範的 bot 工具。可以讓 bot 幫你盯所有收件匣，分出「真的要做的事」和 FYI。FYI 是「僅供參考」的意思，這類訊息看過就好，可以直接略過。
• 36:10 示範一：Fisher 是接入所有收件匣的執行助理（receiver agent），當天上午 9:04 完成了它的例行程序
  ↳ 第一個示範：Fisher 是 receiver agent，也就是專門負責收訊的 AI 助理。agent 指的是能自己動手做事的 AI。Fisher 當天早上 9:04 已經自動跑完例行檢查。
• 36:46 Fisher 會依排程例行檢查所有收件匣、挑出新內容，並主動傳訊給幕僚長 agent OP1，彙報 email、行事曆、工作聊天的所有資訊
  ↳ Fisher 會在固定時間把收件匣巡一遍，只挑新進來的內容，整理好後主動回報給 OP1。OP1 是 chief of staff agent，角色像幕僚長，負責接手後續的分派。
• 37:17 講者說甚至可以關掉 Slack 和 email 通知，交給 bot 在背景監看並把最重要的事提報上來，大幅減少 context switching
  ↳ 講者甚至把 Slack（工作用的聊天軟體）和 email 的通知關掉，交給 bot 在背景盯著。這樣就少了 context switching，也就是一直被打斷、切換工作所消耗的腦力。
• 37:47 這樣比較能進入專注模式，工作也更開心；幕僚長 OP1 會把 Fisher 給的資訊拆解成實際的任務與子任務
  ↳ 少了打斷，人比較能專心，也做得比較開心。OP1 拿到 Fisher 的彙報後，會把「誰傳了什麼訊息」轉成具體的待辦事項，再拆成細項步驟。
• 38:17 有些訊息不必處理；有些要處理，但光讀訊息看不懂狀況。bot 會讀完整段 Slack 對話，歸納出對方真正想要什麼
  ↳ 有些訊息看完就好；有些要處理，但只看一句話搞不懂狀況。bot 會把整串 Slack 對話讀完，幫你抓出對方真正想要的是什麼。
• 38:52 「自動完成的任務清單」：Fisher 和 OP1 合作找出任務，OP1 發現一件 territory dispute（幾位 AE 在爭誰該負責某個客戶）
  ↳ 結果是一份 bot 自己整理好的待辦清單。其中 OP1 抓到一件 territory dispute：幾位 AE（負責談成交易的業務）在爭某個客戶該歸誰負責。
• 38:52 OP1 可以把這個任務轉交給另一個 territory planning bot，並附上事情的來龍去脈
  ↳ OP1 不自己處理這件事，而是轉給專門管業務區域規劃的 bot，並把前因後果一起交代過去，對方不用從頭問一遍。
• 39:23 territory planner bot 掌握 rules of engagement、各 territory 的劃分方式和 CRM 的完整脈絡，能產出不錯的第一版交付成果
  ↳ 這個 bot 知道公司的 rules of engagement，也就是客戶該歸誰的規則，也清楚區域怎麼劃分，還看得到 CRM（存客戶和名單資料的系統），所以能先交出像樣的第一版。
• 39:23 講者不必自己想怎麼處理這場爭議，但仍然可以進來檢查成果是否合理
  ↳ 講者不用自己從零想這場爭議怎麼解決，但決定權還是在他手上。他可以進去看 bot 的建議合不合理，再做決定。
• 40:02 整體就像一個團隊：監看收件匣、拆解任務、轉交給適合的隊友完成，講者只負責監督整個流程並做最後定案
  ↳ 整體就像一支小團隊：有人收信、有人拆任務、有人做專業的事。講者從親自動手的人變成主管，只負責看流程順不順，最後拍板定案。
• 40:02 示範二：打造 xAI 內部使用的「名單交友 app」（講者說是 a dating app for leads）
  ↳ 第二個示範是做一個 xAI 公司內部用的 app。講者開玩笑說它是「名單的交友軟體」，因為操作方式跟交友軟體一樣是左滑、右滑。
• 40:39 marketing sales handoff 是企業的經典問題：行銷產出一堆名單，業務不喜歡、不想跟進，名單放到過期；也缺少讓行銷調整鎖定對象的回饋循環
  ↳ marketing sales handoff 指的是行銷把 lead（潛在客戶名單）交給業務的那段交接。常見狀況是業務嫌名單不好、放到過期，行銷又沒有 feedback loop（回饋機制）可以知道要怎麼改。
• 41:13 app 設計：每位 AE 登入後只看到自己名下的名單；左滑結束名單時必須填具體的結束原因，送出後會正確寫回 CRM
  ↳ 每位 AE 登入後，只會看到自己負責的名單。往左滑代表「不追了」，但一定要選原因，送出後資料會正確寫回 CRM，不會只留在 app 裡。
• 41:13 右滑可以把該名單直接加入後續的 follow-up sequence
  ↳ 往右滑代表「要追」，這筆名單會直接排進 follow-up sequence，也就是事先設定好的一連串追蹤信件或聯絡步驟。
• 41:47 RevOps／MarOps 的角色因此轉變：不再只是盯業務遵守 SLA、轉述零散的名單回饋，而是替團隊「設計一場遊戲」
  ↳ 以前 RevOps 像糾察隊，要盯業務有沒有遵守 SLA（事先約定好的服務標準），再把零散的回饋轉給行銷。現在的角色變成設計一套讓大家願意主動參與的流程。
• 41:47 從名單被結束的原因取得有價值的資訊，並用程式化的方式回饋給行銷團隊，改善鎖定對象，讓業務拿到更多想要的名單
  ↳ 每次左滑都會留下原因，累積起來就是有用的資料，而且能自動整理給行銷。行銷據此調整要找哪類客戶，業務也就拿到更多自己想要的名單。
• 42:21 目標是讓業務覺得有趣，願意每天把名單清到 inbox zero
  ↳ 目標是讓審名單變得像滑手機一樣有趣，讓業務每天都願意把名單清到 inbox zero，也就是待處理的數量歸零。
• 42:21 做法：告訴 product manager bot 要做一個內部 app 讓業務審核名單，說明大致機制和額外需求，並強調一開始就要把跟 CRM 的 auth flow 做好
  ↳ 做法是跟 product manager bot（扮演產品經理、負責規劃需求的 bot）說明想法和大致機制，並特別強調要先把跟 CRM 的 auth flow（登入授權的連線流程）做好。
• 42:54 關鍵需求：業務登入後能看到自己名下的名單，資訊也要正確寫回 CRM
  ↳ 最關鍵的有兩點：業務登入後看到的是自己名下的名單，而且在 app 裡做的操作要正確寫回 CRM。這兩點沒做好，這個 app 就沒有用。
• 42:54 product manager bot 名叫 Juno，是很好的 thought partner；以往的 AI 工具急著討好，會直接開始寫程式
  ↳ 這個 bot 叫 Juno，講者說它是很好的 thought partner，也就是能陪你一起把點子想清楚的討論對象。以前的 AI 工具急著討好，一聽到需求就直接開始寫程式。
• 43:29 舊 AI 的問題：成品可能跟想像不符、太受第一個 prompt 牽制，讓人害怕 prompt 沒寫好
  ↳ 舊做法的問題是成品常常跟腦中想的不一樣，而且整個結果被第一句 prompt（你下給 AI 的指令）綁死，讓人很怕一開始沒講清楚。
• 43:29 Grokbot 會先停一下、問很好的追問，問到講者一開始沒想到的地方，可以一問一答地進行
  ↳ Grokbot 會先停下來追問，而且問到講者一開始沒想到的細節。你只要一題一題回答就好，不必一開始就把需求寫得很完美。
• 44:04 回答範例：只顯示新名單、不加其他篩選條件
  ↳ 舉例來說，被問到要顯示哪些名單時，講者回答只顯示新名單，不需要其他篩選條件。
• 44:04 被問到「名單被接受時 CRM 要改什麼」：講者回答不改任何欄位，因為名單狀態真正改變的時間點是業務主動聯繫的時候
  ↳ Juno 問：業務右滑接受名單時，CRM 要改哪些欄位？講者回答都不改，因為名單狀態要等業務真的去聯絡客戶，才算真正改變。
• 44:43 公司已經有自動化會追蹤聯繫活動並更新 lead status；Grokbot 的追問逼使用者更深入思考自己的點子，而不是無腦回答
  ↳ 公司本來就有自動化機制，會追蹤聯絡紀錄並更新 lead status（名單目前的進度狀態）。這種追問逼人把流程想清楚，不會隨口回答「好」就帶過。
• 44:43 其他回答：結束時要填原因加選填備註（reason and optional notes）；離線操作選擇先排入佇列、確認後才算完成
  ↳ 其他回答：左滑時一定要填原因，備註則可選填；如果操作時沒有網路，動作會先排隊等著，確認送出成功後才算完成。
• 45:20 另一個選項選了 local only；接著 product manager bot 會產出產品規格（spec）
  ↳ 另外一題講者選了 local only（字面意思是「只在本機」）。問完所有問題後，Juno 會產出 spec，也就是產品規格書，寫清楚要做什麼、怎麼運作。
• 45:58 Juno 寫完 spec 後，會主動交給工程 bot Ondes 開始建置，講者不用另外下 prompt 叫它交接
  ↳ Juno 寫完規格後，會自己把工作交給工程 bot Ondes 開始做，講者不需要再下指令叫它們交接。
• 45:58 講者指出，用一般 AI 工具時，就算拿到好的產出，也得自己把它搬進下一個系統
  ↳ 講者點出一般 AI 工具的麻煩：就算 AI 給了很好的答案，你還是得自己複製貼上，搬到下一個工具或系統繼續做。
• 46:30 這裡可以把它看成一個替你從頭到尾把事做完的團隊；Ondes 收到 spec 後就開始工作
  ↳ 這裡的差別在於，你面對的是一整支會自己接力的團隊，從想需求到動手做全部串在一起。Ondes 一拿到規格就直接開工。
• 47:04 成品展示用的是假資料，是講者用 Grokbot 做出的真實介面 mockup；很多業務現在每天用它把待審名單清到零
  ↳ 影片畫面是 mockup（用假資料做的示範畫面），但介面真的是用 Grokbot 做出來的。講者說現在很多業務每天用它把待審名單清到零。
• 47:04 卡片上一眼就能看到名單的各項資訊，把卡片往左推就能結束該名單
  ↳ 每張卡片上一眼就能看到這筆名單的重點資訊，不想追的話，把卡片往左推，就能結束這筆名單。

在示範中，講者被問到「名單被接受時 CRM 要改什麼」，他怎麼回答？