IT支持团队分工示例的核心，是把“谁接单、谁判断、谁处理、谁升级、谁复盘”写成一张可填写的职责表。本文给出一份按一线服务台、二线专业支持、三线系统与厂商、支持负责人四类角色填好的完整示例，逐项解释字段填法，并说明如何改写成自己团队的版本。示例中的角色、时限和分级均为演示取值，落地时可借助ONES Desk的工单分派与状态流转承载责任分工。
要点总览（TL;DR）
- 分工示例按一线服务台、二线专业支持、三线系统与厂商、支持负责人四类角色，逐行写清负责事项、输入、产出、响应时限和升级条件。
- 每类请求只设一个第一责任人，协作角色负责配合与交接，不承担最终关闭责任，避免共同负责导致无人跟进。
- 响应时限必须与升级条件成对出现，超时或影响范围扩大时转给明确角色，升级路径控制在一到两级。
- 改写时先列团队实际收到的请求类型，再按事项指定责任人；时限与分级按值班安排和影响范围重新设定，示例取值仅用于演示。
- 团队规模小或没有专职二线时合并角色；事件恢复与根因治理、设备维修技术操作不在本文范围。
这份分工示例要解决什么问题
这份示例面向内部服务与IT支持场景，覆盖员工报障到问题关闭的常规路径：员工通过服务台、即时通讯或邮件提交请求，一线受理并判断，能当场解决的直接关闭，需要专业处理的转二线，涉及系统变更或厂商的转三线，支持负责人处理升级、协调与复盘。示例的目标是让每一类请求都有明确的第一责任角色和升级出口，避免出现“大家都管、没人负责”的情况。
使用方式上，建议先把示例当作模板通读一遍，再对照本团队实际收到的请求类型逐行替换。示例中的响应时限（如15分钟、2小时、1个工作日）和升级条件（如超时未响应、影响人数超过阈值）都是演示取值，用于说明字段之间的配合关系，不代表行业标准，也不构成对任何团队的服务水平要求。团队规模、值班安排、人员技能结构不同，取值需要相应调整。
需要说明的是，本文聚焦分工表本身，即角色、事项、交接与升级的书面约定。事件恢复的具体操作流程、根因治理、设备维修技术细节不在本文展开，这些内容属于服务事件与问题管理、终端运维的专门范围。
完整示例：一张填好的IT支持团队分工表
下表是一份填好的分工表示例，按请求类型组织，每行只设一个第一责任人，协作角色用于交接配合，不承担最终关闭责任。表中“响应时限”指第一责任人首次回应的时限，“升级条件”指触发转派的判断依据。
| 请求类型 | 第一责任人 | 负责事项 | 输入 | 产出 | 响应时限 | 升级条件 | 协作角色 |
|---|---|---|---|---|---|---|---|
| 账号与权限申请 | 一线服务台 | 受理申请、核对审批、开通或转交 | 员工申请单、主管审批记录 | 开通结果回执、工单关闭记录 | 15分钟首次回应 | 涉及核心系统高权限时转二线复核 | 二线专业支持 |
| 办公软件使用问题 | 一线服务台 | 远程协助、常见故障排查 | 问题描述、截图、设备信息 | 解决说明或转派记录 | 30分钟首次回应 | 30分钟内未解决转二线 | 二线专业支持 |
| 终端设备故障 | 二线专业支持 | 诊断硬件与系统、安排维修或更换 | 一线转派单、设备编号、故障现象 | 诊断结论、维修或更换安排 | 2小时首次回应 | 需厂商保修或备件采购时转三线 | 一线服务台、三线系统与厂商 |
| 网络接入异常 | 二线专业支持 | 排查接入配置、定位断点 | 报障单、位置与网络环境信息 | 排查记录、恢复确认 | 30分钟首次回应 | 涉及网络设备配置变更时转三线 | 三线系统与厂商 |
| 业务系统故障 | 二线专业支持 | 复现问题、判断影响范围、组织处理 | 报障单、影响用户范围、错误信息 | 影响评估、处理方案、恢复确认 | 15分钟首次回应 | 影响多个部门或核心流程时升级至支持负责人 | 一线服务台、三线系统与厂商、支持负责人 |
| 系统变更与厂商协调 | 三线系统与厂商 | 执行变更、对接厂商、验证结果 | 变更申请、二线处理记录 | 变更记录、验证报告 | 1个工作日首次回应 | 变更失败或影响扩大时升级至支持负责人 | 二线专业支持、支持负责人 |
| 升级投诉与跨部门协调 | 支持负责人 | 受理升级、协调资源、跟踪闭环 | 升级工单、处理历史记录 | 协调结论、关闭确认 | 1小时首次回应 | 涉及预算或跨团队决策时上报上级管理者 | 一线服务台、二线专业支持、三线系统与厂商 |
| 重复问题与复盘 | 支持负责人 | 汇总高频问题、组织复盘、推动改进 | 工单统计、二线处理记录 | 复盘记录、改进事项清单 | 按周汇总 | 改进事项涉及系统改造时转三线评估 | 二线专业支持、三线系统与厂商 |
这张表可以直接作为填写底稿：保留表头，把“请求类型”换成团队实际收到的事项，再逐行确认第一责任人是否唯一、升级条件是否可判断。示例中同一事项没有出现两个第一责任人，协作角色只出现在配合位置，这是保证责任清晰的关键。
逐项解释：每个字段为什么这样填
第一责任人与协作角色为什么要分开
第一责任人是该行事项的最终关闭者，负责推进到有结论为止；协作角色提供信息、执行配合动作或承接转派，但不承担关闭责任。示例中“终端设备故障”的第一责任人是二线专业支持，一线服务台负责转派和回访，三线负责厂商保修对接。如果写成“一线和二线共同负责”，出现延误时就难以判断该由谁跟进。填写时可以先问一句：这件事最后是谁点“关闭”？答案就是第一责任人。
响应时限与升级条件如何配对
时限单独存在没有意义，必须配一个“超时后转给谁”的出口。示例中办公软件问题设定30分钟首次回应，超时未解决转二线；业务系统故障设定15分钟首次回应，影响多个部门时升级至支持负责人。这里有两个不同的触发维度：时间触发（超时）和影响触发（范围扩大）。填写时建议每行至少写一个可判断的触发条件，避免使用“视情况升级”这类无法执行的表述。升级路径只设一到两级，超时后直接转给明确的角色，减少层层转派。
输入与产出字段的作用
输入是接手时拿到的凭据，产出是交接或关闭时留下的记录。示例中“终端设备故障”的输入包括一线转派单、设备编号和故障现象，产出包括诊断结论和维修安排。这两个字段让交接有据可查，减少“电话里说过了”造成的遗漏。填写时可以把输入理解为“上一步必须交给我什么”，把产出理解为“我这一步必须留下什么”，两者对齐后，工单在角色之间流转时信息不会断档。
三线角色的边界怎么划
三线系统与厂商在示例中承担两类工作：执行系统变更和对接厂商。它的边界在于，三线处理的是需要系统权限、变更窗口或外部厂商介入的事项，常规排查和用户沟通仍由一线、二线完成。示例中“网络接入异常”由二线排查，只有涉及网络设备配置变更时才转三线。这样划分可以避免三线被日常问题淹没，也让变更类操作集中在有权限的角色手中。填写时建议明确写出“什么条件下才转三线”，而不是把所有疑难问题都推给三线。
从示例到自用：可迁移的填写规律
把示例改写成自己团队的版本，可以按以下规律操作，这些规律来自示例的填写逻辑，适用于不同规模的IT支持团队。
- 先列事项，再定角色。不要先按现有人员画格子，而是先把团队一个月内实际收到的请求类型列出来，合并同类项，再为每类事项指定第一责任人。按人头分工容易产生职责重叠，按事项分工则天然对应“谁最常处理这类问题”。
- 升级路径只设一到两级。示例中最多出现“一线转二线”“二线转三线”“升级至支持负责人”三种单步转派，没有出现多级串联。层级越多，工单停留时间越长，责任越模糊。填写时可以让每条升级路径的终点是一个具体角色，而不是“上级”。
- 把判断类工作与执行类工作分开。一线负责受理、判断和常见问题处理，二线负责专业诊断，三线负责变更与厂商协调。判断类工作前置可以减少一线反复向上确认，执行类工作集中则便于积累经验。示例中账号权限申请由一线核对审批后开通，只有高权限才转二线复核，就是这一规律的体现。
- 时限按请求类型和优先级分别设定。示例中业务系统故障的首次回应时限短于办公软件问题，系统变更按工作日计。统一时限会让紧急事项和一般事项争抢同一资源。填写时可以先按影响范围分两到三档，再为每档设定时限，并确保时限与升级条件成对出现。
分工表写完后，还需要一个承载流转的地方。ONES Desk 可用于IT服务、内部支持等场景，团队可以在其中集中管理工单状态、处理进度和责任分工，并通过自定义工单属性与工作流匹配上述角色和请求类型；工单还可关联到项目工作项持续跟踪。分工表规定“谁负责什么”，工单系统让每次转派、回应和关闭留下记录，两者配合才能让职责表真正执行起来。
适用边界：哪些情况需要调整示例
这份示例适合作为起点，以下情况需要先调整再使用。
- 团队规模很小或没有专职二线。当IT支持只有两三个人时，一线与二线的角色需要合并，示例中的转派关系可以简化为“受理人负责到底，涉及厂商时再转出”。此时分工表应减少角色数量，保留请求类型和升级出口即可。
- 事件恢复与根因治理。示例只覆盖从报障到关闭的常规路径，重大事件的恢复流程、根因分析和问题管理属于服务事件与问题管理的专门范围，本文不展开。团队如果有独立的事件管理机制，应在分工表中注明与本文示例的衔接点，而不是把两套流程混在一张表里。
- 设备维修的技术操作。示例中终端设备故障只写到诊断和安排维修，具体的拆装、刷机、备件更换等操作步骤不在本文范围，需要由终端运维规范另行规定。
- 时限与分级为演示取值。示例中的15分钟、30分钟、2小时、1个工作日等时限，以及“影响多个部门”这类分级描述，都是为了说明字段配合关系而设定的演示值，不构成行业标准，也不代表任何产品的内置能力。团队应结合自身值班安排、人员技能和服务对象预期重新设定，并在运行一段时间后根据工单数据调整。
当团队同时服务多个业务线、存在外包厂商或跨地域值班时，示例中的角色还可以进一步细分，例如按业务线设置二线接口人，或为厂商协调单设一个跟踪角色。调整的原则不变：每类请求一个第一责任人，每条升级路径有明确终点，每个时限配一个可执行的触发条件。
常见问题
团队只有两三个人，这张分工表还能用吗？
可以用，但需要先合并角色。两三个人的IT支持团队通常没有独立的二线和三线，建议把一线受理与二线诊断合并为“受理人负责到底”，只在涉及厂商保修、系统变更或备件采购时转出一个外部协调角色。表格保留请求类型、第一责任人、升级出口三列即可，输入、产出和时限仍建议保留，用来记录交接凭据和回应预期。角色数量减少后，升级路径相应缩短，避免工单在少数几个人之间反复转派。
响应时限应该按什么标准设定，示例里的15分钟、2小时有参考价值吗？
示例中的时限是演示取值，用于说明时限与升级条件的配合关系，不构成行业标准。实际设定时可以先按影响范围分档：影响多个部门或核心流程的请求给较短时限，个人办公软件问题给较长时限；再结合值班人数和高峰时段调整。设定后运行一段时间，用工单数据回看首次回应是否普遍超时，再决定放宽或收紧。时限必须配一个可判断的升级条件，例如“超时未解决转二线”或“影响超过一个部门升级至支持负责人”，否则时限只是数字。
一线判断不了该转给谁，分工表怎么处理这种情况？
这通常说明请求类型的划分还不够细，或者缺少判断依据。可以在分工表中为容易混淆的请求补充“判断要点”，例如账号权限申请写明“涉及核心系统高权限转二线复核”，网络接入异常写明“涉及网络设备配置变更转三线”。一线按判断要点对照执行，减少反复向上确认。如果某类请求经常出现判断分歧，说明它可能需要拆成两类事项，分别指定责任人。分工表运行一段时间后，把一线转派错误的记录汇总起来，反过来修订判断要点，比要求一线自行把握更可执行。
分工表写好后，怎么保证每次转派都按表执行？
书面分工表需要落到具体的流转载体上。常见做法是把请求类型做成工单的必填属性，把第一责任人设为对应角色的默认处理人，把升级条件写成状态流转规则，让转派动作在系统里留下记录。ONES Desk 可用于IT服务、内部支持等场景，团队可以在其中集中管理工单状态、处理进度和责任分工，并通过自定义工单属性与工作流匹配角色和请求类型。这样分工表规定“谁负责什么”，工单记录每次转派、回应和关闭，两者对照才能发现执行偏差。
示例里没有写重大故障的恢复流程，是遗漏了吗？
这是有意设定的范围边界。本文示例覆盖员工报障到问题关闭的常规路径，重大事件的恢复流程、根因分析和问题管理属于服务事件与问题管理的专门范围，需要单独设计流程和角色。团队如果已有事件管理机制，建议在分工表中注明衔接点，例如“业务系统故障影响多个部门时，按事件管理流程启动，支持负责人担任协调角色”，把两套流程的接口写清楚，而不是把事件恢复的步骤塞进日常分工表。设备维修的具体技术操作同样不在本文范围，由终端运维规范另行规定。
