資源和成本最佳化 - 工作人員模式

深入瞭解結構正確的 資源和成本最佳化 → 工作人員企業資源和成本最佳化

模式

要尋找的位置良好的外觀
Agentforce | 動作✅ 設計動作接受集合。處理工作人員 50 個個案更新時,會叫用具有個案識別碼集合的單一動作,而非 50 個個別叫用
Agentforce | 動作✅ 在單一 SOQL 陳述式中使用關係查詢,以在整個動作鏈之間管理 SOQL 預算
平台 | 平台快取✅ 在「平台快取」中快取參照資料,以免在相同交談中的「動作」之間重複查詢
平台 | Apex✅ 將超過同步限制的工作人員作業移至 Queueable 或批次 Apex。
平台 | Apex✅ 使用 Apex 執行記錄載入設定檔動作。接近同步化限制時,將高計算處理移至非同步化內容
Agentforce | 動作✅ 具有實子系記錄限制和資料誤差情況分頁的設計動作
Agentforce | 動作✅ 當數量超過可能以無法預測的方式要求「所有歷程記錄」之工作人員的上限時實作取樣
平台 | 規模中心✅ 使用「刻度中心」交易追蹤來識別哪些動作耗用過多查詢

反模式

要尋找的位置看起來怎麼壞
Agentforce | 動作⚡️ 針對每個記錄叫用個別動作 (例如 50 個個案更新的 50 個個別呼叫),而非接受集合
平台 | Apex⚡️ 在 10-15 個動作的複雜工作流程中,執行每個動作 5-10 個 SOQL 查詢,達到 100 個同步 SOQL 限制
平台 | Apex⚡️ 在「動作」中同步執行大型處理,而非在非同步環境中執行 (例如,在同步 Apex 中評分 1,000+ 個商機)
Agentforce | 動作⚡️ 允許工作人員從擁有 15,000 個機會的帳戶或擁有 5,000 個活動的個案中提取無限制的子系記錄,而不使用防禦式編碼

模式

要尋找的位置良好的外觀
平台 | 事件監視✅ 在試用階段中監視「事件監視」中的 API 耗用,以瞭解完整首展之前的實際用量
Data 360 | 組態✅ 針對向量搜尋設定 top-k 限制,以僅提取實際使用的結果數目
Data 360 | Analytics✅ 在 Data 360 Analytics 中監視向量搜尋結果利用率,以調整 top-k 參數
平台 | 平台事件✅ 當條件需要工作人員介入而非排程輪詢而耗用 API 呼叫時發佈平台事件,無論工作存在為何
整合 | 動作✅ 使用複合模式:建立單一 MuleSoft Experience API 以並列彙總多個系統檢查 (庫存、定價、信用),工作人員叫用 1 個外部動作耗用 1 個呼叫
整合 | 動作✅ 設計單一 MuleSoft 流程以執行所有下游更新,而非針對每個工作人員互動執行多個序列流程
Agentforce | 工作人員組態✅ 使用標準元件將工作人員內嵌在 Lightning 頁面中,以避免每個互動耗用 API 呼叫
業務 | 規劃✅ 根據預測的工作人員交易量評估 MuleSoft 授權模型 (交易型與平台型授權),以決定最佳經濟性

反模式

要尋找的位置看起來怎麼壞
Data 360 | 組態⚡️ 僅使用前 5 個項目時,以取得前 50 個向量搜尋結果,而浪費了 90% 的運算和內容預算
平台 | 已排程工作⚡️ 無論工作存在情況為何,排程輪詢會耗用 API 呼叫 (例如,每次檢查 5 分鐘會以 80% 的時間尋找沒有工作)
整合 | 已命名認證⚡️ 使用耗用 3 個呼叫的 3 個個別動作,而非使用彙總多個系統呼叫的單一複合 API
平台 | Apex⚡️ 當標準 Lightning 元件可以避免此情況時,自訂 LWC 提出明確的 API 要求會耗用 API 呼叫
整合 | 外部系統⚡️ 輪詢 Salesforce 狀態變更的外部系統會耗用數百個每日 API 呼叫,而非訂閱 CDC 事件
整合 | 動作⚡️ 針對每個步驟 (查詢客戶、查詢產品、檢查庫存、建立訂單、更新庫存、通知寄送) 進行序列 API 呼叫,當複合模式會降低耗用量 75% 時,每個交易會耗用 12 次以上的呼叫
整合 | 工作人員組態⚡️ 在許多系統之間協調工作人員動作,而不評估是否需要每個系統互動,將 API 耗用乘以每個新增的系統

