案例性質：以下為 SasaDaily 假設示範案例，用來說明企業如何把 Glean 放進實際工作流程。公司、人數、案件量、節省時間與成果數字全部是教學情境，不是真實企業公開導入成果。
一家 10 人的商用冷凍設備服務公司。
客戶包括：
餐廳。
飯店。
超市。
食品工廠。
中央廚房。
每天只要有一台：
冷藏櫃。
冷凍庫。
製冰機。
大型冷凍設備。
突然不冷。
客戶第一句通常不是：
「請幫我找相關文件。」
而是：
「東西快壞掉了，你們什麼時候可以來？」
這時工程師最缺的其實不是 AI 幫忙寫一封漂亮 Email。
而是：
最快找到這台設備以前發生過什麼。
這家公司原本的資料散在哪裡？
客戶基本資料與設備資訊：
在 Salesforce。
技術手冊：
在 Google Drive。
工程師以前處理類似故障的討論：
在 Slack。
尚未解決的技術問題：
在 Jira。
另外還有：
零件照片。
維修報告。
現場檢查紀錄。
舊報價。
原廠公告。
資料其實很多。
真正的問題是：
沒有人能在一個地方一次看到。
客戶一通電話進來，工程師先花時間「找東西」
例如某飯店說：
「地下室冷凍庫今天早上溫度一直降不下來，上次好像也發生過。」
服務人員接到案件後。
以前可能要：
先開 Salesforce。
找客戶。
確認設備型號。
再去 Drive 找說明書。
接著進 Slack 搜：
這個型號以前有沒有人修過。
再看 Jira：
是否有相同問題尚未解決。
如果文件名稱不一致。
設備序號寫法又不同。
找資料本身就可能花掉十幾分鐘。
而這時：
真正的維修工作還沒有開始。
Glean 在這個案例裡先不負責「修機器」
公司的第一個導入目標非常小：
把找背景資料的時間縮短。
不是讓 AI 判斷：
壓縮機壞了。
冷媒不足。
感測器失效。
更不是讓 AI 自己決定：
要不要停機。
換什麼零件。
報多少錢。
第一階段只做：
找資料。
整理資料。
指出資料衝突。
第一步：從客戶與設備開始搜尋
服務人員先輸入：
客戶名稱。
設備型號。
設備序號。
目前症狀。
例如：
「找出這間飯店這台冷凍設備最近兩年的相關維修紀錄、目前有效技術手冊、相似故障案件，以及仍未解決的問題。」
Glean 再從已連接、而且這位使用者有權限存取的企業資料中搜尋。
可能找到：
Salesforce 的客戶案件。
Drive 裡的維修手冊。
Slack 的工程討論。
Jira 的歷史問題。
這時 AI 做的第一件事不是：
直接告訴工程師答案。
而是：
把分散資料拉到同一個工作視野。
第二步：整理「這台設備以前發生過什麼」
假設搜尋結果顯示：
六個月前：
曾出現溫度異常。
三個月前：
更換過某個感測元件。
一年前：
工程師曾在 Slack 討論過同系列設備的結霜問題。
Jira 裡：
還有一個相關問題曾經追蹤。
Glean 可以協助把這些資料整理成：
已確認
這台設備以前做過哪些維修。
可能相關
同型號其他設備曾出現什麼問題。
尚未確認
今天的故障是不是同一原因。
這個最後區域非常重要。
AI 可以找到：
「以前很像。」
但不能直接變成：
「所以今天一定也是。」
第三步：每一個重要資訊都保留來源
假設 AI 整理：
「這台設備三個月前曾更換溫度感測元件。」
工程師應該可以回到：
原始維修紀錄。
而不是只有一句 AI 摘要。
再例如：
「目前技術手冊要求先檢查某個項目。」
也要能回到：
真正的手冊。
因為維修工作不是：
AI 寫得很有自信就算完成。
真正需要的是：
可以追溯。
第四步：同時檢查版本
這也接上今天的一分鐘教學。
假設 Glean 搜到三份：
2024 年維修手冊。
2025 年更新版。
另一份沒有清楚版本標記的 PDF。
不能因為第三份：
修改日期最新。
就自動認為：
它是正式版本。
工程師真正需要知道的是：
哪一份目前有效。
如果無法確認：
直接標示：
版本待確認。
第五步：找到「誰以前處理過」
企業知識不一定只存在文件裡。
有時最有價值的答案是：
誰知道。
例如搜尋結果顯示：
公司裡某位資深技師去年處理過三次同系列設備。
那麼比起 AI 再猜一次：
直接讓現場工程師知道：
「這件事可以問誰。」
可能更有價值。
這就是企業知識搜尋和一般網路搜尋很不同的地方。
第六步：現場工程師拿到的是「背景包」
最後送給現場工程師的不是：
「AI 診斷結果。」
而是一份工作背景。
例如：
客戶設備
型號。
服務歷史。
最近維修
做過什麼。
換過什麼。
相關技術文件
目前找到哪些。
版本是否確認。
類似案件
公司以前碰過什麼。
尚未解決問題
哪些 Jira 問題可能相關。
熟悉人員
公司內誰有經驗。
注意事項
哪些內容仍有衝突。
這樣工程師到現場前：
至少不用從零開始。
接下來真正的技術判斷交回人
到了現場：
工程師要檢查：
實際溫度。
壓力。
電氣狀況。
設備聲音。
結霜。
冷媒。
壓縮機。
控制系統。
這些實際狀況：
不能只靠舊文件判斷。
AI 找到的歷史：
只是背景。
不是今天現場的診斷。
第一個停止點：安全程序
如果問題涉及：
電氣安全。
高壓設備。
冷媒。
設備停機。
食品安全。
人員安全。
AI 不能因為找到一份舊維修紀錄就說：
「照上次直接做。」
必須回到：
目前有效的正式安全程序。
再由：
合格技術人員。
現場判斷。
第二個停止點：兩份手冊互相矛盾
例如舊版手冊說：
先做 A。
新版資料卻說：
先做 B。
這時 AI 最好的工作不是：
選一個。
而是：
把衝突指出來。
例如：
「目前找到兩份操作程序，內容不一致，無法確認哪一份適用於這個設備版本。」
然後：
停止。
人工確認。
第三個停止點：保固判定
假設 AI 找到：
去年更換過零件。
今天又壞。
不能因此直接說：
「這次免費。」
保固可能還取決於：
購買日期。
合約。
零件種類。
故障原因。
客戶方案。
例外條款。
所以 AI 可以找：
相關合約。
歷史維修。
原始紀錄。
但最後：
是否屬於保固，由人確認。
第四個停止點：正式報價
AI 可以協助整理：
可能需要的零件。
過去類似案件。
歷史工時。
相關文件。
但正式價格可能受到：
目前零件成本。
庫存。
運費。
急件費。
客戶合約。
折扣。
付款條件。
影響。
所以第一版流程不要做：
AI 找到案例 → 自動報價 → 寄出。
應該做到：
AI 整理背景 → 業務或主管確認 → 正式報價。
第五個停止點：客戶要求「現在就答應」
例如客戶說：
「你先保證今天一定修好。」
AI 就算找到：
以前平均兩小時修好。
也不能代表：
今天一定兩小時。
所以：
完工時間。
費用。
停機時間。
零件到貨。
正式承諾。
仍然留給負責人。
Glean 在這家公司真正省的不是「技術能力」
真正可能省的是：
工程師找資料的時間。
以前：
一個有經驗的技師知道資料在哪。
新人不知道。
老員工休假：
整間公司一起找。
如果企業知識搜尋做得好：
很多原本只能靠：
「去問某某人。」
的資訊。
開始可以先被找到。
但不要把「老員工經驗」全部想成文件
這也是限制。
真正的現場經驗可能是：
看到某種結霜方式。
聽到某種異音。
聞到異常氣味。
知道哪一個零件最近品質有問題。
這些事情：
如果從來沒有被記錄：
Glean 也不可能自己知道。
所以企業 AI 搜尋只能使用：
公司真的留下來的知識。
沒有記錄：
就是沒有 Context。
這家公司因此增加一個新習慣
每次重要維修結束。
工程師不只寫：
「已完成。」
而要留下三類資訊：
問題
客戶實際遇到什麼。
處理
最後確認的原因與處理方式。
注意
下次如果再發生：
最值得先檢查什麼。
不用寫論文。
但至少讓下一個人：
搜尋得到。
這樣 Glean 才會愈用愈有價值
如果所有維修經驗都只留在：
工程師腦袋裡。
電話裡。
私人的聊天訊息裡。
企業搜尋再強也找不到。
所以導入 Glean 真正會逼公司面對一件事：
我們到底有沒有把重要知識留下來？
這家公司要接哪些資料？
第一版可以很克制。
Salesforce
客戶。
設備。
Cases。
服務歷史。
Google Drive
正式技術手冊。
SOP。
維修文件。
Slack
工程討論。
但必須依照公司權限與資料範圍決定哪些頻道適合索引。
Jira
已知問題。
技術追蹤。
尚未解決事項。
先做到這四個。
不是第一天就：
全公司所有 App 全部接進來。
為什麼不先接財務和人資？
因為這條維修流程：
根本用不到。
工程師要處理設備：
不需要知道員工薪資。
也不需要看到其他完全無關的敏感資料。
所以導入原則應該是：
工作需要什麼，就先接什麼。
而不是：
公司有什麼，就全部接什麼。
權限測試必須在正式上線以前做
假設：
一般維修技師。
服務主管。
業務主管。
三種角色。
應該看到的內容可能不同。
那就用三種測試帳號。
問相同問題：
「找到這個客戶所有相關資料。」
然後檢查：
一般技師看到什麼。
主管看到什麼。
業務看到什麼。
這是在測：
該找到的找得到。
也在測：
不該看到的找不到。
千萬不要只用管理員帳號測
管理員往往什麼都看得到。
如果只用管理員測：
AI 搜尋看起來非常完整。
正式給一般員工使用之後才發現：
權限結果完全不同。
甚至更糟：
某些來源原本就設錯。
所以測試一定要用：
真實角色。
這家公司可以怎麼衡量成效？
不要看：
員工每天搜尋 Glean 幾次。
這不是商業成果。
先記六個數字。
KPI 一：找背景資料平均需要多久
例如導入前：
每件比較複雜的維修案件，工程師平均要花 12 分鐘搜尋背景。
導入後：
再重新測。
這是最直接的 KPI。
KPI 二：第一次搜尋是否找到正確來源
例如 100 件案件中：
多少件第一次搜尋就找到：
正確設備。
正確手冊。
正確歷史案件。
這比「AI 有回答」更重要。
KPI 三：有多少答案能回到原始來源
真正需要的不是：
答案很多。
而是：
關鍵答案能不能被驗證。
KPI 四：版本衝突率
例如 100 次查詢中：
多少次找到兩個不同版本。
這個數字如果很高：
真正需要處理的可能不是 AI。
而是：
文件治理。
KPI 五：轉人工確認率
例如：
保固。
安全。
價格。
資料衝突。
多少案件正確停下來。
轉人工不一定代表失敗。
可能代表：
系統邊界設計正確。
KPI 六：因錯誤資料造成的重工
這是最後最重要的品質指標之一。
如果搜尋變快。
但技師拿到很多舊資料：
最後一直重做。
那就沒有真正改善。
假設每月有 80 件需要查歷史的案件
下面只是教學計算。
不是 Glean 官方 ROI。
假設原本：
每件平均花 12 分鐘找資料。
80 件就是：
960 分鐘。
也就是：
16 小時。
導入後假設：
平均降到 4 分鐘。
80 件：
320 分鐘。
約：
5.3 小時。
差距：
約 10.7 小時／月。
這 10.7 小時值多少？
不要先亂填。
公司可以用自己的：
技師完整人工成本。
去算。
例如每小時完整成本是：
[公司自己的數字]
再乘上：
10.7 小時。
才是這一項流程每月可能節省的直接時間成本。
但還要再扣掉：
Glean 授權。
部署。
管理。
資料整理。
員工訓練。
所以不能只看到：
省 10.7 小時。
就說：
ROI 一定很好。
更大的價值可能不是這 10.7 小時
例如：
客戶冷凍庫正在升溫。
如果工程師早 15 分鐘找到：
之前相同設備處理紀錄。
真正價值可能不是：
省 15 分鐘薪資。
而是：
更快找到問題方向。
減少客戶停機時間。
提高第一次到場解決率。
但這些價值：
必須真的記錄。
不能自己想像。
所以可以再追一個商業 KPI
First-Time Fix Rate。
也就是：
第一次到場就把問題解決的比例。
如果企業知識搜尋真的讓工程師拿到更完整背景：
這個比例理論上可能改善。
但一定要：
導入前記。
導入後記。
實際比較。
不能先寫：
「用了 Glean，第一次修復率提高 30%。」
那就是虛構。
可以直接使用的 Glean 商業流程 Prompt
你是我的企業設備服務知識助手。
我要處理的客戶案件是：
客戶：
[名稱]
設備：
[型號／序號]
目前症狀：
[描述]
現場時間：
[如有]
請只使用我有權限存取的公司內部資料。
搜尋範圍優先包括：
CRM 客戶與設備紀錄。
正式技術手冊。
歷史維修報告。
內部工程討論。
已知技術問題與工單。
請依序完成：
第一，設備背景。
整理這台設備目前可以確認的基本資料與過去服務紀錄。
第二，相似歷史。
找出相同設備或相同型號曾經出現的類似問題。
不要因為症狀相似，就直接判定原因相同。
第三，正式文件。
找出目前最相關的技術手冊、SOP 或安全程序。
每個重要結論都保留原始來源。
第四，版本。
如果找到多個版本：
列出差異。
不要自行假設最後修改日期最高的文件一定是正式版本。
第五，衝突與缺口。
把資訊分成：
已確認。
資料互相矛盾。
目前缺少。
第六，公司內部經驗。
如果資料中可以確認曾經處理過相同問題的人員或團隊：
列出可以詢問的對象。
第七，停止條件。
只要涉及：
人員安全。
設備停機。
冷媒或高壓風險。
正式故障診斷。
保固判定。
正式報價。
零件採購承諾。
交期。
合約。
付款。
請標示：
「需要人工確認」。
不要替公司做正式決定。
最後輸出：
案件背景摘要。
最相關的三個原始來源。
可能相關的歷史案例。
目前資料衝突。
仍缺少的資訊。
建議下一位人工負責人要確認什麼。
如果公司資料不足：
直接說不知道。
不要使用一般知識替公司補出不存在的維修紀錄。
第一版不要讓 Agent 自己改 CRM
Glean 已經具有 Agent 與 Action 能力。
但這家公司第一階段不需要急著：
自動更新客戶紀錄。
自動關閉 Ticket。
自動建立報價。
先做到：
搜得到。
找得準。
能追來源。
權限正確。
這四件事跑穩。
再考慮低風險 Action。
如果第二階段要做 Action
可以從：
建立待辦。
準備 Jira Ticket 草稿。
整理維修摘要。
這些比較容易確認的工作開始。
而且每種 Action：
都要另外限制：
哪些人可以使用。
哪些 Agent 可以使用。
不能因為 Search 是唯讀：
就推論所有後續 Action 都一樣低風險。
企業搜尋真正的價值，是把「找人問」變成「先找公司」
以前工程師可能習慣：
先打電話問老王。
老王再說：
「那份文件應該在某個資料夾。」
這就是：
人的記憶在替公司做搜尋引擎。
企業知識平台如果做得好：
第一步可以先變成：
先搜尋公司已經留下來的知識。
找不到。
再問人。
這樣資深員工的時間才不會一直花在：
「檔案在哪裡？」
但人仍然非常重要
因為真正的工作經驗：
不可能全部結構化。
現場的：
聲音。
氣味。
設備狀態。
客戶使用方式。
環境差異。
都可能改變判斷。
所以這個案例不是：
Glean 取代工程師。
而是：
讓工程師到現場以前，不必先當公司資料偵探。
今天最容易犯的錯
公司看到 Glean 可以跨很多工具搜尋。
第一天就說：
「把公司全部資料接進去。」
不要。
這家公司真正需要的第一個問題只有：
一件維修案件進來時，工程師需要哪些背景？
可能只有：
CRM。
技術手冊。
工程討論。
技術問題追蹤。
先接這些。
先證明：
真的省時間。
真的找到正確來源。
沒有權限問題。
再擴大。
今天最重要的商業判斷
這家 10 人商用冷凍設備公司真正值得學的，不是：
「維修公司也可以買 AI。」
而是：
AI 要真正進企業，常常第一步不是讓它做更多，而是先讓它知道公司已經知道什麼。
客戶資料在 Salesforce。
手冊在 Drive。
經驗在 Slack。
技術問題在 Jira。
對員工來說：
這些不是四套軟體。
它們其實都是：
同一件工作的不同碎片。
Glean 的價值就是嘗試把這些碎片重新接成一個可以搜尋、可以引用、可以依權限使用的企業 Context。
但找到資料不等於：
完成維修。
也不等於：
取得正式決策權。
真正成熟的流程應該是：
AI 找背景。
AI 指出來源。
AI 發現衝突。
人檢查現場。
人做專業判斷。
人對價格、安全與客戶承諾負責。
如果最後真正量到：
工程師找資料時間下降。
正確來源找到率提高。
錯用舊文件下降。
第一次到場解決率改善。
那 Glean 才不只是：
「公司多了一個 AI 搜尋框。」
而是真的開始變成：
每天工作流程的一部分。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
AI 商業案例｜2026/08/01：物業管理公司怎麼用 Claude Sonnet 5？從報修分類、廠商安排到住戶通知，遇到費用與正式變更先停
