7 小時解決率的客戶支援：知識圖譜如何將工單時間縮短 75%

要點總結

• LinkedIn 的 GraphRAG 生產部署將檢索準確率提升了 77.6%，並將問題解決時間縮短了 28.6%——同樣的模式適用於任何在互不相連的文件系統中搜尋的 B2B SaaS 支援團隊。
• 一家擁有 320 名員工、每週處理 2,400 張工單的 B2B SaaS 公司平均每張工單花費 28 小時——在 Confluence、Jira 和 3 份產品文件中進行 6 次手動搜尋，45% 的一級工單被升級，因為坐席找不到正確答案。
• 向量搜尋回傳語意相似但結構錯誤的結果——一個針對舊版 API 的臨時方案會出現在當前 API 的問題中，因為向量相似度不理解版本相容性、產品依賴關係或問題解決鏈。
• 一個了解產品依賴關係、API 版本相容性和問題解決歷史的知識圖譜可將解決時間縮短至 7 小時，升級率降至 18%——圖譜遍歷的是向量搜尋看不到的關係。

問題：每張工單 28 小時，45% 的升級率

一家擁有 320 名員工的 B2B SaaS 公司使用 Zendesk 進行工單管理，Confluence 作為知識庫，Jira 追蹤工程問題。支援團隊——18 名坐席每週處理 2,400 張工單——從開啟到解決平均每張工單花費 28 小時。瓶頸不在坐席的努力程度。瓶頸在於搜尋。

每張工單都需要坐席在 4 個系統中搜尋：Confluence（產品文件）、Jira（已知問題和缺陷狀態）、API 參考站點和內部操作手冊 wiki。一名坐席平均每張工單搜尋 6 次，每次 15 分鐘。這意味著每張工單在撰寫任何回覆之前就需要 90 分鐘的搜尋時間。對於一個每週處理 2,400 張工單的團隊來說，這就是 3,600 小時的搜尋時間——相當於 22 名全職坐席除了搜尋什麼都不做。

搜尋結果不一致。同一張工單會因處理坐席不同而得到不同答案，因為每位坐席搜尋方式不同，找到的文件也不同。一級坐席將 45% 的工單升級到二級，因為他們找不到合適的文件——不是因為問題困難，而是因為文件分散在 4 個系統中，沒有統一索引。

更深層的問題是，向量搜尋——大多數 AI 輔助支援工具背後的檢索方法——回傳的是語意相似但結構錯誤的結果。一位客戶詢問 API v3 中的某個錯誤。向量搜尋回傳的是 API v1 的臨時方案，因為文本在語意上相似。坐席閱讀後發給客戶，客戶回覆說不管用。這又產生了第二個工單週期，又是 28 小時，以及 CSAT 下降。

向量搜尋不理解 API v3 已棄用了臨時方案所引用的端點。它不知道該問題已在 Jira 工單 ENG-4471 中解決，修復已在 3.2.1 版本中發布。它不知道客戶的整合使用的是 OAuth 流程，而不是 API key 流程，因此故障排查路徑不同。這些是關係，而非文本相似性——而知識圖譜正是編碼這些關係的資料結構。

手動支援工作流與 GraphRAG 編排的工作流對比——當知識圖譜取代向量搜尋時會發生什麼變化：

代理編排的解決方案：GraphRAG 檢索

解決方案是一個基於公司產品文件、Jira 問題和 Confluence 頁面構建的知識圖譜。圖譜的節點是產品、功能、API 端點、問題、臨時方案和客戶。其邊是依賴關係（功能 A 依賴功能 B）、版本相容性（端點 X 存在於 v2.4+，在 v3.0 中棄用）、問題解決鏈（問題 ENG-4471 由版本 3.2.1 解決）以及產品-客戶映射（客戶使用 OAuth 流程，而非 API key 流程）。

GraphRAG 檢索遍歷圖譜以找到確切答案，而非語意相似的猜測。當客戶詢問 API v3 中的某個錯誤時，圖譜遍歷路徑為：API v3 端點 → 版本相容性檢查 → v3 中已棄用的端點 → 該端點的已知問題 → 解決鏈（ENG-4471 → 版本 3.2.1）→ v3 的有效臨時方案。代理檢索的是帶引用的結構化答案，而非文字區塊。