模式

要尋找的位置良好的外觀
Agentforce | 提示範本✅ 最小化提示長度:移除粗略指示、冗餘的範例、不必要的內容。選擇性內容可改善延遲與品質
平台 | Apex✅ 透過索引篩選條件使用選擇性 SOQL。利用查詢計畫工具來識別造成完整表格掃描的遺漏索引
Agentforce | 工作人員組態✅ 在沒有相依性存在時使用並列動作執行。將帳戶詳細資料和機會同時取回會將延遲與連續的提取減半
平台 | 平台快取✅ 快取經常存取的參考資料 (產品目錄、區域範圍對應、定價規則),以消除重複的 SOQL
平台 | 平台快取✅ 實作符合類似查詢的語意快取,以提供重複的要求,而無須新推斷
平台 | Apex✅ 使用慷慨的非同步管理員限制,以非同步方式處理非緊急要求 (狀態更新、批次處理、報告產生)
平台 | Apex✅ 實際資料量下方的設定檔動作。無論快速 LLM 推斷為何,採取 3 個動作都會變成瓶頸
Agentforce | 動作✅ 在「動作」中實作大量處理,以儘量縮短每個作業的執行時間

反模式

要尋找的位置看起來怎麼壞
Agentforce | 提示範本⚡️ 包含可增加雜訊的詳細內容,而非可改善延遲與品質的選擇性內容
Agentforce | 工作人員組態⚡️ 在沒有相依性存在時依序執行動作 (例如,帳戶查詢 2s + 機會查詢 2s = 4s 依序,而非 2s 並列)
平台 | Apex⚡️ 由於缺少索引而執行完整表格掃描,而非使用具有索引篩選條件的選擇性 SOQL
平台 | 平台快取⚡️ 針對可快取的常見資料重複查詢 Data 360 (每通通話 1.5 秒) (50 毫秒從平台快取)
Agentforce | 工作人員組態⚡️ 非緊急作業 (狀態更新、批次處理、報告產生) 需要同步完成

模式

要尋找的位置良好的外觀
Data 360 | 組態✅ 將 Knowledge 文章、產品文件、個案歷程記錄切成有意義的 250-750 個字區段
Data 360 | 組態✅ 根據工作人員查詢模式驗證區塊大小。平衡準確性 (較小的區塊) 與內容完整性 (較大的區塊)
Data 360 | 組態✅ 使用與工作人員查詢模式相符的內嵌。根據測量的取用精確度與召回的代表查詢驗證選取項目
Data 360 | 組態✅ 使用可確保業務限制的中繼資料篩選增強向量相似度 (例如,不論語意相似度為何,都會篩選已停用的產品)
Data 360 | 組態✅ 使用統一設定檔,將多個來源的客戶資料彙總到單一檢視中。存取單一查詢中的完整內容 (屬性、洞察、參與、預估)
Data 360 | 組態✅ 啟用身分解析,提供準確的跨系統客戶比對
Data 360 | 組態✅ 在符合資料落地合規性法規需求的區域中設定 Data 360 例項

反模式

