傑出作業 - 工作人員模式

深入瞭解結構良好的營運傑出 → 代理企業傑出營運

模式

要尋找的位置良好的外觀
Agentforce | 工作階段追蹤✅ 使用原生工作階段追蹤資料模型 (STDM),在 Data 360 上的統一資料模型中捕捉工作人員互動,而不是建立並列距離測試系統—將每個交談記錄為工作階段、互動 (輪數) 和步驟的追蹤階層 (UserInputStep、LLMExecutionStep、FunctionStep)
Agentforce | 工作階段追蹤✅ 依賴標準 STDM 物件 (AIAgentSession、AIAgentSessionParticipant、AIAgentInteraction、AIAgentInteractionStep、AIAgentInteractionMessage),這些物件會以互動步驟的原生方式來捕捉動作,而不需要個別的動作記錄
Agentforce | 工作階段追蹤✅ 透過將互動步驟聯結至其 LLM 呼叫記錄 (透過 GenerationId 和 GenAiGatewayRequest/Response 參照),而非將這些步驟儲存為自訂工作階段欄位,以取得權杖用量、模型和提示詳細資料
Agentforce | 工作階段追蹤✅ 從「Atlas 推理引擎」 (工作階段追蹤記錄計畫者步驟作為每個互動一部分) 的推理追蹤,以顯示工作人員決策流程並改善除錯性
Agentforce | 工作人員組態✅ 記錄輪次層級詳細資料,包括使用者輸入、工作人員回應、推理說明、信賴分數、已提取內容、已嘗試的動作和發生錯誤
Einstein | Trust 圖層✅ 開啟 Einstein Trust Layer 生成式 AI 稽核追蹤 (提示與回應文字、PII 遮蔽版本、奠基資料、安全性和毒性分數、模型詳細資料) 串流至 Data 360,以及 Einstein 生成式 AI 和回饋意見資料收集與儲存,以進行長期保留
平台 | 自訂物件✅ 將自訂記錄物件保留給刻意例外狀況,例如將工作人員行為與業務成果相關聯的輕量型物件,而非將其設為主要記錄基底
平台 | 顯示面板✅ 將工作人員行為與業務成果相關聯、透過模式分析識別改善機會,並使用品質標記的範例摘要持續學習銷售管道

反模式

要尋找的位置看起來怎麼壞
平台 | 自訂物件⚡️ 手動建立自訂交易物件作為主要對話記錄基底,而非原生工作階段追蹤資料模型,因應儲存多輪對話、大型 JSON 裝載和快速資料成長的規模問題
Agentforce | 工作階段追蹤⚡️ 當 Agentforce 工作階段追蹤已在 Data 360 的統一資料模型中捕捉互動時,建立平行距離測試系統
Agentforce | 工作人員組態⚡️ 僅記錄工作人員的回應,而無須採取輸入、推理追蹤、已提取內容和所採取的動作
Einstein | Trust 圖層⚡️ 在生產環境中停用 Einstein Trust Layer 稽核追蹤,或不開啟「回饋意見資料收集與儲存」,以便在 Data 360 中長期保留
平台 | 監視⚡️ 僅依賴對話成功/失敗,而無須透過 STDM LLM 呼叫聯結來獲取權杖用量、模型和提示詳細資料

模式

要尋找的位置良好的外觀
平台 | 監視✅ 在百分位數 (p50、p95、p99) 中測量回應延遲,顯示一般效能與最差個案體驗
平台 | 監視✅ 個別為每個延遲階段進行儀器處理 (模型推斷、內容尋找、動作執行、網路),以啟用目標最佳化
平台 | 監視✅ 當 p95 延遲超過指示效能降級的值時顯示警示
平台 | 監視✅ 追蹤每個交談、每個工作人員和每個使用個案的權杖散佈 (提示權杖、完成權杖、權杖總數)
平台 | 監視✅ 偵測耗用過多權杖的異常對話,提示問題或不當使用
平台 | 監視✅ 將目前的輸送量與已知的比率限制或即將到達的容量基準警示進行比較
平台 | 監視✅ 計算錯誤率的要求總數百分比,以便在工作人員和期間之間進行比較
平台 | 監視✅ 區分需要不同的回應的錯誤種類 (模型錯誤、權限錯誤、整合錯誤)
平台 | 監視✅ 以工作人員成功回應要求的時間百分比計算可用性,並針對 SLO 進行追蹤
平台 | Proactive Monitoring✅ 根據基準工作人員行為模式設定「Proactive Monitoring」(主動監視),而非接受預設值
平台 | 規模中心✅ 在部署新工作人員或進行重大提示變更後檢閱「刻度中心」資料,驗證資源耗用符合期望

