用Gemini起草季度SLA服务评审叙述

一句话结论：Gemini 可以读取一个季度的服务台工单导出和 CSAT 调研数据，用大约一小时起草出服务评审叙述——趋势、异常项，以及真正值得争论的那几件具体事情。你得到的是一份对自家供应商数字的独立解读。它无法告诉你服务到底好不好。

月度服务报告按合同在第八个工作日送达。九页，开篇是一块绿色的仪表盘，而这家 220 人公司的 IT 经理把它转进一个文件夹，第二页之后就没再看。三份这样的报告攒起来，日历上就冒出一场季度服务评审。

评审会上，客户经理讲的是同样的数字、同样的绿色，大家一致认为服务没问题，会议提前结束。两周后财务总监问：为什么服务台"感觉很慢"？——而没有任何一份文档能回答这个问题。

回答这个问题的原材料是存在的。它躺在 ManageEngine ServiceDesk Plus、Freshservice、Jira Service Management 或 Zendesk 里，作为一份工单导出；也躺在发送 CSAT 邮件的那个工具里。缺的是那几个小时的表格工作——把三个月的数据行变成一个有观点的故事。

这才是值得交给模型的那部分：不是"服务好不好"的判断，而是让这个判断得以成立的那次数据解读。

为什么月度 SLA 报告越堆越多，却从未变成一次真正的对话

月度 SLA 报告是一份合规产物。它存在的目的是证明合同阈值被满足了，而它是由被考核的那一方撰写的。这两件事共同塑造了它：它对照合同里的目标来汇报，并且用可用的最站得住脚的方式来汇报。

这里面没有任何不诚实。但"P2 解决 SLA 达标率 97.4%"是一句关于阈值的陈述，不是关于提单者感受的陈述。一个 P3 解决时间中位数翻倍、却仍然落在宽松 SLA 之内的季度，在每一页上都会显示为绿色。

这些报告还是按月送达、按月阅读的，而这个节奏根本发现不了任何东西。趋势活在季度尺度上。单独一个月看不出：自三月以来同样的五名用户提交了四成的工单；也看不出：自某次人员调整之后，周一早上的等待时间悄悄多了十一分钟。

于是季度评审——本该让这些浮出水面的那场会——开场就是供应商自己的幻灯片，因为客户这一侧没有人准备过另一份解读。这场会于是默认在供应商的框架里进行，这不是谁的错，却是所有人的问题。

Gemini 用工单和 CSAT 导出数据到底能做什么

Gemini 可以通过 Google Sheets 的侧边栏处理表格数据，也可以在 Gemini 应用里以上传文件的方式处理。你能用到哪些功能、文件大小限制是多少，取决于你的 Workspace 版本，而且这些会变——请查阅你所用套餐的当前官方文档。这里真正要紧的能力并不炫目：认真读几千行数据，然后描述出发生了什么变化。

有两样输出值这一个小时。

把一张响应与解决时长的表格变成一段趋势叙述

给它三个月的工单数据行——创建时间、首次响应、解决时间、优先级、分类、提单部门——它会算出那些显而易见的汇总值，而更有用的是，它会把那段话写出来："首次响应中位数稳定在 14 分钟；P3 解决时间中位数从四月的 4.2 小时上升到六月的 7.8 小时，主要由软件安装类工单驱动。"

这句话才是一次服务评审真正需要的东西，也几乎从来没有人写出来过——因为写它需要有人对着透视表坐两个小时，然后用文字形成一个观点。

要明确要求做对比：本季度对上季度，如果有数据，再对去年同期。一段没有基线的叙述，只是一个被形容词包围着的数字。

标出真正值得在评审会上提出来的工单与模式

第二样输出是一份短名单。让它列出：耗时最长的十张工单、所有被重开超过一次的工单、所有工单量增长超过四分之一的分类，以及所有评分在三分及以下的 CSAT 回复，并附上其自由文本评论。

那份名单就是你的议程。它把评审从"我们有没有达到 SLA"变成"这里有十一件具体发生过的事，我们打算怎么办"——而后者才是真正能改进服务的那场对话，也是一家问心无愧的供应商通常会欢迎的那场对话。

一套可落地的流程：从一份 CSV 导出到一份可用于评审的初稿

1. 要原始导出，不要那份报告。向你的 MSP 或你自家的服务台管理员要一份覆盖整个季度的工单级 CSV，包含时间戳、优先级、分类、提单部门和处理记录。如果你的合同并没有赋予你这项权利，那么在下次续约之前把这件事搞清楚很有价值——这是一个合理的要求，也是一个不太好拒绝的要求。

2. 剔除不该离开你环境的内容。提单人姓名和邮箱、处理记录里任何看起来像密码或内部路径的东西，以及任何点名了你自己客户的自由文本。把姓名替换成部门标签，能保住你需要的全部分析，同时去掉大部分风险。

3. 算术在表格里做，不要在提示词里做。自己加上那些派生列——首次响应时长、解决时长、是否违约、周次。相比让模型从四千行数据的两个时间戳里现算，让它描述一个已经躺在单元格里的数字，可靠得多。

4. 先要趋势段落，并且点名基线。"把 Q2 和 Q1 在首次响应中位数、各优先级解决时间中位数、各分类工单量和重开率上做对比。写四段。列出你用到的数字。"引用数字这条指令才是重要的那一半——它让核对成为可能。

5. 异常清单作为单独一轮来要。耗时最长的工单、反复重开的、增长最快的分类、带评论的低分 CSAT。保持为带工单号的编号列表，这样会上每一条都能在几秒内被调出来。

6. 在你相信另外三十个数字之前，先手工核对三个。从叙述里挑几个数字，回到表格里验证。如果这三个是对的，这套方法就在正常工作；如果有一个是错的，这份叙述就不能用了——而你需要在开会之前知道这件事，而不是在会上。

7. 解读要你自己写。模型能告诉你软件安装类的解决时间上升了。只有你知道，同一个季度采购换了笔记本型号，每台新机器都要多装三个应用。那句话就是你贡献的价值，而它不在数据里。

8. 提前三天把议程发出去。一页具体的问题，提前发出，会彻底改变这场会：供应商到场时已经查过同样那十一张工单，这一小时于是花在原因上，而不是花在仪表盘上。

AI 起草的季度评审叙述 vs 供应商撰写的服务评审 vs 根本没有正式评审

基于你自己数据、由 AI 起草的叙述。独立于供应商的框架，便宜到每个季度都能做一遍，而且在一个晚上六点已经疲惫的人做不到的那种彻底性上很强。它不了解你的业务背景，会心安理得地把一个统计假象说成趋势，也无法判断某个数字是否可以接受。正确用法：作为你的会前准备，绝不是这场会的结论。
供应商撰写的服务评审。由了解环境、了解历史、也知道那张工单为什么拖了九天的人准备。那份知识是真实的，也值得拥有。同时它由被考核的那一方撰写，对照的是他们参与设定的阈值——这不是对任何一家供应商的指控，只是一个值得被对冲的结构性事实。
根本没有正式评审。这是三百人以下公司里最常见的安排。服务质量于是靠感觉来评判，通常是在一次事故之后，而相关对话发生在续约时——那正是筹码最高、善意最低的时刻。

真正管用的搭配是前两者并存。供应商带来背景，你带来独立解读，这场会于是有了两个信源，而不是一个。

它会在哪些地方把故事讲错

CSAT 是一份带幸存者偏差的样本，读起来却像一次普查。会回答问卷的用户，是极满意的和极愤怒的那两类。平均分上升，往往意味着那些"有点烦但没那么烦"的人不再回复了。任何仅建立在 CSAT 之上的叙述，都会对你组织中间那一大块——也就是绝大多数人——自信地做出错误判断。

一个头条指标可以藏住它本该衡量的那次失败。三千张工单里九十八个百分点的达标率，仍然留下六十次违约。如果其中五十次属于财务团队、且集中在月末结账那一周，那你就同时拥有一个严重问题和一块绿色仪表盘。每一次都要求把违约按部门和按周拆开。

它分不清趋势和组织调整。工单量下降三成看起来像改善，但同样可能意味着某个受够了的部门不再提单，改成直接打某人手机。数据看不见那条影子队列，你能看见。

处理记录是为了关单而写的，不是为了描述事实而写的。"已解决，已告知用户"可以涵盖从一次真正的修复到一次耸肩之间的一切。一个模型读完一个季度的处理记录，产出的摘要会忠实于被敲下来的文字，而不忠实于实际发生的事。

把这件事做对——工单数据的敏感性、供应商客观性，以及什么时候该让 IT 介入

一份工单导出比它看起来敏感得多。处理记录里有服务器名、共享路径、应用版本、偶尔还有一条本就不该被敲进去的凭据，以及一份关于"你哪些系统很脆弱"的坦白流水账。请把这个文件当作网络拓扑图来对待。

按规则清洗，而不是靠判断清洗。一条固定的预处理步骤——删掉提单人姓名和邮箱列、扫描自由文本里任何形似凭据的内容——能挺过一个忙碌的季度。而"打算小心一点"的意图挺不过去。

在数据进去之前，先搞清楚工具的条款。个人版、商业版和企业版在数据留存以及内容是否可能用于训练上各不相同，而且条款会变。请查阅你所用具体套餐的当前官方文档，然后在公司层面定一条规则：哪些工具可以接收运营数据——而不是把这件事留给当时恰好在准备评审的那个人。

带着一份独立解读去参加供应商评审是健康的，而且应该是公开的。告诉你的服务商你在这么做。一家欢迎客户带着自己的分析来的供应商，正在告诉你一些有用的东西；一家不欢迎的，同样如此。

决定 AI 在你的运营报告体系里该占哪个位置，并写好那些让它可重复的提示词与清洗规则，是 AI+ 支持的工作。底下那套度量框架——明确的响应与解决目标、月度报告、CSAT 采集，以及一场真正算得上对话的季度服务评审——是我们的 SLA 与质量框架，而它所衡量的交付则是管理型 IT 支持。如果你要从其他表格导出里构建类似的叙述，我们关于在 Google Sheets 里自动生成月度销售报告和起草服务台工单回复的文章覆盖了相邻的问题。

常见问题

我能相信一份由 AI 写的、关于我自家供应商表现的总结吗？

把它当作"对你给它的那份数据的解读"来相信，并且在依赖任何数字之前先手工核对三个。它相对供应商报告的优势不是准确度，而是独立性：它是对照你提出的问题来描述你的导出数据，而不是对照写进合同里的那些阈值。至于这些数字是否可以接受，判断权仍然在你手里。

如果我的 MSP 不提供原始工单导出怎么办？

用书面形式提出要求，并记录下答复。关于你自己的用户、你自己的系统的工单级数据，是客户合理应当持有的东西，多数服务商会痛快地给一份 CSV。拒绝本身并不能证明什么，但它是一个信息点——而下一次续约，正是把这项要求变成一条明确合同权利的时机。

这和我的供应商已经在发的那份报告有什么区别？

作者不同，问题也不同。他们的报告回答的是"我们有没有达到约定阈值"，那是合同提出的问题。你的报告回答的是"这个季度发生了什么变化，我们该怎么办"，那是业务提出的问题。两者都正当，只是目前只有其中一份被写了出来。

它适用于任何服务台工具的数据吗？

适用于任何能导出工单级 CSV 的工具，实际上也就是全部——ServiceDesk Plus、Freshservice、Jira Service Management、Zendesk、Halo。列名不同，而添加派生列的工作量在哪里都一样。比工具差异大得多的是工单分类的纪律性：如果你有一半工单归在"其他"，任何分析都救不回来。