要尋找的位置看起來怎麼壞
Data 360 | 組態⚡️ 在向量搜尋結果中使用過大區塊,其中包含不相關的資訊會使相關性稀少
Data 360 | 組態⚡️ 僅依賴語意相似度且不含中繼資料篩選條件,傳回中斷或品質不佳的結果
Data 360 | 組態⚡️ 協調多個個別來源查詢,而非使用 Data 360 統一設定檔來完成客戶內容
Data 360 | 組態⚡️ 使用不符合工作人員查詢模式的內嵌模型 (例如,文件分類內嵌以取得問題回答的相似度)
Data 360 | 組態⚡️ 在非歐洲 Data 360 例項上處理歐洲客戶資料,違反資料落地需求

模式

要尋找的位置良好的外觀
Agentforce | 工作人員組態✅ 明確排定內容的優先順序:最近對話歷程記錄 (最高)、重要業務資料/記錄狀態/權限 (第二)、歷程記錄內容 (最低,只有在空間允許時)
Agentforce | 工作人員組態✅ 在 10-15 輪後,將早期交談摘要整理為簡要概觀,並維持重要事實,而不含完整的文字記錄
Data 360 | 組態✅ 將擴充內容儲存在 Data 360 或自訂物件中,而非在每個 LLM 呼叫中儲存完整歷程記錄。對需求的查詢,讓提示專注於目前需求
Agentforce | 動作✅ 僅傳回「動作」回應中的重要欄位。帳戶尋找會傳回與目前工作相關的欄位,而不會傳回全部 50 個欄位
Agentforce | 工作人員組態✅ 針對內容視窗配置設計明確優先順序邏輯與任意截斷

反模式

要尋找的位置看起來怎麼壞
Agentforce | 工作人員組態⚡️ 不含明確優先順序邏輯的內容任意截斷
Agentforce | 工作人員組態⚡️ 在 10-15 次以上維持完整的文字對話歷程記錄,耗盡內容預算
Agentforce | 工作人員組態⚡️ 在每個 LLM 呼叫中包含完整歷程記錄,而非在外部儲存擴充內容並依需求查詢
Agentforce | 動作⚡️ 當只有子集與目前工作相關時,從帳戶尋找傳回所有 50 個欄位,耗用內容預算
Agentforce | 工作人員組態⚡️ 分配內容預算,而不保留足夠的回應產生空間

模式

要尋找的位置良好的外觀
平台 | 動作✅ 開發涵蓋記錄 CRUD、批准、通知、報告和驗證的集中化「動作」文件庫。平台小組維持確保一致的行為、安全性、效能
Agentforce | 工作人員組態✅ 建立具有深度領域專業知識 (個案管理的服務代理、機會指引的銷售代理) 的專注專家工作人員,維持更窄的內容和更明確的邊界
Agentforce | 工作人員組態✅ 針對跨網域需求使用工作人員產生器協調協調協調專家工作人員
Agentforce | 提示範本✅ 在提示詞產生器中維護已驗證的提示模式。範本會針對 RAG 查詢產生、多步驟推理、回應格式化的已驗證方法
Agentforce | 提示範本✅ 啟用改善方式 A/B 測試的版本提示範本
Data 360 | 組態✅ 在提供多位工作人員的 Data 360 中維護共用Knowledge庫。單一產品 Knowledge 庫奠基銷售、服務和合作夥伴入口網頁工作人員
Agentforce | 工作人員組態✅ 從經過驗證的建構區塊撰寫新工作人員:定義目的、選取「動作」、設定提示 (自訂組建的天數與週數)

反模式

要尋找的位置看起來怎麼壞
Agentforce | 提示範本⚡️ 為每個工作人員建立臨時提示,而非重複使用已驗證的提示範本文件庫
Agentforce | 動作⚡️ 為每個工作人員重新實作「動作」,而非使用集中可重複使用的「動作」文件庫
Agentforce | 工作人員組態⚡️ 建立通用工作人員,嘗試所有案例,而非專注在具有深度領域專業知識的專家工作人員
Data 360 | 組態⚡️ 為每個工作人員重複Knowledge庫,而非共用建立多個工作人員基礎的單一知Knowledge

模式