反模式

要尋找的位置看起來怎麼壞
平台 | 監視⚡️ 僅測量平均延遲,而非百分位數,遮蔽最差的使用者體驗
平台 | 監視⚡️ 追蹤總延遲,而無須儀表個別階段 (推斷、提取、動作執行)
平台 | 監視⚡️ 將所有錯誤視為相同,而非依類型 (模型、權限、整合) 分類以取得適當的回應
平台 | Proactive Monitoring⚡️ 接受預設的 Proactive Monitoring 值,而無須調整基準工作人員行為模式
平台 | 規模中心⚡️ 部署新工作人員或進行提示變更,而無須檢閱「規模中心」資料以驗證資源耗用
平台 | 監視⚡️ 忽略權杖耗用模式並無法偵測耗用 10 倍一般權杖的異常對話

模式

要尋找的位置良好的外觀
Agentforce | 測試中心✅ 從原生測試和評估工具開始:在 Agentforce 測試中心維護可重複使用的測試個案集,並批次對其執行工作人員,檢查工作人員是否選取預期的主題和動作,並產生可接受的回應
Agentforce | 測試中心✅ 使用原生評估程式—立即可用的品質維度和評估對話品質的 LLM-as-judge 方法,並針對組織特定的條件使用編寫自訂評估程式,以使用代表對話,讓評估反映實際用量
Agentforce | 測試中心✅ 針對具有已知回答的實際問題,請在測試中心將已知回答判斷式維持為可重複的測試個案;針對未結束問題,請新增已取樣對話的人類檢閱
Data 360 | 檢索品質✅ 針對以 Knowledge 庫為基礎的工作人員,請使用原生取得品質分析來評估內容相關性、回答相關性,以及回應的忠誠度 (基礎)
Einstein | Trust 圖層✅ 依賴 Einstein Trust Layer 執行階段毒性偵測作為防線第一線,然後透過內容篩選、手動檢閱取樣、使用者報告和人口統計群組之間的公平性稽核來改善安全監視
Data 360 | GenAIFeedback✅ 透過 Agentforce 回饋意見流入至 Data 360 中的 GenAIFeedback/GenAIFeedbackDetail DMO (姆指朝上/朝下、接受/拒絕、編輯、文字記錄) 並產生資料
平台 | Analytics✅ 將明確的回饋意見 (在升級前、交談後、後續調查後要求的回饋意見) 與隱含的訊號 (完成率、升級、捨棄、重試) 結合,與交談特性產生關聯,以引導改善優先順序

反模式

要尋找的位置看起來怎麼壞
Agentforce | 測試中心⚡️ 建立並執行自訂測試機器,而非使用 Agentforce 測試中心的可重複使用測試集和原生評估程式
Agentforce | 測試中心⚡️ 僅依賴無人類審查的自動評估來評估未結束回應的品質
平台 | 監視⚡️ 僅監視準確性,而不追蹤相關性、安全性和使用者滿意度維度
Data 360 | GenAIFeedback⚡️ 當 Agentforce 回饋意見已經流入 GenAIFeedback DMO 時,無法收集有關工作人員回應品質的任何使用者回饋意見 (明確或隱含)
Agentforce | 工作人員組態⚡️ 略過評估人口統計群組中成果分佈的公平性稽核

模式

要尋找的位置良好的外觀
Agentforce | 工作人員組態✅ 在工作人員部署測量代表測試個案的準確性、相關性、安全性和滿意度後,立即建立基準效能
Agentforce | 工作人員組態✅ 根據相同的測試個案定期重新評估,以顯示與使用模式排班無關的效能變更
平台 | 監視✅ 當品質度量下降超出業務影響容忍度所定義的可容忍度值時警示
平台 | Analytics✅ 監視輸入特性 (問題長度、主題散佈、語言複雜度、網域術語),偵測明顯的散佈排班
平台 | 監視✅ 監視回應特性 (平均回應長度、動作叫用率、升級頻率、錯誤模式),以建立行為基準
平台 | 監視✅ 設定當漂移度量超出觸發調查和補救措施時觸發自動警示

