用Gemini起草季度SLA服務審查敘述

一句話結論：Gemini 可以讀取一個季度的服務台工單匯出和 CSAT 調查資料，用大約一小時起草出服務審查敘述——趨勢、異常項，以及真正值得爭論的那幾件具體事情。你得到的是一份對自家供應商數字的獨立解讀。它無法告訴你服務到底好不好。

月度服務報告依合約在第八個工作日送達。九頁，開篇是一塊綠色的儀表板，而這家 220 人公司的 IT 經理把它轉進一個資料夾，第二頁之後就沒再看。三份這樣的報告攢起來，行事曆上就冒出一場季度服務審查。

審查會上，客戶經理講的是同樣的數字、同樣的綠色，大家一致認為服務沒問題，會議提前結束。兩週後財務總監問：為什麼服務台「感覺很慢」？——而沒有任何一份文件能回答這個問題。

回答這個問題的原始素材是存在的。它躺在 ManageEngine ServiceDesk Plus、Freshservice、Jira Service Management 或 Zendesk 裡，作為一份工單匯出；也躺在寄送 CSAT 郵件的那個工具裡。缺的是那幾個小時的試算表工作——把三個月的資料列變成一個有觀點的故事。

這才是值得交給模型的那部分：不是「服務好不好」的判斷，而是讓這個判斷得以成立的那次資料解讀。

為什麼月度 SLA 報告越堆越多，卻從未變成一次真正的對話

月度 SLA 報告是一份合規產物。它存在的目的是證明合約門檻被滿足了，而它是由被考核的那一方撰寫的。這兩件事共同塑造了它：它對照合約裡的目標來回報，並且用可用的最站得住腳的方式來回報。

這裡面沒有任何不誠實。但「P2 解決 SLA 達標率 97.4%」是一句關於門檻的陳述，不是關於提單者感受的陳述。一個 P3 解決時間中位數翻倍、卻仍然落在寬鬆 SLA 之內的季度，在每一頁上都會顯示為綠色。

這些報告還是按月送達、按月閱讀的，而這個節奏根本發現不了任何東西。趨勢活在季度尺度上。單獨一個月看不出：自三月以來同樣的五名使用者提交了四成的工單；也看不出：自某次人員調整之後，週一早上的等待時間悄悄多了十一分鐘。

於是季度審查——本該讓這些浮出水面的那場會——開場就是供應商自己的簡報，因為客戶這一側沒有人準備過另一份解讀。這場會於是預設在供應商的框架裡進行，這不是誰的錯，卻是所有人的問題。

Gemini 用工單和 CSAT 匯出資料到底能做什麼

Gemini 可以透過 Google Sheets 的側邊欄處理試算表資料，也可以在 Gemini 應用裡以上傳檔案的方式處理。你能用到哪些功能、檔案大小限制是多少，取決於你的 Workspace 版本，而且這些會變——請查閱你所用方案的當前官方文件。這裡真正要緊的能力並不炫目：認真讀幾千列資料，然後描述出發生了什麼變化。

有兩樣輸出值這一個小時。

把一張回應與解決時長的試算表變成一段趨勢敘述

給它三個月的工單資料列——建立時間、首次回應、解決時間、優先權、分類、提單部門——它會算出那些顯而易見的彙總值，而更有用的是，它會把那段話寫出來：「首次回應中位數穩定在 14 分鐘；P3 解決時間中位數從四月的 4.2 小時上升到六月的 7.8 小時，主要由軟體安裝類工單驅動。」

這句話才是一次服務審查真正需要的東西，也幾乎從來沒有人寫出來過——因為寫它需要有人對著樞紐分析表坐兩個小時，然後用文字形成一個觀點。

要明確要求做對比：本季度對上季度，如果有資料，再對去年同期。一段沒有基準的敘述，只是一個被形容詞包圍著的數字。

標出真正值得在審查會上提出來的工單與模式

第二樣輸出是一份短名單。讓它列出：耗時最長的十張工單、所有被重開超過一次的工單、所有工單量成長超過四分之一的分類，以及所有評分在三分及以下的 CSAT 回覆，並附上其自由文字評論。

