很多專員都有過這種時候：
明明手上已經在忙，卻又跳進來一筆新對話，心裡忍不住想一句「為什麼這一筆會分給我？」
其實分派不是隨機，也不是誰比較衰就一直被丟。
系統在做分派時，主要就顧三件事：
- 第一，對話不能卡住，不能沒人接。
- 第二，盡量交給處理起來比較順的人。
- 第三，工作量要平均，不要老是同幾個人被分到爆。
所以在設計分派邏輯時，通常會同時看幾個面向：現在有沒有在線、手上還能不能接、跟這筆對話合不合、最近分派是不是太集中在某些人身上。
下面會照著實際發生的順序，一段一段說明。每一段都配一個小情境，讓你在看分派結果時，比較知道「喔，原來是因為這個原因分到我這裡」。
1. 當機器人已經指定「第一個要接的人」
如果在機器人腳本的最後一步，有設定「轉派專員」，並且在「首次分派給」欄位中指定了特定專員，系統在第一次分派時，會直接將交談交給這位專員。
在這個階段，系統不會再檢查技能、群組、工作量或其他分派條件，而是以機器人流程的指定結果為優先，確保交談能先由「被指定的專員」接手。
只有在指定的時間內，該名專員沒有接應，系統才會放棄這次指定，改由後續的分派設定，將交談轉派給下一位符合條件的專員。
需要注意的是，這項指定只影響首次分派。
一旦交談進入後續轉派流程，就會回到原本的分派規則，依照設定進行後續的分派判斷。
管理者在機器人流程中，將某類交談設定為「首次分派給 H 專員」。
當交談從機器人轉到真人時，系統會直接把交談交給 H 專員，不會再比較其他專員。
如果 H 專員在指定時間內沒有接應，交談才會依照既有的分派設定，轉派給其他可分派的專員。
2. 先確認：現在是不是有人真的接得下
分派一開始，系統不會先比誰資深、誰比較會處理問題。
它只看一件事：現在有哪些專員，是真的還能接新的交談。
在 FIRST LINE 裡，只有同時符合下面兩個條件的專員，才會被列入分派名單：
- 專員目前狀態是「在線」
- 專員目前服務中的交談數，還沒到管理者設定的上限
這樣做的原因很單純。
如果專員已經暫時離開，或是手上案件已經滿載，再把新對話分過去，只會讓交談卡住，也增加專員的壓力。
A 專員把狀態設成「離開」，準備去處理其他事情；
B 專員目前在線，但手上同時服務的交談數已經到達管理者設定的上限。
這種情況下在分派時，會先把 A 跟 B 都排除掉，只從在線、而且還沒滿載的專員中，繼續往下做分派判斷。
3. 這筆交談原本是希望交給哪一類專員
在確認有哪些專員接得下之後，系統接著會回頭看這筆交談本身的設定，判斷它理想上應該由哪一類專員來處理。
在 FIRST LINE 裡，常見會參考的設定包含：
- 這個交談所屬的管道，是否有指定需要哪些能力
- 在前面的機器人流程中，是否有限制只能由特定群組或部門接手
系統不是馬上做決定，而是先把這些條件整理出來，作為後續分派的依據，確保交談不會被送到「本來就不該處理這類問題」的專員手上。
管理者在某個管道中設定，該管道的交談只能由具備英文處理能力的專員接手。
當用戶在機器人流程中選到英文相關選項時，這筆交談在進入分派前，就已經被標記為需要英文能力，一般未具備英文能力的專員就不會被列入分派考量。
4. 把交談條件套回目前在線的專員
在確認交談需要哪些條件之後，系統會把這些條件，實際套用到第一步找出的在線專員名單中。
也就是說，只有同時符合下面兩件事的專員，才會被列為可分派對象：
- 符合這筆交談所設定的條件（像技能、群組、部門限制）
- 目前服務中的交談數，還沒有達到上限
這個階段的目的，是把「理想上該接這筆交談的人」，跟「現在真的接得下的人」交集找出來，避免交談被送到不適合、或已經滿載的專員手上。
某個管道被設定，只能由具備英文處理能力的專員接手。
系統先找到目前在線的 10 位專員，其中只有 4 位有設定英文技能；
再進一步檢查後，發現其中 1 位專員已經達到管理者設定的同時服務上限。
最後，真正進入可分派名單的，就只剩下 3 位具備英文能力、且目前還接得下的專員。
5. 條件過嚴時，會先確保交談不被卡住
在實務上，交談的條件有時會設得比較細，但剛好那一刻，所有符合條件的專員都不在線，或已經滿載。
如果管理者有開啟相關設定，系統在發現「完全找不到符合條件的專員」時，會先放寬能力或條件限制，改由目前在線、且尚未達到服務上限的專員接手，避免交談停在等待狀態。
這樣的設計不是忽略設定，而是優先確保交談能被接起來，再由專員視實際狀況處理或轉交。
某個管道原本設定，只能由具備英文處理能力的專員接手。
但當下所有具備英文能力的專員都處於離線狀態。
在有開啟條件放寬的情況下，系統不會讓交談停在分派中等待，而是會先將交談分派給目前在線、且尚未達到服務上限的專員接手處理，確保交談能先被接起來。
等後續有符合英文能力的專員可接應時，再由專員或流程視實際狀況進行轉派，而不是一開始就讓交談卡住。
6. 是否優先交給前一次服務的專員
在進一步比較其他條件之前，系統會先檢查管理者是否有開啟「優先分派給前一次服務的專員」這項設定。
如果有開啟，而且前一次服務該用戶的專員同時符合以下條件：
- 目前狀態為在線
- 服務中的交談數尚未達到上限
- 也在前面步驟產生的可分派名單中
那這筆交談就會直接分派給該名專員，不再進入後續的比較流程。
如果沒有開啟這項設定，或是該專員目前無法接手，系統才會繼續往後進行其他分派判斷。
這樣的安排，是希望在條件允許的情況下，讓同一位專員延續處理，減少來回轉交造成的斷點。
某位用戶昨天由 C 專員處理一筆問題，今天再次進入同一個流程。
如果管理者有開啟優先分派設定，而 C 專員目前也在線、未滿載，系統就會直接把這筆交談交回給 C 專員。
7. 依技能分派時，先看有沒有明顯更適合的人
當管理者使用的是「依技能分派」的模式，系統在可分派名單產生後，會多做一個判斷：
比較每位專員與這筆交談的技能適配程度。
如果在可分派的專員中，剛好只有一位專員的技能等級明顯高於其他人，系統會在這一步就做出決定，直接把交談分派給該名專員，不再進入後續的比較流程。
如果符合條件的專員不只一位，或是多位專員的技能等級相同，系統就不會在這個階段強行選人，而是交由後面的分派機制，繼續進行平衡判斷。
某筆交談被標記需要由具備英文處理能力的專員接手。
在可分派名單中，只有 D 專員的英文技能等級明顯高於其他人。
這種情況下，系統會在這個階段就直接把交談分派給 D 專員，不再進入後續的比較流程。
如果同時有兩位以上的專員英文技能等級相同，系統就會繼續往下，比較工作量與其他分派條件，來決定最終的分派對象。
8. 比較目前的工作量，避免某些人一直被塞
當可分派名單中，有多位專員條件相近、也都能處理這筆交談時，系統接下來會比較每位專員目前的工作量。
在 FIRST LINE 裡，會同時參考：
- 正在分派中的交談數
- 已經在處理中的交談數
這兩者加總後，工作量相對較低的專員，會優先接到新的交談，讓整體分派維持在可負擔的範圍內，而不是集中到同幾位專員身上。
D 專員與 E 專員都具備英文處理能力，也都在可分派名單中。
目前 D 專員手上同時處理 6 筆交談，而 E 專員只處理 2 筆。
在其他條件都相同的情況下，系統會優先把新的交談分派給 E 專員，避免交談集中到已經較忙的專員身上，讓整體工作量維持在比較平衡的狀態。
9. 參考近期的分派紀錄，讓分派更平均
如果前一步比完之後，所有可分派的專員在能力與目前工作量上都沒有差異，系統會再往前看一小段近期的分派紀錄，讓分派結果不會長期集中在同幾個人身上。
- 在 FIRST LINE 裡，會以「可分派專員人數 × 10」作為觀察範圍，檢視這段期間內，每位專員實際被分派交談的次數。
- 在其他條件都相同的情況下，最近被分派次數較少的專員，會優先接到新的交談，讓整體安排維持在相對平均的狀態。
目前可分派的專員只有 2 位，系統會回看最近 20 筆交談的分派紀錄。
在這段期間內，F 專員與 G 專員的工作量相同，能力條件也一致，但 F 專員實際接到的交談次數比較少。
在其他條件都沒有差異的情況下，系統就會把下一筆交談優先分派給 F 專員，讓整體分派結果維持在比較平均的狀態。
10. 最後條件都一樣時，也一定會分得出去
如果在上述所有步驟中，仍然完全分不出差異，系統仍然會做出分派結果，不會讓流程停在原地。
在這種極端情況下，交談會分派給專員 ID 較小的專員，作為最終決定依據，確保每一筆交談都能順利進入處理流程。
目前只剩兩位專員在線，狀態、條件、工作量，以及近期的分派次數都完全相同。
在這種情況下，系統會依照既定的排序規則，從中選擇一位專員接手，確保交談可以立刻進入處理流程，而不會卡在分派階段。
對團隊到底帶來什麼改變
你可以把整個分派流程理解成三個重點：
先確認現在有人接得下，再盡量把交談交給合適的專員，最後把工作量分散開來。
對管理者來說，這套分派機制最大的好處，是服務不會因為人員狀態變動就亂掉。即使有人暫時離開、有人突然忙起來，交談仍然能依照設定自動流動，不需要一直人工盯著誰該接、誰不該接，團隊安排也比較有彈性。
對專員來說，分派結果是有邏輯可循的。不是看到新對話跳進來只能猜「是不是我又被點到」，而是知道系統會看狀態、條件和目前負載，讓每個人都在相對合理的節奏下處理交談，忙的時候不會被一直塞，空的時候也不會被完全忽略。
如果拿來跟沒有分派機制的聊天後台相比，差別會很明顯。沒有分派時，交談常常靠搶、靠人盯、或乾脆固定幾個人處理，短期看起來快，但時間一拉長，容易出現資訊斷層、負載失衡，管理成本也越來越高。
這套分派設計的價值，就在於把「誰來接」這件事，從人為判斷變成一套可調整、可預期的流程，讓團隊在規模變大、情況變複雜時，服務品質仍然能穩定維持。