反模式

要尋找的位置看起來怎麼壞
Agentforce | 工作人員組態⚡️ 初始工作人員部署後無法建立基準效能,因此無法偵測到漂移
平台 | 監視⚡️ 當使用者輸入模式與設計工作人員處理的內容有顯著變化時忽略散佈漂移
平台 | 監視⚡️ 未根據建立的基準監視行為變更 (回應長度、動作率、升級頻率)
平台 | 監視⚡️ 沒有漂移度量的自動警示,僅依賴手動觀察以偵測降級

模式

要尋找的位置良好的外觀
平台 | 監視✅ 監視偵測異常對話的權杖耗用散佈,並調查耗用 10 倍一般權杖的對話
平台 | 監視✅ 偵測失敗率突然增加、新錯誤類型不在基準中,或影響特定使用者或工作人員的當地語系化錯誤集中情況
平台 | Analytics✅ 依識別使用者在初始互動、交談中或工作完成後是否捨棄的交談階段追蹤交談捨棄情況
平台 | 監視✅ 將重要工作人員失敗立即路由至通話工程師、在營業時間對產品小組的品質降級,以及每日摘要的次要異常

反模式

要尋找的位置看起來怎麼壞
平台 | 監視⚡️ 以相同的緊急率處理所有警示,造成警示疲勞和錯過的重大失敗
平台 | 監視⚡️ 忽略成本異常,例如權杖耗用高峰可能表示提示問題、濫用或基礎結構問題
平台 | Analytics⚡️ 未追蹤交談捨棄率或無法依階段分析捨棄
平台 | 監視⚡️ 等待使用者報告,而非透過自動監視主動偵測錯誤率高峰

模式

要尋找的位置良好的外觀
平台 | 來源控制✅ 將提示範本與應用程式程式碼同時儲存在 Git 中,將提示視為值得程式碼檢閱、測試和控制部署的重要應用程式邏輯
Einstein | 提示詞產生器✅ 使用提示詞產生器來使用版本歷程記錄和測試功能來重複提示開發,然後匯出至部署管道的版本控制
平台 | 來源控制✅ 將組態 (模型選取項目、溫度、權杖限制、提取組態、動作權限、功能標記) 儲存為程式碼,以啟用環境特定的值和漂移偵測
平台 | 來源控制✅ 將語意版本套用至工作人員元件:主要 (中斷變更)、次要 (功能)、修補程式 (程式錯誤修正) 和記錄中顯示版本號碼
平台 | 文件✅ 記錄變更的內容、變更的原因、驗證變更的測試,以及每個提示和組態變更都存在哪些回復程序

反模式

要尋找的位置看起來怎麼壞
Einstein | 提示詞產生器⚡️ 無須程式碼檢閱、測試或控制的部署流程,即可進行提示變更
平台 | 組態⚡️ 將工作人員組態儲存在來源控制之外,其中無法偵測到漂移且無法自動化部署
平台 | 文件⚡️ 在不記錄原因、測試結果或回復程序的情況下進行提示變更
平台 | 來源控制⚡️ 無法套用語意版本化,因此無法將事件與特定部署相關聯

模式

要尋找的位置良好的外觀
平台 | 文件✅ 維護模型登錄記錄,其中包含模型系列、特定版本、微調狀態、環境、部署日期和負責小組所部署的模型版本
平台 | 文件✅ 記錄每個工作人員部署,包括版本、環境、時間戳記、部署使用者、取得的批准和部署結果
平台 | 文件✅ 明確地對應工作人員、提示、Knowledge 庫、動作和整合之間的相依性,而不是在事件期間進行探索
業務 | 程序✅ 建立淘汰排程,並提前充分溝通保單支援的最低通知期間,以啟用計畫移轉,而非強制淘汰的緊急應變
平台 | 文件✅ 記錄每個工作人員的回復程序,包括目標版本、執行步驟、驗證測試和通知需求
平台 | 暫存✅ 在非生產環境中測試回復程序,驗證其在生產環境期間依賴這些程序之前的運作

