請假申請流程圖
四條泳道的請假申請流程圖：提交日期與假期類別、年假餘額與替更檢查、主管審批、人力資源升級、薪酬處理與復工面談。
運作方式
把泳道改成你們真實的角色
把員工、主管、人力資源和薪酬，換成你們實際擁有的職能。在規模較細的機構裡，人力資源和薪酬本來就是同一條泳道，應該合併，而不是畫成一次根本不會發生的交接；在輪更制團隊裡，編更負責人通常值得獨立一條泳道，因為真正決定有沒有人替更的其實是他們。
訂好餘額檢查所依據的規則
決定「年假餘額是否足夠？」到底檢驗甚麼：是截至休假日期已累積的餘額，還是全年額度；結轉和半日怎樣計算；補假是否放在同一個池內；以及是否容許出現負數餘額。把答案寫在步驟備註裡，免得每位審批人各用一套自己的算法。
界定升級門檻
給「是否屬於長期或無薪休假？」一個數字和一份清單。常見的觸發條件是：任何一日無薪、任何法定假期（育兒假、領養假、長期病假），或者連續工作日超過某個固定日數的缺勤。同時記下每一類假期人力資源需要哪些文件，讓人力資源審核這一步有明確的輸入。
寫明薪酬截數日和觸發復工面談的條件
寫清楚薪酬最遲需要在哪一日收到這次缺勤、由誰發送，然後訂下令復工面談成為必須項目的條件，例如超過一定長度的病假，或任何長期休假。這兩點是團隊最常留作默契、不寫下來的步驟。
補上你們實際存在的假期類別
年假、病假、育兒假、恩恤假、無薪假和進修假，很少走同一條路。要麼把有差異的類別，由提交時記錄的假期類別分出分支；要麼把這張圖保留為通用路徑，把例外情況放在獨立而互相連結的流程圖裡。
與主管一起審視，並為已批准的圖做版本管理
發佈之前，先與兩三位主管以及人力資源一起走一次這張圖；爭論的焦點會落在升級門檻，以及由誰去通知薪酬。達成共識之後，在 QueryChart 中批准這張圖並做版本管理，令主管接受培訓的流程，和你們日後能拿出來指認的流程是同一個，也令每次修改都有跡可尋，而不是當作新附件四處轉發。
常見問題
請假申請流程應該包含哪些步驟？
最少要有：一份寫明日期、半日和假期類別的申請；一次額度與餘額檢查；一次替更與人手影響檢查；主管的批准或拒絕決定；長期或無薪缺勤的升級路徑；日曆與更表更新；在截數日之前通知薪酬；以及針對長期缺勤的復工面談。最常缺失的正正是例外路徑，也就是餘額不足時怎麼辦、沒有人替更時怎麼辦，以及一份已批准的申請日後被更改或取消時怎麼辦。
員工剩餘年假不足時應該怎麼辦？
給它三條有明確名稱的出路，而不是讓審批人臨場發揮。員工可以把這幾日按無薪處理——這應該是一項政策決定，而且通常由人力資源來定，因為它會改變薪金；也可以把日期改到與已累積餘額相符再重新提交；或者撤回申請。常見的失誤是不作聲地批到負數餘額，而這通常要到年度結束、或者到離職結算時由最後一筆薪金扣回，才會浮現出來。
請假申請由誰批准，主管還是人力資源？
普通年假通常由直屬主管批准，因為真正要決定的是團隊有沒有人替更。人力資源的介入由假期類別和長度觸發，而不是由職級觸發：無薪日數、育兒假或長期病假等法定假期，以及超過你們既定門檻的缺勤，都需要人力資源在預約之前確認政策、額度和證明文件。把這條門檻寫下來，正是令升級在不同主管之間保持一致的原因。
取消或更改的休假應該怎樣處理？
把更改當作同一條紀錄上的一次新申請來處理：重新檢查替更，更新日曆和人力資源系統，並通知薪酬。最容易被略過的正是通知薪酬這一步，因為刪除一項日曆項目不會通知任何人。如果更改發生在薪酬截數日之後，就無法由那一期抽出，只能在下一期更正。把取消保留在紀錄上、而不是刪除，也能令缺勤歷史在日後統計時保持準確。