服务目录清单以“一项服务一行”为基本结构，至少记录服务名称、服务说明、服务分类、服务对象、服务负责人、服务时段、申请入口、交付时限、依赖与前置条件、费用与计费方式、服务级别、状态与版本、关联知识入口等信息。字段可以按团队规模裁剪，其中服务名称、服务说明、服务对象、服务负责人、申请入口、交付时限六项建议设为必填，其余按需选填。下面给出一份可直接复制的空白表格，并逐项说明填写口径、必填分级、完整示例与后续维护方法。
要点总览（TL;DR）
- 服务目录清单按“一项服务一行”组织，核心字段包括服务名称、服务说明、服务分类、服务对象、服务负责人、服务时段、申请入口、交付时限、依赖与前置条件、费用与计费方式、服务级别、状态与版本、关联知识入口。
- 服务名称、服务说明、服务对象、服务负责人、申请入口、交付时限六项建议设为必填，其余字段按组织成熟度和服务数量逐步补齐。
- 空白模板、字段说明与填写示例使用同一套字段名称和顺序，复制后可直接填写，示例为演示情景，数值可按实际替换。
- 清单上线后按季度核对入口可达性与时限准确性，服务项下线保留记录一个周期，字段增删同步更新版本号。
- 清单需要承载实际受理时，可将服务对象、前置条件、交付时限等字段对应配置到服务入口表单，使目录信息与受理入口保持一致。
可复制的服务目录清单空白模板
把下表复制到文档或表格工具中，保留表头，每新增一项服务就增加一行。字段顺序在模板、说明和示例中保持一致，复制后不需要再调整列名。表格中的“填写提示”行仅用于说明，正式使用时删除该行。
| 序号 | 服务名称 | 服务说明 | 服务分类 | 服务对象 | 服务负责人 | 服务时段 | 申请入口 | 交付时限 | 依赖与前置条件 | 费用与计费方式 | 服务级别 | 状态与版本 | 关联知识入口 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 填写提示 | 简短、可识别的服务名 | 一句话说明解决什么问题 | 按组织分类口径填写 | 写明人群或部门范围 | 岗位或姓名加备份人 | 受理时间与例外 | 表单、邮箱或门户位置 | 从受理到交付的时长 | 申请方需先完成的事项 | 免费或计费规则 | 响应与解决标准 | 在用、试运行、下线及版本号 | 操作指南或常见问题位置 |
表格之外建议保留三项附属信息：清单版本号、最后更新日期、维护责任人。它们不占服务行，放在表格上方或文档属性中即可，用于判断当前看到的是否为最新版本。
每个字段记录什么：字段说明与填写口径
字段说明的作用是让不同填写人产出一致的结果。以下逐项给出含义、取值口径和常见写法，填写时以“申请者能否据此判断这项服务是否适合自己、该怎么发起”为检验标准。
| 字段 | 记录内容 | 填写口径与常见写法 |
|---|---|---|
| 服务名称 | 服务的正式名称 | 使用申请者熟悉的叫法，避免内部代号。例如“办公电脑故障报修”“新员工账号开通”。同名服务需加范围限定，如“华东区会议室预订”。 |
| 服务说明 | 这项服务解决什么问题、包含什么 | 一到两句话，写清服务内容和边界。例如“处理办公电脑软硬件故障，含系统重装与配件更换，不含设备采购”。 |
| 服务分类 | 服务所属类别 | 沿用组织已有的分类口径，如 IT 支持、人事服务、行政服务、财务服务。分类层级不宜过深，一级或两级便于筛选即可。 |
| 服务对象 | 谁可以申请 | 写人群或部门范围，如“全体正式员工”“研发中心”“外部客户”。范围有条件的，把条件写在同一格，如“入职满一个月且已领取设备”。 |
| 服务负责人 | 对该服务质量和更新负责的人 | 写岗位加姓名，并附一名备份人。负责人承担清单更新、入口维护和问题升级，不一定是每单的执行人。 |
| 服务时段 | 受理和处理的时间范围 | 写工作日与具体时段，如“工作日 9:00–18:00”。有例外时同格注明，如“节假日仅处理紧急故障”。 |
| 申请入口 | 申请者发起请求的位置 | 写具体位置而非笼统说法，如“服务台门户—IT 支持—电脑报修表单”“发送邮件至 it-support@ 邮箱”。入口应唯一，避免同一服务多个入口导致漏单。 |
| 交付时限 | 从受理到交付的预期时长 | 写明确时长并注明起算点，如“受理后 4 个工作小时内”“审批通过后 2 个工作日”。不同优先级时限不同的，在服务级别字段中补充。 |
| 依赖与前置条件 | 申请前需具备或完成的事项 | 写申请方需自行完成的部分，如“已完成入职登记”“提供设备编号”“上级审批通过”。没有前置条件的填“无”，避免留空被误读为未填写。 |
| 费用与计费方式 | 是否收费及如何计费 | 内部免费服务填“免费（内部结算）”；收费服务写计价单位和结算方式，如“按次计费，每台 50 元，月度结算”。价格易变，可写“以当期价目表为准”并附位置。 |
| 服务级别 | 响应与解决的标准 | 写响应时间和解决时间两段，如“紧急 30 分钟响应、4 小时解决；一般 1 个工作日响应、3 个工作日解决”。级别定义应与组织实际执行口径一致。 |
| 状态与版本 | 服务当前是否可用 | 状态取“在用、试运行、暂停、已下线”等固定值；版本号在服务内容或时限调整时递增，便于追溯变更。 |
| 关联知识入口 | 申请者可自行查阅的资料位置 | 写操作指南、常见问题或自助说明的存放位置。资料尚未建立的可填“待补充”，并在维护计划中安排补齐。 |
服务名称与说明要区分开：名称用于识别和检索，说明用于判断适用性。服务对象与负责人要区分开：前者回答“谁能用”，后者回答“谁对这项服务负责”。入口、时限、服务级别三者构成申请者的预期管理，入口写位置、时限写时长、级别写标准，三者口径应能互相对照。
必填与选填：哪些字段不能空
必填字段的判断依据是：缺少它，申请者无法发起请求，或服务台无法把请求分派给正确的人。按此标准，六项字段建议设为必填，其余字段按管理成熟度逐步补齐。
| 分级 | 字段 | 设为必填的理由 |
|---|---|---|
| 必填 | 服务名称 | 清单的检索和引用都依赖名称，缺失则整行无法使用。 |
| 必填 | 服务说明 | 申请者据此判断服务是否覆盖自己的需求，减少误提和反复沟通。 |
| 必填 | 服务对象 | 明确适用范围，避免无关人员提交后被退回。 |
| 必填 | 服务负责人 | 没有责任人的服务项容易长期失修，也无法确定升级对象。 |
| 必填 | 申请入口 | 入口是服务从清单走向实际受理的关键，缺失则清单只是说明文档。 |
| 必填 | 交付时限 | 申请者需要知道等待多久，服务台也需要据此安排排期。 |
| 选填 | 服务分类 | 服务项较少时可按名称检索；数量增多后建议补齐，便于分组展示。 |
| 选填 | 服务时段 | 全员同一作息的组织可统一说明；存在跨时区或轮班时建议填写。 |
| 选填 | 依赖与前置条件 | 流程简单的服务可省略；涉及审批或材料提交的服务应填写。 |
| 选填 | 费用与计费方式 | 全部免费的组织可统一注明；存在内部结算或对外收费时必须填写。 |
| 选填 | 服务级别 | 初期可只保留交付时限；服务量增大、需要分级响应时再补充。 |
| 选填 | 状态与版本 | 服务项稳定时可暂不记录；进入频繁调整期后应启用。 |
| 选填 | 关联知识入口 | 自助资料尚未建立时可先留待补充，随知识沉淀逐步填写。 |
裁剪时遵循三条原则。第一，先保证六项必填齐全，再考虑增加字段，字段越多填写成本越高，空值也越多。第二，选填字段按“是否有申请者会因此改变行为”来判断，例如前置条件会改变申请顺序，就值得填写；仅用于内部统计的字段可以放到后台系统，不必进入面向申请者的清单。第三，同一组织内保持字段集合一致，不要一部分服务填费用、另一部分不填，否则清单无法横向比较。
填写示例：一条完整服务记录
以下用一条已填写的记录示范各字段如何配合。示例为演示情景，组织名称和具体数值可按实际情况替换。
| 字段 | 填写内容 |
|---|---|
| 服务名称 | 办公电脑故障报修 |
| 服务说明 | 处理办公电脑软硬件故障，含系统重装、外设调试与配件更换，不含整机采购与个人设备维修。 |
| 服务分类 | IT 支持 |
| 服务对象 | 全体正式员工及实习期员工 |
| 服务负责人 | IT 支持组 张明（备份：李华） |
| 服务时段 | 工作日 9:00–18:00，节假日仅处理影响全员办公的紧急故障 |
| 申请入口 | 服务台门户—IT 支持—电脑报修表单 |
| 交付时限 | 受理后 4 个工作小时内完成远程处理；需现场更换配件的 2 个工作日内完成 |
| 依赖与前置条件 | 提供设备编号；系统重装前自行备份本地文件；涉及配件更换需直属上级确认 |
| 费用与计费方式 | 免费（内部结算），超出保修期的配件按当期价目表计费 |
| 服务级别 | 紧急：30 分钟响应、4 小时解决；一般：1 个工作日响应、3 个工作日解决 |
| 状态与版本 | 在用，v1.2（2025 年 3 月调整交付时限） |
| 关联知识入口 | 知识库—IT 支持—电脑常见故障自助排查 |
逐字段对照可以看出配合关系：服务说明中的“不含整机采购”划定了边界，与前置条件中的“配件更换需上级确认”共同减少不符合范围的申请；交付时限给出常规时长，服务级别再按紧急程度细分，两者不冲突；申请入口指向唯一表单，关联知识入口提供先自助后报修的路径；状态与版本记录了时限调整，便于申请者判断信息新旧。复制空白模板后，按此示例的颗粒度填写即可。
模板的调整与维护方法
清单建好后需要持续维护，否则会出现入口失效、负责人离岗、服务已下线但仍可申请等情况。维护工作可以按以下规则执行。
- 字段增删的判断依据：当同一类信息在多个服务中被反复追问，考虑新增字段；当某字段连续一个维护周期内多数为空，或已由后台系统自动采集，考虑删除或移出面向申请者的清单。每次调整字段都更新清单版本号，并在变更说明中记录原因。
- 服务项新增流程：由服务负责人提交新增申请，写明名称、说明、对象、入口和时限，经清单维护人核对字段完整性后上线。新增服务应同时配置申请入口，避免清单先行、入口缺失。
- 服务项下线流程：先确认无在途请求，再将状态改为“已下线”并保留记录一个周期，随后从面向申请者的视图中移除。直接删除会导致历史请求无法追溯。
- 版本与责任人维护：每项服务明确一名负责人和一名备份人，人员变动时同步更新。清单整体保留版本号和最后更新日期，建议按季度做一次全量核对，重点检查入口是否可达、时限是否仍准确。
- 与自助入口的同步：清单中的申请入口和关联知识入口应指向实际可用的位置。入口调整时，清单、门户表单和知识页面三处同步修改，并在版本记录中注明同步日期。
当清单需要承载实际受理时，可以把字段落到服务入口的表单中。ONES Desk 提供统一门户集中接收工单，支持自定义工单属性与工单内容以适配不同收集场景，并可一键分享填写链接，让申请者在门户提交后实时掌握处理进度；工单还可关联到 ONES Wiki 页面，用于记录问题并沉淀服务经验。清单中的服务对象、前置条件、交付时限等字段，可以对应配置为表单中的必填项与说明文字，使目录信息与受理入口保持一致。具体字段配置范围和表单限制以实际产品版本为准。
常见问题
服务目录清单的字段越多越好吗？
字段数量需要与填写成本平衡。字段越多，维护工作量越大，空值也越容易出现。建议先保证六项必填字段齐全，再根据“申请者是否会因为这个字段改变行为”来决定是否增加。例如前置条件会改变申请顺序，值得填写；仅用于内部统计的信息可以放到后台系统，不必进入面向申请者的清单。
同一项服务存在多个申请入口时怎么处理？
建议在清单中只保留一个主入口，其他入口作为过渡期说明或直接关闭。多入口并行容易出现漏单和重复受理，也会让申请者难以判断进度查询位置。如果确实需要保留多个渠道，应在清单中写明各渠道的适用条件和统一归口位置，并在维护时同步检查各入口是否可达。
服务目录清单和服务台门户是什么关系？
清单是服务信息的结构化记录，门户是申请者发起请求的入口。清单中的服务对象、前置条件、交付时限等字段，可以对应配置为门户表单中的必填项和说明文字，使目录信息与受理入口保持一致。ONES Desk 提供统一门户集中接收工单，支持自定义工单属性与工单内容以适配不同收集场景，并可一键分享填写链接，让申请者在门户提交后实时掌握处理进度。具体字段配置范围和表单限制以实际产品版本为准。
服务下线后清单记录要保留多久？
建议先将状态改为“已下线”并保留记录一个维护周期，确认无在途请求后再从面向申请者的视图中移除。保留期间历史请求仍可追溯，也便于回答“这项服务为什么没有了”之类的询问。直接删除记录会导致历史工单失去对应说明，增加后续核查难度。
清单中的关联知识入口指向哪里比较合适？
指向申请者可以自行查阅的操作指南、常见问题或自助排查说明。资料尚未建立时填“待补充”，并在维护计划中安排补齐，避免留空被误读为未填写。入口位置调整时，清单、门户表单和知识页面三处同步修改，并在版本记录中注明同步日期。ONES Desk 可将工单一键关联到 ONES Wiki 页面，用于记录并分析问题、沉淀服务经验，需同时使用 ONES Wiki。