反模式

要尋找的位置看起來怎麼壞
平台 | 文件⚡️ 僅在事件期間探索工作人員、提示和Knowledge庫之間的相依性,而非維護明確的相依性地圖
業務 | 程序⚡️ 提供不足的淘汰通知,強制執行緊急移轉而非計畫轉換
平台 | 文件⚡️ 在生產期間需要最多時會失敗的未經測試回復程序
平台 | 部署⚡️ 不記錄版本、環境、批准或成果的部署工作人員,無法將事件與部署相關聯

模式

要尋找的位置良好的外觀
平台 | UI✅ 系統收集明確的回饋意見 (姆指朝上/朝下、品質分數、註解) 和隱含的回饋意見 (完成率、升級頻率、重試模式)
Data 360 | 資料策劃✅ 透過篩選品質、移除有問題的範例、確保代表性和取消重複項目,來精密設計對話記錄至訓練資料集
Data 360 | 基礎✅ 主要透過在 Data 360 中奠基的 RAG 和提示調整 — Salesforce 原生適應路徑,讓工作人員適應網域詞彙、業務流程和組織特定的 Knowledge
Einstein | BYOLLM✅ 當奠基與提示調整不足時,請在外部微調模型並透過 BYOLLM 連線,而非預期在平台內產生微調
Einstein | 提示詞產生器✅ 建立定期提示檢閱步調,檢查最近對話、品質度量,以及識別改善機會的使用者回饋意見
Einstein | 提示詞產生器✅ 使用 A/B 測試在完整首展之前驗證改善方式,以增量方式實作提示變更
Agentforce | 工作人員組態✅ 維護涵蓋快樂路徑、邊緣個案、對手輸入和歷史問題案例的測試集,隨著發現新的邊緣個案而持續展開

反模式

要尋找的位置看起來怎麼壞
平台 | 資料⚡️ 嘗試改善,而不進行系統的回饋意見收集、進行改善猜測而非以資料為導向
Data 360 | 資料策劃⚡️ 使用未經精密設計的對話記錄進行訓練,包括安全違規、錯誤和非代表範例
Data 360 | 基礎⚡️ 在耗用 RAG 奠基和提示調整之前,請連絡外部微調,這是解決大多數網域調整需求的原生路徑,無須自訂模型
Einstein | 提示詞產生器⚡️ 將提示工程視為一次性的演練,而非根據使用模式演進調整的連續實作
Agentforce | 工作人員組態⚡️ 擁有永不展開的靜態測試集,以涵蓋在生產環境中發現的新邊緣個案

模式

要尋找的位置良好的外觀
平台 | 自訂中繼資料類型✅ 使用自訂中繼資料類型或自訂設定實作功能標記,以針對高風險工作人員變更,將部署與版本分離
平台 | 權限集✅ 使用控制工作人員存取權的權限集,先將工作人員變更釋出至小型使用者子集實作 canary 部署
Agentforce | 工作人員組態✅ 密集監控 canary 群組的成功率、品質、錯誤率、延遲、權杖耗用和滿意度,並僅在 canary 與執行先前工作人員版本的控制群組相符或改善時展開首展
平台 | Analytics✅ 開始避免不明確結果的 A/B 測試之前,請先定義成功條件,並符合業務目標
Agentforce | 工作人員組態✅ 部署 Champion-Challenger 測試以保留已驗證版本作為回復,同時與改善的挑戰者版本進行比較
業務 | 程序✅ 在促銷決策之前,建立目標促銷條件,包括最低樣本大小、品質值和評估持續時間

反模式

要尋找的位置看起來怎麼壞
Agentforce | 工作人員組態⚡️ 同時向所有使用者首展工作人員變更,而無須測試,最大化問題的爆炸半徑
平台 | 部署⚡️ 不使用功能標記部署高風險工作人員變更,無須重新部署即可啟用立即回復
平台 | Analytics⚡️ 在沒有預先定義成功條件的情況下執行 A/B 測試,導致結果不明確且決策不佳
平台 | Analytics⚡️ 執行樣本大小不足的實驗,產生可導致不正確結論的雜訊結果
Agentforce | 工作人員組態⚡️ 針對每個小型提示變更使用功能標記,而非將其保留給業務關鍵工作人員進行高風險變更

