内部服务目录以“一项服务一行”的表格承载，通常包含五组信息：服务标识、服务内容、申请与交付、服务级别、治理信息。本文给出一份可直接复制到表格工具中的空白模板，并逐字段说明填写口径、必填与选填划分，用一条完整示例演示落笔方式，最后说明目录上线后的调整与维护方法。
要点总览（TL;DR）
- 内部服务目录按“一项服务一行”组织，核心信息分五组：服务标识、服务内容、申请与交付、服务级别、治理信息。
- 必填字段决定一条服务能否被用户独立使用，包括名称、编号、类别、负责人、说明、范围、不包含事项、申请入口、申请条件、处理角色、响应与交付时限、服务时间、状态和更新日期。
- 选填字段包括所需材料、支持渠道、优先级口径、版本和关联知识文档，可按目录成熟度逐步补齐。
- 填写时要把服务范围与不包含事项、响应时限与交付时限分开写清，避免用户误申请和时限争议。
- 目录上线后按季度复核、按变更影响分级评审，服务下线保留编号与历史条目，并用变更记录表追溯调整依据。
可复制空白模板：内部服务目录表
下表为空白服务目录，列按五组信息排列，可直接复制到 Excel、在线表格或文档表格中。填写时保持一项服务占一行，同一服务的不同套餐或不同受理渠道另起一行，避免在一格内混写多种情况。
| 服务名称 | 服务编号 | 服务类别 | 服务负责人 | 服务说明 | 服务范围 | 不包含事项 | 申请入口 | 申请条件 | 所需材料 | 处理角色 | 响应时限 | 交付时限 | 服务时间 | 支持渠道 | 优先级口径 | 状态 | 版本 | 更新日期 | 关联知识文档 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| （示例：账号开通） | （如 SVC-001） | （如 账号与权限） | （姓名/岗位） | （一句话说明做什么） | （覆盖对象与边界） | （明确不处理的事项） | （表单/工单/邮件入口） | （谁可以申请、前置条件） | （需提交的审批或信息） | （受理与执行角色） | （如 4 工作小时内） | （如 1 个工作日内） | （如 工作日 9:00–18:00） | （电话/群/工单） | （高/中/低的判定依据） | （在用/试运行/已下线） | （如 v1.2） | （YYYY-MM-DD） | （制度或操作文档名称） |
表格上方建议保留一行分组提示：前四列为服务标识，第五至七列为服务内容，第八至十三列为申请与交付，第十四至十六列为服务级别，最后四列为治理信息。分组提示行只用于阅读定位，正式发布时可隐藏或放入表头批注。
字段说明：每一列记录什么
字段说明的作用是让不同填写人对同一列给出一致口径。下表逐列解释含义与填写要求，模板、说明与后文示例使用同一套字段名。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 服务名称 | 用户申请时看到的服务叫法 | 用动宾结构，如“账号开通”“会议室预订”，避免内部项目代号 |
| 服务编号 | 目录内唯一标识 | 按类别加序号，如 SVC-ACC-001，发布后不随名称修改而变更 |
| 服务类别 | 服务所属分组 | 使用目录统一类别表，如账号与权限、办公设备、网络与访问 |
| 服务负责人 | 对该条目内容准确性负责的人 | 填岗位加姓名，避免只写团队名 |
| 服务说明 | 服务做什么、产出什么 | 两到三句，说明动作与交付物，不写宣传语 |
| 服务范围 | 覆盖的对象、场景与地域 | 写清适用人群、系统或办公地点 |
| 不包含事项 | 容易误认为属于本服务但实际不处理的内容 | 列出常见误申请事项，并指向正确服务或渠道 |
| 申请入口 | 用户发起申请的路径 | 填表单名称、工单入口或邮箱，保证可访问 |
| 申请条件 | 发起申请的前置要求 | 如入职状态、上级审批、已完成培训 |
| 所需材料 | 申请时必须提交的信息或附件 | 列明字段与文件类型，避免“相关材料”这类模糊表述 |
| 处理角色 | 受理、审批与执行的角色 | 按顺序写，如“服务台受理—主管审批—IT 执行” |
| 响应时限 | 从收到申请到首次回复的时间 | 写工作小时或工作日，注明起算点 |
| 交付时限 | 从受理到服务完成的时间 | 与响应时限分开写，注明是否含审批等待 |
| 服务时间 | 可受理与可执行的时间段 | 写工作日与时段，非工作时间说明顺延规则 |
| 支持渠道 | 咨询与催办的通道 | 列电话、群组或工单，注明首选渠道 |
| 优先级口径 | 高、中、低优先级的判定依据 | 按影响人数、业务阻断程度描述，不按申请人职级 |
| 状态 | 条目当前可用性 | 在用、试运行、暂停、已下线四选一 |
| 版本 | 条目内容的修订序号 | 每次实质性修改递增，如 v1.0、v1.1 |
| 更新日期 | 最近一次确认或修改的日期 | 统一 YYYY-MM-DD，例行复核未改动也更新该日期 |
| 关联知识文档 | 操作手册、制度或常见问题文档 | 填文档名称与存放位置，便于用户自助查询 |
两组字段容易混淆，需要单独约定。服务范围与不包含事项的分界是“是否由本服务受理”：范围内写本服务负责的对象和场景，不包含事项写用户常误投但应由其他服务承接的内容，并给出指向。响应时限与交付时限的分界是“是否完成”：响应时限只约束首次回复，交付时限约束服务结果交付，审批等待时间是否计入必须在条目中写明，否则两个时限会被不同人做出不同解释。
必填与选填：哪些字段不能空
必填字段决定一条服务能否被用户独立使用：用户看完能判断是否该找这个服务、去哪里申请、多久能有结果。选填字段用于提升体验和治理精度，可在目录起步阶段后补。
| 类别 | 字段 | 理由与适用场景 |
|---|---|---|
| 必填 | 服务名称、服务编号、服务类别、服务负责人 | 没有标识就无法检索、归属和追责，任何目录都必须具备 |
| 必填 | 服务说明、服务范围、不包含事项 | 决定用户是否找对服务，减少误申请 |
| 必填 | 申请入口、申请条件、处理角色 | 用户据此发起申请，受理方据此分流 |
| 必填 | 响应时限、交付时限、服务时间 | 构成对用户的基本承诺，缺失会导致预期失控 |
| 必填 | 状态、更新日期 | 保证目录可信，避免用户按过期信息申请 |
| 选填 | 所需材料 | 申请无需附件的服务可留空；有审批或附件要求时必填 |
| 选填 | 支持渠道 | 已有统一服务台入口时可留空，多渠道服务建议填写 |
| 选填 | 优先级口径 | 目录起步阶段可先沿用组织统一分级，条目有特殊规则时补充 |
| 选填 | 版本、关联知识文档 | 治理成熟后启用；有操作手册的服务应尽早填写文档 |
最小可用目录保留必填字段即可上线，适合服务数量多、先求覆盖的场景；完整目录补齐选填字段，适合用户量大、申请分流要求高的场景。字段留空时统一填“不适用”或“待补充”，并记录补充责任人，避免空格被理解为“没有要求”。留空的选填字段在用户侧不展示空标签，防止产生歧义。
填写示例：一行完整的服务条目
以下用一条账号开通类服务演示完整填写。示例为演示情景，取值仅用于说明写法，实际填写以组织制度为准。
| 字段 | 示例取值 |
|---|---|
| 服务名称 | 新员工系统账号开通 |
| 服务编号 | SVC-ACC-001 |
| 服务类别 | 账号与权限 |
| 服务负责人 | IT 服务台主管 张某 |
| 服务说明 | 为新入职员工开通办公邮箱、协同平台与业务系统的基础账号，并完成初始权限配置 |
| 服务范围 | 总部及分公司正式员工，入职前三个工作日内提交 |
| 不包含事项 | 不处理权限升级与跨部门数据授权，此类需求走“权限变更申请” |
| 申请入口 | 服务台“账号开通”申请表单 |
| 申请条件 | 已完成入职登记，且直属主管确认岗位与系统清单 |
| 所需材料 | 入职通知单、岗位所需系统清单 |
| 处理角色 | 服务台受理—系统管理员开通—直属主管确认 |
| 响应时限 | 受理后 4 个工作小时内首次回复 |
| 交付时限 | 材料齐全后 1 个工作日内完成开通，审批等待时间不计入 |
| 服务时间 | 工作日 9:00–18:00，非工作时间提交顺延至下一工作日 |
| 支持渠道 | 服务台工单（首选）、IT 支持群 |
| 优先级口径 | 影响新员工当日入职办公为高；常规入职为中；批量补录为低 |
| 状态 | 在用 |
| 版本 | v1.2 |
| 更新日期 | 2025-03-14 |
| 关联知识文档 | 《账号开通操作手册》《权限申请制度》 |
逐项看取值依据：服务名称用动宾结构并限定对象，便于检索；编号按类别缩写加序号，后续改名不影响引用；服务范围写清人群与提交时点，把“入职前三个工作日”作为可核验条件；不包含事项直接指向权限变更服务，减少误投；两个时限分别写明起算点和审批等待的处理方式，避免争议；优先级按业务影响判定，与申请人身份无关。
常见错误有三类。其一是把服务说明写成部门职责，如“负责账号管理”，用户无法判断能否申请，应改为具体动作与产出。其二是把不包含事项留空，导致用户把权限升级也提交到开通入口，应列出高频误申请项并给出指向。其三是响应时限与交付时限写同一数值，或未注明审批等待是否计入，应分别描述首次回复与结果交付，并写明计时规则。
调整与维护：目录上线后怎么改
目录上线后按固定节奏复核，按变更影响决定评审层级，才能保持条目可信。以下规则可直接作为维护清单使用。
- 字段增删判断标准：用户申请时反复询问的信息、受理方反复澄清的信息，优先新增为字段；连续两个复核周期无人使用的选填字段可合并或删除。新增字段先在一个类别试点，确认填写成本后再全量推广。
- 更新频率与责任人：服务负责人每季度复核一次所属条目，核对入口、时限与状态；目录管理员每月抽查条目完整性，重点检查更新日期与状态是否与实际一致。
- 变更评审与通知方式：修改服务范围、时限、申请条件属于实质性变更，需服务负责人与目录管理员共同确认，版本号递增并在服务入口发布变更说明；仅修正错别字或文档名称可直接更新，更新日期照常修改。
- 服务下线与历史条目处理：服务停止时状态改为“已下线”，保留条目与编号，补充下线日期和替代服务；历史条目不在目录首页展示，但保留在归档视图中，供查询和审计使用。
建议在表格之外维护一张变更记录表，字段包括：变更日期、服务编号、变更字段、变更前内容、变更后内容、变更原因、评审人、通知范围。变更记录与服务条目通过编号关联，复核时可直接追溯每次调整的依据。
当目录条目需要承载申请提交、审批流转和状态跟踪时，可以把每个服务条目对应为工作项类型或申请表单，由服务负责人维护条目内容，申请记录按条目归集，状态从受理到完成在同一处更新。ONES 的文档与工作项管理可用于承载这类条目和申请流转，具体配置按组织现有流程确定。目录中的条目内容与申请记录分开管理，条目修订走版本与评审，申请处理走工单状态，两者通过服务编号关联，避免把一次申请的处理结果写回目录条目。
常见问题
服务目录刚起步，字段填不全怎么办？
先保证必填字段完整，目录即可上线使用。选填字段留空时统一填“不适用”或“待补充”，并记录补充责任人，避免空格被理解为没有要求。用户侧不展示空标签，防止产生歧义。等条目稳定后，再按类别逐步补齐所需材料、支持渠道和关联知识文档。
同一项服务有多个受理渠道或多个套餐，应该写成一行还是多行？
按“一项服务一行”的原则，不同套餐或不同受理渠道另起一行，各自使用独立的服务编号。这样申请入口、处理角色和时限可以分别约定，用户按自己的情况选择对应条目。若强行写在一格内，时限和条件会互相干扰，受理方也难以分流。
响应时限和交付时限的审批等待时间怎么处理？
两个时限必须分别写明起算点和是否包含审批等待。响应时限只约束首次回复，交付时限约束服务结果交付。审批等待是否计入要在条目中明确写出，否则不同填写人和受理人会对同一数值做出不同解释，用户预期也会失控。
目录条目和实际申请记录要不要放在一起管理？
建议分开管理。条目内容走版本与评审，申请处理走工单状态，两者通过服务编号关联。把一次申请的处理结果写回目录条目，会让条目频繁变动、版本失去意义。当条目需要承载申请提交、审批流转和状态跟踪时，可以把每个服务条目对应为工作项类型或申请表单，由服务负责人维护条目内容，申请记录按条目归集。ONES 的文档与工作项管理可用于承载这类条目和申请流转，具体配置按组织现有流程确定。
服务下线后，历史条目要不要删除？
保留条目与编号，把状态改为“已下线”，补充下线日期和替代服务。历史条目不在目录首页展示，但保留在归档视图中，供查询和审计使用。删除条目会让此前的申请记录失去关联对象，也不利于后续追溯服务调整过程。
