照服員智慧派工排班

🎯 這條流程解決什麼

照服員派工是居家長照機構最燒腦的日常工作，沒有之一。每個個案的服務時段、項目、地點都不一樣：早上九點要去 A 阿嬤家備餐、十點半要到隔壁區 B 阿公家協助沐浴、下午又有另一個案場的陪同就醫。照服員彼此之間又有技能差異（有沒有受過管路照護、移位訓練）、每月工時上限、固定排休、以及只跑特定區域的限制。排班人員常常同時開著好幾張試算表，靠肉眼和記憶手動拼班，一個照服員臨時請假，就得連環調動好幾個個案，整個下午就這樣耗掉。

排得不好，代價是雙重的。對機構，是照服員大量時間浪費在跨區奔波的路上，等於付了薪水卻沒產生服務；對長者與家屬，則是服務遲到、甚至開天窗——而長照服務一旦延誤，影響的是長輩準時被照顧、準時用餐用藥的基本需求，家屬的信任也跟著流失。更別說手動排班幾乎無法驗證「這個班表有沒有違反工時規定」，到了月底結算才發現某位照服員超時，已經來不及補救。

以一家有 20 位照服員、每日約 60 個服務時段的機構估算，資深排班人員每天要花 2 到 3 小時排隔日班表，臨時異動再加 1 小時以上，一週光排班就吃掉 15 到 20 小時人力，而且高度依賴特定老手，一旦這個人請假，整個排班就停擺。

這條流程把派工的判斷規則交給自動化：彙整當期所有個案需求，依技能、地區、工時與既有班表媒合出可行人選，再把同一人當日的多個案場串成合理路線，最後把個人班表推播到照服員手機並追蹤簽到。排班人員從「手動拼圖」變成「審核與微調」，臨時異動也能更快重派。完整的自動化編排思路可參考 /automation，更多排程與媒合邏輯的範例見 /recipes。

導入後的改變

導入前： 排班人員開多張試算表，憑記憶逐一比對技能、地區、工時與排休，手動拼出班表，再一個個用 LINE 或電話通知照服員。每日排班 2 到 3 小時，臨時異動再加 1 小時以上，工時是否超標到月底才知道，高度依賴特定老手。

導入後： 系統自動彙整需求、套用媒合規則產出建議班表並標出衝突，排班人員只需審核與微調，確認後一鍵推播到每位照服員的 LINE，並自動追蹤簽到。每日排班作業壓到 30 到 45 分鐘，異動重排 15 分鐘內完成。

以前述機構估算，每週排班工時可從 15 至 20 小時降到 5 至 7 小時，省下約 6 成；因為媒合時就把工時上限與排休納入硬條件，超時違規幾乎可以即時擋下，月底結算的爭議大幅減少；路線最佳化讓照服員每日通勤空檔縮短，等於在不增聘人力的情況下，多釋放出可服務的時段。服務遲到與開天窗的比例，也因為有簽到追蹤與未到通知而明顯下降。

流程怎麼運作

1. 需求彙整（📋）： 排程觸發（每日或每週）或新個案進來時，流程讀取 Google Sheets 中各個案的服務項目、時段、地區與特殊照護需求清單，整理成當期待排的服務任務池。
2. 條件媒合（🧮）： 對每個服務任務，比對照服員的技能標籤、可服務地區、既有班表與當月累計工時，排除不符資格或會造成衝突、超時的人選，產出每個任務的可行候選名單。這一步把「硬規則」（資格、工時、衝突）和「軟偏好」（盡量固定同一照服員服務同一長者）分開處理。
3. 路線最佳化（🗺️）： 對同一照服員當日的多個案場，依地理位置與服務時段串成合理動線，減少來回跨區的移動空檔，並保留必要的通勤緩衝。
4. 班表推播（📲）： 排班人員在 Sheets 上審核確認後，流程把每位照服員的個人班表透過 LINE Notify 推播出去，內含個案地址、時段與服務內容摘要。
5. 簽到追蹤（✅）： 每個服務時段開始前提醒照服員簽到；若逾時未回報抵達，自動通知督導，讓督導能即時了解狀況並調度替代人力。

需要的工具與串接重點

• Google Sheets： 同時是個案需求表、照服員資料表（技能、地區、工時上限、排休）與班表輸出的中樞，建議分頁清楚、欄位結構化。
• Google Calendar： 每位照服員一個行事曆，作為既有班表與衝突檢查的依據，確認後也寫回行事曆。
• LINE Notify： 班表推播與簽到提醒的主通道，照服員多半習慣用 LINE。
• Gmail： 用於督導端的彙整通知或正式班表存查。
• n8n / Make： 核心編排。媒合與路線邏輯較複雜，建議放在 Function／Code 節點，並把規則參數（工時上限、緩衝時間）抽成可調設定。重要原則是：系統只產出「建議班表」並標出衝突，最終確認由人操作，不要讓系統自動發班。整體串接藍圖可參考 /automation。

常見錯誤與注意事項

• 自動媒合不等於最終派工： 系統僅依設定條件給出建議，正式派工前須由排班人員或督導人工確認照服員資格、長者照護需求與雙方意願是否真正合適，AI 不取代專業判斷。
• 勞動條件須合規： 照服員工時、休息時間與勞動條件必須符合勞動基準法與長照相關規定，工時上限與連續工作時數要設成硬條件，不可為了排滿而違規。
• 敏感個資保護： 個案地址、健康狀況屬高度敏感個資，推播內容只給需要的照服員，並落實 Sheets 權限控管與保密。
• 照護連續性： 媒合時盡量讓同一位照服員服務同一位長者，貿然頻繁換人會影響照護品質與長者信任，這點要設為軟偏好而非單純最佳化通勤。

台灣中小企業情境案例

新北一家中型居家長照機構，原本由一位資深督導包辦所有排班，每天傍晚要花近三小時排隔日班，照服員臨時請假就得手忙腳亂地打電話補人，月底還常發現有人工時超標。導入這條流程後，督導改為每天傍晚花約半小時審核系統產出的建議班表，把例外個案手動微調，確認後一鍵推播。三個月下來，照服員的平均每日通勤空檔減少約四分之一，等於每位照服員每週能多承接一到兩個時段；超時違規幾乎歸零；最關鍵的是，這位資深督導請假時，代理人也能照著系統的建議把班排出來，機構不再被單一老手綁住。

延伸應用

這條流程可以和上下游緊密串接：把 /workflows 的服務評估預約結果，自動帶進需求彙整作為新個案來源；服務完成後再接到家屬進度回報流程，形成「評估 → 派班 → 回報」的完整鏈路。進一步還能加上動態調度：當某照服員回報異常或臨時請假，系統自動從候選名單推薦替補並通知督導確認。若機構規模成長，可把路線最佳化升級為串接地圖 API 計算實際車程，讓動線更精準。更多可組合的自動化模組與範本，/recipes 裡有不少能直接拿來改用。

流程圖

用到的工具

更多「醫療健康」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →