"帮我看下这个"和"顺便处理一下"，是 IT 部门最容易被吃掉的时间。问题不在于忙，而在于没人知道到底忙在哪儿：没有入口、没有记录、没有优先级，最后只能按谁催得急来处理。
一、先有入口，再有制度
服务台的第一步不是选系统，而是收口：所有请求走一个入口。群消息、私聊、电话都可以用，但要统一转化成工单。没有这一步，后面的分级和统计都无从谈起。
- 统一入口：一个渠道受理，杜绝私聊指派
- 口头也说清：帮同事处理完，顺手补一张工单
- 入口要方便：扫码、短链、群内指令都行，提交成本决定使用率
二、工单字段怎么设计
| 字段 | 作用 |
|---|---|
| 提交人、部门 | 统计归属与回访 |
| 现象描述 | 快速判断与知识库检索 |
| 影响范围 | 分级依据 |
| 紧急程度 | 与影响范围交叉验证 |
| 期望时间 | 业务侧的真实诉求 |
| 附件 | 截图、日志、报错文本 |
字段不宜多，六到八个够用。多一个字段，填写率就降一档；关键是要让提交人明白"填得越准，处理越快"。
三、事件分级与响应时效
| 级别 | 判定 | 首次响应 | 目标解决 |
|---|---|---|---|
| P1 | 全局或核心业务不可用 | 15 分钟内 | 4 小时内 |
| P2 | 部门级不可用或有替代方案 | 30 分钟内 | 1 个工作日 |
| P3 | 单人不可用 | 2 小时内 | 2 个工作日 |
| P4 | 咨询、需求、优化建议 | 1 个工作日 | 排期处理 |
分级不是为了惩罚
它的作用只有一个：让"先修哪个"不再取决于谁嗓门大。级别由影响范围决定，不由提交人的职位决定——这一点写进制度，执行才顺畅。
四、SLA 怎么算才有意义
指标不求多，四个就够：首次响应时间、解决时间、返工率、满意度。前两个看效率，后两个看质量。
- 响应时间从提交时刻算起，含节假日口径要提前约定
- 解决时间区分"等待用户"和"IT 处理中"，别把等待都算进 IT 头上
- 返工率超过一定比例，说明是处理质量或培训问题
- 满意度只在关闭后抽样回访，避免每次都问导致敷衍
五、让流程跑起来的三个前提
- 有备件与权限：常见故障需要换件与账号权限，缺了这两样，SLA 是空话
- 有值班与备份人：单人负责的流程，遇到休假就断
- 有月度回顾：看数据、看高频问题、做知识沉淀
最后一点尤其重要：服务台的数据不是给管理层看的报表，而是改进的输入。每月花半小时看一遍——哪些问题重复出现、哪些本该自助解决、哪些流程可以再做一步——三个月之后，工单量通常会明显下降，而满意度上升。
#IT服务台#工单管理#SLA#运维流程
