> 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" %} **範例** 在十二月，排程管理員 Alice 可以建立一個從 1 月 1 日開始、持續四週到 1 月 28 日的排程。若要排到 1 月 28 日之後，Alice 必須建立另一個獨立排程，而且她可以立即這麼做。 {% endhint %} #### 管理員可以為特定客服人員與排程建立自訂工作規則 Workforce Management 管理員可以建立規則，為班次與排程設定某些條件。系統會自動檢查規則違規情況，例如最長工時、休息時間、連續工作日、班次間最短間隔，或必備活動。當排程違反任何規則時，系統會提醒管理員。 ## 預測 #### 預測會將歷史互動資料轉換為人力配置建議 預測可推估未來聯絡中心的互動量，讓您能在正確的時間配置正確數量的客服人員。Workforce Management 會使用歷史佇列資料，以 15 分鐘為增量產生預測，然後將這些流量預估轉換為人力配置建議。 {% hint style="success" %} **範例** 排程管理員 Alice 已為未來四週建立了一個預測。此預測使用歷史資料，以 15 分鐘為增量預測每日互動量。每天的預測量是根據過去對應日期的資料而定，也就是說，週一的預測來自之前的多個週一，而週二的預測則來自之前的多個週二。因此，如果上午 8 點到下午 2 點之間在週一通常比週二更忙，預測就會反映出週一相較於週二有更高的人力需求。 {% endhint %}
#### **A** 預測需要至少具有一個相關聯佇列的排程群組 預測需要至少具有一個相關聯聯絡中心佇列的排程群組。一旦具備這些條件，管理員就會定義名稱、開始日期與期間（最多四週），然後選擇要鎖定的指標。系統會在整個預測期間內，以每 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 數量，存取詳細的每月與每週分項，並將資料匯出為 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.