> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/zh-tw/shang-wu-fu-wu/zoom-workforce-management/workforce-management-explainer/core-concepts.md). # 核心概念 ## 排班群組 排班群組是 Zoom Workforce Management 中的頂層使用者群組，在組織、檢視與管理使用者方面扮演關鍵角色。排班群組作為整個系統中篩選使用者的主要篩選條件，也是建立員工班表與產生預測的關鍵元件。 #### 排班群組由代理人、佇列，以及相關的聯絡管道所組成 每個排班群組都由三個元件構成：至少一個聯絡管道（例如語音、視訊或訊息）、處理這些管道的聯絡中心佇列，以及被指派來處理這些管道的代理人。 **聯絡管道** 是客戶用來與聯絡中心連線的通訊媒介。聯絡管道的例子包括 **語音** （電話）， **視訊** （視訊互動），或 **訊息** （簡訊、網頁聊天，以及應用程式內聊天，例如 Facebook Messenger 或 WhatsApp）。 **聯絡中心佇列** 是實現預測的關鍵。當佇列連結到排班群組時，Workforce Management 會提取其歷史互動資料來建立基準並預估未來量。沒有佇列時，仍然可以手動為該群組排班——只是無法使用預測功能。 **客服專員** 可加入排班群組，以便進行批次排班與篩選。將代理人與群組關聯，可更快建立預測、產生班表，並將遵循度報表篩選到特定團隊。 {% hint style="warning" %} **重要** 一個佇列或代理人同一時間只能屬於一個排班群組。 {% endhint %} 對於較大型的組織，排班群組可巢狀包含於組織群組中——這是一層階層結構，可簡化跨多個團隊的權限管理、報表篩選與預測設定。 ## 活動 在聯絡中心中，代理人的班次通常會事先排定不同的任務或職責，例如參加團隊會議、休息用餐，或處理支援佇列。在 Workforce Management 中，這些項目被稱為 **活動**，並且是代理人班次的構成要素。 常見活動的例子包括，但不限於： | | | | ----------------------------------------------------------- | -------------------------------------------------------------- | #### Workforce Management 提供六種獨特的活動類型，供排班與報表用途使用 一個 **活動類型** 會定義某項活動屬於生產性或非生產性，並用於將活動分類以供報表與排班之用。透過六種不同的活動類型，只有當代理人被排定為 *生產性* 活動類型時，才會為其所屬排班群組的用人需求做出貢獻。六種活動類型如下： * **生產性**：表示代理人能夠為其所屬排班群組的用人需求做出貢獻。 * **不在辦公室**：將代理人排定為「不在辦公室」狀態。 * **非生產性**：代表排定的時間，用於工作相關活動，但不會貢獻於其所屬排班群組的用人需求，例如會議、輔導等。 * **例外**：用於計入代理人花費的時間 *未遵循排班*，例如代理人因 IT 問題或緊急狀況而無法完成其排定的活動。 * 例外無法在建立班次時使用，只能在必要時加入已發布的班表。 * **用餐**：代表保留給用餐的非生產性時間。 * **休息**：代表保留給非用餐休息的非生產性時間。 #### 活動可建立或自訂，並加入額外資訊以符合某個環境 帳戶或排班管理員可以建立或自訂符合其環境與工作流程的活動，協助帳戶確保具備足夠的活動，以支援代理人一天中可能執行的各種任務。活動的可自訂功能包括： * **名稱：** 自訂或新活動的自訂名稱 * **預設時長**：活動預設排定的時間長度 * **管道**：與該活動相關聯的聯絡中心管道 * **付費狀態**：該活動是有薪（生產性時間）還是無薪（用餐／休息） * **遵循度**：是否將該活動計入遵循度報告 * **允許編輯**：代理人是否可以申請 *新增*, *變更*，或 *刪除* 排班中的一個活動 #### 固定時間的活動可以批次加入使用者班表 在班表產生後，Workforce Management 管理員與主管可以為特定一組代理人，在指定日期、時間與持續時間，批次排定固定時間活動，從而簡化訓練課程或團隊會議等事件的排程。使用此功能時，活動會加入所選代理人的班表，而不論現有活動為何；然而，若發生排程衝突，或是在使用者未上班期間排定活動，系統可以產生並套用替代時間建議。 ## 班次 班次是代理人在一個工作日或一週中執行的預排活動。活動是指在特定時間點的具體任務或責任，而班次則是一名代理人在特定時間範圍內被指派之活動的組合。 例如，代理人可能需要在兩個不同時間分別負責電話佇列與聊天佇列；然而， *班次* 是正式化的計畫，用來定義 *何時* 這些活動要在一個工作日或一週中如何執行。 #### 班次支援固定與動態排班模式 在建立班次時，排班管理員可以在 **固定** 與 **動態** 班次模式之間選擇。 透過 **固定** 在班次排程中，使用者通常會每週在相同時間開始與結束班次和休息。下圖提供了一個 *固定* 班次的範例，其中每位被指派的代理人在每天的固定時段都有一致的活動。
透過 **動態** 在班次排程中，管理員可以調整設定，以最佳化每日與每週的彈性開始、午餐與休息時間。例如，某位代理人某週週一的休息時間可能是下午 1 點，但下一週週一則可能是下午 2 點，讓排班管理員能將人力排班與預測對齊，以滿足預期需求。若企業在沒有預測的情況下排班，這有助於錯開休息與用餐時間以避免重疊。動態班次也支援更彈性的休息時長，讓管理員可將休息與用餐設定為 5 分鐘的遞增單位，例如 5、15 或 20 分鐘，同時確保所有活動仍以標準的 15 分鐘間隔開始。 \ 下圖提供了一個動態班次的範例，其中代理人每天的開始、休息與用餐時段可能會有所變動，以符合預測需求。在圖片上半部，會指定每個活動的彈性時間；而下半部則呈現其在班次中的排定位置範例，並與所定義的彈性時間相符。 {% hint style="info" %} **注意** 動態班次一次只能使用一個預設活動。 {% endhint %}
#### 班次支援每日彈性的開始與結束時間 班次可為一週中的每一天同時支援固定與彈性的開始與結束時間，並可依需求自訂，以滿足多樣的排班需求。 {% hint style="success" %} **範例** 排班管理員 Alice 可以建立一個簡單的班次，涵蓋週一到週五的 8-5。或者，Alice 也可以建立一個班次，週一、週三和週五為 8-5，週二和週四為 10-7，或任何其他偏好的時間組合。 {% endhint %} #### 一名代理人同一時間只能被指派到一個班次 在設計班次時，請記住一名代理人同一時間只能被指派到一個班次。每個班次都應全面設計，確保代理人的所有活動都已排定於該週。 #### 每個班次可指派給無限數量的代理人 雖然每位代理人同一時間只能被指派到一個班次，但每個班次可指派給無限數量的代理人。 {% hint style="success" %} **範例** 排班管理員 Alice 建立了一個 8-5 的單一班次，內容為語音、視訊和訊息佇列時間各三等分。Alice 可以將此班次指派給代理人 Bob 和 Maurice，以及任何其他需要的代理人。\ \ 然而，如果 Alice 建立一個 *第二* 涵蓋不同活動的 8-5 班次，則無法再指派 Bob 和 Maurice 或任何其他已被指派班次的代理人，除非先將他們從目前指派的班次中移除。 {% endhint %} #### 在設計班次時，排定的工作時間會依每位代理人設定的時區顯示 在設計班次時，請記住排定的工作時間會依每位代理人設定的時區顯示，而非固定或通用。 {% hint style="success" %} **範例** 排班管理員 Alice 位於紐約（UTC-5），並建立了一個 8-5 的班次。當 Alice 將代理人指派到此班次時，代理人將會依其 Zoom 帳戶設定的時區看到班次時間與持續時間。\ \ 因此，若位於洛杉磯（UTC-8）的代理人被指派到這個 8-5 班次，他們會在自己的本地時區（UTC-8）中看到 8-5 的排程。同樣地，若位於紐約的代理人被指派到同一個班次，他們也會在自己的本地時區看到該排程。\ \ 在這種情況下，兩位代理人都是依各自的時區從 8-5 工作。然而，由於所在地之間有時區差異，他們開始工作的時間會相差三個小時。從紐約的 Alice 角度來看，洛杉磯的代理人會依各代理人各自的時區顯示，從 11-8 工作。 {% endhint %} ## 排程 #### 排程是多個排班群組及其底層基礎架構／組件的集合
下圖提供了一個排程的範例，由多個排班群組組成，橫跨一天。各種色塊標示出每位代理人在一天中負責的不同活動。若需要，排班管理員可進一步細分此檢視，以依個別代理人或特定排班群組查看排程。
#### 每個排程一次最多可產生四週 在建立排程時，排班管理員一次最多可建立四週的排程。這並不限制排程可以提前多久建立，而是限制每次可定義的排程長度。換句話說，排班管理員可以透過建立一個接一個的排程，來一次排定超過四週的內容。 {% hint style="success" %} **範例** 在 12 月時，排班管理員 Alice 可以建立一個自 1 月 1 日開始、持續四週到 1 月 28 日的排程。若要排到 1 月 28 日之後，Alce 必須建立另一個獨立排程，而且她可以立即這麼做。 {% endhint %} #### 管理員可以為特定代理人與排程建立自訂工作規則 Workforce Management 管理員可以建立規則，以設定班次與排程的某些條件。系統會自動檢查是否違反規則，例如最長工時、休息時間、連續工作日、班次之間的最短間隔，或必須排定的活動。若排程違反任何規則，系統會提醒管理員。 ## 預測 #### 預測會將歷史互動資料轉換為人力配置建議 預測可預估未來聯絡中心互動量，讓您能在正確的時間配置正確數量的代理人。Workforce Management 會使用歷史佇列資料，以 15 分鐘為單位產生預測，接著將這些量的預估轉換為人力配置建議。 {% hint style="success" %} **範例** 排班管理員 Alice 為未來四週建立了一份預測。此預測使用歷史資料來預估以 15 分鐘為單位的每日互動量。每一天的預測量都以過去對應日期的資料為基礎，這表示週一的預測來自過去的週一，而週二的預測則來自過去的週二。因此，如果上午 8 點到下午 2 點之間在週一通常比週二更忙，預測就會反映出週一比週二需要更高的人力配置。 {% endhint %}
#### **一個** 預測需要至少有一個相關佇列的排班群組 預測需要至少有一個相關聯絡中心佇列的排班群組。完成後，管理員會定義名稱、開始日期與持續時間（最多四週），然後選取要目標化的指標。系統會針對預測期間內的每個 15 分鐘區間，計算預估量與建議人力配置。 剛接觸 Zoom Contact Center 嗎？可以透過 CSV 匯入歷史佇列資料（每個檔案最多 10MB），在即時資料累積之前，先建立初始預測。 #### 預測可圍繞四種績效目標建立 | 指標 | 其作用 | | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **服務水準目標** |

