内部服务目录模板是一张逐项登记服务的空白表，用来把分散在各团队的IT与职能服务整理成可查询、可申请、可追责的清单。核心字段包括服务编号、服务名称、服务说明、服务对象、申请入口、责任团队、服务时段、响应与交付时限、所需审批、依赖系统、成本归属和状态。使用顺序是：先复制空白表，再按字段说明逐列填写，然后用一条完整示例校准口径，最后约定评审与更新节奏。
要点总览（TL;DR）
- 内部服务目录模板是一张逐行登记服务的空白表，核心字段包括服务编号、名称、说明、服务对象、申请入口、责任团队、服务时段、响应与交付时限、所需审批、依赖系统、成本归属和状态。
- 最小可用目录的必填字段是服务编号、名称、说明、服务对象、申请入口、责任团队和状态；服务时段、时限、审批、依赖系统和成本归属可按服务成熟度逐步补齐。
- 填写顺序建议先复制空白表，再按字段说明逐列填写，然后用一条完整条目校准口径，最后约定评审与更新节奏。
- 目录上线后需要指定条目责任人和目录维护人，按季度全量评审，并在申请入口、责任团队或时限变化后及时更新。
- 当申请需要跨团队流转时，可把目录中的责任团队和时限对应到可跟踪的工单上，目录本身仍按模板维护。
可复制的内部服务目录空白模板
下表可直接复制到文档或表格工具中使用。每一行登记一项服务，表头保持不变，行数按实际服务数量增减。建议在表格工具中冻结首行，并为“服务编号”列设置唯一性校验，避免重复登记。
| 服务编号 | 服务名称 | 服务说明 | 服务对象 | 申请入口 | 责任团队 | 服务时段 | 响应时限 | 交付时限 | 所需审批 | 依赖系统 | 成本归属 | 状态 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
如果目录规模较小，可以先用精简版：保留服务编号、服务名称、服务说明、服务对象、申请入口、责任团队、状态七列，其余字段在服务上线后补齐。精简版适合首次建目录时快速成型，完整版适合服务数量多、跨团队协作频繁的组织。
每个字段登记什么：目录字段说明
字段说明的作用是让不同团队按同一口径填写，避免同一含义出现多种写法。下表逐字段给出含义与填写口径，填写时以“填写口径”列为准。
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 服务编号 | 目录内唯一标识 | 采用“团队缩写-三位序号”格式，如IT-001；一经分配不再复用，服务下线后编号保留 |
| 服务名称 | 服务的对外称呼 | 用用户能听懂的名词短语，如“办公电脑申领”，避免内部代号和缩写 |
| 服务说明 | 服务包含什么、不包含什么 | 一到三句话写清交付物和边界，例如“提供标准配置笔记本，不含专业设计软件授权” |
| 服务对象 | 谁可以申请 | 写具体范围，如“全体正式员工”“研发中心”“华东区销售”，避免只写“所有人” |
| 申请入口 | 用户提交申请的渠道 | 写可点击或可搜索的入口名称与位置，如“IT服务台-硬件申请表单”；入口变更时同步更新 |
| 责任团队 | 负责受理和交付的团队 | 写到具体团队而非个人，如“IT运维组”；同时可备注一名接口人 |
| 服务时段 | 服务可受理的时间 | 写工作日与时段，如“工作日9:00-18:00”；7×24服务需单独注明 |
| 响应时限 | 从受理到首次回复的时间 | 写明确时长，如“4个工作小时内响应”；与交付时限分开填写 |
| 交付时限 | 从受理到完成交付的时间 | 写标准时长或区间，如“3个工作日内完成”；受外部依赖影响的可注明条件 |
| 所需审批 | 申请前需要的审批环节 | 写审批角色与顺序，如“直属主管审批”；无需审批填“无” |
| 依赖系统 | 交付所依赖的系统或资源 | 列出关键系统名称，如“账号中心、资产管理系统”；用于评估变更影响 |
| 成本归属 | 费用由谁承担 | 写成本中心或部门，如“计入申请方部门IT费用”；免费服务填“无内部结算” |
| 状态 | 服务当前是否可用 | 从“在用、试运行、暂停、已下线”中选一，暂停和下线需注明原因与时间 |
填写时有两个常见口径问题需要提前统一。一是时限的计时起点，建议统一为“申请提交成功”而非“审批通过”，并在目录说明中写明。二是服务对象的颗粒度，同一服务面向多个群体时，可拆成多行登记，也可在单元格内用分号分隔，但全目录应保持同一种做法。
必填与选填：哪些字段不能空
最小可用目录的底线是：用户能查到服务、知道找谁、知道从哪里申请。据此划分必填与选填字段，可以在建目录初期快速成型，再逐步补齐。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 服务编号 | 必填 | 唯一标识，用于引用、变更记录和跨表关联 |
| 服务名称 | 必填 | 用户检索的第一入口 |
| 服务说明 | 必填 | 决定用户是否找对服务，减少误申请 |
| 服务对象 | 必填 | 明确适用范围，避免越权申请 |
| 申请入口 | 必填 | 没有入口的目录条目无法转化为实际申请 |
| 责任团队 | 必填 | 明确受理方，便于转派和追责 |
| 状态 | 必填 | 防止用户申请已下线服务 |
| 服务时段 | 选填 | 标准工时服务可默认按组织作息，非标准时段服务必须填写 |
| 响应时限 | 选填 | 有服务级别约定的服务应填写；内部互助类服务可暂缺 |
| 交付时限 | 选填 | 同上，与响应时限配套填写更有意义 |
| 所需审批 | 选填 | 无审批环节时填“无”，比留空更清晰 |
| 依赖系统 | 选填 | 涉及系统变更或故障排查时价值高，简单服务可暂缺 |
| 成本归属 | 选填 | 涉及内部结算或预算分摊的服务必须填写 |
字段留空需要约定处理方式，否则空值会被误读。建议约定三条：必填字段留空的条目不得发布，只能停留在草稿状态；选填字段留空统一填“待补充”，并记录补充责任人；任何字段留空超过一个评审周期，由目录维护人在评审会上提出并决定补齐或删除该字段。这样空值有明确含义，不会与“不适用”混淆。
填写示例：一条完整的服务条目
下面用“办公电脑申领”示范一条完整条目，字段顺序与空白模板一致。示例为演示情景，取值仅用于说明填写口径。
| 字段 | 示例取值 |
|---|---|
| 服务编号 | IT-003 |
| 服务名称 | 办公电脑申领 |
| 服务说明 | 为新入职及设备到期的员工提供标准配置笔记本电脑，含操作系统与办公软件预装；不含专业设计软件授权和外部设备 |
| 服务对象 | 全体正式员工及实习期超过三个月的实习生 |
| 申请入口 | IT服务台-硬件申请表单 |
| 责任团队 | IT运维组（接口人：终端支持岗） |
| 服务时段 | 工作日9:00-18:00 |
| 响应时限 | 4个工作小时内响应 |
| 交付时限 | 库存有货时3个工作日内交付；需采购时10个工作日内交付 |
| 所需审批 | 直属主管审批 |
| 依赖系统 | 账号中心、资产管理系统 |
| 成本归属 | 计入申请方部门IT费用 |
| 状态 | 在用 |
几个关键字段的填写理由值得说明。服务说明写明了“不含”的部分，是因为设计软件授权由另一项服务承接，写清边界能减少转派。交付时限拆成库存与采购两种情形，是因为两者差异明显，合并写成一个数字会误导申请人。依赖系统列出账号中心和资产管理系统，是为了在系统变更时能快速定位受影响的目录条目。成本归属写到“申请方部门”，明确了内部结算方向，避免费用争议。
从空白表到成稿的对照方法是：先在空白表第一行逐列填入上述取值，检查每个必填字段非空、选填字段无歧义，再对照字段说明表核对格式是否符合口径，例如编号格式、时限单位、状态取值。确认无误后，这一行即可作为其他条目的填写参照。
目录的调整与维护方法
目录建好后如果缺少维护规则，会逐渐出现入口失效、责任团队变更未更新、已下线服务仍可申请等问题。建议把维护拆成变更流程和定期检查两部分。
新增与下线服务的处理流程：
- 提出方按空白模板填写完整条目，必填字段齐全后提交目录维护人。
- 维护人核对编号唯一性、申请入口可访问、责任团队确认受理，三项通过后发布。
- 服务下线时，先将状态改为“已下线”并注明下线日期和替代服务，保留条目至少一个评审周期后再移出正式目录。
- 下线服务的申请入口同步关闭或跳转到替代服务，避免用户提交到无人受理的渠道。
字段增删的评审方式：字段调整影响所有条目的填写口径，不宜由单个团队自行修改。建议在评审会上按“新增字段是否所有服务都适用、是否已有字段可替代、历史条目如何补齐”三个问题讨论，通过后更新字段说明表，并给出现有目录的补齐期限。
更新频率与责任人约定：每项服务指定一名条目责任人，负责本条目内容的准确性；目录维护人负责整体格式与发布。建议每季度做一次全量评审，服务时段、时限、责任团队发生变化的条目在变更后五个工作日内更新。评审记录保留变更内容和决定人，便于追溯。
目录与申请入口的一致性检查：每次评审时抽查申请入口是否可访问、表单字段是否与目录描述一致、审批环节是否仍按目录执行。发现不一致时，以实际受理流程为准修正目录，或调整流程使其与目录一致，两者选其一并记录原因。
当目录条目增多、申请需要跨团队流转时，可以把目录中的责任团队、响应与交付时限对应到实际的工作项上：用户从申请入口提交后生成可跟踪的工单，按责任团队分派，处理状态和时限在工单上可见，评审时直接查看工单记录核对目录口径。ONES 的工作项与流程配置可以承载这类申请流转和状态跟踪，目录本身仍以本文模板为准维护。
常见问题
内部服务目录和IT服务台是什么关系？
目录回答“有哪些服务、找谁申请、什么时候能办好”，服务台承接“提交之后怎么处理”。两者可以分开建设：先用本文模板把服务条目登记清楚，再把申请入口指向服务台的申请表单。目录中的责任团队、响应时限和交付时限，可以直接作为服务台分派和计时口径的参照。若目录条目较多、申请需要跨团队流转，建议在目录评审时同步检查服务台表单字段与目录描述是否一致。
服务对象写“全体员工”可以吗？
可以，但需要确认这项服务确实面向所有员工，且没有隐藏的资格条件。如果服务只对正式员工开放、实习生需要额外审批，或者某些区域暂未覆盖，就应写清具体范围。同一服务面向多个群体且待遇不同时，建议拆成多行登记，每行对应一个服务对象和一套时限、审批口径，避免申请人按“全体员工”理解后产生预期偏差。
响应时限和交付时限必须同时填写吗？
不强制同时填写，但两者配套填写更有意义。响应时限约束的是首次回复，交付时限约束的是完成交付，只写其中一个会让申请人无法判断整体等待时间。对于有服务级别约定的服务，建议两项都填；内部互助类服务可先填响应时限，交付时限写“视具体情况”并注明由责任团队在受理时告知。无论哪种做法，计时起点应在目录说明中统一写明。
目录里的申请入口失效了怎么办？
申请入口失效会直接阻断服务申请，应优先处理。建议在每次评审时抽查入口可访问性，日常由条目责任人发现变更后五个工作日内更新。入口暂时无法恢复时，可先将状态改为“暂停”并注明临时申请方式，恢复后再改回“在用”。如果入口已永久迁移，应同步更新目录和旧入口的跳转，避免用户从旧链接提交到无人受理的渠道。
服务下线后条目要立即删除吗？
不建议立即删除。先把状态改为“已下线”，注明下线日期和替代服务，保留条目至少一个评审周期，便于用户和历史申请记录对照。保留期内同步关闭或跳转原申请入口。一个评审周期后，若确认无引用需求，再从正式目录移出；服务编号保留不复用，避免与历史记录冲突。
