AI 電話自動化：通話結果 4-way 分流與重撥規則完整工程設計

TL;DR — AI 電話自動化的關鍵不在 AI 講話多自然，而在掛上電話之後的 4-way outcome routing：每通電話依結果（answered / no_answer / voicemail / failed）自動分流到下一條動作鏈。實務驗證的最小可運作系統是「3-edge branching + automation_resume_queue + 退避重撥（5s/10s/20s）」三件組，配上 pg_cron 每 10 秒輪詢一次。本文給你 4-way 完整路徑圖、跨通路接力（voicemail → SMS / no_answer → LINE）、5 條最常踩的規則設計坑，以及為什麼壽險團隊 60 天接通率 8%→22% 真正的工程關鍵是 voicemail 自動轉 SMS，而不是盲目重撥。

為什麼 outcome routing 是 ROI 落地的工程化問題

AI 電話 vs 真人客服 ROI 攝回試算的攝回曲線假設一件事：每通撥出的電話都被有意義地處理。實務上，30–50% 的外撥通話會撞到答錄機（詳見答錄機偵測指南），其中又有相當比例的 no_answer 跟 failed。如果這三類都用同一條路徑回收，AI 電話的攝回試算就是空的。

換句話說，AI 電話的工程瓶頸不在 AI 模型多聰明，在於通話結束的那一刻系統知不知道下一步該做什麼。這是 RevOps 跟銷售營運主管的問題，不是模型訓練的問題。把這層工程做對，phase-1 的 ROI 文章才有意義；做錯，模型再聰明也救不回來。

4-way branching 完整圖：每個 outcome 接什麼

實務上的最小可運作系統把通話結果分四向。

Outcome	預設動作	規則範例	主要風險
answered	寫回 contact context、觸發後續腳本（成交/異議/反對話術）	接通 ≥30 秒視為有效對話、＜10 秒視為人接後快掛斷	「接通即視為成交」造成漏記真實異議
no_answer	排程下一次重撥（24h 後 / 不同時段 / 不同號碼出口）	上限 3 次、間隔 24/48/72 小時、不在原時段	過度重撥變騷擾、踩公平交易法第 25 條
voicemail	切換通路：自動發 SMS 或 LINE 訊息接續	第 1 次不留言＋發 SMS 連結；第 2 次再撥另一時段	留答錄機訊息浪費 TTS 成本、轉化率低
failed	退避重試（5s/10s/20s）、辨識失敗類型（線路忙、號碼空號、服務中斷）	短退避 ×3 後升級到下一通路或標記無效名單	退避做錯會雪崩擊垮上游 SIP 提供者

failed 跟 no_answer 是兩個東西：前者是技術錯誤（號碼錯、線路忙、服務中斷），後者是人沒接。混在一起會把可重撥的對象（人沒接）跟該標記為無效的對象（號碼空號）放進同一條重撥隊列，白燒撥打成本。

voicemail 也跟 no_answer 不一樣。對方手機振鈴一段時間後切到語音信箱，系統收到的 SIP 200 OK 跟人接起一模一樣（詳見答錄機偵測指南）。錯把 voicemail 當 answered 路由，AI 開場白會對著答錄機講完，contact context 寫進「已接觸」，下次跟進時客戶 confused——「上次什麼時候打過給我？」

重撥規則設計：間隔、上限、退避

no_answer 路徑上的重撥規則決定了 AI 電話會不會變騷擾電話。三個必須調的旋鄞。

間隔。台灣消費者反感連續來電，行銷實務上至少給 24 小時冷卻；如果第二次仍 no_answer，第三次間隔拉到 48–72 小時並切換到不同時段（例如第一次 14:00 撥、第二次改 19:00 撥）。連續撥同一時段 3 次同樣 no_answer，繼續撥的邊際機率極低。

上限。3 次是台灣 B2C 的合理上限，B2B 可拉到 5 次。超過上限應該寫回 contact 標記為「短期無聯繫」，3–6 個月後才重新進入名單；不要無上限重撥，依公平交易法第 25 條，足以影響交易秩序的顯失公平行為違法，重撥太多通可能被認定為不正當電銷。NCC 投訴一旦成立，整支 SIP 號碼可能被停用。

退避。failed 路徑要區分系統性錯誤（上游 SIP 服務 5xx）跟單通話錯誤（號碼空號、忙線）。系統性錯誤要退避重試（exponential backoff，常見序列 5s/10s/20s 或加拖動），避免一群失敗請求同時重試把上游打爆——這是分散式系統的標準做法。單通話錯誤直接判斷號碼有效性，無效就標記、不重撥。

