用Gemini分析雲端PBX通話資料

一句話答案： 從雲端PBX匯出三個月的通話明細（CDR），把辦公時間、時區與國定假日清單一併當作上下文交給Gemini，請它以「當地小時＋星期幾」輸出接通率與放棄率，而不是一個月平均值。浮現出來的模式幾乎總是覆蓋時段的問題，而不是電話系統的問題——也就是說，這是一個排班決策，不是一次採購決策。

問一位營運主管，公司每週大概漏接多少通電話，你通常只會得到一個聳肩，或是一個從上一季某份報告裡模糊記得的數字。再問櫃檯人手夠不夠，你會得到一個非常篤定、但背後沒有任何數據的答案。這兩個問題都有精確答案，而這些答案一直躺在電話系統裡。

這篇文章講的就是怎麼把它們取出來：從雲端PBX匯出什麼、怎麼給Gemini下提示才能讓數字有意義、一次完整分析實際長什麼樣，以及多數教學會跳過的那一段——當你匯出一份裝滿客戶電話號碼的檔案時，你同時製造了什麼樣的隱私曝險。

電話系統早就知道、卻從來沒人去看的東西

每一台雲端PBX都會為經過它的每一通電話寫一筆通話明細紀錄（CDR）。一筆典型紀錄包含時間戳記、呼叫方向、主被叫號碼、接收該來電的佇列或分機、響鈴時長、通話時長、結果狀態碼（已接聽、放棄、語音信箱、忙線、失敗），通常還有是誰接的。對一家中小企業而言，三個月的話務量一般是幾千到幾萬筆。

這個量級剛好卡在最尷尬的中間：用試算表用肉眼看，太多了，看不出任何真東西；要立案做BI、建資料倉儲或導入一套人力調度平台，又太少了。於是實際狀況是沒人去看，關於電話覆蓋的討論一直停留在軼事層次——誰最近抱怨得最大聲，就聽誰的。

同時，代管雲端PBX平台自帶的儀表板會很樂意告訴你：上個月94%的來電被接聽了。這個數字是真的，但幾乎沒有用。缺掉的那6%並不是平均撒在整個月裡的，它高度集中在某些小時、某些工作日、某些佇列，而且通常集中在某一個市場打來的電話上。找出這個集中點，就是整件事的全部。

怎麼從雲端PBX拿到能用的通話資料

幾乎所有代管PBX都能從管理後台匯出CSV格式的CDR，多數也提供同一份資料的API。如果你的電話系統是透過認證過的會話邊界控制器（SBC）整合進Microsoft Teams，那麼紀錄常常是被拆開的：PBX端保存中繼腿，Teams端保存用戶端腿。兩邊都要匯出，並依通話識別碼關聯起來，否則你會無聲無息地漏掉所有「在Teams裡接起、而不是在話機上接起」的電話。

盡量讓後台一次匯出它能給的最長時間範圍。三個月是可用的下限——一個月太短，分不出這是真實模式還是剛好遇上很糟的兩週；整整一年又太笨重，而且包含你早就調整過的排班安排。

通話明細匯出——哪些欄位真正重要，哪些欄位會誤導你

結果狀態碼（disposition） 是整個分析的支點，同時也是各家平台定義最不一致的欄位。在你解讀任何結論之前，先讀廠商文件，確認每個碼到底代表什麼。
「放棄」和「未接」不是同一件事。 放棄是指主叫在有人接起前就掛斷了。而「未接」在很多平台裡只是說響鈴群組裡某一支分機沒接——兩秒後同事接起來了。把兩者都當成失敗來統計，你會憑空造出一場並不存在的危機。
接聽前響鈴時長 是檔案裡最被浪費的欄位。平均應答速度比接通率更能說明主叫的真實體驗，而且它變化得更早：佇列在人們開始掛斷之前很久，響鈴時長就已經在惡化了。
通話時長 單看幾乎沒有意義。三分鐘的通話，如果解決了問題就是好事，如果是被轉接兩次才走到那一步就是壞事。
重複來電需要合併。 同一個號碼十五分鐘內打了三次，那是一位不滿意的客戶，不是三通電話。不做合併，重複撥號剛好會在你覆蓋最差的那些小時裡把話務量灌得虛高。
內部分機互打的話務通常應該排除。 那是真實使用量，但不是客戶需求，而且它會扭曲你算出來的每一個比率。