IdeaBosque 技術堆疊將其落地到真實系統中：

• MCP 模組 連接 Zendesk（工單上下文：客戶、產品、嚴重程度）、Jira（問題狀態：開放、進行中、已解決、已發布版本）和 Confluence（文件：API 參考、操作手冊、整合指南）。每個系統都作為代理呼叫的型別化工具暴露——get_ticket_context、search_issues、get_documentation、get_release_notes。
• 知識圖譜 編碼了 4,200 個節點（產品、功能、端點、問題、臨時方案）和 8,500 條邊（依賴關係、版本相容性、解決鏈、客戶映射）。圖譜是檢索引擎——而非向量儲存。
• A2A 委派 讓支援代理交接子任務：分流代理對工單分類，檢索代理遍歷圖譜，升級代理在問題為新問題時路由到二級。每個代理各司其職。
• 人工在環——代理起草帶引用的回覆，由支援坐席審核並發送。對於圖譜中不存在的新問題，代理升級到二級，並附帶它搜尋了什麼以及無法找到什麼的結構化摘要。

結果：對業務的影響

指標	手動工作流	代理編排
平均解決時間	28 小時	7 小時
每張工單搜尋次數	6 次手動（90 分鐘）	1 次圖譜遍歷（30 秒內）
一級升級率	45%	18%
答案一致性	同一工單，不同答案	帶引用的結構化答案
自助服務分流	10%（知識庫搜尋）	30–40%（GraphRAG 驅動的自助服務）
技術工單的 CSAT	72%	87%（+15 個百分點）
坐席搜尋工時	3,600 小時/週（相當於 22 名 FTE）	600 小時/週（相當於 4 名 FTE）

從 28 小時壓縮到 7 小時是頭條數字。但其背後的營運變化更為重要。一級坐席無需升級即可解決 82% 的工單（從 55% 提升），因為圖譜遍歷能找到他們手動搜尋無法找到的答案。自助服務分流從 10% 提升到 30–40%，因為 GraphRAG 檢索能在首次嘗試時回傳正確答案——客戶自己找到答案，而不是開工單。

每週 3,600 小時的搜尋時間降至 600 小時。這相當於 18 名全職坐席從搜尋中解放出來去處理真正的客戶問題——或者更現實地說，一個團隊能以 8 名坐席而非 18 名來處理每週 2,400 張工單。

技術工單的 CSAT 改善——從 72% 到 87%——源於答案的準確性。圖譜回傳的是針對客戶 API 版本的正確臨時方案，而非針對不同版本的看似合理的猜測。這就是一次性解決與第二個工單週期之間的區別。

相關閱讀

• 用於客戶支援的 GraphRAG：知識圖譜如何回答你的資料庫無法回答的問題——77.6% 檢索準確率提升背後的技術架構，附 LinkedIn 生產部署詳情
• MCP + A2A：每個生產級代理 AI 系統背後的兩個協定——將 Zendesk、Jira 和 Confluence 連接為代理呼叫的型別化工具的協定堆疊
• 獨立 AI 代理如何協同工作：Hermes 代理的 A2A 橋樑——讓分流、檢索和升級代理相互交接工作的 A2A 委派模式

---

一家擁有 320 名員工的 B2B SaaS 公司，因在 4 個互不相連的系統中手動搜尋，每張支援工單損失 28 小時。一級坐席將 45% 的工單升級，因為他們找不到合適的文件。一個基於產品依賴關係、API 版本相容性和問題解決鏈構建的 GraphRAG 知識圖譜，將解決時間縮短至 7 小時，升級率降至 18%，並讓 14 名坐席從搜尋中解放出來去處理真正的客戶問題。圖譜遍歷的是向量搜尋看不到的關係。

申請一次範圍明確的構建

一週的發現期。您將獲得系統清單、工作流地圖和固定範圍——無論是否與我們合作構建。