要尋找的位置良好的外觀
平台 | 自訂中繼資料類型✅ 使用「自訂中繼資料類型」和提示詞產生器控制行為,而無須變更程式碼。管理員無須開發週期即可修改提示範本和推理參數
Agentforce | 工作人員組態✅ 將子集路由至試驗版本,比較完整首展前的品質度量、滿意度、工作完成度 (例如,10% 到 v2、90% 到 v1)
Agentforce | 工作人員組態✅ 若在 A/B 測試期間發現問題,請監視驗證期間並維護回復功能
Agentforce | 動作✅ 定義元件之間的明確介面契約:動作指定輸入、輸出、錯誤、效能預期
Agentforce | 工作人員組態✅ 在多週首展期間逐步展開成功版本 (10% 到 25% 到 50% 到 100%)
Agentforce | 動作✅ 保留介面契約時,取代不含工作人員修改的「動作」實作

反模式

要尋找的位置看起來怎麼壞
平台 | Apex⚡️ 需要程式碼變更才能修改工作人員行為,而非使用組態驅動的方法 (自訂中繼資料類型、提示詞產生器)
Agentforce | 工作人員組態⚡️ 未對比較品質度量與滿意度之子集進行 A/B 測試的新工作人員版本完整首展
Agentforce | 動作⚡️ 根據動作實作詳細資料而非介面契約的工作人員,在實作變更時損毀
Agentforce | 工作人員組態⚡️ 不需漸進式首展即可將新版本立即部署至 100% 的使用者
Agentforce | 工作人員組態⚡️ 在試驗版本測試期間未使用回復功能運作

模式

要尋找的位置良好的外觀
Agentforce | 工作人員組態✅ 盡可能以最少的工作人員動作解決每個要求 — 系統會為每個動作耗用「彈性信用」,因此將多步驟邏輯合併為單一動作會直接降低成本
Agentforce | 工作人員組態✅ 根據記錄的「彈性信用」耗用率和預期互動量來模型化每月成本預測,以啟用預算規劃
Einstein | 監視✅ 依工作人員、使用個案和使用者族群監視彈性信用耗用,以識別需要最佳化的高耗用模式
Einstein | 監視✅ 比較實際耗用與預測,以通知未來規劃並識別最佳化機會

反模式

要尋找的位置看起來怎麼壞
Agentforce | 工作人員組態⚡️ 鏈結多個小型動作,其中一個合併動作會解決要求,並乘以每個互動的「彈性信用」耗用
業務 | 規劃⚡️ 發現只有在生產部署後,「彈性信用」耗用才會超出預測,因為未執行任何互動成本建模

模式

要尋找的位置良好的外觀
Agentforce | 工作人員組態✅ 設計工作階段邊界與逾時,使交談持續適當,而不會過早終止並強制進行新的可計費交談
Agentforce | 工作人員組態✅ 將工作人員功能專注在第一個對話解決方案上,讓工作在初始對話內完成,而不需要可計費的後續追蹤
Einstein | 監視✅ 追蹤第一個對話的解決率作為「每個對話」定價下的成本效率度量
Agentforce | 工作人員組態✅ 處理現有對話內容內的相關問題,而非開啟各自產生固定費用的個別對話

反模式

要尋找的位置看起來怎麼壞
Agentforce | 工作人員組態⚡️ 由於工作階段短逾時而提早終止對話,強制使用者開始新的可計費對話以完成單一工作
Einstein | 監視⚡️ 僅監視總交談量,而不追蹤第一個交談解決率,缺少「每個交談」定價下的主要成本杠杆

模式

要尋找的位置良好的外觀
業務 | 文件✅ 促進採用,讓授權使用者主動與工作人員互動,因為未測量的「每位使用者」定價值來自使用情況,而非從最小化每個互動。
Einstein | 監視✅ 追蹤利用率以識別低使用率授權使用者以進行目標式訓練或授權重新配置
業務 | 文件✅ 依使用者族群將工作人員互動連線至業務成果,以便高價值的使用個案可證明每個座位的投資
業務 | 規劃✅ 依步調檢閱使用者族群,讓授權與實際使用狀況保持一致,而不會漂移至過度授權

