服务目录要让人能查、能申请、能判断进度，至少应覆盖五类信息：服务标识（名称、编号、分类）、服务内容（范围、交付物、不包含事项）、服务对象与入口（适用人群、申请入口、自助说明）、服务承诺（受理时间、响应与解决时限、优先级规则）、责任与依赖（服务负责人、支持团队、审批与前置条件）。本文提供可直接复制的空白表格、逐字段填写口径、必填与选填的取舍规则、一条完整示例，以及上线后的维护方法。在服务入口场景中，ONES Desk 可通过统一门户和自定义表单承载目录条目的申请与流转，后文在相应位置说明衔接方式。
要点总览（TL;DR）
- 服务目录至少覆盖五类信息：服务标识、服务内容、服务对象与入口、服务承诺、责任与依赖；维护信息用于长期管理。
- 精简版模板适合目录初建快速铺开，完整版增加交付物、自助说明、审批、前置条件、成本、状态与版本记录。
- 必填字段按“缺了就无法提交、无法受理或无法判断责任人”判断，最小可用目录包含名称、编号、分类、范围、不包含事项、适用对象、申请入口、响应与解决时限、负责人和支持团队。
- 填写时把服务范围与不包含事项成对写，时限写清计时起点与暂停条件，优先级规则给出可判断依据。
- 上线后按新增、下线、合并、承诺调整、负责人变更分别处理字段，并按季度复核完整性、入口可达性与时限匹配度。
可复制的服务目录空白模板
模板按六组字段组织：服务标识、服务内容、服务对象与入口、服务承诺、责任与依赖、维护信息。每行对应一项服务，字段以列呈现，复制到表格工具后即可逐行填写。先给精简版，适合目录初建或服务数量较多时快速铺开；再给完整版，适合服务承诺明确、需要长期维护的团队。
精简版空白表（最小可用）
| 服务名称 | 服务编号 | 服务分类 | 服务范围 | 不包含事项 | 适用对象 | 申请入口 | 响应时限 | 解决时限 | 服务负责人 | 支持团队 |
|---|---|---|---|---|---|---|---|---|---|---|
完整版空白表（含维护字段）
| 分组 | 字段 | 填写内容 |
|---|---|---|
| 服务标识 | 服务名称 | |
| 服务标识 | 服务编号 | |
| 服务标识 | 服务分类 | |
| 服务内容 | 服务范围 | |
| 服务内容 | 交付物 | |
| 服务内容 | 不包含事项 | |
| 服务对象与入口 | 适用对象 | |
| 服务对象与入口 | 申请入口 | |
| 服务对象与入口 | 自助说明 | |
| 服务承诺 | 受理时间 | |
| 服务承诺 | 响应时限 | |
| 服务承诺 | 解决时限 | |
| 服务承诺 | 优先级规则 | |
| 责任与依赖 | 服务负责人 | |
| 责任与依赖 | 支持团队 | |
| 责任与依赖 | 所需审批 | |
| 责任与依赖 | 前置条件 | |
| 维护信息 | 成本口径 | |
| 维护信息 | 服务状态 | |
| 维护信息 | 版本号 | |
| 维护信息 | 变更记录 |
完整版采用“一行一字段”的纵向结构，便于逐项核对；实际录入表格工具时，可将“字段”列转为表头、每项服务占一行。两版字段名称保持一致，精简版是完整版的子集，后续扩充时直接补列即可。
每个字段填什么：字段说明与取值口径
字段说明解决“填什么、怎么填、填到什么程度”的问题。下表按模板顺序给出含义、填写口径与示例取值，示例仅用于说明格式，不代表真实服务。
| 字段 | 含义 | 填写口径 | 示例取值 |
|---|---|---|---|
| 服务名称 | 用户能识别的服务叫法 | 用动作加对象，避免内部缩写；同一分类下名称不重复 | 新员工账号开通 |
| 服务编号 | 目录内唯一标识 | 分类代码加顺序号，编号一经启用不随名称修改而变更 | IT-ACC-001 |
| 服务分类 | 服务所属类别 | 按用户查找习惯划分，层级控制在两级以内 | 账号与权限 / 账号开通 |
| 服务范围 | 这项服务具体做什么 | 写清对象、动作和结果，控制在三句以内 | 为入职员工创建办公账号并完成基础权限配置 |
| 交付物 | 服务完成后用户得到什么 | 写可验证的结果，如账号可用、设备签收 | 可登录的账号及初始密码通知 |
| 不包含事项 | 容易混淆但不在本服务内的事项 | 列出最常被误提的需求，并指向正确服务 | 不含业务系统权限申请，请走“业务系统权限”服务 |
| 适用对象 | 谁可以申请 | 写角色或人群范围，必要时注明地域或部门限制 | 正式入职员工及其直属主管 |
| 申请入口 | 用户从哪里提交 | 写入口名称和位置，入口变更时同步更新 | 服务台门户“账号开通”表单 |
| 自助说明 | 申请前用户可自行完成的操作 | 给出检查步骤或常见问题指引，减少无效提交 | 先确认入职信息已同步，再提交申请 |
| 受理时间 | 服务台接收和处理申请的时间段 | 写工作日与时段，注明节假日安排 | 工作日 9:00–18:00 |
| 响应时限 | 从受理到首次回复的时限 | 按优先级分档，写明计时起点 | 普通 4 工作小时内响应 |
| 解决时限 | 从受理到完成的时限 | 与响应时限分开写，注明暂停计时条件 | 普通 1 个工作日内完成 |
| 优先级规则 | 不同情况的处理顺序 | 给出可判断的定级依据，避免只写高、中、低 | 影响全员办公为高，单人账号问题为普通 |
| 服务负责人 | 对该服务内容和承诺负责的人 | 写到岗位或姓名，避免只写部门 | IT 服务台账号管理岗 |
| 支持团队 | 实际处理或后备支持的团队 | 写团队名称，多个团队时注明分工 | IT 运维组（一线）、信息安全组（权限审核） |
| 所需审批 | 提交后需要谁批准 | 写审批角色和顺序，无审批时明确写“无需审批” | 直属主管审批 |
| 前置条件 | 申请前必须满足的条件 | 写可核验的条件，如已完成入职登记 | 入职信息已在人事系统登记 |
| 成本口径 | 服务是否计费及计费方式 | 内部服务可写“内部结算”或“不计费”，外部服务写计价单位 | 内部结算，按账号数计入部门成本 |
| 服务状态 | 服务当前是否可用 | 用固定取值：在用、试运行、暂停、已下线 | 在用 |
| 版本号 | 条目内容的修订版本 | 每次实质修改递增，格式统一 | v1.2 |
| 变更记录 | 条目修改的时间、内容和修改人 | 一行一次变更，写清改了什么 | 2025-03-10 解决时限由 2 日调整为 1 日，张三 |
命名与编码需要提前约定。服务名称面向用户，用用户熟悉的说法；服务编号面向管理和检索，保持稳定。分类按用户查找路径设计，例如“账号与权限”“设备与终端”“软件与工具”“咨询与支持”，分类调整时同步检查编号前缀是否需要迁移。
服务范围与不包含事项要成对填写。范围写“做什么、做到什么程度”，不包含事项写“最容易被误认为属于本服务的内容”，并给出正确去向。两者合起来构成服务边界，比单独写一段描述更能减少错单。
时限表达要包含计时起点、时间单位和暂停条件。例如“受理后 4 工作小时内首次响应，等待用户补充信息期间暂停计时”。优先级规则给出可判断的依据，让提交人和处理人对定级结果有共同预期。
必填与选填：最小可用目录的字段取舍
必填的判断标准是：缺了这项信息，用户无法提交、服务台无法受理，或无法判断由谁负责。按此标准，最小可用目录需要以下字段。
| 字段 | 建议 | 判断理由 |
|---|---|---|
| 服务名称 | 必填 | 用户检索和识别服务的入口 |
| 服务编号 | 必填 | 唯一标识，支撑检索、统计和变更追踪 |
| 服务分类 | 必填 | 决定用户在目录中的查找路径 |
| 服务范围 | 必填 | 缺失会导致提交内容与处理能力不匹配 |
| 不包含事项 | 必填 | 减少错单，明确相邻服务的分工 |
| 适用对象 | 必填 | 判断申请人是否有资格提交 |
| 申请入口 | 必填 | 没有入口，目录条目无法转化为实际申请 |
| 响应时限 | 必填 | 用户对处理节奏的基本预期 |
| 解决时限 | 必填 | 与响应时限共同构成服务承诺 |
| 服务负责人 | 必填 | 条目内容和承诺的维护责任人 |
| 支持团队 | 必填 | 实际处理归属，缺失会导致分派无依据 |
| 交付物 | 选填 | 结果不易描述时可先省略，后续补充 |
| 自助说明 | 选填 | 有成熟自助路径时填写，效果最明显 |
| 受理时间 | 选填 | 服务台统一公示受理时间时可不在每条重复 |
| 优先级规则 | 选填 | 组织已有统一定级规则时可引用统一规则 |
| 所需审批 | 选填 | 无审批环节的服务可省略，有审批则必填 |
| 前置条件 | 选填 | 存在硬性前置要求时填写 |
| 成本口径 | 选填 | 涉及内部结算或对外计费时填写 |
| 服务状态 | 建议填写 | 目录规模扩大后用于区分在用与下线服务 |
| 版本号、变更记录 | 建议填写 | 多人维护时用于追溯修改 |
不同服务类型的取舍可以差异化处理。账号权限类服务通常审批和前置条件明确，这两项应填；设备类服务涉及交付物和签收，交付物字段应填；软件类服务常需要版本和许可说明，可在自助说明中体现；咨询类服务边界较软，服务范围和不包含事项更要写具体，时限可按响应而非解决承诺。
字段暂时缺失时，不要留空造成歧义。统一使用标注约定：尚未确定写“待定”并注明计划补充时间；不适用写“不适用”；由统一规则覆盖的写“见服务台统一规则”。这样读者能区分“没填”和“确实没有”。
填写示例：一条完整服务条目
以下为演示情景中的一条完整条目，服务对象、时限和审批均为示例设定，用于说明字段如何协同表达。
| 字段 | 填写内容 |
|---|---|
| 服务名称 | 新员工账号开通 |
| 服务编号 | IT-ACC-001 |
| 服务分类 | 账号与权限 / 账号开通 |
| 服务范围 | 为已完成入职登记的新员工创建办公账号，配置基础办公权限，并通知本人首次登录方式 |
| 交付物 | 可正常登录的办公账号及初始密码通知 |
| 不包含事项 | 不含业务系统权限申请、邮箱容量扩容，分别走“业务系统权限”和“邮箱扩容”服务 |
| 适用对象 | 正式入职员工及其直属主管 |
| 申请入口 | 服务台门户“账号开通”表单，可由主管代提 |
| 自助说明 | 提交前确认人事系统入职状态为“已入职”；忘记密码请使用自助重置，不重复提交开通申请 |
| 受理时间 | 工作日 9:00–18:00，法定节假日顺延 |
| 响应时限 | 受理后 4 工作小时内首次响应 |
| 解决时限 | 受理后 1 个工作日内完成；等待补充材料期间暂停计时 |
| 优先级规则 | 影响新员工入职当日办公为高优先级，其余为普通；高优先级 2 工作小时内响应 |
| 服务负责人 | IT 服务台账号管理岗 |
| 支持团队 | IT 运维组（开通执行）、信息安全组（权限审核） |
| 所需审批 | 直属主管审批 |
| 前置条件 | 人事系统已完成入职登记 |
| 成本口径 | 内部结算，按账号数计入部门成本 |
| 服务状态 | 在用 |
| 版本号 | v1.2 |
| 变更记录 | 2025-03-10 解决时限由 2 个工作日调整为 1 个工作日，张三 |
逐项看，服务范围写明了对象（新员工）、动作（创建账号、配置权限）和结果（通知登录方式）；不包含事项把最容易混入的两类需求指向了正确服务，边界因此清晰。时限部分把响应和解决分开，并写明暂停计时条件；优先级规则给出了可判断的依据，而不是只给等级名称。责任字段区分了负责人和支持团队，审批与前置条件各自独立，读者能据此判断提交前要准备什么、提交后由谁处理。
这条示例与 S1 完整版模板的字段一一对应，与 S2 的填写口径一致。实际使用时替换具体内容即可，字段结构不需要改动。
目录上线后的调整与维护方法
服务目录的价值取决于长期准确。服务变化时，条目要跟着变；条目变化时，入口和自助说明要同步。维护工作可以按事件和节奏两类来安排。
| 场景 | 字段处理 | 完成标志 |
|---|---|---|
| 新增服务 | 按完整版模板填写全部必填字段，分配新编号，状态设为试运行或在用 | 用户可从入口检索到并成功提交 |
| 服务下线 | 状态改为已下线，保留条目和变更记录，申请入口指向替代服务 | 旧入口不再接收新申请，替代路径可查 |
| 服务合并 | 保留一个主条目，被合并条目状态改为已下线并在不包含事项中指向主条目 | 用户按原名称检索时能找到合并去向 |
| 承诺调整 | 更新响应或解决时限，递增版本号，记录调整原因 | 条目与对外公示口径一致 |
| 负责人变更 | 更新服务负责人和支持团队，检查审批角色是否随之调整 | 新提交能分派到正确团队 |
版本与变更记录按“实质修改才递增”的节奏维护：名称、范围、时限、负责人、入口发生变化时递增版本并记录；错别字修正可合并记录。变更记录写清时间、改动内容和修改人，便于回溯某次调整的原因。
定期复核建议按季度执行，检查项包括：每条在用服务的必填字段是否完整；响应与解决时限是否仍与实际处理能力匹配；申请入口链接是否可达；自助说明中的步骤是否仍然有效；已下线服务是否还有用户从旧路径提交；负责人和支持团队是否仍在岗。复核结果直接回写到条目，不另建台账。
服务入口与自助说明要随目录同步调整。入口名称、表单位置或可申请人群变化时，在同一次修改中更新申请入口和适用对象；自助说明引用的检查步骤失效时，替换为当前有效步骤。目录条目、入口表单和自助指引三者描述同一项服务，任何一处修改都应检查另外两处是否需要同步。
在服务入口的承载上，ONES Desk 可通过统一门户集中接收工单，并支持自定义工单属性与工单内容，便于把目录中的服务分类、适用对象、优先级等字段映射到提交表单；一键分享填写链接可用于把申请入口分发到不同人群。工单处理过程中可评估和定义优先级，并通过报表汇总处理情况，用于复核响应与解决时限的执行效果。目录条目与工单的字段映射关系、以及服务目录是否以独立对象承载，需结合实际产品配置确认。知识库内容的编写规范与工单流转规则设计属于相邻主题，本文不展开。
常见问题
服务目录刚起步，服务数量不多，应该先用精简版还是完整版模板？
服务数量少、承诺尚未稳定时，可以先用精简版把必填字段填起来，让用户能查到服务、找到入口、提交申请。等某类服务的申请量上升、处理时限需要对外承诺时，再把该条目升级为完整版，补充交付物、自助说明、审批、前置条件、成本与版本记录。两版字段名称保持一致，精简版是完整版的子集，升级时直接补列即可，不需要重建条目。
同一项服务由多个团队共同处理，服务负责人和支持团队怎么填？
服务负责人填对该服务内容和承诺整体负责的岗位，通常是一线服务台的对应岗位；支持团队按分工列出实际处理团队，并注明各自负责的环节，例如“IT 运维组负责开通执行、信息安全组负责权限审核”。这样分派时有明确归属，出现跨团队争议时也有协调主体。若服务负责人发生岗位调整，应同步检查审批角色和支持团队是否需要一起更新。
服务承诺中的响应时限和解决时限，遇到用户迟迟不补充材料怎么计算？
在解决时限字段中写明暂停计时条件，例如“等待用户补充材料期间暂停计时”，并约定恢复计时的触发点，如用户提交补充信息后继续计算。响应时限通常只覆盖首次回复，不因等待材料而顺延。把暂停与恢复规则写在条目里，提交人和处理人对时限结果有共同预期，也便于后续复核时判断超时原因。
服务下线或合并后，旧条目直接删除可以吗？
建议保留旧条目并把服务状态改为已下线，同时在变更记录中写明下线时间和替代服务。用户按原名称检索时仍能找到条目，并从申请入口或不包含事项中看到新的去向，避免从旧链接提交后无人受理。服务合并时保留一个主条目，被合并条目在下线说明中指向主条目，主条目的服务范围需要覆盖原两项服务的内容。
目录条目和门户里的申请表单是两套内容，如何避免长期不一致？
把目录条目作为字段口径的来源，表单字段从条目字段映射而来：服务分类、适用对象、优先级等字段在两边使用同一套取值。入口名称、表单位置或可申请人群变化时，在同一次修改中更新申请入口和适用对象，并检查自助说明中的步骤是否仍然有效。复核时把“入口链接是否可达、表单字段与条目是否一致”列为固定检查项，发现问题直接回写到条目。
