IT支持记录是一张把内部服务请求从受理到关闭讲清楚的工单，通常包含提交人、问题现象、影响范围、分类与优先级、处理过程、解决结果和后续动作。本文给出一份办公网络中断的完整填写示例，逐字段说明填写理由，并归纳可迁移到账号权限、软件安装等请求的规律与适用边界。示例为演示情景，可借助ONES Desk这类工单管理产品承载记录留痕与状态流转。
要点总览（TL;DR）
- IT支持记录需要把提交人、问题现象、影响范围、分类与优先级、处理过程、解决结果和后续动作写清楚，让请求、处理与结果三个环节可以回看。
- 示例以办公网络中断为演示情景，按受理、处理、关闭全过程填写，问题描述写到可复现，处理过程按时间记录动作与观察结果。
- 影响范围决定优先级，解决结果要附验证主体和验证范围，关闭前由请求人确认，后续动作写成可指派、可检查的具体条目。
- 这套写法可迁移到账号权限、软件安装、打印机故障等内部服务请求；设备维修教程、事件恢复与根因治理放在记录之外。
- ONES Desk 可承载工单属性自定义、状态流转与关联知识库或项目工作项；预置模板与关闭确认机制属于选型时需向产品方核验的配置项。
这份示例要解决什么填写问题
IT支持记录在内部服务场景中承担三重作用：让请求人把问题说清楚，让处理人知道从哪里接手，让团队在事后能回看这件事是怎么被解决的。它是一份服务过程的凭证，连接请求、处理与结果三个环节。填写质量直接影响响应速度：描述含糊的记录往往需要反复追问，处理过程缺失的记录在交接或复盘时无法还原现场。
本文示例覆盖一条工单从受理、处理到关闭的完整过程，重点回答三个问题：一张完整的记录需要哪些字段，每个字段为什么这样填，以及这套写法能否迁移到其他内部服务请求。示例中的编号、人员、时间与设备信息均为演示设定，用于展示填写结构，不代表真实客户案例，也不附带任何量化成效。
完整示例：一条办公网络中断的IT支持记录
以下示例设定为某公司办公区三层东侧的网络中断事件，工单由行政助理提交、IT支持工程师处理。表格按字段分组呈现，便于对照填写。
| 字段分组 | 字段 | 示例填写内容 |
|---|---|---|
| 基本信息 | 工单编号 | IT-2024-0318-017 |
| 基本信息 | 提交人 | 行政部 李某 |
| 基本信息 | 提交时间 | 2024-03-18 09:42 |
| 基本信息 | 提交渠道 | 服务台在线表单 |
| 问题描述 | 现象 | 三层东侧办公区约12个工位无法连接公司Wi-Fi，有线网络同样无响应；手机热点可正常上网，判断为办公区网络设备侧问题 |
| 问题描述 | 发生时间与频率 | 09:30左右开始，持续存在，重启电脑后未恢复 |
| 问题描述 | 影响范围 | 三层东侧约12人无法访问内网系统与共享盘，影响当日报销单据提交；其他楼层正常 |
| 分类与优先级 | 分类 | 网络与连接 / 办公区无线及有线接入 |
| 分类与优先级 | 优先级 | 高（多人受影响且阻断内网业务操作） |
| 分类与优先级 | 指派对象 | IT支持组 王某（网络方向） |
| 处理过程 | 09:55 受理 | 王某接单，电话联系李某确认影响范围与起始时间 |
| 处理过程 | 10:10 初步排查 | 远程查看三层接入交换机状态，发现东侧端口组离线 |
| 处理过程 | 10:35 现场处理 | 到弱电间检查，确认该交换机供电模块异常，更换备用交换机并恢复端口配置 |
| 处理过程 | 11:05 恢复验证 | 请李某协助确认东侧工位Wi-Fi与有线网络恢复，内网系统可正常访问 |
| 解决结果 | 处理结论 | 交换机供电模块故障导致端口组离线，更换备用设备后网络恢复 |
| 解决结果 | 验证方式 | 请求人现场确认12个工位网络恢复，IT侧复查交换机端口状态正常 |
| 关闭信息 | 关闭时间与关闭人 | 2024-03-18 11:20，王某关闭，李某确认可关闭 |
| 后续动作 | 关联事项 | 故障交换机送修登记（资产编号SW-3F-02）；在知识库补充“办公区整片断网排查步骤”条目；提请关注同批次交换机供电模块状态 |
这份示例的关键在于前后自洽：问题描述中的“三层东侧约12人”与影响范围、验证环节的人数一致；处理过程的时间点连续且与关闭时间衔接；后续动作指向记录之外的具体事项，而非笼统的“持续跟进”。
逐项解释：每个字段为什么这样填
字段填写的共同标准是：让没有到过现场的人也能据此判断问题性质、处理路径和完成状态。以下按字段分组说明判断依据。
问题描述：写到可复现、可判断
示例中的描述包含现象（无法连接Wi-Fi、有线无响应）、对照信息（手机热点正常，排除终端侧问题）、时间与频率（09:30开始、持续存在）、已做尝试（重启电脑无效）。这些信息让处理人不必先打电话追问就能判断大致方向。描述中写“约12个工位”而非“很多人”，是因为可计数的影响范围能直接支撑优先级判断。请求人不必给出技术结论，只需把看到的现象和已尝试的动作写清楚。
影响范围与优先级：范围决定紧急程度
优先级依据影响人数、业务阻断程度和是否有替代方案综合判断。示例中多人无法访问内网系统、影响当日报销提交，且无临时替代手段，因此定为高。若同样断网但仅影响一人且可用手机热点完成工作，优先级可降为中或低。填写时把影响范围写具体，优先级才有依据可查，避免出现“感觉比较急”这类无法复核的判断。
处理过程：记动作与时间，不记口号
示例的处理过程按时间顺序记录“谁在什么时间做了什么、看到什么结果”，例如“远程查看交换机状态，发现东侧端口组离线”。这类记录在交接班、复盘或同类问题再发时可以直接复用。写成“已排查网络问题”则丢失了排查路径和判断依据，对后来者没有参考价值。每条记录保持一个动作加一个观察结果，时间点精确到分钟即可。
解决结果：写清验证方式
解决结果需要回答“怎么确认问题真的解决了”。示例同时记录了两侧验证：请求人现场确认12个工位恢复，IT侧复查端口状态正常。只写“已恢复”缺少验证主体和验证范围，事后出现反复时无法判断当时是否真正解决。验证方式应与问题描述中的影响范围对应，描述里提到多少人、哪些系统，验证就覆盖同样的范围。
关闭信息与后续动作：两件事分开写
关闭信息回答“这条工单何时、由谁、经谁确认结束”，示例中记录了关闭时间、关闭人和请求人确认。后续动作回答“工单之外还有什么要做”，例如设备送修、知识库补充、同类设备关注。二者混写会导致工单关闭后遗留事项无人跟踪，或遗留事项被误认为工单未完成。把后续动作写成可指派、可检查的具体条目，比写“持续关注”更有执行价值。
从这份示例能迁移出哪些填写规律
这套写法适用于账号权限申请、软件安装、打印机故障、系统访问异常等内部服务请求。以下五条规律可以直接迁移。
- 描述以现象和影响为主。请求人写看到什么、影响谁、已尝试什么；技术判断留给处理环节。账号权限类请求则写清申请的系统、账号、所需权限和业务用途，同样遵循“可判断”标准。
- 过程记录按时间顺序留痕。每条记录包含时间、动作和观察结果。软件安装类请求可记录“检查系统版本—下载安装包—安装并启动验证”的步骤链，便于他人接手。
- 结果需可验证。解决结论要附验证主体和验证范围。权限开通类请求的验证可以是“请求人登录目标系统并完成一次实际操作”。
- 关闭前确认请求人认可。由请求人确认问题不再出现再关闭，避免处理人单方面判断完成。确认方式可以是工单内回复或口头确认后由处理人记录。
- 同类请求沉淀为常见问题条目。重复出现的请求（如某系统登录失败、某型号打印机驱动安装）在处理完成后整理成自助条目，让后续请求人先自助解决，减少重复工单。
这些规律落到工具上，对应的是记录字段可配置、处理过程可留痕、状态流转可追踪。ONES Desk 面向IT服务、内部支持等场景，支持自定义工单属性与工单内容以适配不同收集需求，团队可以集中管理工单状态、处理进度和责任分工；工单还可关联到 ONES Wiki 页面沉淀服务经验，或关联到 ONES Project 的工作项持续跟踪需要研发介入的事项。是否提供预置的IT支持记录模板、关闭前的请求人确认机制，属于选型时需要向产品方核验的具体配置项。
适用边界：哪些内容不放进IT支持记录
IT支持记录的目标是讲清一次服务请求的处理过程，以下内容适合放在记录之外或仅以引用方式出现。
设备维修技术教程不纳入记录正文。示例中更换交换机只记录动作和结果，具体的拆装步骤、接线规范属于操作手册或知识库文章的内容。记录里写教程会稀释关键信息，也不便于按工单检索。
事件恢复与根因治理归服务事件与问题管理。当一次故障影响面较大、需要多团队协同恢复时，恢复过程的指挥与沟通属于事件管理；故障反复出现需要分析根因、制定改进措施时，属于问题管理。IT支持记录可以关联这些事项的编号，但不必承载完整的根因分析和治理计划。示例中的“提请关注同批次交换机供电模块状态”就是一条指向问题管理的线索，而非治理方案本身。
记录与知识库文章职责不同。记录回答“这一次发生了什么、怎么处理的”，知识库文章回答“这类问题以后怎么判断和处理”。前者是过程凭证，后者是可复用的方法。处理完成后把可复用部分提炼进知识库，两者各司其职。
示例情景与真实案例的区分。本文全部字段内容为演示设定，用于说明填写结构；真实记录应使用实际的人员、时间、设备与验证信息，并遵守所在组织的信息记录规范。
常见问题
IT支持记录和知识库文章应该怎么分工？
记录回答“这一次发生了什么、怎么处理的”，是单次服务的过程凭证；知识库文章回答“这类问题以后怎么判断和处理”，是可复用的方法。处理完成后，把记录中可复用的判断路径和操作步骤提炼进知识库，记录本身保留原始时间、人员和验证信息。两者混写会让工单越写越长，也会让知识库条目失去通用性。
请求人描述问题时写不出技术原因，记录还能填完整吗？
可以。请求人只需写清看到的现象、影响谁、从什么时候开始、已经尝试过什么，例如“无法连接Wi-Fi、有线无响应、手机热点正常、重启电脑无效”。技术判断由处理人在排查环节完成并写入处理过程。把现象和判断分开记录，既降低请求人的填写门槛，也让处理路径有据可查。
工单关闭后还有遗留事项，应该记在哪里？
遗留事项写在后续动作里，与关闭信息分开。关闭信息记录何时、由谁、经谁确认结束；后续动作记录设备送修、知识库补充、同类设备关注等工单之外要做的事。后续动作应写成可指派、可检查的具体条目，并明确责任人或关联事项编号，避免工单关闭后无人跟踪。
用ONES Desk承载IT支持记录时，哪些配置需要提前核验？
ONES Desk 支持自定义工单属性与工单内容，团队可以集中管理工单状态、处理进度和责任分工，工单还可关联到 ONES Wiki 页面或 ONES Project 工作项。是否提供可直接套用的IT支持记录模板、关闭前的请求人确认机制，以及字段与工作流配置在具体版本和套餐中的可用范围，建议在选型时向产品方核验。
一次故障影响多个楼层、需要多团队协同恢复，还按普通IT支持记录填吗？
影响面较大、需要多团队协同恢复的故障，恢复过程的指挥与沟通属于事件管理；故障反复出现需要分析根因、制定改进措施时，属于问题管理。IT支持记录可以关联这些事项的编号，记录本次请求的处理与结果，完整的根因分析和治理计划放在对应管理流程中，避免把记录写成分析报告。