⚠️ 注意：很多團隊把「退避」跟「重撥」混為一談。退避是面對「系統錯了」做的秒級重試（5s/10s/20s）；重撥是面對「人沒接」做的天級嘗試（24h/48h）。兩條路徑的邏輯、風險、上限完全不同，混在一起設計就出事。

跨通路接力：voicemail → SMS / no_answer → LINE

voicemail 跟 no_answer 各自最有效的接續通路不一樣。

voicemail → SMS。對方已經切到答錄機，留 30 秒 TTS 訊息的轉化率遠低於發一封簡訊。SMS 在台灣觸達率高、不需要 app、客戶任何時候有空都能讀。建議第 1 次 voicemail 直接掛斷不留言、改發一封 60 字內 SMS（含可預約／回撥的短連結）。第 2 次 voicemail 才考慮留 TTS 訊息——但訊息不超過 15 秒、明確說明回電後會進到對話而非另一台答錄機。

no_answer → LINE 接續。如果客戶已加入公司 LINE 官方帳號（在台灣 SMB 場景常見，LINE 在台灣 2024 年月活躍使用者突破 2,100 萬），no_answer 後 30 分鐘內推一則 LINE 訊息「剛才有試著打給您...」搭配回電預約連結，比直接重撥當天有效得多。這也避開了同一通路「你又打給我」的反感。

兩條接續路徑的共同要求：訊息不能脫離 contact context。AI 電話開場時知道 5 分鐘前 SMS 講過什麼、LINE 留過什麼問題；客戶也應該收到「接續上次未完成的對話」而不是「全新的廣告」。這是 AI 原生 CRM 的 4-way routing 跟舊式自動撥號平台的差別。

automation_resume_queue 工程細節

把 4-way branching 落到資料庫層，最小可運作系統三件組：3-edge action node、resume queue table、pg_cron poller。

3-edge action node。trigger_call 這類動作節點輸出三條邊：answered / no_answer / failed（voicemail 在 zh-TW 場景下歸屬於 no_answer 或單獨第四邊，依產品設計）。下游的每一條 automation 鏈接一條邊。設計時要把 voicemail 當第一公民，不是 no_answer 的子型別——後者會在轉化率分析時把答錄機跟人沒接混算。

automation_resume_queue table。儲存「等待 callback」的 automation run id、預期 resume 時間、CAS（compare-and-swap）狀態欄位避免重複拾起。schema 上的關鍵欄位是 resume_at timestamptz、status enum (pending/processing/completed/failed)、attempt_count int、backoff_seconds int。狀態流轉用 CAS update：UPDATE ... SET status='processing' WHERE status='pending' AND id IN (...) 確保多 worker 環境下同一筆只被處理一次。

pg_cron poller。pg_cron 是 PostgreSQL 內建擴充套件，依官方說明「a simple cron-based job scheduler for PostgreSQL (10 or higher) that runs inside the database as an extension」（citusdata/pg_cron），最小排程間隔 10 秒。每 10 秒掃一次 automation_resume_queue WHERE resume_at <= NOW() AND status = 'pending'，CAS 拾起一批，呼叫對應的 automation step 繼續執行。

business-hours deferral。台灣行銷規範下，非緊急電銷建議只在 09:00–18:00 撥；queue poller 在午夜時段照樣輪詢，但發現任務的 resume_at 落在「非營業時段」就把它順延到隔日 09:00。這條邏輯放在 queue 層，不放在 dispatcher 層——dispatcher 只該關心「這通該不該打」，營業時段是 queue 排程屬性。

💡 實務通則：pg_cron 10 秒輪詢、CAS 拾起、business-hours 延後，三件組的工程量約 2 週。比起重新發明排程系統便宜得多，且資料庫內部執行避免了外部 worker 的網路延遲跟認證複雜度。

5 個常見 routing 規則設計坑

第一，過度重撥變騷擾。沒設上限或設太高的團隊在 1–2 個月內被 NCC 投訴的機率明顯上升。3 次/B2C、5 次/B2B 是合理起點，超過要有業務理由跟客戶同意紀錄。

第二，no_answer 跟 voicemail 沒分開。前面講過，這兩個路由策略完全不同。混在一起的代價是 voicemail 留訊息的成本被算進「外撥成功」KPI，看起來接通率 50%、實際有效對話 25%。

第三，業務員工時沒扣。answered 後若觸發業務員上場（典型場景：保險業 AI 電話完成名單篩選後 handoff 給真人），系統必須把業務員當下的 capacity 算進排程——不能在業務員週六休假時把名單塞進去他下週一一上班瞬間爆滿。詳見 AI 客服轉真人怎麼設計 中的 capacity 表。