那份名單就是你的議程。它把審查從「我們有沒有達到 SLA」變成「這裡有十一件具體發生過的事，我們打算怎麼辦」——而後者才是真正能改進服務的那場對話，也是一家問心無愧的供應商通常會歡迎的那場對話。

一套可落地的流程：從一份 CSV 匯出到一份可用於審查的初稿

1. 要原始匯出，不要那份報告。向你的 MSP 或你自家的服務台管理員要一份涵蓋整個季度的工單級 CSV，包含時間戳記、優先權、分類、提單部門和處理記錄。如果你的合約並沒有賦予你這項權利，那麼在下次續約之前把這件事搞清楚很有價值——這是一個合理的要求，也是一個不太好拒絕的要求。

2. 剔除不該離開你環境的內容。提單人姓名和信箱、處理記錄裡任何看起來像密碼或內部路徑的東西，以及任何點名了你自己客戶的自由文字。把姓名替換成部門標籤，能保住你需要的全部分析，同時去掉大部分風險。

3. 算術在試算表裡做，不要在提示詞裡做。自己加上那些衍生欄位——首次回應時長、解決時長、是否違約、週次。相比讓模型從四千列資料的兩個時間戳記裡現算，讓它描述一個已經躺在儲存格裡的數字，可靠得多。

4. 先要趨勢段落，並且點名基準。「把 Q2 和 Q1 在首次回應中位數、各優先權解決時間中位數、各分類工單量和重開率上做對比。寫四段。列出你用到的數字。」引用數字這條指令才是重要的那一半——它讓核對成為可能。

5. 例外清單作為單獨一輪來要。耗時最長的工單、反覆重開的、成長最快的分類、帶評論的低分 CSAT。保持為帶工單號的編號列表，這樣會上每一條都能在幾秒內被調出來。

6. 在你相信另外三十個數字之前，先手動核對三個。從敘述裡挑幾個數字，回到試算表裡驗證。如果這三個是對的，這套方法就在正常運作；如果有一個是錯的，這份敘述就不能用了——而你需要在開會之前知道這件事，而不是在會上。

7. 解讀要你自己寫。模型能告訴你軟體安裝類的解決時間上升了。只有你知道，同一個季度採購換了筆電型號，每台新機器都要多裝三個應用。那句話就是你貢獻的價值，而它不在資料裡。

8. 提前三天把議程發出去。一頁具體的問題，提前發出，會徹底改變這場會：供應商到場時已經查過同樣那十一張工單，這一小時於是花在原因上，而不是花在儀表板上。

AI 起草的季度審查敘述 vs 供應商撰寫的服務審查 vs 根本沒有正式審查

基於你自己資料、由 AI 起草的敘述。獨立於供應商的框架，便宜到每個季度都能做一遍，而且在一個晚上六點已經疲憊的人做不到的那種徹底性上很強。它不了解你的業務背景，會心安理得地把一個統計假象說成趨勢，也無法判斷某個數字是否可以接受。正確用法：作為你的會前準備，絕不是這場會的結論。
供應商撰寫的服務審查。由了解環境、了解歷史、也知道那張工單為什麼拖了九天的人準備。那份知識是真實的，也值得擁有。同時它由被考核的那一方撰寫，對照的是他們參與設定的門檻——這不是對任何一家供應商的指控，只是一個值得被對沖的結構性事實。
根本沒有正式審查。這是三百人以下公司裡最常見的安排。服務品質於是靠感覺來評判，通常是在一次事故之後，而相關對話發生在續約時——那正是籌碼最高、善意最低的時刻。

真正管用的搭配是前兩者並存。供應商帶來背景，你帶來獨立解讀，這場會於是有了兩個訊息源，而不是一個。

它會在哪些地方把故事講錯

CSAT 是一份帶倖存者偏差的樣本，讀起來卻像一次普查。會回答問卷的使用者，是極滿意的和極憤怒的那兩類。平均分上升，往往意味著那些「有點煩但沒那麼煩」的人不再回覆了。任何僅建立在 CSAT 之上的敘述，都會對你組織中間那一大塊——也就是絕大多數人——自信地做出錯誤判斷。