模式

要尋找的位置良好的外觀
平台 | 監視✅ 透過自動監視錯誤率、品質度量降級、成本異常、延遲增加和使用者升級的警示來偵測工作人員失敗
平台 | 監視✅ 使用使用者報告機制補充自動偵測,以啟用自動監視錯誤問題的升級
業務 | 程序✅ 根據使用者影響、爆炸半徑、資料完整性風險和復原急迫性,以客觀定義嚴重性條件
平台 | 文件✅ 將初始回應程序記錄為執行手冊,可由沒有深入工作人員專長的通話工程師執行
Agentforce | 工作人員組態✅ 在初始回應中包含:停用失敗的工作人員 (斷路器)、路由回復、收集診斷、通知利害關係人、起始事件通訊

反模式

要尋找的位置看起來怎麼壞
平台 | 監視⚡️ 依賴使用者報告作為主要偵測機制,而非自動監視工作人員失敗
業務 | 程序⚡️ 使用主觀嚴重性分類,這會導致實際問題的升級過低或小型問題的升級過多
平台 | 文件⚡️ 沒有執行手冊,需要在每次事件期間由具有深入工作人員專業知識的工程師進行事件特定調查
業務 | 程序⚡️ 以與傳統應用程式失敗相同的方式處理工作人員失敗,而不考慮幻覺、主題外回應或安全違規

模式

要尋找的位置良好的外觀
平台 | Apex✅ 使用可設定的錯誤值 (例如 50% 錯誤率)、持續時間範圍 (例如 5 分鐘滾動式時段) 和復原測試 (定期試用要求) 來實作斷路器
Agentforce | 工作人員組態✅ 設計回復階層:主要精密工作人員 → 更簡單的備份工作人員 → 靜態常見問題回應 → 人力轉移
平台 | 協調流程✅ 在協調流程層內實作回復邏輯,而非在個別工作人員內實作,以在工作人員生態系統之間啟用一致的行為
Agentforce | 工作人員組態✅ 設計保留交談內容、溝通交談原因的人工轉移工作流程,並路由至具有相關專業知識的適當的人工工作人員
平台 | 監視✅ 依照主題、工作人員和失敗原因監視轉移率,以識別工作人員功能缺口
Agentforce | 工作人員組態✅ 當複雜的推理失敗時,請回復至更簡單的邏輯;當即時資料無法使用時,請對快取的資料進行操作;當整合失敗時,請以唯讀模式進行作業
平台 | 協調流程✅ 定期測試回復路徑,並在需要時驗證其運作

反模式

要尋找的位置看起來怎麼壞
Agentforce | 工作人員組態⚡️ 沒有斷電器,允許失敗的工作人員在解決問題時重複影響使用者
平台 | 協調流程⚡️ 在個別工作人員內實作回復邏輯,而非在協調流程層,進而產生不一致的行為
Agentforce | 工作人員組態⚡️ 設計可完美運作或完全失敗的雙位元傳送/失敗工作人員,但沒有優良的降級選項
平台 | 協調流程⚡️ 切勿測試回復路徑,發現它們不僅在實際事件期間運作
Agentforce | 工作人員組態⚡️ 人性轉接會失去對話內容,強制使用者重複資訊

模式

要尋找的位置良好的外觀
業務 | 程序✅ 執行無罪的事件後審查,專注於系統改善,而非個別故障建立心理安全
業務 | 程序✅ 透過偵測、調查、回應、復原和使用時間戳記建立初始條件的詳細時間表
業務 | 程序✅ 使用「五個原因」技術,從症狀逐層細分至根本原因,而非簡化結論
業務 | 程序✅ 分析影響因素,包括監視缺口、測試缺口、文件缺口、自動化缺口和結構缺口
業務 | 程序✅ 評估偵測:哪些訊號應早於偵測到問題、哪些監視可加速偵測
業務 | 程序✅ 指定防止循環的具體、指派的時間繫結動作項目 (例如,「超過 10 分鐘超過 5% 的錯誤率新增警示 - 已指派:Alex - 逾期:2 週」)
業務 | 程序✅ 在後續審查中追蹤動作項目完成度,確保實際發生持續改善
平台 | 文件✅ 在共用 Knowledge 庫中記錄事件後審查,並使用標記來啟用多個事件的模式分析
業務 | 程序✅ 透過小組會議或午餐學習會議,廣泛共用事件後審查,而非立即事件回應者