時區、國定假日，以及為什麼原始平均值會掩蓋問題

CDR的時間戳記通常存成UTC，或存成很多年前某位已離職同事替租戶設定的那個時區。如果你的客戶在日本、值機台在香港、溢出話務落在新加坡，一份從不做當地時間換算的分析，會產出一張錯得沒人會發現的圖。

明確告訴模型租戶時區是什麼，說明你要的結果用哪個當地時區，並把國定假日清單交給它。香港、中國大陸、日本、新加坡的假期並不對齊，否則黃金週或農曆新年會表現成「兩週原因不明的低話務」，悄悄把所有平均值往下拖。

真正管用的提示一點也不花俏：上傳CSV，然後補上檔案本身承載不了的上下文——各據點的營業時間、每班值機人數、你們平台裡每個狀態碼的意義、假日清單，以及你想回答的那個具體問題。在你圍繞一份超大匯出檔做規劃之前，先查一下Gemini目前文件裡對檔案大小與格式的限制；如果檔案太大，就按月拆開、分段分析。

一個完整範例——從三個月通話明細到一份排班建議

一家140人的製造企業，總部在香港，廣東有兩個廠區，客戶分布在日本與東南亞。三個月約11,000通外部來電。PBX儀表板顯示接通率91%，所有人早就一致認為「還可以」。

第一條提示刻意收得很窄：依當地小時與星期幾分組；對每一組給出來電總數、已接聽數、放棄數，以及接聽前或放棄前的響鈴時長中位數；排除內部分機通話；同一號碼十五分鐘內的多次呼叫視為一次嘗試。

結果掉出三件事。上班日的第一個小時原來是整週最糟的一小時：香港時間08:00到09:00之間打進來的電話約占整週來電量的七分之一，放棄率是日均水準的三倍以上。而值機台是從09:00才開始排班的。快一小時的日本客戶，多年來一直在往一間空辦公室打電話。

第二件是午休。12:30到13:30之間放棄率大約翻了三倍，響鈴時長中位數超過四十秒。值機台名義上有排輪值，實際上沒有。

第三件更小、也更有意思：17:30之後有一條持續存在的日語來電尾巴——量不大，但放棄率極高，因為唯一一位雙語同事已經下班了。

這三個發現，在91%這個接通率裡一個都看不到。

不要叫模型去數數。 這是整個流程裡最重要的一條習慣。語言模型在成千上萬列資料上的算術是不可靠的：它會近似、會抽樣，或者非常有自信地給出一個看起來很合理的總數。正確做法是請Gemini把彙總邏輯寫出來——一條Google Sheets公式、一份樞紐分析規格，或一段你可以自己在CSV上跑的Python程式。然後跑一遍、對一次。用模型決定問題的形狀與解讀答案，用確定性的算術產出數字。任何最後會擺到管理層面前的數字，都應該在沒有模型參與的情況下可重現。

排班問題也要用同樣的紀律。問「我們需要幾位客服？」只會換來一個很有自信的猜測。問「在處理時長中位數四分鐘、放棄率目標不超過5%的前提下，這些分組各自意味著每小時需要多少人力，並把計算過程寫出來」，你拿到的才是能核對、也能爭論的算術。

AI輔助分析 vs PBX內建報表 vs 導入客服中心平台

