Arova Nexus Phase 0
Arova Nexus Phase 0
所屬模組： Service Desk（可選）
Wireframe： 開啟互動原型 → 側邊欄「工單管理」
IT 服務請求散落在 Email、Line、口頭交辦，沒有統一追蹤。主管簽核靠紙本或 Email 轉寄。SLA 無法管理——沒人知道哪張工單快超時了。
員工寄 Email 到 IT helpdesk 信箱即可提交服務請求，零學習成本。系統自動解析寄件人、主旨、內文和附件。
非 IT 請求過濾：AI 判斷非 IT 相關問題（如 HR、財務）時，自動回覆「請聯繫 XX 部門」，不進入工單系統。
AI 意圖分類：AI 先判斷 Email 的意圖類型，再走不同處理路徑：
| 意圖 | 判斷依據 | 處理路徑 |
|---|---|---|
| 🔧 問題排障 | 「壞了」「連不上」「錯誤」「無法」等描述現有問題的語氣 | → KB 信心度分層回覆（下方） |
| 📋 服務申請 | 「申請」「需要」「開通」「安裝」等提出新需求的語氣 | → 引導填表回覆（下方） |
| ❓ 不明/非 IT | 無法判斷或非 IT 相關 | → 回覆「請聯繫 XX 部門」或建工單由人工分類 |
服務申請引導填表：當 AI 判定為服務申請時，系統回覆 Email 引導員工到服務目錄填寫正式表單：
回覆範例：
您好，我們收到您的 VM 申請需求。
為了加速處理，請點擊以下連結填寫正式申請表：
👉 [填寫 VM 申請表單]（Token 連結，72 小時有效）
填寫後系統會自動進行合規檢查、主管簽核和自動建置。
如需協助，直接回覆此 Email。
Phase 2 擴充：AI 直接從 Email 內文提取結構化欄位（CPU / Memory / Port 等），缺少必填欄位時自動回覆追問，全程在 Email 中完成，不需要點連結填表。
AI 分類（問題排障路徑）：IT 相關問題由 AI 自動擷取類別（VPN / Email / 帳號 / ...）、急迫度（從語氣和內容推斷）、關鍵字和 error code。
KB 信心度分層回覆（SD-030 中信心混合回覆）：AI 搜尋知識庫後，依信心度決定回覆策略：
| 信心度 | 回覆策略 | 說明 |
|---|---|---|
| ≥ 0.80（高） | 回覆解決步驟 | 「以下步驟可能有幫助：1. ... 2. ... 如未解決請回覆」（Deflection 候選） |
| 0.50-0.79（中） | 混合回覆：回參考文章 + 同時自動建單 | 「IT 已建立工單會處理（REQ-XXXX），同時這些文章可能對您有幫助：...」 |
| < 0.50（低） | 直接建立工單 | 不回覆無意義的 Email，直接建單通知工程師 |
為什麼中信心改混合回覆？ 早期版本中信心層只回參考文章不建單，員工有「被打發」感受 + IT 容易錯過真正需要處理的工單。改為「同時回參考 + 建單」雙保險：
Email 文案範例（中信心層）：
您好，我們收到您的問題，IT 團隊已建立工單（REQ-XXXX）開始處理。
同時，以下文章可能對您有幫助：
📖 KB-042 ...
📖 KB-058 ...
（請避免「請先自助參考」「請先嘗試」等暗示「先自助」的詞）
若高信心員工回覆「還是不行」，系統正式建立工單，附上完整 context（原始問題 + 已嘗試步驟 + error code + AI 分析）。
錯誤處理：
| 情境 | 處理方式 |
|---|---|
| Email 格式無法解析 | 建立工單，原始 Email 作為附件，標記 ai_processed: false |
| AI 分類信心度低 | 建立工單但不自動分派，由 IT 主管手動分類 |
| 員工 Email 不在系統中 | 自動回覆「請聯繫 IT 部門確認帳號」，不建立工單 |
| Deflection 超時 | 自動回覆後 24 小時無回覆，標記為「可能已解決」 |
員工全程使用 Email，IT 工程師全程使用工單系統，兩邊的對話無縫串接：
AI 自動回覆成功解決的問題不會建立工單，計為 Ticket Deflection。
Deflection Rate 計算（SD-030 微調）： 只有高信心度（≥ 0.80）+ 員工 24 小時內未再回覆才計入 Deflection。中信心混合回覆已建單，不算 deflect；低信心直接建單，自始不參與 deflection 計算。
Deflection Rate = 高信心自助解決數 ÷ (高信心自助解決數 + 正式建立工單數) × 100%
輔助指標： 中信心混合回覆另計「員工自助提早關閉率」 = 24 hr 內員工回覆「已解決，可關閉」的中信心工單數 ÷ 中信心工單總數 × 100%。此指標可看出 KB 在中信心區間的實際輔助效果。
預估 KB 內容足夠時 Deflection Rate 可達 20-30%。此指標同時出現在 分析報表 的 Ticket Deflection 報表範本中。
使用者自助瀏覽所有可申請的 IT 服務，每個服務有專屬的動態表單。不用打電話給 IT，自己點幾下就送出申請。
自動化綁定：管理員可為每個服務設定「簽核通過後自動觸發 Workflow」。例如「VPN 帳號申請」綁定「VPN 開通」Workflow，簽核通過後系統自動執行開通流程，零 IT 人工介入。工單詳情頁顯示 Workflow 執行狀態（執行中 / 完成 / 失敗）。詳見 自動化 的觸發方式說明。
綁定 UI（SD-012 AC④）：管理員於服務目錄頁每張服務卡片右上角見編輯 icon（End User 視角隱藏），點擊展開 modal-edit-service-catalog 設定：
| 欄位 | 說明 |
|---|---|
| 服務名稱 / 分類 / 描述 | 基本資訊 |
| 綁定 Workflow | 下拉選已發布 Workflow 清單（或「不綁定」） |
| 簽核通過後自動觸發 | 開關 toggle；綁定後預設開啟 |
| 失敗時通知 | 唯讀說明：Workflow 負責人 + 工單處理人 |
從提交到關閉的完整追蹤：新建 → 待處理 → 處理中 → 待簽核 → 已解決 → 已關閉。每個狀態變更都記錄在時間軸上，使用者和 IT 人員都能看到。工單解決時系統自動寄 Email 通知使用者（含修復說明），使用者全程只需使用 Email 即可。
依優先級自動套用回應和解決時間。工單佇列預設依 SLA 剩餘時間排序——快超時的排最前面（黃色），已超時的用紅色標示。
SLA 計算方式：
Filter Tabs（7 個，對齊工單生命週期）：
[全部] [待處理] [處理中] [等待中] [待簽核] [已解決] [已關閉]
每個 tab 後顯示即時計數（5 秒內隨工單狀態變更更新）。預設選「全部」。
列表欄位（6 欄，從原 9 欄整併）：
| 欄位 | 內容 |
|---|---|
| 優先級 | 緊急 / 高 / 中 / 低 badge |
| 編號+標題 | 標題為主文，工單編號小字標於下方；點整格進詳情頁 |
| 類型 | emoji icon：💬 Request / 🔧 Change / ✅ Task；hover 顯示完整名稱 |
| 申請人→處理人 | 合一格顯示「申請人 → 處理人」；未指派時 → 後顯示「未指派」灰字 |
| 狀態+SLA | 上方狀態 badge / 下方 SLA 倒數；超時紅、剩 < 25% 黃；Task 類型顯示「無 SLA」灰字。等待中狀態加子說明 ⏸ SLA 暫停（SLA 倒數標 ⏸ 灰字）；待簽核狀態加子說明 📋 等主管簽核；其他 4 狀態無子說明（語意已清晰，避免冗餘） |
⋯ |
行末 overflow icon button（見下方） |
為什麼整併？ 從 9 欄 → 6 欄，掃描速度大幅提升；申請人 / 處理人合一格節省常空欄寬；類型 emoji icon 比 badge 更省版面；狀態 + SLA 在同欄因為兩者高度相關。
行末 ⋯ overflow menu（SD-028）： 取代原本「指派 / 審核 / 狀態」三個含意不一致的文字按鈕，依工單狀態顯示對應動作：
| 狀態 | menu 內容 |
|---|---|
| 待處理 | 指派 / 接手 / 拒絕 |
| 處理中 / 等待中 | 更新狀態 / 轉派 |
| 待簽核（主管視角） | 核准 / 退回 |
| 待簽核（非主管） | ⋯ 隱藏 |
| 已解決 / 已關閉 | ⋯ 隱藏 |
排序： 預設依 SLA 剩餘時間升序（已超時最前），SLA 同等級依建立時間升序。Task 類型（無 SLA）排在最後。
工單管理頁面 KPI 卡片的計算方式：
| 指標 | 計算方式 | delta 比較基準 |
|---|---|---|
| 未結工單 | count(tickets WHERE status ∉ {已解決, 已關閉}) | vs 24 小時前 |
| 待簽核 | count(tickets WHERE status = 待簽核) | 顯示靜態提示「需主管處理」 |
| 本月提交 | count(tickets WHERE created_date ∈ 當月 1 日~今日) | vs 上月同期（上月 1 日~上月同日） |
| SLA 達標率 | 當月加權達標率 = Σ(各優先級達標數) ÷ Σ(各優先級總數) × 100% | vs 上月同期達標率，百分點差 |
Filter Tab 數字定義：
需要主管核准的申請自動進入簽核佇列。支援多級串聯簽核、Email 一鍵核准、逾時自動提醒。
IT 人員處理工單時，可以拆出子任務指派給其他同事。母工單可以看到所有子任務的進度。
防火牆規則變更、系統升級等變更申請，有獨立的表單和簽核流程。未來版本加入 AI 風險摘要。
工單詳情頁固定 4 個 tabs，避免資訊密度過高（與事件詳情頁簡化後一致）：
| Tab | 內容 |
|---|---|
[詳情] |
上方：AI 分析摘要（分類、急迫度、關鍵字、可能原因、KB 推薦）；下方：申請內容、附件 |
[溝通] |
整合 Email + 留言為單一 thread，每筆標來源（💬 留言 / 📧 Email），保留「僅內部」標示 |
[時間軸] |
狀態變更歷程（每次更動含操作人、時間、說明） |
[子任務] |
從本工單拆出的子任務清單（SD-024） |
為什麼合併「Email 溝通」與「留言」？ 兩者都是訊息往來，差別只在通道；End User 不知有別、IT 視角看完整 context 反而需要統一 thread。
「AI 分析」改入詳情 tab 上方：與事件管理同樣模式，第一眼就看到 AI 摘要不必切 tab。
合規檢查改徽章 + modal：工單合規檢查發現違規時，標頭顯示紅色徽章 ⚠️ 合規檢查（N 項違規），點擊開 modal 列違規清單與對應規則。無違規時不顯示徽章 — 99% 工單詳情頁少 1 個 tab。
Email 來源 AI 加值（保留）： Email 來源工單在「詳情」tab 上方額外顯示「原始 Email 全文」與「AI 自動回覆紀錄」（若有 deflection 嘗試），其他 tab 結構不變。
自動化執行區塊（SD-012 AC④ + 綁定 Workflow 後顯示）：當工單源於服務目錄且該服務已綁定 Workflow 時，「詳情」tab 增加「自動化執行」區塊：
| 欄位 | 內容 |
|---|---|
| Workflow 名稱 + 版本 | 例「VPN 申請開通 v2」 |
| 執行狀態 | Badge：🔄 執行中 / ✓ 完成 / ✗ 失敗 / ⏸ 等待簽核 |
| 執行 ID | 連結，點擊跳 page-workflow-run 該次執行追蹤 |
| 開始時間 + 總耗時 | 時間戳記與耗時秒數 |
| 失敗時 | 顯示錯誤摘要 + 「重試」按鈕（從失敗節點重新執行） |
工單 MUST NOT 因 Workflow 失敗自動標為「已解決」，避免假完成。
標頭依工單狀態 + 使用者角色決定主動作（顯眼）與 overflow（⋯ menu），同時最多顯示 2~3 個主動作（Hick 定律）：
| 工單狀態 | 主動作 | overflow ⋯ |
|---|---|---|
| 待處理 | [接手][指派] |
拒絕 / 升級為 Incident |
| 處理中（含「等待中」子狀態） | [更新狀態][+ 子任務] |
轉派 / 升級為 Incident |
| 待簽核（主管專屬） | [核准][退回] |
加註留言 |
| 待簽核（非主管） | （無主動作） | — |
| 已解決（主管專屬） | [關閉] |
重新打開 |
| 已解決（非主管） | （無主動作） | 重新打開（限工程師判斷修復失敗） |
| 已關閉 | （無主動作） | — |
「升級為 Incident」是低頻動作（< 5%），固定放 overflow 不佔主位。
MUST NOT 顯示「AI 分析」按鈕 — 與「AI 分析」tab 命名衝突造成行為混淆；AI Copilot 入口改用右下角常駐 FAB（與事件管理已採用模式一致）。
工單調查過程中如果發現是系統性問題（例如多人報修 VPN 壞了，調查後發現是 VPN 伺服器故障），可點 overflow menu 的「升級為 Incident」— 注意這不是 convert（轉換），而是 ITIL 標準的 escalate-and-link：原工單保留並變終態「已升級」、新事件建立、雙向關聯。
升級時系統動作（atomic）：
escalated_from_ticket權限： IT Staff / IT Manager / Admin 可升級；其他角色 overflow menu 隱藏此選項。
為什麼不做 true conversion？ ITIL v4 定義 Service Request 與 Incident 是不同 ontology（「要求」vs「中斷」），convert 語意錯誤；業界標竿（ServiceNow / BMC Helix / Jira SM）也都用 escalate / link 不用 convert。詳見 產品指南首頁術語表。
事件誤報關閉後原工單處置： 若升級後的事件被判定為誤報關閉（IN-005 / IN-030），原工單 MUST NOT 自動解凍 SLA；工程師需手動於工單 overflow「重新打開」恢復「處理中」並重啟 SLA（稽核留存操作）。
對稱於工單升級為事件，事件也可從詳情頁 overflow menu 「建立關聯工單」快速建立關聯工單（例：事件發現需要申請變更 → 建立 Change Request；或事件需要使用者端驗證 → 建立 follow-up Request）。此動作採 create-related 模式，原事件狀態不變。詳見 事件管理 PG-04。
工單狀態生命週期新增終態「已升級」：
| 終態 | 觸發條件 | SLA 處理 |
|---|---|---|
| 已關閉 | 走完標準流程或被關閉 | 關閉時停止 |
| 已升級 | 工單升級為 Incident（SD-027） | 升級時間點停止，事件 MTTR 接管 |
SD-029 工單列表「已關閉」tab 計數含「已升級」子類；tab 內以 badge 區分：一般「已關閉」灰底 / 「已升級」灰底 + 🔼 icon + tooltip「已升級為事件 INC-YYY」。Analytics 工單 SLA 達標率計算時，「已升級」工單以「升級時間點 − 建立時間」判定，不算入事件處理時間。
管理員在「設定 > Email 設定」配置 Email 通道的參數：
| 設定項目 | 說明 | 預設值 |
|---|---|---|
| IT Helpdesk 信箱 | Inbound Email 地址（如 it-support@company.com） | — |
| 非 IT 請求過濾 | AI 判斷非 IT 問題時自動回覆引導到正確部門 | 啟用 |
| AI 自動回覆 | Email 收到後 AI 搜尋 KB 並依信心度回覆 | 啟用 |
| KB 信心度門檻 | 高信心（回覆解決步驟）≥ 0.80 / 低信心（直接建工單）< 0.50 | 0.80 / 0.50 |
| Deflection 等待時間 | 自動回覆後多久無回覆視為已解決 | 24 小時 |
| 結案通知 | 工單解決時自動寄 Email 通知申請人 | 啟用 |
管理員可在此頁面調整門檻值（例如降低高信心門檻到 0.75 讓更多問題觸發自動回覆）。
一般使用者王小明需要 VPN 帳號：
- 在服務目錄選「VPN 申請」
- 填寫原因、選權限類型、送出
- 主管收到通知，在簽核佇列核准
- IT 團隊收到工單開始處理
- 開通完成，小明在「我的請求」看到狀態變成「已解決」
IT 維運人員陳大文每天早上：
- 打開工單佇列，看到 12 張待處理
- SLA 快超時的 REQ-0042 排在最上面（紅色）
- 點進去看申請內容，開始處理
- 需要同事協助，拆一個子任務給李維運
- 處理完畢更新為「已解決」，使用者自動收到通知
員工提交 IT 請求時，系統自動比對 Policy Rules（合規規則），在提交前檢查是否符合內部規範：
詳見 合規智能 模組說明。
| 版本 | 功能 |
|---|---|
| v0.1 MVP | 工單 CRUD + 服務目錄 + 基礎 SLA + 簽核 + 工單合規檢查（Layer 1 精確規則） |
| v0.2 | 子任務 + 標籤 + 自動分派規則 |
| v0.3 | AI Triage Agent + AI 風險摘要（變更類型） |
| v1.0 | SLA 報表 + 獨立任務 + AI 重複工單偵測 |