IT支持记录示例通常围绕一次内部报障展开，从员工提交请求到支持人员关闭工单，完整记录请求信息、处理过程和结果确认三组字段。本文给出一份填写完整的办公电脑无法登录记录，并逐项说明填写理由，帮助读者理解各字段的作用，迁移到账号权限、软件故障、网络连接等内部服务场景。
要点总览（TL;DR）
- 示例围绕一次办公电脑无法登录的内部报障，按请求信息、处理过程、结果确认三组字段完整填写，可直接对照使用。
- 现象描述写报错原文、尝试次数与影响对比；影响范围与紧急程度分开判断，分别回答“影响多大”和“多快要处理”。
- 排查动作按时间顺序保留关键判断依据，解决方式与遗留事项分开写，关闭前完成用户确认。
- 字段结构可迁移到账号权限、软件故障、网络连接等内部服务请求，重点是时间、责任人、状态前后一致。
- 记录只覆盖单次请求的受理与处置；事件恢复与根因治理、设备维修技术教程不写入本文范围。
这份IT支持记录示例要解决什么问题
这份示例面向内部员工报障、IT支持人员受理的日常场景，交付物是一份字段齐全、前后自洽的填写记录。读者可以把它当作模板对照使用：先看完整填写结果，再理解每个字段为什么这样写，最后提炼出可复用的填写规律。
记录本身要支撑三件事。第一是查询，当用户再次询问进度，或主管想了解某类问题的处理情况时，能直接从记录中找到答案。第二是交接，当原处理人休假或转交他人时，接手人读记录即可继续处理，不必重新询问用户。第三是关闭确认，记录中保留用户确认与关闭时间，说明这次请求以什么方式结束。
需要说明的是，本文只讨论单次内部服务请求的记录填写。事件恢复的整体流程设计、根因治理、设备维修操作步骤不在本文范围内，示例中的人物、部门、设备与时间均为演示情景。
完整示例：一次办公电脑无法登录的支持记录
以下示例设定为：某公司市场部员工在工作日上午发现办公电脑无法登录系统，通过服务台提交报障，IT支持人员完成受理、排查、处置与关闭。示例中的人名、部门、编号均为虚构，用于演示字段写法。
| 字段分组 | 字段 | 填写内容 |
|---|---|---|
| 请求信息 | 请求人 | 李明（示例） |
| 部门 | 市场部 | |
| 联系方式 | 分机 8021，企业即时通讯账号 liming | |
| 设备或系统 | 办公笔记本 NB-市场-037，Windows 登录界面 | |
| 现象描述 | 输入正确密码后提示“用户名或密码不正确”，连续尝试三次均失败；同一账号在网页邮箱可正常登录 | |
| 影响范围 | 仅本人一台设备受影响，无法进入桌面使用本地办公软件；网页邮箱与即时通讯正常 | |
| 紧急程度 | 中：当日有对外报价文件需处理，但可通过其他设备临时应对 | |
| 报障时间 | 2025-03-11 09:12 | |
| 处理过程 | 受理人 | IT支持 王强（示例） |
| 受理时间 | 2025-03-11 09:20 | |
| 初步判断 | 网页端可登录、本机登录失败，判断为本地账户缓存或密码同步问题，暂不按账号锁定处理 | |
| 排查动作与时间点 | 09:25 远程连接设备，确认登录界面报错信息；09:32 核对账号状态，确认账号未被锁定；09:40 检查本机是否近期修改过密码，发现用户前一日在网页端改过密码，本机仍使用旧凭据 | |
| 处置措施 | 09:48 指导用户在本机使用新密码登录，并清除保存的旧凭据；09:55 重启设备复测登录正常 | |
| 协作方 | 无，单人处理完成 | |
| 结果确认 | 恢复时间 | 2025-03-11 09:55 |
| 解决方式 | 用户使用网页端修改后的新密码完成本机登录，旧凭据清除后不再报错 | |
| 用户确认 | 10:05 李明确认可正常登录并打开本地办公软件 | |
| 关闭时间 | 2025-03-11 10:08 | |
| 遗留事项 | 提醒用户后续修改密码后同步更新本机保存的凭据；建议在入职与改密通知中补充该提示 |
这份记录从09:12报障到10:08关闭，时间线连续，受理人、处置人与确认人清晰，状态从“待受理”走到“已关闭”，读者可以据此还原整个过程。
逐项解释：每个字段为什么这样填
现象描述写可观察事实
“电脑坏了”无法帮助支持人员判断问题。示例中写明了报错原文、尝试次数、失败范围，以及“网页邮箱可正常登录”这一对比信息。可观察事实让受理人不必先打电话追问，就能形成初步判断。填写时建议包含：看到什么提示、在哪个界面、什么操作触发、是否影响其他功能。
影响范围与紧急程度要分开判断
影响范围回答“多少人、多少业务受影响”，紧急程度回答“多快需要处理”。示例中影响范围是单人单机，紧急程度定为中，理由是当日有报价文件需求但存在替代设备。两者分开写，排班人员才能据此排序：影响全楼的网络中断即使描述简短也应优先，单人问题则按紧急程度和排队情况安排。填写时避免把“很急”直接等同于“影响大”，也不要用紧急程度替代范围描述。
排查动作按时间顺序记录关键判断
示例中的排查动作带有时间点和判断依据：先确认报错，再核对账号状态，再检查密码修改记录。这样写的好处是，接手人能看到处理人排除了哪些可能，避免重复排查。填写时不必记录每一次点击，但要保留改变判断方向的动作，例如“确认账号未被锁定”直接排除了锁定这一分支。
解决方式与遗留事项分开写
解决方式说明这次请求如何恢复，遗留事项说明关闭后仍需跟进的内容。示例中解决方式是用户用新密码登录成功，遗留事项是提醒改密后同步本机凭据、建议补充通知。两者混在一起写，关闭后容易丢失后续动作；分开写，遗留事项可以单独转成待办或知识条目。
从这份示例可以迁移的填写规律
这份示例的字段结构可以复用到账号权限、软件故障、网络连接等内部服务请求。迁移时重点不在照抄内容，而在保持结构和一致性。
- 统一字段结构。同类请求使用同一组字段，便于横向查看。例如账号权限申请也记录请求人、系统名称、所需权限、影响范围、紧急程度，处理过程记录审批与开通动作，结果记录开通时间与用户确认。
- 时间、责任人、状态保持一致。报障时间不晚于受理时间，恢复时间不晚于关闭时间；每个处理动作有对应责任人；状态流转与时间点匹配。发现不一致时先核对再关闭。
- 面向下一个接手人写。记录中的缩写、设备编号、系统名称首次出现时写清楚，判断依据写出来，让未参与处理的人也能读懂。
- 关闭前完成用户确认。用户确认是关闭的前提，确认内容写清“确认什么恢复正常”，而不是只写“已解决”。
当这类记录从个人表格搬到统一的服务台工具中，字段结构和状态流转就需要有承载的地方。ONES Desk 面向企业服务与协作场景，可用于 IT 服务、内部支持等场景，支持自定义工单属性与工单内容，适配不同的收集场景；团队可以集中管理工单状态、处理进度和责任分工。示例中的请求信息可以对应工单的收集字段，处理过程对应处理记录与状态流转，结果确认对应关闭前的确认环节。若某次请求需要研发跟进，工单可一键关联到 ONES Project 的需求或缺陷工作项持续跟踪；处理中形成的经验也可关联到 ONES Wiki 页面沉淀。是否采用工具承载，取决于团队是否需要跨人查询、交接和统计，单人或临时场景用统一模板同样可行。
适用边界：哪些内容不写进IT支持记录
IT支持记录聚焦单次请求的受理与处置过程，回答“谁在什么时候报了什么、谁怎么处理、结果如何”。以下内容适合放在其他位置，不必塞进这条记录。
- 事件恢复与根因治理。当同一问题反复出现或影响多个用户时，恢复过程之外的根因分析、改进措施属于服务事件与问题管理范畴，记录中可保留关联编号，详细分析另处展开。
- 设备维修技术教程。拆机步骤、系统重装操作手册等内容属于技术文档，记录中写清处置动作和结果即可，操作细节放到知识库。
- 与本次请求无关的沟通。记录保留与处置相关的信息，闲聊、重复确认等内容可精简，避免关键信息被淹没。
最后再次说明，本文示例为演示情景，用于说明字段写法与填写规律，不代表真实客户案例或实测效果。读者在实际使用时，应结合本单位的服务台字段配置与审批要求调整，涉及具体产品版本与配置差异时以实际环境为准。
常见问题
IT支持记录里的“影响范围”和“紧急程度”能不能合并成一个字段？
可以合并，但会损失排序依据。影响范围回答“多少人、多少业务受影响”，紧急程度回答“多快需要处理”，两者并不总是同向：单人单机问题可能因为对外交付而紧急，全楼网络中断也可能发生在非工作时段。分开填写时，排班人员可以先按范围判断波及面，再按紧急程度安排顺序。若团队请求量很小、由同一人处理，合并为一个“优先级”字段也能运转，前提是在字段说明中写清判断口径。
用户口头说“好了”，还需要在记录里写用户确认吗？
需要。口头反馈容易随时间模糊，记录中的用户确认要写清确认时间、确认人和确认内容，例如“10:05 李明确认可正常登录并打开本地办公软件”。这样在后续回访、争议核对或同类问题复现时，能判断当时是以什么状态关闭的。若用户暂时联系不上，可在记录中注明已尝试联系的时间与方式，把请求置为待确认状态，待用户回复后再关闭。
同一问题反复出现，是继续开新的支持记录还是并入原记录？
单次请求仍按次记录，保证每次报障的时间、影响和处置可追溯；同时在记录中关联此前的记录编号或问题单号，便于看出重复发生的规律。根因分析、改进措施属于服务事件与问题管理范畴，适合放在问题单中展开，支持记录里保留关联编号即可。这样既不丢失单次处理细节，也避免把分析内容塞进每条记录。
用表格记录和用服务台工具记录，怎么选？
判断依据是是否需要跨人查询、交接和统计。单人或临时场景用统一模板的表格即可满足；当请求量增加、多人轮班、需要按状态流转和按类别统计时，工具承载更合适。ONES Desk 面向企业服务与协作场景，可用于 IT 服务、内部支持等场景，支持自定义工单属性与工单内容，适配不同的收集场景，团队可以集中管理工单状态、处理进度和责任分工。示例中的请求信息可对应工单收集字段，处理过程对应处理记录与状态流转，结果确认对应关闭前确认环节。
记录关闭后，遗留事项应该怎么处理才不丢失？
把遗留事项写成可执行的动作，而不是泛泛提醒。示例中写的是“提醒用户后续修改密码后同步更新本机保存的凭据；建议在入职与改密通知中补充该提示”，前者可以转成对用户的待办，后者可以转成知识条目或通知模板的修改建议。在工具中，处理中形成的经验可关联到 ONES Wiki 页面沉淀；需要研发跟进的事项可关联到 ONES Project 的工作项持续跟踪。遗留事项与解决方式分开写，关闭后仍能单独检索。