PBX內建報表 免費、即時、已經開著。它在總量、分機活動、中繼使用率這些事情上確實好用。但只要問題需要跨維度切分——按小時×市場×佇列×狀態——它就很吃力，因為它只能回答設計者當初預想過的問題。
對通話明細匯出做AI輔助分析 是回答一次性診斷問題的正確工具，而且採購成本為零。你可以在晚上十點提出一個此前沒人預想過的問題，午夜之前拿到一個站得住腳的答案。它的限制也是真的：這是快照而非即時檢視，得有人去做匯出，而且每個數字都需要複核。
客服中心平台（CCaaS） 買到的是即時佇列管理、話務預測、遵時率追蹤與客服品質評分。當電話是你的主要客戶通路、而且客服在十五人以上時，它對得起授權費。但對一個六個人、還要兼顧其他工作的值機台來說，這是一筆很大的經常性支出，去解決一個用試算表加一個好問題在一個下午就能診斷出來的問題。

誠實的順序是：先診斷、再採購。相當一部分本來準備買客服中心平台的公司，最後發現自己真正的問題是排班表。

真正的答案往往不是電話系統的問題

在幾乎每一次這樣的分析裡，結論都不是「電話系統不夠用」，而是「08:15沒有人在台上」，或是「唯一能用日語接電話的人在隔一個時區、17:30就下班」，又或是「溢出話務被路由到一個一天只查兩次的語音信箱」。

這些都是覆蓋決策，而真正的槓桿只有那麼幾個：你可以調整排班表，這不花錢，而且往往就夠了；你可以延長覆蓋時段，這代表要嘛替早晚班付費，要嘛把非上班時間的話務路由給一支已經7×24運作的多語種服務台；你可以改路由，讓未接來電溢出到有人值守的地方，而不是掉進語音信箱。或者你也可以判斷這個放棄率是可以接受的——這完全是一個正當答案，只要它是一個決策，而不是一次意外。

分析的作用，就是把它變成一個決策。「我們大概應該多加點電話人手」在預算會議上每次都會輸。「我們在08:00那一小時丟掉34%的來電，而那一小時占我們來電量的14%，其中大部分來自日本」——就不會。

把這件事做對——通話資料隱私、錄音同意，以及什麼時候該讓IT介入

一份CDR匯出檔，本質上就是一堆帶時間戳記的客戶電話號碼。在香港《個人資料（私隱）條例》（PDPO）、新加坡PDPA、中國大陸《個人信息保護法》（PIPL）與GDPR之下，這都屬於個人資料——號碼指向一個人，通話模式還說明了關於這個人的一些事。在它靠近任何AI工具之前，有四件事需要先定下來。

上傳前先做假名化。 對主叫號碼做雜湊，或截掉後四碼，並把對照關係保存在檔案之外。按小時統計話務量，並不需要知道是誰打來的。這一步幾乎不損失任何分析價值，卻能消除大部分曝險。
把錄音與逐字稿當成完全不同的一類資料。 CDR是中繼資料，錄音是內容；在亞太多數法域，錄音伴隨著告知或同意義務、更長的保存爭議，以及困難得多的跨境傳輸問題——尤其是PIPL之下源自中國大陸的資料。任何人都不應該自作主張把通話錄音上傳到通用AI工具。
用企業版，不要用個人帳號。 各大AI服務的消費版與企業版在資料處理、保存與模型訓練承諾上是不同的。如果你所在的組織還沒簽署相應協議，那這次分析就不是「被核准了」，而只是「發生了」。
想清楚檔案事後放在哪裡。 三個月的客戶通話紀錄躺在某位員工的下載資料夾裡，或某個個人雲端硬碟上，等於一份等著筆電遺失才被觸發的資料外洩通知。

到這一步，這套流程就不再只是一條聰明的提示，而開始變成IT治理。我們的AI+ 支援服務覆蓋的正是這塊地：選對版本層級、把資料處理規則定下來，並讓假名化這一步變成流程預設動作，而不是分析師記得做才做的事。而匯出本身、API存取權限、保存政策與存取控制，則屬於日常維運你基礎架構的那支團隊——對我們很多客戶來說，就是Brocent的代管IT支援團隊。如果你希望在決定採購某個平台之前，先請人看一眼你自己的通話資料，歡迎與我們聯絡。