人員需在指定時間窗內回覆一定百分比的互動

範例：如果某公司的服務水準協議要求在 30 秒內回覆 75% 的所有來電互動，預測就會將每個 15 分鐘期間內達成預期目標所需的人力納入考量。

| | **平均接聽速度** |

人員需將所有來電的平均等待時間維持在指定秒數以下

範例：如果某公司目標是將平均接聽速度維持在 30 秒，預測會考量達成該目標所需的人力。請注意，這個指標計算的是等待時間的算術平均值。例如，若一通電話在 1 秒內被接聽，而另一通電話在 60 秒內被接聽，兩通電話的累積平均接聽速度約為 30 秒。

| | **佔用率** |

人員需以代理人實際處理互動所花費時間的百分比為目標

範例：如果一名代理人在一小時中有 54 分鐘都在與客戶互動，該使用者的佔用率就是 90%。因此，建立 90% 佔用率的預測，通常代表每位代理人每小時約有 54 分鐘在支援客戶。

| | **損耗率** |

加入人力緩衝，以因應缺勤、非生產性活動與例行不可用時間

範例：如果預測需要 10 位代理人，但損耗率為 20%，則預測人數會提高到 12 位代理人，以因應兩位可能的缺席。即使有 20% 的代理人缺席，預測所需的最低人力水準仍可維持。

