审批人休假了，工单只能一直等吗？ServiceDesk Plus委派审批、备份负责人和请假交接实操指南
审批人休假、出差或临时不可用时，不应该只能依赖管理员手动催办，也不应该通过共享账号或口头授权绕过审批。ServiceDesk Plus Cloud支持委派机制，可在用户不可用期间重新安排待处理请求和审批：技术员名下请求可以转为未分配、交给指定技术员或按照全局规则处理；审批则可以交给具备相应权限的备用用户或组织角色。企业真正需要建立的是“谁不在—谁接手—接手什么—什么时候恢复”的交接规则，让请假不再成为IT服务流程里的隐形单点故障。
直接回答：审批人不在岗，工单应该怎么办？
如果审批是后续工作的必要前置条件，就不应该让请求无限等待原审批人回来，也不建议临时把审批账号交给别人。更合理的做法是提前配置委派：明确不可用时间，把待审批事项交给具有相应权限的备用用户或组织角色；如果技术员同时负责实际处理工作，还要决定其已有请求是转为未分配、交给另一名技术员，还是保持原负责人。委派结束后，再恢复正常责任关系并检查休假期间产生的异常和遗留事项。
什么是审批委派？
审批委派，是指原本负责批准或拒绝某项请求的用户暂时无法履行职责时，在指定时间范围内将审批权转交给其他具备审批权限的用户或组织角色。它并不是永久修改原审批流程，而是解决休假、出差、培训、临时离岗等短期不可用场景。
什么是请求委派？
请求委派关注的是“谁继续处理工单”。例如一名桌面技术员休假三天，他名下已经存在十几张未完成请求。企业可以根据规则将这些请求交给另一名技术员，或重新放回未分配队列。审批委派解决“谁有权做决定”，请求委派解决“谁继续做实际工作”，两者不应该混在一起。
本文适合谁阅读？
本文适合已经通过ServiceDesk Plus管理软件申请、权限开通、设备采购、员工入离职、变更、发布和采购审批，却经常出现“审批人不在，流程就停住”的ITSM负责人；也适合需要管理技术员排班、请假交接和备用负责人的服务台主管。
功能范围说明：本文涉及的委派操作主要依据ServiceDesk Plus Cloud当前帮助文档。不同部署版本、许可版本和后续产品更新可能存在功能差异，正式配置时应以企业当前环境中的菜单和最新官方帮助文档为准。
企业把IT服务流程做得越规范，审批通常越多。员工申请高权限账号，需要主管和系统负责人批准；采购新电脑，需要预算负责人审批；生产系统变更需要变更经理或相关责任人确认；软件许可证采购还可能涉及采购审批。一开始，这些审批能够解决“谁都能随便提、IT直接执行”的管理问题。
但流程运行一段时间以后，另一个问题很快就会出现：审批人并不是24小时都在线。
部门主管休年假一周，新员工的软件权限一直无法批准；采购负责人去外地开会，设备采购单卡在他的待审批列表；变更负责人临时请病假，生产变更已经安排好窗口，却没有人能够完成最终审批。技术团队明明已经准备好了所有工作，却只能等一个人回来点击“批准”。
这种问题看起来是“某个人不在”，实际上属于流程设计中的单点依赖。如果一项关键服务只能由固定某个人继续推动，那么人员休假、出差、调岗甚至离职，都可能直接转化为服务延期。
ServiceDesk Plus Cloud的服务模板本身支持多阶段审批，一个服务请求最多可以配置5个审批阶段，每个阶段还可以包含一个或多个审批人，并按照“任意一人审批”“全部审批”“首次响应”“多数审批”“按百分比审批”等方式判断是否通过。审批设计越精细，人员可用性就越应该一起考虑，否则完整的审批流程很容易因为其中一个人暂时缺席而失去效率。
因此，成熟的ITSM系统不应该只定义“正常情况下谁审批”，还要提前定义“这个人不在时怎么办”。委派机制真正解决的，就是审批和处理流程中的人员连续性问题。
一、为什么审批人一休假，整条服务流程就容易卡住？
审批本身并不会让流程变慢，真正容易造成阻塞的是“审批责任只绑定到一个人，却没有备用处理机制”。特别是在需要多阶段审批的服务里，只要其中一个节点长期没有动作，后面的技术任务就可能全部处于等待状态。
第一，审批节点经常是硬前置条件。很多服务请求在获得批准之前，本来就不应该开始执行。例如管理员账号申请、付费软件采购、生产权限、硬件采购等。如果审批人不在，IT既不能贸然执行，也无法继续推进，这种等待自然会直接转化成整体交付延期。
ServiceDesk Plus Cloud服务模板甚至可以配置“请求获得批准之前不要分配技术员”。这种设计能够避免技术员提前投入，但也意味着审批人不可用时，后续执行链会完全停住。因此，审批流程和委派机制本质上应该配套设计。
第二，企业往往只处理“计划休假”，没有处理“临时不可用”。年假一般会提前知道，临时病假、紧急出差、连续会议却未必有完整交接。如果只有靠审批人本人提前发邮件说“我不在，有事找某某”，一旦来不及交接，审批就会直接停在原账号下。
第三，技术员请假和审批人请假经常被当成一回事。实际上，两类责任不同。技术员离岗以后，需要处理的是名下未完成请求和未来新请求是否继续分给他；审批人离岗以后，需要处理的是他是否仍作为请求、变更、发布、问题或采购单的决策节点。一个人可能同时具有技术员和审批人两个身份，因此两类委派都需要检查。
第四，临时找人“代点批准”容易破坏责任边界。审批人不在，有些团队会让其把登录凭据交给同事，或者让管理员临时修改审批结果。这种做法虽然快，却会让系统记录无法准确回答“真正做出审批决定的是谁”。正式委派的价值，就是让备用审批人使用自己的身份完成动作，保留责任关系。
第五，恢复上班后没有做反向交接。不少团队只关注“请假期间不要卡住”，却忘了员工回来以后还要恢复正常责任。有些临时请求仍留在替班技术员名下，有些审批已经由备用人员完成，有些事项处理中途发生过变更。如果没有恢复检查，临时委派就容易变成长期责任混乱。
| 人员不可用场景 | 真正受影响的内容 | 建议动作 |
|---|---|---|
| 技术员请假 | 已有工单和后续处理责任 | 转未分配或委派给备用技术员 |
| 审批人请假 | 待审批请求及后续流程 | 委派给有权限的用户或角色 |
| 主管临时出差 | 短期大量服务请求审批 | 配置限时委派 |
| 关键负责人突然病假 | 已有请求和紧急审批 | 管理员按既定备用规则处理 |
| 人员恢复工作 | 临时转出的责任和遗留事项 | 核对委派结果并恢复正常分工 |
一句话判断
如果某个人暂时离开以后，一项服务就完全没有其他合法方式继续推进，那么这个流程存在人员单点依赖。委派的目的，就是提前给这个单点准备清晰、受控的替代责任人。
二、请求可以转给别人，审批也可以转给别人，但两种委派不能混着配
ServiceDesk Plus Cloud当前的委派配置把“请求所有权”和“审批”分开处理，这是实际落地时最重要的一点。管理员不能只看到某位技术员休假，就默认把他所有职责统一交给另一个人，而应该分别决定他的工单和审批如何处理。
请求所有权委派：当技术员不可用时，系统可以根据配置把分配给他的请求转为未分配、委派给指定技术员、不进行处理，或者依据全局委派配置执行。这里解决的是“实际工作继续由谁处理”。
这几种方式没有一种永远正确。如果某个支持组采用统一抢单方式，休假技术员的工单转回未分配队列可能更合适；如果某位技术员拥有明确的岗位备份人，例如网络A角和B角，则直接委派给指定技术员更容易保持连续性；如果只是短时间不可用，而且当前请求并不紧急，也可以根据企业规则决定暂时不转。
审批委派：ServiceDesk Plus Cloud当前支持将不可用用户待处理的请求、变更、发布、问题和采购单审批委派出去。企业可以选择组织角色作为替代审批人，也可以指定一名备用用户。无论使用哪种方式，都要先确认替代用户具备对应审批权限。
这一点非常重要。备用审批人应该是“本来就有资格在这个场景做决定的人”，而不是因为原审批人休假，就临时找一名方便的人点击批准。例如服务器采购的备用审批人可以是有采购审批职责的另一位负责人，而不能简单指定普通技术员代签。
临时单次审批委派：除了基于人员不可用配置的委派，ServiceDesk Plus Cloud在请求详情中还支持把某个待审批事项直接委派给一位用户。当前官方帮助文档说明，一次审批只能委派给一位用户；完成委派以后，原审批人暂时不能批准或拒绝该项审批。如果审批仍处于待处理状态，原审批人可以撤销委派后自行处理。
备用审批人也不能继续把这项审批再转给第三个人，只能执行批准或拒绝。这个限制能够避免审批责任在多个人之间不断转手，最后很难确认到底谁真正负责。
| 问题 | 应该判断什么 | 建议动作 |
|---|---|---|
| 技术员名下还有工单 | 其他人是否需要继续处理 | 配置请求所有权委派 |
| 用户同时是审批人 | 休假期间是否存在待审批事项 | 另外配置审批委派 |
| 只需要临时转一项审批 | 备用人是否具有审批权限 | 使用单次审批委派 |
| 同一岗位经常需要代班 | 是否存在稳定的A/B角机制 | 优先使用组织角色或固定备用人 |
| 备用人权限不足 | 是否有资格批准该业务事项 | 不要为了不断流临时越权 |
不要用“共享账号”代替审批委派
委派的意义之一，就是让备用人员使用自己的身份执行审批，并保留真实操作记录。如果审批人把账号密码直接交给同事，即使流程没有停，审批日志看到的仍然是原审批人，后续审计、责任确认和异常追查都会变得困难。人员连续性不能以牺牲责任可追溯为代价。
三、ServiceDesk Plus怎么配置请假委派？从全局规则到个人临时委派分六步
如果企业只在审批已经卡住以后才临时找管理员改负责人，委派就仍然属于“救火”。更好的方式，是在ServiceDesk Plus里提前建立统一规则，再允许技术员和请求者按照企业权限范围配置自己的不可用安排。
第一步：先在自动化设置中启用委派
ServiceDesk Plus Cloud当前需要在“设置 > 自动化 > 委派”中开启委派功能。管理员还可以决定是否为即将到来的请求启用委派。只有启用相关配置以后，请求和审批才能按照委派机制转移。
第二步：确定谁可以为自己配置委派
管理员可以允许技术员为自身不可用情况配置委派，也可以允许请求者为自己配置。这样计划休假时，用户可以在离岗前完成交接，而不是每次都必须让管理员代操作。企业可以根据内部控制要求决定是否开放这项自助能力。
第三步：标记不可用时间，不要只写“这周休假”
委派配置可以记录不可用类型、持续时间和原因，并支持按时间范围管理。计划休假最好写清具体时间，让委派只在真正需要的期间生效，避免员工已经回来，临时代理关系仍然继续存在。
第四步：分别决定请求和审批怎么处理
对技术员而言，请求所有权可以转为未分配、交给指定技术员、暂不处理或使用全局配置；审批则可以委托给组织角色或指定用户。配置时应该分别回答“他的工作谁继续做”和“他的决策权限谁临时代替”，不能因为两者都属于同一个人就一并处理。
第五步：检查备用审批人的权限和业务范围
官方文档明确要求，被选择为备用审批人的用户应具备相应审批权限。因此企业在建立A/B角时，不能只把姓名填进去，还要验证其是否有权审批对应的请求、采购或其他事项。尤其涉及高权限账号、生产变更和采购金额时，备用人也应该遵循原本的权限边界。
第六步：员工回来以后检查已完成委派和未完成事项
ServiceDesk Plus Cloud会按照持续时间把委派标记为进行中、已计划和已完成。员工恢复工作以后，可以查看休假期间由备用人员处理过的事项，确认哪些请求已经解决、哪些审批已经完成、哪些还需要继续跟进。委派结束并不等于交接结束，恢复后的复核同样重要。
ServiceDesk Plus Cloud还允许通过调度器和技术员可用性图表，在标记技术员不可用的同时配置委派。对于需要统一排班的服务台团队，这样可以把请假安排、人员可用性和工作交接放在同一套管理流程里，而不是一边在排班表里写“休假”，另一边再靠群消息通知同事帮忙看工单。
委派列表本身也可以区分活动委派、已过期委派和“未委派的不可用”。后者尤其值得服务台主管定期检查：它直接告诉管理员，哪些人已经被标记为不可用，却还没有明确安排备用处理方式。这类记录很可能就是未来流程阻塞的风险点。
委派前最好固定检查这5件事
① 不可用时间是否明确；② 备用人员是否有实际业务能力；③ 是否具备对应系统权限和审批权限；④ 已有请求是否需要立即转交；⑤ 委派结束以后由谁检查遗留事项。把这五项固定下来，委派才不会只是把“等待A”变成“等待B”。
四、真正容易出问题的是“临时不在”：用三个模拟场景看委派怎么落地
模拟场景A：部门经理休假，新员工第一天还拿不到系统权限
场景：员工入职流程中，CRM、财务系统和VPN权限都需要直属经理审批。经理提前休假一周，却没有设置任何审批代理。
结果：IT已经准备好电脑和基础账号，但业务系统权限请求一直停留在待审批状态。员工已经入职，真正影响其工作的却不是IT执行速度，而是审批节点无人处理。
调整：企业为部门负责人建立固定备用审批角色。计划休假前配置限时委派，由具备授权资格的副负责人在指定期间处理审批。经理返回后委派自动退出活动期，并对休假期间批准的事项进行必要交接。
建议观察：企业可以自行跟踪入职请求等待审批时间、入职当天未完成权限数量、因审批人不可用产生的超时，以及备用审批人实际处理数量。
模拟场景B：技术员请病假，名下20张工单没人知道要不要接
场景：一名桌面技术员临时病假，名下仍有多张处理中请求，其中既有普通软件问题，也有即将到期的高优先级事件。
问题：如果全部保持原负责人，高优先级请求可能继续计时却无人处理；如果一股脑全部转给另一名技术员，又可能突然造成对方负载过高。
调整：团队预先定义临时不可用规则：高优先级和临近SLA请求进入重新分配流程，普通低风险事项回到组内未分配队列，再结合组内调度完成分派。对于明确由A/B角维护的专项系统，则直接委派给备用负责人。
建议观察：跟踪技术员不可用期间的SLA违规、重新分派次数、备用人员新增工单量和恢复上班后的遗留工单数量，判断交接规则是否真正适合当前团队。
模拟场景C：生产变更窗口已经确定，最终审批人突然临时出差
场景：某项生产变更已经完成风险评估、实施计划和测试，周末窗口也已经确定，但最后一名审批人临时出差无法及时处理。
错误做法：为了赶窗口，让管理员直接跳过审批，或者让同事使用原审批人的账号点击批准。这样虽然没有延期，却破坏了审批责任和操作记录。
调整：如果企业已经定义相应替代授权，可以将待处理审批委派给符合权限要求的备用审批人，由其使用自己的身份查看变更信息并作出批准或拒绝。若没有合法备用授权，则应该按照既有变更治理规则重新安排，而不是为了窗口强行绕过控制。
建议观察：可以记录因关键审批人不可用导致的变更延期次数、临时委派次数、委派审批后的拒绝或补充信息比例，用这些数据判断关键岗位是否需要更完善的备用授权设计。
委派机制运行一段时间以后，还应该反向检查组织设计。如果某一个审批人几乎每次休假都会造成大量请求需要临时转移，说明问题可能已经不只是“请假交接没做好”，而是审批权过度集中。此时可以重新评估是否适合使用组织角色、多人审批规则或更合理的授权层级。
ServiceDesk Plus服务请求审批本身支持任意一人、全部审批、首次响应、多数审批以及按百分比审批等不同条件。对于不同风险等级的服务，企业可以结合自身制度选择适当方式。低风险标准服务不一定需要固定某一名高层负责人逐项审批，高风险权限和生产变更则仍应保持更严格的决策边界。
这里需要区分产品功能和企业治理规则：ServiceDesk Plus提供审批、组织角色和委派能力，但“哪类事项谁可以代批、代批金额上限、哪些权限禁止代理”仍然需要企业依据自身制度确定。工具可以执行授权关系，却不能替企业决定谁应该拥有这项授权。
| 建议复盘指标 | 它能说明什么 | 发现异常后的动作 |
|---|---|---|
| 平均等待审批时间 | 审批是否成为主要等待环节 | 分析岗位与阶段 |
| 未委派的不可用人数 | 请假交接是否存在空档 | 及时补充委派 |
| 因审批人不在产生的超时 | 关键岗位是否存在单点风险 | 建立A/B角或组织角色 |
| 备用审批使用频率 | 代理关系是否属于常态 | 必要时调整正式审批结构 |
| 委派后返工或撤销 | 备用人员是否真正具备决策能力 | 调整权限或培训备用人 |
核心要点速览
审批人或技术员休假，本质上是人员可用性发生变化，不能靠临时口头交接解决。 ServiceDesk Plus Cloud委派功能可以在用户不可用期间分别处理请求所有权和审批责任；请求可以转为未分配、交给指定技术员或按照全局配置处理；请求、变更、发布、问题和采购单等审批则可以交给具备对应权限的用户或组织角色。计划休假应提前配置，不可预期的临时缺席则需要预先定义备用规则；员工恢复工作以后，还应检查休假期间已经处理和仍然遗留的事项。
写在最后：流程不能因为一个人今天不在，就失去继续运转的能力
很多企业已经把IT审批设计得非常完整：谁申请、谁审批、需要几个阶段、通过以后由谁执行，都有明确规则。但真正考验一套流程是否成熟的，往往不是所有人都在岗的正常一天，而是关键负责人休假、出差或临时无法处理工作的时候。
如果每次人员缺席都需要管理员临时改单、群里找人代批，说明流程虽然“有审批”，却还缺少连续性。更可靠的方式，是在正常运行时就定义备用人员、权限边界和委派时限，让人员变化也成为流程设计的一部分。
借助ManageEngine ServiceDesk Plus，企业可以把服务请求审批、技术员可用性、请求责任和委派管理放在同一套ITSM环境中。这样，请假不再意味着工单停住，临时代班也不需要牺牲审批记录和责任边界，服务流程才能真正做到人员会变化、责任仍然清楚、工作继续推进。
常见问题解答（FAQ）
延伸阅读与官方资料：
