柳溪動物醫院只有一位獸醫師，大部分時間都在手術室裡，櫃檯則忙著應付眼前的 來客。他們的 AI 智慧體櫃檯負責回答網頁線上聊天，也接聽電話。當普莉婭寫下 「可以請艾利斯醫師回電談貝拉的用藥嗎？」，醫院想要當下就知道——趁普莉婭 還在網站上、還沒轉身去找別家醫院的時候，而不是聊天結束半小時之後。
Live 就是為此而存在的。它一次開在一個 對話洞察 的一個是／否欄位上。智慧體接著就會在對話進行中標記請求，那個欄位的標籤上 掛著的提醒工作流程，幾秒內就會執行。你沒有打開的每個欄位，都照原本的方式 運作，分毫不差。
它背後的是／否欄位
對話洞察是一份簡短的問題清單，AI 會就每一段對話逐一回答。每個問題就是一個 欄位，每個欄位有一個類型：是／否、列舉（從你寫好的一組值裡 選一個）、文字或數字。
是／否欄位問的是一個只有兩種答案的問題。柳溪的對話洞察櫃檯跟進裡 有一個叫要求回電的欄位，它的擷取指引寫著什麼時候答案是「是」： 「客戶要求獸醫師或醫院回電。」
開啟產生為標籤之後，答案就會變成對話上的一個標籤：
| 欄位類型 | 開啟「產生為標籤」後，對話會得到 |
|---|---|
| 是／否 | 答案是「是」時，欄位名稱 要求回電；答「否」時什麼都不會有 |
| 列舉 | AI 挑選的那個值，例如 緊急 |
| 文字、數字 | 永遠不會產生標籤 |
標籤就是工作流程在聽的東西。電子郵件提醒是一個「標籤被加到對話上時啟動」的 工作流程，所以真正把郵件送出去的，就是那個標籤。
一個標籤，多個請求
標籤只有「在對話上」和「不在對話上」兩種狀態。「這通對話跟疫苗有關嗎？」 這類問題適合這種設計，它一旦成立就會一直成立。請求就不適合了，因為客戶 可能開口不止一次：
- 沒有開 Live 時，分析第一次答「是」，標籤就放上去了。一小時後普莉婭 再問一次，標籤已經在上了，什麼也不會加，提醒也不會再執行。
- 開了 Live 之後，智慧體每次標記請求，它就會變成標籤底下一個帶編號的 請求：「Request 1」、「Request 2」。只要有請求還開著，標籤就 留在對話上，最後一個被標記為已處理時才拿下來。每個新請求都能讓提醒再 執行一次。
這就是為什麼只有是／否欄位能開 Live：「是」是客戶做出的一個動作，下一個 「是」就是一個新請求。列舉的值描述的是對話本身，沒有東西可以數。 **「During the conversation」**區塊只列出會產生標籤的是／否欄位。當一份 對話洞察一個都沒有時，它會說 「櫃檯跟進 has no yes/no fields that produce a label, so nothing can be Live yet.」
欄位開了 Live 之後有什麼不同
當要求回電產出它的標籤、而那個標籤上掛著一封電子郵件提醒時：
| 未開 Live | 開 Live | |
|---|---|---|
| 提醒什麼時候到 | 對話洞察執行時，也就是對話結束之後 | 客戶開口後幾秒內，人還在的時候 |
| 同一個對話裡，客戶稍後又問一次 | 沒有事：標籤已經在上了 | 一個新請求，加一封新提醒 |
| 誰找到它 | 對話結束後的檢查 | 智慧體，在客戶開口的當下。就算它漏了，對話結束後的檢查仍然會找到，提醒屆時照樣寄出 |
對話後分析在 Live 欄位底下照常執行。它是最後一道安全網：智慧體沒標記到的 請求，照樣會在對話結束時被記錄下來並寄出提醒，跟沒開 Live 時一模一樣。
Live 適用的範圍
你的智慧體會對話的所有地方：網頁聊天小工具、智慧體的測試頁面、WhatsApp 和其他訊息管道、電子郵件回覆，還有來電與外撥電話。
在電話中，智慧體會快速嘗試標記請求一次，最多兩秒，來電者完全不用等它。 如果沒有成功，智慧體就用它自己的話繼續講下去，改由通話結束時的檢查來找到 請求。沒有被記錄成對話的通話，永遠不會被即時標記。
請 Octo 設定
最快的方式，是對 Octo 說一句話：
每次有人要求回電，請立刻寄電子郵件通知我。Octo 會找出產出那個標籤的欄位（或者提議在智慧體的對話洞察裡加一個），建好 提醒工作流程，然後在把欄位轉為 Live 之前，把這個改動會觸及的一切攤給你看。 你同意之前，什麼都不會改變。
用詞有差。「馬上」「立刻」「一開口就通知」「還在聊的時候」「每次開口都 通知」這些說法要的是即時。一句平淡的「有回電請求跟我說一聲」，得到的是 對話結束後才寄達的一般提醒，Octo 會跟你說一次它可以做成即時。
或是自己到設定裡開啟
-
在 /agents 上開啟這個智慧體，進入設定。
-
在對話結束後——對話洞察掛在這裡——的下方，有一個屬於它自己的區塊 「During the conversation」：
「Turn a yes/no field Live and this agent flags it as soon as the customer asks, so its workflows run within seconds. Fields that aren’t Live are still found after the conversation ends.」
沒有掛對話洞察時，它會說 「Attach a Dialog Insight above to choose what this agent flags while the conversation is still going.」
-
每個會套用標籤的是／否欄位都有一張卡片，上面有 Live 開關，以及那個 標籤上的工作流程。列舉、文字和數字欄位不會列出：只有是／否欄位能開 Live。
一個會產生標籤的是／否欄位，就有一張卡片。 -
把要求回電的 Live 開關打開。確認對話框 「Turn on Live detection for “要求回電”?」 會彈出來。讀完內容，按下 「Turn on Live」。
只有工作區的擁有者和管理員能改這個開關。其他人看到的是唯讀狀態，附著一句 「Only workspace owners and admins can change Live detection.」
這個確認對話框會告訴你什麼
確認對話框會在 「This changes it for」 下方，列出這個開關觸及的一切：
- 使用這份對話洞察的每一個智慧體和行銷活動。 開關在對話洞察上，不在 智慧體上。如果櫃檯把它分享給下班後的專線，兩個都會開始標記。共用中的 對話洞察會在卡片上方說明這一點：「Shared with 1 other agent. A Live switch here changes it for all of them.」
- 標籤上的每一個工作流程，以及各自什麼時候執行。標著 「Built for after the conversation. It reads the AI summary, which doesn’t exist yet while a conversation is live.」 的工作流程，在你打開 Live 之前值得先看一眼。
- 模型無法使用工具的智慧體。 它們無法在對話進行中標記任何東西，但它們 的請求仍會在對話結束後被找到。
如果在對話框開著的期間，有智慧體、行銷活動或工作流程開始使用這個欄位， 它會顯示 「Something changed since you opened this」，並請你 「Review again」。
客戶會聽到什麼
智慧體用它自己的話回覆，範圍以它的指示為準。它不會照稿念出一句固定台詞， 也絕不會告訴客戶是誰收到了提醒。
這留下了一個風險：智慧體承諾了你的團隊做不到的事（「艾利斯醫師五分鐘後就 會回電給你」）。所以確認對話框裡有一個以智慧體命名的核取方塊 「Tell 櫃檯 what we can promise」，它會在智慧體的指示裡加入一行。一開始 的內容是：
「When a customer asks about “要求回電”, tell them the team will follow up. Don’t promise a specific time.」
把它改成你團隊真正的做法，例如「我們會在當天下午回電」。這一行只會進到這個 智慧體的指示裡，不會進到共用這個欄位的其他智慧體。
重複請求與提醒工作流程
每張卡片都會在 「Workflows on the label “要求回電”」 下方，顯示每個工作 流程的執行時機：
| 卡片上寫的 | 意思是 |
|---|---|
| 「Runs for each new request (requests within 30 minutes are merged)」 | 工作流程的觸發條件在每一次重複時都會執行。Octo 建立即時提醒時就是這樣設定的 |
| 「Runs when the label is added: the first request, and again after every request is handled」 | 在 Live 出現之前建立的提醒，或建立時沒有選重複執行的提醒。它會維持原樣；可以請 Octo 改成每個請求都執行 |
| 「Runs once per conversation until this field is Live」 | 設在還沒開 Live 的欄位上的重複提醒 |
兩道限制，防止話多或帶著惡意的客戶灌爆你的收件匣：
- 30 分鐘內的請求會合併。 一個還開著的請求，30 分鐘內又來一句「請打給 我」，算是同一個請求：一個請求、一封提醒。請求上會顯示 「Asked again at 4:12 PM, merged into this request」。
- 每段對話在 24 小時內，最多 5 個請求會啟動工作流程。 第 6 個之後的 請求照樣會被記錄、照樣顯示，標上 「Alert limit reached」，但整個工作 流程會為它們跳過——不只是那封郵件。如果工作流程還會更新 CRM 或傳訊息 給誰，那些步驟也一併跳過。
提醒郵件寫了什麼
Octo 建立的提醒會把請求本身帶過去，所以郵件寫得清楚這是哪一個請求。從第二 個請求起，主旨結尾是「(第 2 次請求)」「(第 3 次請求)」，以此類推。客戶姓名 上方的那一行長得像 要求回電 · 第 2 次請求 · 第 1 次請求仍未處理（第一個 請求只顯示標籤本身）。它的下方是：
- 客戶留了電話號碼或電子郵件時的撥打電話與寄送電子郵件按鈕。
- AI 備註，可能引用客戶原話：智慧體標記請求時，針對它寫下的內容。 「由 AI 助理在對話中撰寫。AI 摘要會在對話結束後產生。」 這一段以純文字 顯示，所以客戶打下的任何字，都不會在你的收件匣裡變成連結。
- 對話的最近訊息。
- 開啟對話與標記為已處理。「標記為已處理」只會打開對話並定位到那個 請求。它本身絕不會改變任何東西，因為郵件掃描器會打開郵件裡的每一個 連結。在那裡再多按一下，才會真正處理完成：見 追蹤未處理的客戶請求並標記為已處理。
先實測一次：測試會送出真的提醒
智慧體測試頁面和試用語音裡的對話，跟其他對話一樣會被即時標記，提醒 工作流程也會真的執行：郵件寄到的是真實地址。這是看到 Live 運作最快的方式， 所以實際試一次吧。
想讓之後的測試不再進到你的提醒裡，就對 Octo 說：
只提醒真實的對話。它會加上一個關於對話來源的篩選條件，來自測試頁面、試用語音和測試批次的 對話，就不會再啟動提醒。這些測試對話的請求，仍然會出現在收件匣裡。
不適用於緊急情況
每一張 Live 卡片都帶著一行 「Alerts can be delayed or missed. Not for emergencies.」 這句話是認真的。提醒是工作流程寄出的一封電子郵件，而郵件 可能延遲、被過濾，或者永遠沒有被打開。
如果欄位跟緊急情況有關，確認對話框會再說一次（「Email alerts can be missed or delayed; they are not an emergency service.」），並為智慧體提供另一行 不同的台詞：
「If the customer describes an emergency, tell them to call 911 or their local emergency number now. Don’t say that the team has been told.」
在動物醫院，把它改成寫明緊急動物醫院的名稱，並且保留這一行。Live 能讓請求 更快到你的團隊手上，但它不會讓你的團隊變成緊急服務，也絕不能讓客戶以為 它會。
把 Live 關掉
把開關切回去，並確認 「Turn off Live」。智慧體就不再於對話進行中標記 這個欄位，改回在對話結束後才找到它，所以提醒會晚一點到，同一個對話裡的 重複請求也不會再各自提醒。已經開著的請求會維持開著，直到有人把它標記為 已處理。
接下來
- 追蹤未處理的客戶請求並標記為已處理 ——收件匣那一側：哪些對話還需要人處理，以及把每個請求結案。
- 設定一個對話洞察 ——Live 開關所坐落的那幾個欄位。