| {% hint style="info" %} **注意** 當預測選取多個指標時，系統會套用最嚴格的限制。例如，如果服務水準目標要求在 30 秒內回覆 75% 的互動，而平均接聽速度目標設定為 60 秒，系統就會優先考量服務水準，因為達成較嚴格的門檻會自動滿足平均接聽速度的要求。 {% endhint %} #### 區間與批次編輯可讓您將歷史資料無法預測的因素納入考量 原始歷史資料並不總能反映您已知即將發生的情況。預測可以透過兩種方式調整： * **區間編輯**：手動提高或降低任何 15 分鐘區間的預估量（適用於預期的尖峰） {% hint style="success" %} **範例** 如果某公司預期某一小時內的來電量異常高，排班管理員可以手動增加預期量來因應預期的變化。 {% endhint %} * **批次編輯**：將百分比或固定數量的變更套用到整個預測 {% hint style="success" %} **範例** 如果某公司即將在下週啟動新的行銷活動，並預期量會增加 10%，就可以更新預測以反映 10% 的增加，確保人力配置充足。這種批次編輯方式可讓主管依特定數量修改量，例如每 15 分鐘增加（或減少）10 通來電；或依百分比修改，例如每 15 分鐘來電增加（或減少）20%。 {% endhint %} #### 將預測套用到排程，以便在期間開始前找出人力缺口 一旦發布，預測即可套用到排程。 **人力配置** 子區段會列出套用到本週排程的所有排班群組，並比較 *已排定* 與 *所需* 的人力，並提供 *淨人力* 差額。此表格可讓排班管理員快速判定每 15 分鐘增量的人力水準，並可動態調整使用者已排定的活動，以維持足夠的人力。
#### 運用人工智慧，根據預測自動產生最佳化班次排程 系統會在考量班次長度、最少與最多工作日數，以及休息和午餐等預先規劃活動等參數後，決定符合服務水準協議所需的最佳班次數量。Workforce Management 管理員可以選取多個服務群組，將產生的班次套用到排程中，並依偏好批次指派代理人。 #### 建立容量規劃，以預測最長 12 個月的人力需求 這些規劃會計算全職當量（FTE）需求，並考量每個排班群組的工時、損耗百分比與離職率等因素。使用者可以透過視覺化小工具檢視與比較所需 FTE 與目前 FTE，存取詳細的每月與每週明細，並將資料匯出為 CSV 或 PDF 格式。 #### 標記特殊日期以進行自訂預測，因假期、停業或異常情況而將其從過去與未來資料中排除 Workforce Management 管理員可以使用百分比或固定值來調整量或處理時間。特殊日期會在預測與人力配置檢視中醒目顯示，且所有變更都會記錄在稽核報告中。這有助於透過納入獨特的業務事件來提升預測準確度。 #### 透過週期性排程，自動建立短期預測 Workforce Management 管理員可以將短期預測設定為每週自動建立，最長可持續 4 週。管理員可以指定預測應何時建立，例如在預測期間開始前 5 天。排定的預測會維持與原始範本預測相同的排班群組與預測指標。管理員也可以透過行事曆檢視來查看與管理週期性預測，並可選擇刪除單一執行個體或整個系列。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://library.zoom.com/technical-library/zh-tw/shang-wu-fu-wu/zoom-workforce-management/workforce-management-explainer/core-concepts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.