反模式

要尋找的位置看起來怎麼壞
業務 | 程序⚡️ 以責責為中心的過世後討論可降低心理安全並防止誠實評估失敗
業務 | 程序⚡️ 簡單的根本原因結論 (「工作人員有程式錯誤」),而非可有效修復的特定發現
業務 | 程序⚡️ 如「改善監視」等模糊的動作項目,而非特定且已指派的時間繫結工作
業務 | 程序⚡️ 指示持續改善程序失敗的低動作項目完成率
業務 | 程序⚡️ 將事件後學習隔離至立即回應者,而非廣泛共用以進行組織學習

模式

要尋找的位置良好的外觀
業務 | 程序✅ 驗證預先部署檢查清單,包括測試、安全審查、規範驗證、文件、監視組態和利害關係人批准
業務 | 程序✅ 根據爆炸半徑、資料敏感度、動作授權機構、整合相依性、復原複雜性和合規性涵義來評估風險
業務 | 程序✅ 根據風險將批准需求分級:高風險需要執行批准、安全審查和漸進式首展;低風險需要對等審查和標準測試
平台 | 批准流程✅ 使用 Salesforce 批准流程或外部部署工具實作自動化、追蹤和可稽核的批准工作流程
業務 | 程序✅ 定義需要執行批准、原因文件和加速部署後審查的緊急略過程序
平台 | 監視✅ 個別追蹤緊急部署;高緊急部署頻率表示需要調查的流程問題

反模式

要尋找的位置看起來怎麼壞
業務 | 程序⚡️ 無論工作人員風險設定檔為何,都套用統一的批准深度、浪費精力處理低度風險工作人員或評論低度高度風險工作人員
業務 | 程序⚡️ 部署生產工作人員但不進行測試、安全性、合規性和監視的預先部署檢查清單驗證
平台 | 部署⚡️ 沒有緊急略過程序,導致在生產事件期間發生重大修復延遲
業務 | 程序⚡️ 經常需要緊急部署,表示標準流程中斷,而非特殊狀況

模式

要尋找的位置良好的外觀
Agentforce | 工作人員組態✅ 測試輸出特性 (包含必要資訊、維持適當的語氣、包含引號),而非非決定性工作人員輸出的確切文字
Agentforce | 工作人員組態✅ 建立最低品質值 (例如「逾期測試集的準確性為 95%,安全違規為零,公平性稽核未顯示人口統計差異超過 5%」)
Agentforce | 工作人員組態✅ 使用敵對輸入執行安全測試,包括提示插入、中斷嘗試、要求升級和超出範圍要求
Agentforce | 工作人員組態✅ 由未參與工作人員開發的小組成員執行安全測試,提供有關漏洞的新觀點
平台 | 效能測試✅ 在實際負載下測試,包括同時對話、一般對話長度和預測使用量
平台 | 安全性✅ 驗證工作人員無法存取未經授權的資料、無法執行未經授權的動作,且提示插入無法升級權限
平台 | CI/CD✅ 使用 Salesforce Code Analyzer 和專業 AI 安全性工具在部署管道中整合安全性掃描

反模式

要尋找的位置看起來怎麼壞
Agentforce | 工作人員組態⚡️ 測試工作人員在非決定性的輸出上比對完全相符的文字,而非測試輸出特性
平台 | 效能測試⚡️ 僅測試單一使用者案例、缺少管理員限制問題、資源限制和延展性瓶頸
Agentforce | 工作人員組態⚡️ 略過安全測試或讓開發人員測試自己的工作人員,而不會對漏洞有新的觀點
平台 | 安全性⚡️ 未測試提示插入是否可升級工作人員權限或存取未經授權的資料
Agentforce | 工作人員組態⚡️ 擁有不代表實際用量多樣性的靜態測試集,包括不同的使用者類型和對話複雜性