第四，重撥沒寫回 contact context。第 2 次重撥開場時 AI 不知道第 1 次講過什麼、客戶說過「我下午 3 點後再打」沒有，等於每次都從頭問一次。這對客戶體驗的傷害比 no_answer 本身更大。重撥前 AI 必須讀完同一 contact 的歷次對話摘要。

第五，failed 退避序列做錯。固定 backoff（每次都 5 秒）會把同一群失敗請求堆在同一秒重試；指數 backoff 沒拖動會把 5 秒、10 秒、20 秒切成清晰的尖峰。建議帶 ±20% 隨機拖動（jitter），讓重試請求自然散開。沒做退避拖動是 SIP 上游被打爆的常見原因。

✅ 快速行動：建立 4-way routing 的順序是 answered（必有）→ failed（避免無限重試打爆服務）→ no_answer（重撥規則）→ voicemail（最後做，因為偵測層複雜）。一次只開一邊，看 7 天 KPI 再開下一邊。

30 人壽險團隊 60 天接通率 8%→22% 的 routing 工程

痛點：壽險業務團隊 30 人，月名單 8,000 通；過去用真人外撥，接通率 8%（其中 30% 又是答錄機被誤算為接通），有效對話率不到 5.6%。業務員每月撥 270 通才能換到 15 場有效對話，產能瓶頸明顯。

AI 解法：導入 4-way outcome routing 工程：(a) voicemail 自動偵測並切到 SMS 接續而非留言，(b) no_answer 24h 後重撥不同時段，最多 3 次，(c) failed 區分系統錯誤跟空號，空號直接退出名單，(d) answered 自動把通話摘要寫回 contact context，業務員 handoff 時看得到 AI 已蒒集的客戶資訊。

預期效益：60 天後接通率從 8% 上升到 22%（參考壽險 AI 電話導入實戰）。關鍵不在 AI 模型升級，在於 voicemail 自動轉 SMS 後不再「對著答錄機講完台詞」、no_answer 換時段重撥比同時段硬撥有效、failed 退場讓名單品質提升。每月可釋出 240–320 名業務員拜訪時數。

「AI 電話最大的工程槓桿在掛電話的那一刻，不在開場白。」——壽險團隊 60 天接通率拉一倍的真實工程，不是 prompt 寫得多漂亮，是 4-way routing 把真實有效的對話從噪音裡篩出來。

常見問題

AI 電話自動重撥是合法的嗎？

合法，但有條件。公平交易法第 25 條禁止「足以影響交易秩序之顯失公平行為」，過度重撥可能被認定構成。實務上 B2C 重撥上限 3 次、B2B 上限 5 次、間隔 ≥24 小時，並在 contact context 留紀錄，是相對安全的設計。NCC 投訴一旦成立，整支 SIP 號碼可能被停用，遠比偶爾少打幾通損失大。

no_answer 跟 voicemail 為什麼要分開處理？

兩個路徑接續策略不同。no_answer 代表人不在或不方便接，下次換時段再撥仍可能成功；voicemail 代表電話被切到答錄機，留 30 秒 TTS 轉化率低，改發 SMS 或 LINE 接續更有效。混在一起的代價是把答錄機留言成本算進「成功外撥」KPI，看起來接通率 50%、實際有效對話 25%。詳見 AI 電話答錄機偵測指南。

為什麼 pg_cron 10 秒輪詢就夠？不需要更即時的 queue？

電話 outcome routing 的 SLA 通常以分鐘計（重撥間隔 24 小時、退避 5–20 秒），10 秒輪詢延遲完全在可接受範圍。換成 Redis Streams 或 Kafka 增加的工程複雜度跟運維成本不對應；資料庫內部 pg_cron + CAS update 已足以支擐每秒數千通的 queue 流量。先用 pg_cron 跑到工程瓶頸再升級，不要過早優化。

退避重試的退避時間怎麼決定？

固定 backoff（每次都 5 秒）會把失敗請求堆在同一秒重試；指數 backoff（5/10/20 秒）切成清晰尖峰，仍可能擊垮上游。建議帶 ±20% 隨機拖動（jitter）：第 1 次 4–6 秒、第 2 次 8–12 秒、第 3 次 16–24 秒，讓重試請求自然散開。3 次都 failed 後不要繼續重試，升級到下一通路或標記無效名單。

想看完整 AI 電話導入路徑、外撥腳本設計與 KPI 設定？閱讀本系列的支柱長文 AI 電話行銷完整指南。