上篇我们深入探讨了SLA设计的重要性，现在，让我们进一步挖掘服务目录设计的精髓，掌握服务实施的实战技巧，并且领略服务优化的艺术。这是我们的最终篇章，毫无保留，全是干货，让你满载而归。
服务目录
ITSM的目的是让服务成为明星，让服务类型隐身。服务目录设计，就像是一块试金石，老鸟新手一眼便知。目录设计得当，项目成功就相当于迈进了一大步。 传统ITIL理论太宽泛，落地难，咱们得改良。每个服务得有个固定的团队和SLA，不然服务就成了摆设，要么没人管，要么没期限。
服务目录里的细节也得抠：
- 服务负责人：一旦服务SLA报警或评价低，他们得第一个知道。
- 服务范围：公共的，全局都用；专属的，特定人群专享。
- 服务类型：各种服务分门别类，比如请求、故障、事件等，每种都有典型例子，一看就明白。
服务类型 | 描述 | 典型 |
请求 | 日常小事，如PC修修、密码重置 | PC故障,邮件申请,密码重置 |
故障 | 系统不灵了，得修 | OA故障,ERP报修 |
事件 | 监控报警，得人工介入 | 监控告警处理 |
问题 | 大难题，找根本的解决方案 | ERP性能优化 |
变更 | 生产环境动手术，硬件换换、软件调调 | 服务器硬盘更换 |
发布 | 新东西上线，软件更新、硬件部署 | 新系统上线 |
任务 | 工单的协同任务或者个人任务 | 个人事务 |
安全 | 应急处理，网络安全、*毒斗士 | 网络安全响应，*毒处理 |
需求 | 业务新想法，产品经理最爱 | CRM新需求 |
记住，这分类不是死规定，根据自家情况调整。
- 服务属性：各种属性定清楚，比如关联的配置、应用系统、交付方式，还有图标和描述，方便识别和服务。
服务设计技巧
- 服务名称 名字得通俗，比如“电脑出毛病”，别整“业务问题”这种云里雾里的。描述要详细，减少误会。
正面示例 | 反面示例 |
服务名称:PC故障；服务描述:主要面向个人电脑用户的一般故障,例如配件故障,网络中断等问题 | 服务名称:业务问题；服务描述:无 |
- 服务范围 别太大，比如“所有系统”，这样职责不清；也别太细，“导航栏错位”之类的，工单会爆棚。公共服务用公共，专属服务要管好。
- 服务自动化 自动分配工单，自动关闭超时未处理的，低评分自动警告服务台，减少人为干预。
- 多渠道接入 网站、电话、APP、微信、钉钉...年轻人爱啥来啥，传统用户就多照顾电话。
- 统一入口 服务目录是起点，用户只看目录，系统自动匹配服务类型和流程。
- 服务团队层级 一层团队别超10人，2到7人正好，多级设计能支持更多工程师。
服务名称 | 一线支持服务团队 | 二线支持服务团队 | 三线支持服务团队 |
PC故障 | L1TA | L2TA | L3TA |
PC故障 | L1TA,L1TB,L1TC | L2TA,L2TB | L3TA |
服务实施：从蓝图到现实
- 服务合同：ITILv4的精髓，得靠服务合同体现，这是服务关系的桥梁。
- 供应商合同：跟供应商的协议要盯紧，维保信息得跟上，别到时候掉链子。
- 服务配置：初始化设置，邮件、呼叫中心这些基础设施得准备好。
- 动态调整：牛气的功能！网页上就能调整服务参数，随时适应变化，服务经理随时掌控大局。
服务运营：日常运维的规矩
- 工单管理 核心流程，别每个服务都从头造轮子，拿个模板，微调一下，马上能用。
节点 | 节点内容 |
新建 | 权限审核 |
审批 | 是否审批，简单/复杂 |
分发 | 自由抢单还是空闲优先,满意度高优先,或者按工单分发规则进行指派 |
处理 | 一线-->二线-->三线 |
评价 | 是否自动评价,评价过低是否需要人工干预 |
关闭 | 是否自动关闭还是需要回访,是否需要转知识库 |
- 巡检管理 日常的巡逻，设备和检查指标得配对，能自动抓取数据就更赞了。
- 告警管理 海量告警要过滤，转成事件工单，处理进度实时同步给监控系统。
- 考核管理 既要硬数据，也要软反馈，自定义评分，公平又全面。
服务优化：持续向前的动力
- 服务报告：从不同角度分析数据，用户满不满意，SLA达没达标，总结经验教训。
- 持续改进：找出弱点，对症下药，不断进化，服务越来越强。
这一波实操分享就到这里，售后服务嘛，涉及到技术支持和新需求开发，因情况而异，就不细讲了。咱们的实战攻略到此结束，希望能帮到你！