反模式

要尋找的位置看起來怎麼壞
業務 | 規劃⚡️ 佈建無採用計畫的「每位使用者」授權,為少於參與工作人員的使用者支付固定每個座位費用
Einstein | 監視⚡️ 絕不依使用者族群檢閱利用率,讓授權漂移到浪費傳統職位的相同過多授權

模式

要尋找的位置良好的外觀
Agentforce | 工作人員組態✅ 實作以簡單邏輯處理初始路由的分級工作人員,僅在複雜性需要時將使用者導向至專門工作人員
平台 | 流程✅ 針對以規則為基礎的邏輯足夠的決定性案例,請返回流程自動化,將工作人員的推理保留給真正需要的不明確情況
Data 360 | 工作人員組態✅ 選擇性地取得奠基資料,僅在工作人員的推理需要時叫用向量搜尋和文件提取,而非在每次互動時。

反模式

要尋找的位置看起來怎麼壞
Agentforce | 工作人員組態⚡️ 將每個要求直接路由至專門的工作人員,為簡單分級邏輯可以處理的要求產生昂貴的複雜叫用
平台 | 流程⚡️ 針對以決定性規則為基礎的工作流程,使用工作人員考量,讓「流程」在不含變數耗用的情況下以更低的成本執行
Data 360 | 工作人員組態⚡️ 取得每個互動的奠基資料,無論是否需要推理,進而推動 Data 360 不追蹤實際需求的耗用

模式

要尋找的位置良好的外觀
Data 360 | 工作人員組態✅ 使用定義的重新整理步調 (例如 24 小時) 快取產品目錄內嵌,從快取提取例行問題,並僅查詢 Data 360 的新資料或客戶特定的資料
Data 360 | 工作人員組態✅ 實作快取策略來減少常見要求的重複查詢,並平衡成本最佳化與資料更新度需求
Data 360 | 組織✅ 與增量成長成本分開,模型化先前的資料取用與處理成本 (調和、身分解析、內嵌產生)
Data 360 | 工作人員組態✅ 評估 RAG 額外費用是否為特定使用個案提供品質改善,然後再新增增量取得的產生

反模式

要尋找的位置看起來怎麼壞
Data 360 | 工作人員組態⚡️ 儘管大多數查詢是相同的常見問題,但未實作快取,因此會針對重複的相同回應耗用「彈性信用」
Data 360 | 組織⚡️ 實作積極快取,而不考量資料更新性需求,將過時資訊提供給使用者

模式

要尋找的位置良好的外觀
平台 | 組織✅ 將 Partial Copy Sandbox 與目標客戶資料範例搭配使用,以用於工作人員開發,並保留「完整複製 Sandbox」專用於生產前驗證
平台 | 組織✅ 預先計畫開發基礎結構成本,包括 Data 360 容量、提示測試的彈性信用以及整合連線

反模式

要尋找的位置看起來怎麼壞
平台 | 組織⚡️ 每個開發人員為工作人員開發佈 Full Copy Sandbox,將 Sandbox 成本乘以 5 倍
平台 | 組織⚡️ 依賴臨時手動測試提供不足的涵蓋範圍,僅在生產環境中發現品質問題
業務 | 規劃⚡️ 在規劃期間將開發基礎結構成本設為不可見,進而在實作期間導致重大非預期成本

模式

要尋找的位置良好的外觀
業務 | 文件✅ 建立涵蓋全部六個成本種類的全方位 TCO 模型:開發、推斷 (Flex Credits)、基礎結構 (Data 360 + MuleSoft)、作業、管治和變更管理
業務 | 文件✅ 建立預測 3-5 年成本的試算表 TCO 模型,並使用互動量、信用額度消耗率和成長趨勢的記錄假設
業務 | 文件✅ 執行敏感性分析,顯示哪些假設最影響投資總額,以啟用重點驗證工作
業務 | 文件✅ 將進行中營運成本模型化為成熟工作人員每年有意義的週期性開發成本分數,從一般 AI 工作人員產業基準而非固定 Salesforce 數字中取得
業務 | 規劃✅ 包含經常低估的變更管理成本 (使用者訓練、業務流程調整、組織變更)

