请假审批流程泳道图：申请-审批-抄送-销假与异常情况
很多团队的请假流程，看起来简单：员工发起、主管同意、抄送 HR，就结束了。真正跑起来却常常卡在“细节没写清楚”：
- 到底谁决定“能不能请”？谁负责“记录到系统里”？
- 请假开始前临时改期怎么办？提前返岗要不要销假？
- 病假需要什么材料、补交的时限、验收标准在哪里？
- 主管口头同意了，但考勤系统没同步，月底对账一地鸡毛。
把请假审批画成泳道流程图的价值，就在于把“责任边界”和“交接点”写明白：谁做什么、做到什么程度、交付什么、系统里落到哪里。
先给结论：一张能落地的请假审批泳道图，至少要包含这些
- 泳道不要只画“员工/主管/HR”三条，至少要把“系统（考勤/审批）”单独作为泳道（哪怕只是一个节点），否则落地责任会丢。
- 关键交接点必须写清三件事：交接物（表单/材料/截图/证明）、交接条件（满足什么才流转）、验收标准（什么叫合格/完整）。
- 任何“口头同意/群里 OK”都应被流程吸收：要么回填到系统、要么转成可追溯的审批记录。
- 正常路径只占一半，另一半是异常：驳回、补材料、改期、紧急请假、提前返岗销假、超时未处理。
需要把流程快速画成泳道图、并导出给培训材料或制度附件时，可以直接用工具把泳道/节点/连线整理成一张干净的图：泳道流程图在线制作。
泳道怎么分：这 5 条泳道最常见，也最不容易翻车
请假审批的泳道划分，本质上是在回答“谁对哪段结果负责”。常见的做法有两种：按部门（员工、用人部门、HR、财务）或按角色（申请人、审批人、记录人、复核人）。在请假场景里，建议优先按角色+系统落点来分。
1）员工（申请人）
负责发起、补充材料、确认请假起止、必要时发起改期/撤回/销假。
2）直属主管（一级审批人）
负责对“业务可行性/排班影响”做判断，必要时转交上级或部门负责人。
3）部门负责人/项目负责人（可选的二级审批）
当请假会影响关键交付、或公司制度要求（例如连续请假超过 N 天）时进入。
4）HR/行政（制度与材料复核）
负责对“请假类型与材料合规”做复核；并对特殊类型（病假、婚育假、产检假、工伤）做材料要求与归档。
5）系统（审批系统/考勤系统）
负责记录、状态变更、通知、对接打卡/排班/薪资规则。把系统画出来，不是“技术细节”，而是为了明确：谁来点那个按钮。
小提示：如果你们公司“审批系统=考勤系统=同一个平台”，系统泳道仍然值得保留。它能避免“审批通过了，但考勤没生效”的责任扯皮。
正常流程模板：申请 → 审批 → 抄送/通知 → 考勤生效 → 销假/归档
下面这套节点写法，适合大多数公司（年假/事假/调休/病假均可扩展）。关键是：每个节点都要写“动作 + 产物”。
节点 A：员工发起请假申请
- 输入字段（建议写在节点备注里）：请假类型、起止时间（含半天/小时）、请假原因（可选）、联系人/交接人、影响范围（可选）。
- 交接物：系统表单（含时间范围）+ 交接安排（如有）。
- 验收标准：时间范围与排班/节假日规则一致；半天/小时口径明确（例如 9:00-12:00 还是 13:00-18:00）。
常见反例：只写“明天请假一天”。
- 为什么不行：请假开始/结束时间不清，遇到跨天、跨时区、半天、调休，很容易算错。
- 修正写法：写成“2026/04/10 13:00–18:00（半天）”或“2026/04/10 09:00–2026/04/11 18:00（两天）”。
节点 B：系统校验（自动）
- 校验项：余额是否足够（年假/调休）、是否与已有请假/出差冲突、是否在排班允许范围内。
- 失败分支：返回员工修改；必要时提示“余额不足，需转为事假/无薪假（按制度）”。
这一节点写清楚后，很多“人肉对余额”的沟通都能被吞掉。
节点 C：直属主管审批
- 判断问题（建议写成一个明确的条件句）：
- “在不影响关键交付/值班排班的前提下，是否同意？”
- 同意：流转到下一节点。
- 不同意：驳回并要求填写驳回原因（避免“不同意”三个字造成二次拉扯）。
常见反例：主管在群里回复“OK”。
- 风险：月底追溯困难，系统记录缺失。
- 修正：把“群里 OK”变成一个流程动作——主管在系统里点“同意”，或由员工在系统里补提并引用审批截图（并规定时限）。
节点 D：二级审批（条件触发）
触发条件可以写成菱形判断：
- “连续请假是否 ≥ N 天？”
- “请假是否涉及关键岗位/唯一值班？”
- “是否跨国家/跨时区影响排班？”
条件满足则进入部门负责人审批，否则跳过。
节点 E：HR/行政复核（按类型触发）
不是每一种请假都需要 HR 复核。把复核写成“按类型触发”，流程会更顺。
- 病假：材料要求（病历/诊断证明/发票等）、补交时限、隐私处理方式。
- 婚育/产检/陪产：材料清单与归档要求。
- 工伤：需要与安全/法务流程联动时，走另一路分支。
建议把“材料补交”单独画成回路：
- HR 发现材料不齐 → 退回员工补交 → 员工补交后重新进入 HR 复核。
节点 F：系统生效与通知（抄送）
- 动作：系统把审批结果写入考勤规则；通知员工、主管、HR；必要时抄送交接人/排班负责人。
- 交接物：系统状态=已通过；考勤日历/排班表更新完成。
- 验收标准：员工的考勤日历能看到请假标记；排班或值班表同步更新（若你们有单独系统，需明确“谁去同步”。）
节点 G：销假/提前返岗（可选，但强烈建议画出来）
很多公司只画“请假”，不画“销假”。结果是：员工提前返岗了，但系统仍按请假计薪/计出勤。
销假节点至少要写清：
- 触发：提前返岗/实际请假少于申请。
- 动作：员工发起销假（填实际结束时间）；主管确认；系统回收多余请假时长并修正考勤。
- 例外：如果是病假，销假是否需要补充“复工证明”（按制度）。
异常情况怎么画：把“最容易吵架的 6 种情况”单独做分支
请假流程真正的难点，不在“同意/不同意”，而在例外。建议把异常画成“从哪里分出去、回到哪里”，而不是简单写一句“异常处理”。
1）紧急请假（先走人，后补流程）
适用场景：突发疾病、家中紧急事件。
建议分支：
- 员工先通知主管（电话/IM）→ 主管给出临时意见 → 员工在 T+1 工作日内补提系统申请。
- 系统节点要写明：若逾期未补提，自动提醒；超过 T+N 进入异常清单由 HR 跟进。
关键点：把“先通知”也变成可追溯记录（例如要求在系统里补填“紧急请假说明”，并由主管在系统确认）。
2）余额不足（年假/调休不够）
很多争议来自“到底能不能批”。建议在图里把规则写明：
- 系统校验余额不足 → 员工选择：改为事假/无薪假（按制度）或调整时间 → 重新走审批。
- 如果允许“先借后补”（少数公司），也要明确谁批准、借多少、如何在下月回补。
3）改期/延长/缩短（请假变更）
改期不是重新走一遍，而是“变更请求”。建议画成：
- 员工发起变更（变更前后时间对比）→ 主管审批 → 系统更新考勤 → 若涉及 HR 复核类型则同步复核。
反例：员工在群里说“我改成后天”，主管回“行”。
- 风险：系统仍按原时间计；后续追责困难。
4）驳回与补材料（把原因和标准写出来）
驳回最怕两件事：理由不清、标准不一致。
- 驳回节点要求填写原因（可选模板）：时间冲突/排班冲突/材料不合规/信息不完整。
- 补材料分支写清：补什么、怎么补、补到哪里、多久内补齐。
5）跨系统同步失败（审批通过但考勤没生效）
如果你们是“审批系统 + 考勤系统”两套，建议把这条异常写进图里：
- 系统同步失败 → 通知 HR/考勤管理员 → 人工同步/重试 → 记录工单号 → 回填系统状态。
写清“谁负责重试”和“多久内解决”，否则月底就会变成“你以为对方会处理”。
6）销假失败/未销假（提前返岗但仍计请假）
建议做一个定期检查：
- 系统在请假结束后 X 小时检查员工是否打卡/是否返岗 → 若返岗但未销假，提醒员工补销假 → 超时则通知主管/HR。
节点怎么写才不空：把“交接点三件套”写在节点旁边
请假泳道图最常见的问题，是节点写得像口号：
- “HR 处理”
- “主管审批”
- “系统录入”
看似有流程，实际上无法执行。更可落地的写法是把交接点写成“动作 + 交付物 + 标准”。下面给一套可直接贴进图里当注释的模板。
交接点模板（可复用）
- 交接物：表单字段齐全/证明材料/截图/工单号
- 交接条件：余额充足/材料合规/时间不冲突/审批链完整
- 验收标准：系统状态已更新 + 通知已送达 + 考勤日历可见
如果你需要把这些“注释”统一放到节点旁边、并让连线尽量不打架，可以用在线工具做结构化编辑与自动对齐：泳道流程图在线制作。
一个具体示例：年假 2 天 + 改期 + 提前返岗（含销假）
把抽象流程落到一次真实操作，很多团队会立刻发现缺口。
场景：员工 A 申请 4/15–4/16 年假两天。审批通过后，因项目安排改为 4/16–4/17。后来 4/17 下午提前返岗，需要销假半天。
在泳道图里可以这样走：
- 员工泳道：发起年假申请（4/15 09:00–4/16 18:00）。
- 系统泳道：校验余额与冲突，校验通过。
- 主管泳道：同意。
- 系统泳道：生效并通知。
- 员工泳道：发起“变更请求”（原时间 → 新时间 4/16 09:00–4/17 18:00）。
- 主管泳道：同意变更。
- 系统泳道：更新考勤日历（4/15 取消、4/16–4/17 生效）。
- 员工泳道：4/17 13:00 提前返岗，发起销假（实际结束时间=4/17 13:00）。
- 主管泳道：确认。
- 系统泳道：回收 4/17 下午半天年假额度，并修正考勤。
这个例子里至少暴露三个关键点：
- 变更请求是否复用原审批链，还是要求重新走完整审批？
- 变更后是否需要重新做余额校验与冲突校验？
- 销假是否影响薪资口径（部分公司按小时、部分按半天）。
把规则写进图里，比在群里反复解释更省事。
验收清单：你的请假审批泳道图画完后，逐条对照
- 泳道是否覆盖：员工、直属主管、（可选）二级审批、HR/行政、系统（审批/考勤）？
- “同意/驳回”的判断条件是否写成一句可判定的话，而不是情绪化表述？
- 申请节点是否明确时间口径（小时/半天/天）与起止边界（是否包含当天）？
- 是否包含“变更/改期/撤回”的分支，并写明回到哪个节点？
- 是否包含“材料补交”的回路，并写明补交时限与验收标准？
- 是否包含“紧急请假：先通知后补提”的分支，并写明 T+N 规则？
- 是否包含“销假/提前返岗”的分支，并写明考勤修正动作？
- 若存在多系统，是否画出“同步失败”的异常，以及责任人、时限与记录方式？
- 是否能从任意节点追溯到系统里的一个状态（已提交/审批中/已通过/已驳回/已撤回/已销假）？
当你需要把这份流程交付给新人培训、制度附件或审计材料时，最好导出一份高清图并保持可二次编辑版本，避免后续改一次就要重画。泳道流程图在线制作 支持导出常见格式，适合直接贴进 PPT/文档。
常见问题（FAQ）
Q1：请假到底要不要 HR 参与审批？
看你们制度的“控制点”放在哪里。
- 如果公司主要关注“业务影响”，主管审批就够；HR 更适合做规则维护与抽查。
- 如果请假类型涉及材料合规（病假、婚育假、工伤等），HR 复核能减少后续争议。
实践里最稳妥的是：把 HR 作为“按类型触发的复核”，而不是所有请假都走 HR。
Q2：抄送/通知算不算流程的一部分？
算，而且常常是“落地”的关键一环。
很多冲突发生在“人不知道”：交接人没收到通知、排班负责人不知道、临时换班没同步。把通知画在系统泳道里，并写清抄送对象，会让流程更少靠“记得”。
Q3：病假材料涉及隐私，泳道图里怎么写才合适？
把材料要求写成“类型 + 规则”，不要把具体病情信息当作交接物。
例如：
- 交接物：诊断证明（仅用于类型与时长核验）
- 存放位置：HR 专用存储/权限控制
- 验收标准：盖章/日期/时长一致
Q4：请假审批超时怎么办？
建议在系统泳道画“超时提醒/升级”机制：
- 超过 X 小时未处理提醒审批人
- 超过 Y 小时自动升级到上一级或通知 HR/行政
- 记录超时次数，用于改进流程与资源配置
Q5：年假/调休的余额到底以哪个系统为准？
只要存在多个口径（HR 台账、考勤系统、项目排班表），就会发生争议。
建议在泳道图里明确：
- 余额来源系统（唯一真源）
- 同步频率与责任人
- 发现不一致时的处理路径（谁核对、在几天内修正、回填记录）
Q6：需要把“撤回申请”单独画出来吗？
只要你们允许撤回，就值得画出来。
撤回至少要写清：
- 允许撤回的条件（未审批/已审批但未开始/已开始则走销假或变更）
- 撤回后系统状态与考勤修正动作
如果一张请假泳道图能做到“谁负责点按钮、点完后系统里是什么状态、发生变更回到哪里”，它基本就能稳定运行，而不会只停留在制度文件里。
最后补两块：请假类型与材料要求、以及“销假”怎么画才不打架
请假流程最容易在两类地方出问题：一是“不同请假类型材料不一样”，二是“返岗后到底谁来销假、系统怎么生效”。这两块如果不在泳道图里占一个明确位置，执行时就会变成临时口头规则。
1）不同请假类型的材料与校验点（建议写在 HR/系统泳道的节点备注）
把材料要求写进泳道图，并不是为了增加复杂度，而是为了让流程可复用、可验收。
- 年假/事假/调休：通常不需要证明材料，但要校验余额、排班冲突、是否跨节假日。
- 病假：常见要求是病假条/就诊证明；关键是“补交时限”和“未补交怎么处理”。
- 婚育相关假：常见要求是证明材料；建议把“材料归档”作为一个明确节点。
- 紧急请假：常见是先口头同意，后补系统；建议把“事后补录”画成必经节点，而不是默认发生。
一个好用的写法是：在 HR 泳道放一个节点“复核类型与材料”，并在节点备注里列出“合格材料的最小集合”。这样即使不同团队制度略有差异，也能在一张图里完成对齐。
2）销假节点怎么画：把“返岗事实”与“系统落点”拆开
很多团队对“销假”理解不一致：有人认为返岗当天打卡就算销假，有人认为必须在系统里点“销假”。如果不拆开，最后一定会出现考勤对账问题。
建议把销假拆成两步：
- 员工泳道：提交销假（或提交提前返岗说明）
- 系统泳道：更新请假状态并同步考勤规则（必要时触发补卡/修正排班）
并且给一个判断节点：
- “是否提前返岗/是否跨天变更？”
- 否：按原计划结束
- 是：走改期/销假分支，明确需要谁确认、系统如何记录
这套拆法的好处是：
- 返岗是事实，系统记录是动作，责任不再混在一起
- 考勤对账时可以追溯：是谁点了“生效”按钮，什么时候生效
如果你需要把上述泳道与节点快速排版成一张清晰的泳道图，并导出 SVG / PNG / JPEG 或 draw.io 便于后续维护，可以直接用：