一個頭條指標可以藏住它本該衡量的那次失敗。三千張工單裡九十八個百分點的達標率，仍然留下六十次違約。如果其中五十次屬於財務團隊、且集中在月底結帳那一週，那你就同時擁有一個嚴重問題和一塊綠色儀表板。每一次都要求把違約按部門和按週拆開。

它分不清趨勢和組織調整。工單量下降三成看起來像改善，但同樣可能意味著某個受夠了的部門不再提單，改成直接打某人手機。資料看不見那條影子佇列，你能看見。

處理記錄是為了關單而寫的，不是為了描述事實而寫的。「已解決，已告知使用者」可以涵蓋從一次真正的修復到一次聳肩之間的一切。一個模型讀完一個季度的處理記錄，產出的摘要會忠實於被敲下來的文字，而不忠實於實際發生的事。

把這件事做對——工單資料的敏感性、供應商客觀性，以及什麼時候該讓 IT 介入

一份工單匯出比它看起來敏感得多。處理記錄裡有伺服器名稱、共用路徑、應用版本、偶爾還有一條本就不該被敲進去的憑證，以及一份關於「你哪些系統很脆弱」的坦白流水帳。請把這個檔案當作網路拓撲圖來對待。

按規則清洗，而不是靠判斷清洗。一條固定的前處理步驟——刪掉提單人姓名和信箱欄位、掃描自由文字裡任何形似憑證的內容——能挺過一個忙碌的季度。而「打算小心一點」的意圖挺不過去。

在資料進去之前，先搞清楚工具的條款。個人版、商業版和企業版在資料保存以及內容是否可能用於訓練上各不相同，而且條款會變。請查閱你所用具體方案的當前官方文件，然後在公司層面定一條規則：哪些工具可以接收營運資料——而不是把這件事留給當時恰好在準備審查的那個人。

帶著一份獨立解讀去參加供應商審查是健康的，而且應該是公開的。告訴你的服務商你在這麼做。一家歡迎客戶帶著自己的分析來的供應商，正在告訴你一些有用的東西；一家不歡迎的，同樣如此。

決定 AI 在你的營運報告體系裡該佔哪個位置，並寫好那些讓它可重複的提示詞與清洗規則，是 AI+ 支援的工作。底下那套度量框架——明確的回應與解決目標、月度報告、CSAT 蒐集，以及一場真正算得上對話的季度服務審查——是我們的 SLA 與品質框架，而它所衡量的交付則是管理式 IT 支援。如果你要從其他試算表匯出裡建構類似的敘述，我們關於在 Google Sheets 裡自動產生月度銷售報告和起草服務台工單回覆的文章涵蓋了相鄰的問題。

常見問題

我能相信一份由 AI 寫的、關於我自家供應商表現的總結嗎？

把它當作「對你給它的那份資料的解讀」來相信，並且在依賴任何數字之前先手動核對三個。它相對供應商報告的優勢不是準確度，而是獨立性：它是對照你提出的問題來描述你的匯出資料，而不是對照寫進合約裡的那些門檻。至於這些數字是否可以接受，判斷權仍然在你手裡。

如果我的 MSP 不提供原始工單匯出怎麼辦？

用書面形式提出要求，並記錄下答覆。關於你自己的使用者、你自己的系統的工單級資料，是客戶合理應當持有的東西，多數服務商會痛快地給一份 CSV。拒絕本身並不能證明什麼，但它是一個訊息點——而下一次續約，正是把這項要求變成一條明確合約權利的時機。

這和我的供應商已經在發的那份報告有什麼區別？

作者不同，問題也不同。他們的報告回答的是「我們有沒有達到約定門檻」，那是合約提出的問題。你的報告回答的是「這個季度發生了什麼變化，我們該怎麼辦」，那是業務提出的問題。兩者都正當，只是目前只有其中一份被寫了出來。

它適用於任何服務台工具的資料嗎？

適用於任何能匯出工單級 CSV 的工具，實際上也就是全部——ServiceDesk Plus、Freshservice、Jira Service Management、Zendesk、Halo。欄位名稱不同，而新增衍生欄位的工作量在哪裡都一樣。比工具差異大得多的是工單分類的紀律性：如果你有一半工單歸在「其他」，任何分析都救不回來。