反模式

要尋找的位置看起來怎麼壞
業務 | 規劃⚡️ 在工作人員業務個案中僅包含開發成本,而不模型化持續耗用 (Flex Credits、Data 360、operations),在部署後發現顯著的非預定年度成本
業務 | 規劃⚡️ 省略管理額外費用 (安全審查、人力監督基礎結構、稽核記錄、合規性驗證),這會隨著工作人員的自主性和風險層級而成長
業務 | 規劃⚡️ 低估變更成本,特別是工作人員建立重大工作流程排班,進而導致預算短缺

模式

要尋找的位置良好的外觀
業務 | 文件✅ 透過包含維護成本的全方位 3 年 TCO 比較,評估預先建置 Agentforce 工作人員與自訂開發
業務 | 文件✅ 在「結構決策記錄」中建立文件與購買決策,以在成本和功能變更時啟用未來重新評估
Agentforce | 工作人員組態✅ 請考慮透過提示詞產生器和動作組態自訂預先建立的工作人員,作為立即可用與完全自訂之間的中間位置
業務 | 規劃✅ 超出成本的因素決策條件:時間對價值、組織開發能力、策略差異化值和廠商相依性容忍度

反模式

要尋找的位置看起來怎麼壞
業務 | 規劃⚡️ 建立自訂工作人員是因為「我們想要控制」,而無需模型化 3 年 TCO 顯示預先建立的選項可能會明顯便宜
業務 | 規劃⚡️ 僅根據第一年的成本選擇建立或購買,而不預測多年的持續維護、信用額度消耗和廠商更新效益

模式

要尋找的位置良好的外觀
業務 | 文件✅ 部署前比較工作人員的 TCO 與傳統自動化替代項目 (流程、Apex、手動流程),驗證投資理由
業務 | 文件✅ 建立手動流程基準,包括完整員工成本、錯誤率、處理時間和輸出容量,以顯示潛在的節省成本
Agentforce | 工作人員組態✅ 為需要自然語言瞭解、適應性推理或處理傳統自動化無法符合能力的高案例變異性的工作部署工作人員
平台 | 流程✅ 使用具有明確規則的決定性工作流程使用流程自動化,以更低的成本提供相等成果,而不需要變數推斷耗用

反模式

要尋找的位置看起來怎麼壞
Agentforce | 工作人員組態⚡️ 部署工作人員進行簡單的決定性路由工作,耗用 $15,000 的年度信用額度,當「流程」會提供相等功能而不含變數成本時
業務 | 規劃⚡️ 預設為所有自動化的工作人員方法,而不評估傳統自動化是否以更低的總成本提供相同成果

模式

要尋找的位置良好的外觀
Einstein | 監視✅ 建立彈性信用耗用顯示面板,依工作人員、使用者族群、期間和互動類型顯示耗用,以快速識別耗用高峰
Einstein | 監視✅ 實作每個互動成本歸屬,將信用耗用連結至業務交易 (每個已解決個案的成本、每個合格商機的成本、每個已處理訂單的成本)
Einstein | 監視✅ 依工作人員設定預算警示的範例值 (例如 70% 與 85%) 和使用個案 (不僅限組織範圍),以在覆寫前啟用主動介入
Einstein | 監視✅ 實作異常偵測以識別異常的耗用模式 (顯示提示效率不佳、非預期的使用模式或濫用狀況的突然高峰)
業務 | 文件✅ 與業務專案關係人和技術小組共用成本顯示面板,建立透明度以啟用感知成本的工作人員用量
業務 | 文件✅ 執行每季預算審查以比較實際耗用與預測、評估業務成果,並根據證明值調整配置
業務 | 規劃✅ 將 10-15% 的信用額度預算保留給試驗和非預期的耗用成長,以避免創新瓶頸
業務 | 規劃✅ 根據工作人員採用趨勢、新部署和擴充使用個案建立多年預測,以啟用產能規劃和供應商協商

