请假申请流程图
四条泳道的请假申请流程图：提交日期与假别、年假余额与顶班检查、主管审批、人力资源升级、薪酬处理与复工面谈。
运作方式
把泳道改成你们真实的角色
把员工、主管、人力资源和薪酬，换成你们实际拥有的职能。在规模较小的组织里，人力资源和薪酬本来就是同一条泳道，应当合并，而不是画成一次根本不会发生的交接；在轮班制团队里，排班负责人通常值得单独一条泳道，因为真正决定有没有人顶班的其实是他们。
定好余额检查所依据的规则
决定“年假余额是否足够？”到底检验什么：是截至休假日期已累计的余额，还是全年额度；结转和半天怎么计算；调休是否放在同一个池子里；以及是否允许出现负数余额。把答案写在步骤备注里，免得每位审批人各用一套自己的算法。
定义升级门槛
给“是否属于长期或无薪休假？”一个数字和一份清单。常见的触发条件是：任何一天无薪、任何法定假（育儿假、收养假、长期病假），或者连续工作日超过某个固定天数的缺勤。同时记下每一类假期人力资源需要哪些材料，让人力资源审核这一步有明确的输入。
写明薪酬截止日和触发复工面谈的条件
写清楚薪酬最迟需要在哪一天拿到这次缺勤、由谁发送，然后定下让复工面谈成为强制项的条件，例如超过一定长度的病假，或任何长期休假。这两点是团队最常留作默认、不写下来的步骤。
补上你们实际存在的假别
年假、病假、育儿假、恩恤假、无薪假和进修假，很少走同一条路。要么把有差异的假别，从提交时记录的假别上分出分支；要么把这张图保留为通用路径，把例外情况放在单独的、相互链接的流程图里。
和主管一起审阅，并为已批准的图做版本管理
发布之前，先和两三位主管以及人力资源一起走一遍这张图；争论的焦点会落在升级门槛，以及由谁去通知薪酬。达成一致之后，在 QueryChart 中批准这张图并做版本管理，让主管接受培训的流程，和你们日后能拿出来指认的流程是同一个，也让每次修改都有迹可循，而不是作为新附件到处转发。
常见问题
请假申请流程应该包含哪些步骤？
至少要有：一份写明日期、半天和假别的申请；一次额度与余额检查；一次顶班与人力影响检查；主管的批准或驳回决定；长期或无薪缺勤的升级路径；日历与排班更新；在截止日之前通知薪酬；以及针对长期缺勤的复工面谈。最常缺失的恰恰是例外路径，也就是余额不够时怎么办、没有人顶班时怎么办，以及一份已批准的申请后来被变更或取消时怎么办。
员工剩余年假不够时该怎么办？
给它三条有名有姓的出路，而不是让审批人临场发挥。员工可以把这几天按无薪处理——这应当是一项政策决定，而且通常由人力资源来定，因为它会改变工资；也可以把日期改到与已累计余额相符再重新提交；或者撤回申请。常见的失误是默不作声地批到负数余额，而这通常要到年度结束、或者到离职结算时从最后一笔工资里扣回来，才会浮出水面。
请假申请由谁批准，主管还是人力资源？
普通年假通常由直属主管批准，因为真正要决定的是团队有没有人顶班。人力资源的介入由假别和长度触发，而不是由职级触发：无薪天数、育儿假或长期病假等法定假，以及超过你们既定门槛的缺勤，都需要人力资源在预约之前确认政策、额度和证明材料。把这条门槛写下来，正是让升级在不同主管之间保持一致的原因。
取消或变更的休假应该怎么处理？
把变更当作同一条记录上的一次新申请来处理：重新检查顶班，更新日历和人力资源系统，并通知薪酬。最容易被跳过的正是通知薪酬这一步，因为删掉一条日历日程不会通知任何人。如果变更发生在薪酬截止日之后，就无法从那一期里撤出，只能在下一期更正。把取消保留在记录上、而不是删除，也能让缺勤历史在日后统计时保持准确。