模式

要尋找的位置良好的外觀
平台 | 文件✅ 記錄每個變更:變更的項目、原因、驗證的測試內容,以及存在的回復程序
公司 | 通訊✅ 通知所有利害關係人 (使用者、作業小組、支援、業務),說明變更的內容、時間、優點、風險以及要連絡的人員
公司 | 通訊✅ 建立不同變更類型的通訊範本,將訊息標準化並減少準備額外費用
平台 | 事件監視✅ 以顯示實際使用模式的「事件監視」資料通知低用量期間的工作人員部署時間
業務 | 程序✅ 將主要工作人員變更部署至週中,避免週末時發生事件回應功能降低
業務 | 程序✅ 建立主要業務事件之前的變更凍結期間 (會計年度結束、產品推出、主要行銷活動)
業務 | 程序✅ 每年提前足夠地傳達受限制期間的文件變更凍結行事曆

反模式

要尋找的位置看起來怎麼壞
平台 | 部署⚡️ 在使用量高峰、月結束、季結束或主要業務事件期間部署
平台 | 部署⚡️ 在事件回應能力有限時,於週一 (延遲) 或週五 (員工減少) 部署
業務 | 程序⚡️ 過度變更凍結會使改善速度變慢,但不會降低比例的風險
公司 | 通訊⚡️ 部署工作人員變更,而不通知受影響的使用者、作業小組、支援小組或業務專案關係人
平台 | 文件⚡️ 在沒有記錄原因的情況下進行變更、建立重新探索經驗的組織,而不是建立經驗

模式

要尋找的位置良好的外觀
平台 | UI✅ 在對話 UI 內實作回饋意見集合,在互動是新的而非延遲的集合時啟用立即回應
平台 | Analytics✅ 查詢對話記錄會分析問題類型、對話長度、依照主題的成功率,以及依對話特性的使用者滿意度
平台 | Analytics✅ 依錯誤類型、受影響的使用者、交談模式和時間分佈來分析錯誤記錄分組,以顯示系統問題
平台 | Analytics✅ 依頻率與影響排定錯誤修復的優先順序:影響許多使用者的高頻率錯誤需要立即注意
平台 | 監視✅ 初始部署後建立品質基準,並根據趨勢下降時的基準警示監視持續品質

反模式

要尋找的位置看起來怎麼壞
平台 | UI⚡️ 延遲回饋意見收集 (例如日後追蹤電子郵件),減少回應率並導入召回偏差
平台 | Analytics⚡️ 未分析使用模式,以判斷工作人員是否正確地說明作業複雜度,或功能是否未充分利用
平台 | Analytics⚡️ 將所有錯誤視為相等,而非依頻率與業務影響排定優先順序
平台 | 監視⚡️ 無資料做出改善決策、缺少品質基準與趨勢監視

模式

要尋找的位置良好的外觀
業務 | 程序✅ 提供一致的試驗結構:假設、試驗設計、度量、樣本大小和成功條件
業務 | 程序✅ 在執行前記錄實驗,以避免對結果進行不明確的解譯
平台 | Analytics✅ 追蹤交談中繼資料中的變體指派,以依變體啟用成果關聯
平台 | Analytics✅ 根據預期的效果大小、統計效能和可接受的錯誤率,在實驗前計算必要的樣本大小
平台 | Analytics✅ 使用多重武器盜版最佳化,以動態地將更多流量配置給效能較佳的變體,進而降低機會成本
平台 | 文件✅ 維護試驗目錄,其中包含已測試的變體、測量的成果、達成的結果,以及為防止重新測試失敗方法所做的決策

反模式

要尋找的位置看起來怎麼壞
業務 | 程序⚡️ 執行沒有預先定義假設和成功條件的實驗,導致結果不明確
平台 | Analytics⚡️ 使用樣本大小不足產生雜訊結果,導致改善決策不佳
平台 | 文件⚡️ 沒有實驗目錄,導致小組重新測試先前失敗的方法並失去組織 Knowledge
平台 | Analytics⚡️ 不追蹤哪些使用者接收哪些變體,因此無法取得成果關聯性