反模式

要尋找的位置看起來怎麼壞
Einstein | 監視⚡️ 僅透過每月發票審查來監視信用額度耗用,發現預算超出 6 週,且沒有續約前最佳化的時間
Einstein | 監視⚡️ 僅在組織層級設定預算警示,缺少指示最佳化機會的每位工作人員和每個使用個案耗用高峰
業務 | 規劃⚡️ 需要緊急預算會增加,因為未及時實作耗用監視,以主動識別及處理覆寫
業務 | 規劃⚡️ 在會計年度開始時設定年度預算一次,而無須檢閱,讓高價值工作人員缺少信用額,而低 ROI 工作人員耗用配置
業務 | 規劃⚡️ 為試驗分配零預算預留,強制小組在任何探索之前透過長時間的批准來證明每個新的使用個案

模式

要尋找的位置良好的外觀
Einstein | 監視✅ 依工作人員例項追蹤耗用,啟用工作人員類型與使用個案之間的比較,顯示哪些工作人員提供最佳的 ROI
業務 | 文件✅ 將耗用與業務流程 (商機資格、個案解決、訂單處理) 連線,讓業務主管能夠評估策略對齊方式
Einstein | 監視✅ 依部門、角色或使用者區段追蹤耗用,顯示工作人員採用率最高且成本集中於何處
業務 | 規劃✅ 使用每季成本評論比較整個組合的工作人員 ROI,並根據證明值將投資從低 ROI 重新分配至高 ROI 工作人員

反模式

要尋找的位置看起來怎麼壞
業務 | 規劃⚡️ 在沒有業務單位歸屬的情況下將所有工作人員成本分配至 IT 預算,以防止業務主管評估費用是否符合優先順序
業務 | 規劃⚡️ 將工作人員耗用視為未區分的成本,而不將耗用與業務成果連結,因此無法計算 ROI

模式

要尋找的位置良好的外觀
業務 | 文件✅ 實作顯示回報以依業務單位提供耗用可視性,建立成本認知以啟用明智的使用決策,而無須有爭議的退貨爭議
業務 | 文件✅ 針對大量生產工作人員使用含退貨的混合配置,針對實驗或少量工作人員使用顯示回應,以平衡責任與創新彈性
業務 | 文件✅ 執行每季審查,討論耗用是否符合提供的價值,進而達成最佳化承諾

反模式

要尋找的位置看起來怎麼壞
業務 | 規劃⚡️ 針對試驗工作人員實作完整的負債回扣,透過立即對新生使用個案強制執行預算責任來阻止創新和探索

模式

要尋找的位置良好的外觀
Agentforce | 提示範本✅ 去除系統提示中不必要的說話方式,識別每個額外的權杖會在所有互動之間新增預先填入運算和延遲—修剪系統提示以瞭解工作人員實際使用的內容
Agentforce | 提示範本✅ 透過選取式的相關性,僅包含相關資訊,並以相關性排名來確保最高值的資訊符合內容限制
Agentforce | 提示範本✅ 指定例行互動的簡要回應格式,避免要求詳細的格式設定或詳細的說明來將完成權杖最小化
Agentforce | 提示範本✅ 重複在類似工作人員之間使用標準化提示範本,減去提示最佳化投資,同時建立一致性和效率

反模式

要尋找的位置看起來怎麼壞
Agentforce | 提示範本⚡️ 以對話方式撰寫提示,而不最佳化每個互動耗用 2K+ 權杖,包括粗略的指示和工作人員極少參照的範圍範例
Agentforce | 提示範本⚡️ 針對內容的所有潛在相關資料,而非選擇性地僅包含相關資訊,充滿提示權杖耗用
Agentforce | 提示範本⚡️ 為每個工作人員建立唯一的提示範本,而非標準化模式,將提示工程工作乘以不含比例的品質優點

