这些年和不少团队的运维负责人聊下来，十有八九都跟我抱怨过同一件事：每天上班就是在救火，变更、故障、紧急需求排着队来，服务目录？我们有张Excel表，基本没人敢信，也没人照着用。说实话，这几乎是我见过的所有ITIL4服务目录管理落地失败的共同起点——不是工具不行，也不是流程不够细，而是团队从一开始就把服务目录理解成了“给服务起个名字、登记一下那种文档”。
ITIL4把服务目录管理放进了“服务设计”这个价值链活动中，它真正要回答的问题不是“我们有什么服务”，而是：每一项服务到底对应什么业务成果、什么成本、什么可用性、谁对质量负责，以及用户怎么申请、故障怎么响应。这些问题想不清楚，你配再好的CMDB、再豪华的工具，目录照样是死的。想清楚了，一张表格也能把团队从“救火队”慢慢变成“服务专家”。这篇就结合我自己的落地经验，把ITIL4服务目录管理的设计思路、搭建步骤、工具选型和避坑要点一次讲透，适合正在做运维转型、准备上ITSM平台的团队参考。
1. 先弄清楚：ITIL4为什么把服务目录当成转型抓手
1.1 服务目录不是一张清单，而是“服务方-消费方”的能力契约
很多团队把服务目录等同于固定资产登记表，列上“OA系统、ERP系统、网络、服务器”就算完事。这是最大的误解。ITIL4对服务的定义是“通过促进期望结果实现而为客户创造价值的方式，无需管理特定成本和风险”，翻译成大白话就是：服务不是“你有个系统”，而是“你能通过这个系统给业务交付什么结果”。
服务目录管理的核心对象其实是这个“结果”。比如“邮件系统”不是服务，“提供安全可靠的企业邮件收发能力，确保员工日常沟通不中断”才是服务；“备份系统”也不是服务，“在发生数据丢失时按约定时限完成数据恢复”才是服务。当你把描述方式从资产视角切换成能力视角，目录的性质就变了——它不再是IT部门自嗨的台账，而是IT对业务的一份能力契约。
这份契约要写清楚四个问题：
- 业务能获得什么结果（服务描述与业务价值）；
- 质量是什么水平（服务级别指标，如可用性、响应时长）；
- 申请和交付要走什么流程（服务请求目录与审批链）；
- 出了事找谁、多久能恢复（事件响应机制与服务Owner）。
这四个问题，正是ITIL4服务价值链中“设计服务与服务绩效”环节要落地的内容。所以服务目录管理从来不是一个孤立流程，它上接服务战略，下接事件、问题、变更、请求等运营流程，中间还要支撑服务财务管理和持续改进。没有目录，这些流程都缺乏一个“统一的锚点”。
1.2 从四维模型看服务目录的定位
ITIL4提出了四维模型：价值流与流程、组织与人员、信息与技术、供应商与合作伙伴。很多团队做服务目录时只盯着“信息与技术”这一维——建个数据库、配个页面，然后就不管了。但真正让目录发挥作用的，是其他三个维度。
组织与人员这一维，要求你明确服务Owner、服务交付经理、支持团队角色，否则目录上挂着一堆服务，出了问题没人拍板。供应商与合作伙伴这一维，要求你把外部供应商提供的服务也纳入目录管理，SLA要延伸到供应商合同里，否则目录承诺得很漂亮，外包团队根本不认账。价值流与流程这一维，要求你把目录和请求履行、事件管理、变更评估串起来，用户从目录里点一个服务，背后就该有对应的工单流程自动启动。
我见过最典型的失败案例：目录做得漂漂亮亮，服务名称、描述、SLA全齐，但事件工单、变更评估、采购申请完全不参考这份目录。结果就是目录是“面上的”，流程还是“地下跑”的。所以如果你准备搭建服务目录，请一开始就用四维模型的眼光审视：每个目录项是否已经映射到了流程、角色和供应商？缺哪块补哪块，否则上线三个月就会变废纸。
1.3 服务目录成熟度：你们团队目前在第几层
做改革前，建议先给现状打个分。我按照实操经验，把服务目录的成熟度分成五个层级：
- L0 无目录：服务靠口头传递，新员工入职靠问，领导要数据靠临时统计；
- L1 文档化目录：有一份共享文档或表格，列了服务和负责人，但没人维护、没人强制使用；
- L2 流程化目录：目录与事件、请求工单打通，用户能按目录提单，SLA开始生效；
- L3 业务化目录：目录能映射业务服务和底层技术组件，成本、容量、风险等级清晰，能支撑变更影响分析和服务改进；
- L4 产品化目录：服务像产品一样运营，有生命周期管理、定价与计费、用户满意度闭环，IT部门对外体现清晰的业务价值。
大部分团队在L0到L1之间，老板喊“数字化转型”后想直接跳到L3、L4。我的建议是别急，先老老实实做到L2，让团队体会到“目录能帮我少救火”的甜头，再往上走阻力会小很多。目录建设不是一次性工程，是一次持续演进的能力建设。
2. 起步前必须想明白：三层目录、属性模型和范围边界
2.1 业务服务目录、技术服务目录和请求目录，别混在一起
ITIL4服务目录管理有个关键设计：目录要分层，但很多团队一上来就摊大饼。标准做法是至少分成两层——业务服务目录和技术服务目录，有条件再拆出第三层请求目录。
业务服务目录面对业务部门，用业务听得懂的语言描述，比如“新员工入职IT服务”“在线交易保障服务”“远程接入服务”。技术服务目录面对IT团队内部，描述支撑这些业务服务的技术组件和运维活动，比如“数据库高可用保障”“核心路由器监控”“身份认证系统运维”。这两层要有映射关系：业务目录上的每个服务，都要能链接到技术目录中的若干条目，这样出故障时才能做影响分析。
请求目录则更像“菜单”，是用户实际下单买东西的地方。比如“申请新笔记本电脑”是一个请求项，“申请ERP账号权限”是一个请求项，“申请网络专线扩容”是另一个请求项。请求目录可以挂在业务服务下面，也可以独立展示，重点是每一项都要有明确的履行流程、审批路径和时限承诺。
把这三层混在一个目录里是新手最容易犯的错。业务部门看到满屏的“WAF策略调整”“存储扩容流程”完全懵掉，IT团队又在业务描述里找不到技术抓手。我一向坚持的建模原则是：对外一页纸说清业务服务，对内一张表说清技术支撑，中间用映射关系串联。
2.2 服务目录的核心属性怎么设计（附参数示例）
服务目录的字段不能凭空拍脑袋，每个字段都应该对应一个管理目的。基于ITIL4实践“ITIL的服务目录”中的建议，结合我自己的落地模板，一套可用的核心属性至少包括六类：
| 属性类别 | 建议字段 | 用途说明 | 示例 |
|---|---|---|---|
| 基础信息 | 服务编号、名称、描述、分类 | 唯一标识与检索 | SVC-001、邮件服务、提供企业邮箱收发与归档能力 |
| 服务级别 | 可用性目标、响应时限、解决时限、恢复目标 | 定义SLA，支撑考核 | 99.9%可用性，4小时响应，24小时解决 |
| 组织职责 | 服务Owner、服务交付经理、支持团队、审批人 | 明确责任，避免踢皮球 | IT运维部系统组负责日常监控 |
| 价值与成本 | 业务重要性、成本中心、计费信息 | 支撑投入产出分析和收费 | 影响范围：全体员工；年度成本15万 |
| 依赖关系 | 关联技术组件、依赖业务服务、关联供应商 | 支撑影响分析和变更评估 | 依赖AD域控、Exchange集群、防火墙策略 |
| 运营信息 | 请求目录链接、事件模板、变更模板、发布节奏 | 联动运维流程 | 用户入口：服务台；事件优先级P1 |
字段不是越多越好。做目录时有个“三个月原则”：凡是一个字段上线后三个月内没有任何流程真正引用它，就删掉。目录需要维护成本，字段越杂，维护意愿越低，最后必然腐烂。
2.3 哪些服务该进目录：三类“必选”和两类“暂不进”
很多团队纠结“什么算服务，要不要把磁盘扩容也算进去”。我的建议很直接：目录不是资产清单，你只需要收录真正有用户、有SLA、有运维投入的服务。
三类必须收录：
- 面向业务部门的核心服务：直接影响业务运作或收入的，比如订单处理、客户门户、核心数据库服务；
- 高频请求支撑服务：员工天天要用的，比如账号权限、邮箱开通、设备申请，这些要进请求目录，否则服务台天天做二传手；
- 有合规或安全要求的服务：等保相关、审计相关、数据备份恢复类服务，必须有明确的责任人和SLA记录。
两类暂不进：
- 一次性项目或临时任务：比如某个专项迁移、一次性数据清洗，这种属于项目不是在运营的服务，进目录会污染SLA统计；
- 内部未定义清楚所有权的服务：连Owner都没有，进了目录只会让目录变成“死名单”。
目录范围不是越大越好，而是越可控越好。我建议第一批进目录的服务控制在10到15个，先把核心业务服务打透，验证建模逻辑和运营流程后再滚动扩容。
3. 实操：六步搭建一套能落地的服务目录
3.1 第一步：服务盘点与业务优先级排序
搭建目录的第一步不是画字段，而是把现有的“服务”从各个团队脑子里挖出来。我会组织一轮盘点工作坊，参加的人包括运维负责人、核心系统管理员、服务台主管，最好拉上一两位业务部门代表。
盘点时按“业务线”走，不要按“系统”走。比如业务线“销售”下面，涉及CRM、电子合同、客户主数据、报表平台等；业务线“财务”下面涉及总账系统、费控系统、电子发票接口等。让与会者逐个业务线回答三个问题：
- 这个业务线当前依赖哪些IT系统？
- 如果某一个系统中断，业务损失有多大？
- 过去三个月，这个业务线的故障、变更、请求主要集中在哪些系统？
用“中断影响度”和“工单频度”两个维度画一个二维矩阵，把业务线下的系统分为高/中/低优先级。这个矩阵直接决定目录收录顺序和SLA等级。在实际场景中，高影响+高频次的一定是第一梯队，高影响但低频次的往往是被忽视的“隐性炸弹”，比如灾备切换服务，平时没人提，出事就翻天，这种也必须纳入第一批。
3.2 第二步：定义服务负责人与履行团队（RACI矩阵）
服务没有Owner，目录就是一张“无主之花”。这一步的落地关键是做一张RACI矩阵，不要只写一个“负责人”字段。对于目录里的每一个服务，至少定义四项角色：
- Responsible（执行的）：一线支持团队、服务台、二线专家组；
- Accountable（拍板的）：服务Owner，对整个服务质量负责，通常是各组主管或服务交付经理；
- Consulted（咨询的）：关联团队，如安全、网络、外包厂商；
- Informed（被告知的）：业务条线对接人、财务、合规等。
以“核心数据库服务”为例：执行人是DBA组，拍板人是数据库团队负责人，咨询人包括机房/云平台团队、安全团队，被告知人是业务系统PM和财务。这张矩阵不只写进目录里，还要同步给服务台和事件经理——他们接到工单时，按矩阵分配就能大幅减少“这个单该转给谁”的无效沟通。
这里要强调一个容易踩的坑：不要把服务Owner写成“IT部”。IT部是一个组织，不是一个人，出了问题没人能真正负责。服务Owner必须是具体的人，哪怕代理服务，也得写“张三（代理：李四）”，这样管理抓手才存在。
3.3 第三步：把SLA从口号变成可测量的指标
服务目录里最容易被写死的字段就是SLA。常见的病根是两种：一是拍脑袋定“响应时间1小时”，根本没考虑支持团队排班和系统告警链路；二是定得太复杂，光指标就有十来个，结果一个都没法统计。
我用的方法是“两层三类”指标：
| 指标类型 | 定义 | 常用目标示例 |
|---|---|---|
| 响应指标 | 从用户提交到服务台/流程系统首次响应的时长 | 普通请求：4小时；故障请求：15分钟 |
| 恢复指标 | 从确认故障到业务恢复可用的时长 | P1：4小时；P2：8小时；P3：3个工作日 |
| 完成指标 | 从用户提交到服务关闭的全程时长，适合请求履行类服务 | 设备申请：3个工作日；权限申请：1个工作日 |
定义SLA时有一个经验公式：先查过去三个月的工单数据，取“P80分位”作为初值，再和业务方讨论压缩10%到15%作为改进目标。比如过去三个月普通权限申请，从提单到开通的耗时，梳理下来80%在1.5个工作日以内完成，那SLA就定1.5个工作日，再和团队商定第三个月压缩到1个工作日。如果你们连历史工单数据都没有，就先定一个比较宽的承诺，例如2个工作日，运行一个月后再用分位数修标，不要直接写个看似漂亮但注定违约的数字。
SLA之所以重要，不是要作为罚款依据，而是给“救火队”一个转向的坐标系。当团队开始能够回答“我们承诺什么、做到没有”，就离服务专家更近了。
3.4 第四步：梳理服务依赖与成本模型
服务目录和CMDB的关系常被搞反。正确的关系是：服务目录是业务视角的“顶部”，CMDB是技术视角的“底座”。服务目录里每一个业务服务，都应该有一份依赖清单，指向CMDB中的配置项，比如服务依赖应用节点、应用数据库、中间件、虚拟化集群、存储、负载均衡、混合云网关等。
构建依赖关系时有三个操作建议：
- 先纵向打通，再横向铺开。先从1到2个核心业务服务开始做全链路依赖图，梳理出应用-中间件-基础设施-外部依赖的完整链路，成功后复制方法到其他服务；
- 依赖信息不用追求100%精确，重点是识别“单点故障”。真正有用的是找出单点——比如核心数据库只有一台物理机在撑，没有高可用，那么“数据库服务”目录项的可用性承诺就要打个问号；
- 成本模型不要太复杂。服务成本建议由“直接运维成本+分摊的共享资源成本+外部采购成本”三部分构成，年度核算一次即可。实在没有财务数据，按“资源量×单价”的粗放方式算出相对值，也能支撑“哪个服务最昂贵”的判断。
成本这块很多团队会卡住，因为财务数据拿不到。我的应对是：不要等财务给完美数据，先从云账单、机房电费、维保合同中抠出可直接归属的部分，把大头的服务和资源挂上成本。这一步的价值不是为了做内部计费，而是让你能回答“这个服务到底花了公司多少钱”。一旦能回答这个问题，IT的服务专家身份就初步立住了。
3.5 第五步：工具选型（对比ServiceNow、Jira Service Management、自研）
服务目录必须有工具承载。别拿Excel硬扛，也别一上来就上重武器。我按团队规模和预算，梳理了三条路线：
| 方案 | 适合场景 | 优点 | 明显短板 |
|---|---|---|---|
| ServiceNow ITSM | 中大型企业，有专门流程团队和预算 | 原生ITIL4实践覆盖、CMDB集成强、生态成熟 | 实施周期长，价格偏高，定制需要专业能力 |
| Jira Service Management | 研发/技术型团队，中小规模，已有Jira生态 | 上手快、请求目录体验好、与研发流程天然集成 | CMDB能力弱，复杂SLA与资产管理需插件 |
| 开源/自研（OTRS、iTop等） | 预算有限，团队有开发能力 | 灵活可控、成本低 | 需要自行维护，SLA、依赖映射等要自己开发 |
工具选型上我给三条建议：
- 先画流程再选工具。很多团队买了ServiceNow，却连事件分类都没有，结果上了一大堆模块没人维护，还不如先用Jira把请求目录跑起来。流程成熟度决定工具下限，工具只是放大器。
- 目录必须在同一个系统里和工单联动。用户从目录点服务，应该自动生成对应请求或事件模板，而不是复制链接再去另一个系统提单。一但目录和工单分离，基本可以断定目录会变僵尸。
- 先试用后扩展。任何工具至少做两周试用，让服务台和两组核心运维团队真实提单，检验“目录搜索-提单-SLA计时-派单”全链路是否顺滑，不要被厂商演示动画迷惑。
工具本身不会让服务目录成功，但选错工具会让后续运营心力交瘁。我的个人倾向是，中小团队优先Jira Service Management或iTop，先让目录转起来，等人员能力和流程成熟度到了，再评估ServiceNow。
3.6 第六步：发布、评审与首次“目录日”运营
搭建完目录，不要直接全量上线。我建议按这个节奏推进：
- 第一周：核心服务只在IT内部试运行，服务台先用目录派单，发现问题直接在后台改字段和流程；
- 第二周：选一个配合度高业务部门做试点，全程盯着请求量和吐槽点；
- 第三周：根据试点反馈修订SLA、描述和入口路径，召开“目录日”评审会，拉业务代表、运维主管、服务台坐在一起逐一过一遍目录内容。
- 第四周：全量发布，配合邮件、IM群、培训做入口宣传。
“目录日”这个概念是我自己定的，每月一次。第一次目录日最重要，不是走形式，而是要现场敲定三个决议：新增哪些服务、废弃哪些服务、哪些SLA需要调整。目录是活的，必须有一个固定的运营节拍。我见过太多的团队把目录上线当作项目结束，结果半年后目录里的联系方式都是离职员工，那时候想挽回就难了。
4. 从“救火队”到“服务专家”：目录如何真正改变工作模式
4.1 把“救火”变成“预案”：事件管理与目录联动
服务目录对一线最直观的改变，是让事件管理从“听描述猜系统”变成“按目录定位”。服务台接到电话，用户报“财务系统登不上”，过去服务台要先问一圈、查一堆表格才知道转给谁。现在按目录定位：财务系统服务→关联的技术组件和RACI矩阵里，应用组和数据库组的联系方式一目了然，同时目录中预先定义了P1/P2/P3事件等级，服务台在提单页面直接按业务影响定级，不用靠个人经验猜。
这就是“救火队”转变的开始。救火队的特征是每次火灾都当第一次，服务专家的特征是不同类型火灾提前有预案。目录就是预案的索引：每类服务预置了告警模板、故障升级路径、备选方案（比如“数据库服务不可用”预案里自带“切换只读副本”的步骤），事件工单一开，预案上下文已经被目录带出来了。
我在给一个客户做落地时，把他们的“订单系统”目录项下挂了一个应急预案链接和应急组织通讯录。后来真实发生了一次数据库锁死事故，服务台按目录信息30秒内拉起了线上会议，过去光找人就起码折腾半小时。这就是目录联动事件管理最直接的收益。
4.2 用目录反向驱动变更评估、问题复盘
服务目录的价值不只在于“接单”，更在于“改前评估”和“事后复盘”。
变更评估时，变更经理最怕的是“不知道动一下A系统会影响谁”。如果变更申请链接到了服务目录，变更影响分析就能直接从目录的“依赖关系”字段反向推导：这个变更涉及的技术组件，挂在哪些技术服务目录下，又通过业务服务目录影响了哪条业务线。系统化做法是变更表里增加“关联服务编号”字段，变更评审只看一个列表就能判断影响范围。我在实际项目里发现，这个动作至少能减少30%的“变更后才发现业务部门没通知到位”的投诉。
问题复盘的场景更突出。月度问题分析会上，以前大家各说各话，A团队说网络问题，B团队说DB问题，问题管理会变成争论会。有了目录，统一用“服务”作为统计维度：这个月“订单服务”的问题数、事件数、主要原因分布是什么？哪个技术组件的故障对“订单服务”影响最大？把讨论从“谁的责任”转向“哪个服务最脆弱”，问题管理才真正走向根因改进。
4.3 服务改进的三类指标，怎么报给业务部门
年度汇报时，IT部门常常被问“你们这一年到底干了啥”。有了服务目录，就有了统一的回答口径。我建议按周/月/季度向业务部门输出三类指标：
| 指标类别 | 具体内容 | 业务含义 |
|---|---|---|
| 可用性指标 | 核心业务服务月度可用性、P1事故次数、恢复时长 | 告诉业务“IT服务稳不稳” |
| 请求效率指标 | 各类服务请求的平均响应时间、平均完成时间、积压量 | 告诉业务“IT响应快不快” |
| 服务成本指标 | 每项服务的年度成本、成本趋势、单位成本 | 告诉业务“IT花得值不值” |
把这些指标做成一张“服务健康看板”，在月度经营会上展示，效果比单发一份《运维月报》好得多。关键思路是把“指标挂在服务上而不是系统上”，比如“可用性99.95%”业务部门不敏感，但换成“订单业务全年非计划中断不超过4次，每次不超过2小时，预计影响营收不超过X万元”，业务负责人立刻就能听懂。
这个阶段的团队，已经开始用服务语言和业务对话。我们不再是接单修机器的“救火队”，而是有服务目录、有SLA、有成本模型、有持续改进数据支撑的服务专家。
5. 常见坑位与排查实录
5.1 坑一：目录更新不及时，三个月就失效
症状：上线三个月后，新系统没加进去，老系统还在目录里挂着，负责人已经离职。 病根：没有形成“目录更新机制”，把目录当成一次性项目，而不是持续运营对象。 排查与对策：
- 在变更流程中加一个硬关卡：新系统上线发布前，必须提交服务目录变更申请，否则发布不予批准；
- 设目录管理员角色，每周检查新增的配置项与目录项是否匹配；
- 把“目录准确率”做成月度指标，定个目标例如95%，每月目录日核对一次。
我自己带团队时，会把目录管理员设成服务台主管兼任，因为服务台最清楚实际收到的服务请求和目录描述是否对得上。让最贴近炮火的人维护目录，效果远好于远端的流程团队。
5.2 坑二：SLA定得不科学，要么天天赔笑脸，要么形同虚设
症状：一种是SLA定得太高，团队加班也完不成，月底绩效难看；一种是定得太低，用户吐槽“这也要承诺？”。 病根：SLA没依据历史数据，也没跟业务共识。 排查与对策：
- 翻工单历史数据，用P80分位做基线，
- 把SLA草案发给业务部门关键用户评审，看他们能不能接受，再考虑平衡成本与能力；
- 上线后每月统计SLA达成率，连续三个月达成率超过95%，就主动调高5%-10%，形成持续改进节奏。
这里有个SLA维度的细节：响应SLA和解决SLA必须分开设置，不能混为一个字段。响应快不代表解决快，合并统计会让用户感受被数字误导。目录字段设计时就分开，统计报表才能准确暴露短板。
5.3 坑三：成本绑定太复杂，财务和运维扯皮
症状：成本字段一直为空，财务说数据敏感，运维说算不明白，目录的“价值与成本”一项成了摆设。 病根：把服务成本做成精确财务核算，而IT需要的是相对值与管理抓手。 排查与对策：
- 第一年只做“相对成本分级”：按资源占用、维保单价、人力投入粗分为高/中/低三档，先让目录具备排序能力；
- 第二年再做“服务计费模型”，以各团队上报的自下而上估算为准，不必等财务的完美分摊；
- 成本数据只需要服务Owner和交付经理可见，不必全量公开，减少内部博弈压力。
我一直跟团队强调：成本模型的核心价值是支撑“哪里有浪费”和“哪个服务最贵”的讨论，不是给财务做年报。方向错了，这事就永远推不动。
5.4 坑四：目录做好了没人用，入口不统一
症状：目录在ITSM系统里，但用户还是习惯发邮件、发IM、打电话找熟人。 病根：没有把服务入口收口，用户不知道“原来这件事该走目录”。 排查与对策：
- 所有IT相关请求在服务台统一收口，接到线下请求时明确回复“请走服务目录提单，我们会优先处理”，拒绝让旧习惯延续；
- 把高频请求项做成“快捷入口”，放在企业办公门户或IM工作台首页，用户点一次就能提单；
- 设置“首月激励”：正式发布后第一个月走目录提单的请求，服务台优先处理；线下渠道一律按低优先级排队。这个方法实测有效，一般两周就能养成新习惯。
入口收口是一场心理战。用户不是故意要绕过流程，只是过去没有“确定性”。当你目录上的每一项都有明确的时限承诺和进度可视，用户自然会选择走目录。前提是你的目录真能兑现承诺，否则回流会比想象中更快。
5.5 自查清单：月度目录健康度检查
做目录运营的人最需要的是“定期体检”。下面这张清单是我每月目录日会逐项过一遍的，直接抄用即可：
| 检查项 | 目标值 | 检查方法 |
|---|---|---|
| 目录服务项总数与业务系统匹配率 | 100%覆盖核心业务 | 对比最新系统清单和目录清单 |
| 目录服务项负责人有效联系率 | ≥90% | 抽查联系人是否在职、是否应答 |
| 服务目录项支持平均修改时间 | ≤5个工作日 | 看最近一次变更工单历时 |
| SLA达成率 | ≥90% | 统计各服务SLA达标比例 |
| 用户从目录提单的比例 | ≥80% | 看工单来源统计分析 |
| 服务成本数据更新时间 | 每季度更新 | 查看成本字段时间戳 |
| 目录管理员工单处理数 | 每月至少处理10条 | 看目录维护日志 |
这套检查没必要一次全达标，选三项最弱的做下月改进目标就行。目录管理是“慢功夫”，只要每月都在动，就不会腐烂清零。我经手过的几十个案例里，凡是坚持目录日三个月以上的团队，服务质量数据都开始明显变好，团队在业务面前说话的底气也完全不一样了。
最后再分享一点我的切身体会。服务目录这件事，真正难的从不是字段设几个、工具选哪家，而是你能不能坚持在每个月的目录日里，面对业务和团队，把“这个服务值多少钱、稳不稳定、能不能更快”这几个问题，一次次认真回答下去。当你做到这一点，你手下的就不只是一个个工单，而是一整套经过验证的服务能力清单。“救火队”的称号，自然就被“服务专家”取代了。