模式

要尋找的位置良好的外觀
Agentforce | 工作人員組態✅ 快取經常詢問問題的常見工作人員回應,直接從快取中提供重複查詢 (快取達成率高於 30% 表示重要最佳化機會)
Data 360 | 工作人員組態✅ 快取穩定 Knowledge 內容 (產品目錄、保單文件、參考資料),以減少每個參照常見資訊互動的提取負擔
Agentforce | 工作人員組態✅ 在使用者工作階段內實作交談快取,在不重新傳送完整歷程記錄的情況下跨輪維護內容,並減少多輪互動中的權杖耗用
Agentforce | 工作人員組態✅ 根據內容波動性定義快取無效策略 (產品資訊會在小時/天快取,即時資料不應快取)

反模式

要尋找的位置看起來怎麼壞
Agentforce | 工作人員組態⚡️ 儘管有 60% 的查詢是相同的常見問題,但不必要使用「彈性信用」來重複使用相同的回應,但未實作快取
Agentforce | 工作人員組態⚡️ 快取需要最新狀態的即時資料 (庫存層級、定價、可用性),提供過時資訊,進而導致工作人員回應不正確
Agentforce | 工作人員組態⚡️ 切勿重新整理快取回應,進而在產品、原則或程序變更時導致過期的回答

模式

要尋找的位置良好的外觀
業務 | 文件✅ 需要業務個案,包括預測的 3 年 TCO、含度量方法的預期業務成果、與替代方案的比較,以及風險評估
業務 | 文件✅ 定義可將部門授權的投資與需要執行批准的投資分開的批准值,以便高投資或高風險工作人員得到比例的執行審查
業務 | 文件✅ 要求試用部署在完整生產投資前驗證假設 (耗用、品質、採用)
業務 | 文件✅ 在工作人員提案中包含 ROI 計算 (例如透過已解決個案示範的 4:1 報酬率和手動處理成本節省)

反模式

要尋找的位置看起來怎麼壞
業務 | 規劃⚡️ 部署沒有業務個案的工作人員,探索預測的信用額度耗用 3 倍,同時提供不明確的業務價值,建立未經記錄 ROI 的非預定年度耗用
業務 | 規劃⚡️ 略過試用部署並直接移至完整生產環境,缺少在認可完整預算前驗證耗用假設的機會
業務 | 規劃⚡️ 批准工作人員的投資,而不比較可以更低成本提供相同價值的其他方法 (手動流程、傳統自動化)

模式

要尋找的位置良好的外觀
業務 | 文件✅ 執行年度組合審查,評估所有工作人員,比較成本、用量、業務價值和策略對齊方式,以顯示每位工作人員檢閱忽略的最佳化機會
業務 | 文件✅ 定義日落條件 (採用率低、投資報酬率差、功能過多、成本過高),以防止累積耗用預算的低價值工作人員
業務 | 規劃✅ 實作持續的投資重新分配,將資源從績效不佳的工作人員轉移至符合不斷發展業務優先順序的高價值機會
業務 | 文件✅ 依 ROI 分類工作人員 (例如,前 2 個提供 70% 價值且成本為 50% = 極好;中 4 個提供 25% 價值且成本為 35% = 可接受;下 2 個提供 5% 價值且成本為 15% = 日落候選項目)

反模式

要尋找的位置看起來怎麼壞
業務 | 規劃⚡️ 部署的工作人員無限期保留在生產環境中,無須利用率或值檢閱,累積了耗用預算的低價值工作人員,這些工作人員可以為高價值的機會提供資金
業務 | 規劃⚡️ 僅個別評估沒有產品組合觀點的工作人員,缺少一些工作人員提供最多價值的洞察,而許多工作人員耗用不成比例的資源