支持经理必备的帮助台报告指标｜Deskhero

每位支持经理都应按优先级报告的指标包括：工单量、首次响应时间（FRT）、解决时间（MTTR）、首次联系解决率（FCR）、CSAT、SLA 合规率、积压工单时长、重新打开率、升级率、每位客服处理的工单数、平均处理时长（AHT）、每张工单成本、NPS 以及渠道明细。从这里开始，你就能全面了解团队的健康状况。

以下是按优先级排列的列表，以及建议的报告频率：

工单量 — 每日快照，每周趋势
首次响应时间（FRT） — 每日（SLA 违约时实时提醒）
解决时间 / MTTR — 每日趋势，每周复盘
首次联系解决率（FCR） — 每周
CSAT — 每周得分，每月趋势
SLA 合规率 — 每日仪表盘，每周汇总
积压工单时长 — 每日关注超过 48 小时的工单
重新打开率 — 每周
升级率 — 每周
每位客服处理的工单数 — 每日工作量检查
平均处理时长（AHT） — 每周
每张工单成本 — 每月
NPS — 每月或每季度
渠道明细 — 每周

大多数团队都试图一次性跟踪所有指标，最终却对任何指标都没有采取行动。第一版仪表盘先选择最重要的六项，清理好数据，然后再逐步加入其余指标。

关键要点

可靠的帮助台报告始于干净的数据、一份包含真实目标的精简 KPI 列表，以及每周一次的复盘，并且每个数字都有人负责。

要点	详情
区分指标与 KPI	在构建任何仪表盘之前，将每个指标标记为“诊断指标”或“KPI”，以避免信号混杂。
FRT 和 CSAT 是投资回报率最高的组合	优先设置首次响应时间和 CSAT；它们易于快速配置，并且直接受团队控制。
基准需要结合具体背景	将建议的美国目标范围（例如，电子邮件 FRT 不超过 1 小时、CSAT 达到 80% 以上）作为起点，然后根据自身 90 天基线设定目标。
数据质量先于仪表盘	在公开发布任何指标之前，确保所有时间戳均由服务器生成，字段均由自动化设置。
Deskhero 自动完成指标采集	Deskhero 会自动填充工单字段，并提供内置的工单洞察地图，因此从第一张工单开始就能获得可用于报告的数据。

帮助台指标和 KPI 有什么区别？
按用途分类的核心帮助台报告指标
如何为团队设定现实的目标和基准
如何设计每类受众都会真正使用的仪表盘
报告之前先确保数据正确
会误导指标的报告陷阱
今天即可复制使用的实用仪表盘模板
报告真正能带来回报的地方
Deskhero 从第一天起就为你提供可用于报告的数据
来源
常见问题

帮助台指标和 KPI 有什么区别？

工单系统产生的每一个数字都是指标。KPI 是你决定要求团队对其负责的指标，并且为它设定了目标，以及指标下滑时相应的后果。这一区别很重要，因为把两者混在同一份报告中，会让人无法分清哪些内容只是信息，哪些内容代表绩效标准。

当三个条件同时满足时，一个指标才会成为 KPI：它对业务有直接影响（CSAT 与留存相关），足够稳定，能够在数周内形成有意义的趋势，并且团队中的某个人确实可以通过决策改变它。例如，工单量几乎总是诊断指标。它能告诉你工作有多忙，但客服无法仅靠更加努力地工作来减少流入需求。另一方面，CSAT 是 KPI 候选项，因为客服和经理可以通过响应质量、速度和解决准确性来影响它。

实际的区分方式如下：

诊断指标（用于提供背景，而非设定目标）：工单量、渠道明细、升级数量、AHT
KPI 候选项（设定目标，每周跟踪）：FRT、MTTR、FCR、CSAT、SLA 合规率、重新打开率、每张工单成本

一个常见错误是在同一张图表中混合数量和质量指标，却不进行标准化。每天处理 80 张工单的客服，CSAT 几乎总会低于处理 30 张工单的客服，这不一定是因为前者表现更差，而是因为高工作量压缩了响应质量。将每位客服处理的工单数与 CSAT 一起报告，这样数字才能讲完整的故事。

专业提示： 首次设置报告时，在仪表盘的列标题或组件标题中，将每个指标标记为“诊断指标”或“KPI”。这会迫使团队提前就哪些内容是目标、哪些内容只是背景达成一致，也能避免经理把诊断数字当成绩效评判。

按用途分类的核心帮助台报告指标

常见的 17 项帮助台指标可以自然分为四组：生产力、效率、客户体验，以及可靠性/财务。下面每组都包含公式、计算示例、以美国为重点的基准范围，以及数字发生变化时应采取的行动。

按用途分类的帮助台指标示意图

生产力指标

工单量 定义：某一期间创建的工单总数。 公式：统计报告时间窗口内 created_at 的工单数量。 示例：周一至周五共 340 张工单 = 每天 68 张。 基准：取决于团队规模；应跟踪周环比变化，而不是绝对数量。 如果出现峰值：在增加员工人数之前，先检查是否存在产品事故、营销活动或季节性因素。 类型：仅作诊断指标。

每位客服处理的工单数 定义：每位在岗客服的平均每日工单量。 公式：分配的工单总数 ÷ 期间内在岗客服人数。 示例：340 张工单 ÷ 5 位客服 = 每位客服每周 68 张工单。 基准：对于基于电子邮件的支持，每位客服每天 40–80 张工单是常见范围；实时聊天会显著压缩这一数字。 如果持续上升：重新分配任务或启动招聘评估；持续超负荷通常会预测未来 2–4 周内 CSAT 下滑。 类型：诊断指标。

渠道明细 定义：通过各个渠道到达的工单占比（电子邮件、聊天、电话、表单、社交媒体）。 公式：（来自渠道 X 的工单数 ÷ 工单总数）× 100。

基准：没有通用目标；用它将人员配置和 SLA 规则与实际渠道组合对齐。 如果聊天占比增长：检查并发会话的 AHT 和人员配置。 类型：诊断指标。

效率指标

首次响应时间（FRT） 定义：从工单创建到客服首次回复所需的时间。 公式： first_response_at − created_at（大多数 SLA 仅计算工作时间）。 示例：工单上午 9:00 创建，首次回复时间为上午 9:47 = FRT 47 分钟。 基准：电子邮件不超过 1 小时是美国广泛引用的目标；实时聊天不超过 5 分钟。 如果 FRT 上升：检查队列分配、客服可用性，以及自动确认是否掩盖了真实延迟。 类型：KPI 候选项。

双手调节响应时间控制旋钮

平均处理时长（AHT） 定义：客服从打开到关闭一张工单期间实际投入工作的平均时间。 公式：所有工单的总处理时长 ÷ 已关闭工单数。 示例：850 分钟总处理时长 ÷ 17 张工单 = AHT 50 分钟。 基准：高度取决于具体情境；密码重置的 AHT 为 10 分钟、账单争议的 AHT 为 90 分钟，都可能是正确的。 如果 AHT 上升：审查最耗时的工单类别，并为这些类别创建知识库文章。 类型：诊断指标（仅针对特定工单类别作为 KPI，不要用于整个队列）。

解决时间 / MTTR 定义：平均解决时间，从工单创建到关闭。 公式：所有已关闭工单的（resolved_at − created_at）之和 ÷ 已关闭工单数。 示例：5 张工单分别在 2 小时、4 小时、6 小时、3 小时和 5 小时内解决 = 总计 20 小时 ÷ 5 = MTTR 4 小时。 基准：标准优先级不超过 24 小时；高优先级不超过 4 小时是美国服务台常见目标。 如果 MTTR 上升：按优先级和类别进行细分。通常某一种工单类型会拉高平均值；解决该类别的问题就能推动整体数字改善。 类型：KPI 候选项。

首次联系解决率（FCR） 定义：无需后续联系或重新打开即可解决的工单占比。 公式：（首次联系时解决的工单数 ÷ 工单总数）× 100。

如果 FCR 下降：审查重新打开次数最多的工单类别，并更新客服话术或知识库内容。 类型：KPI 候选项。

客户体验指标

CSAT（客户满意度评分） 定义：正面评价其支持体验的客户占比（通常为 5 分制中的 4–5 分）。 公式：（正面回答数 ÷ 回答总数）× 100。

调查设计很重要：在工单关闭后 30 分钟内发送、设计良好的 CSAT 调查，比几天后发送的调查能产生质量更高、更可执行的反馈。 如果 CSAT 下降：提取逐字评论，按客服和类别细分，在得出结论前寻找其中的模式。 类型：KPI 候选项。

NPS（净推荐值） 定义：客户向他人推荐你的支持服务的可能性，采用 0–10 分制。推荐者（9–10 分）减去贬损者（0–6 分）= NPS。 公式：（推荐者占比 − 贬损者占比）。

基准：正 NPS（高于 0）是最低标准；对于 B2B 支持，高于 +30 被认为是良好水平。 如果 NPS 下降：NPS 是滞后指标，因此应与 CSAT 和重新打开率结合，以找出运营层面的原因。 类型：KPI 候选项（每月或每季度跟踪）。

重新打开率 定义：由客户重新打开的已解决工单占比。 公式：（重新打开的工单数 ÷ 已解决工单总数）× 100。

如果重新打开率上升：检查客服是否为了达到解决时间目标而过早关闭工单。 类型：KPI 候选项。

可靠性和 SLA 指标

SLA 合规率 定义：在约定 SLA 时间窗口内得到解决或响应的工单占比。 公式：（符合 SLA 的工单数 ÷ 工单总数）× 100。

如果合规率下降：确定是哪个优先级层级发生违约，以及违约发生在 FRT 还是 MTTR。

类型：KPI 候选项。

积压工单时长 定义：按照未解决时长分布的未关闭工单。 公式：对于每张未关闭工单：当前时间戳 − created_at。以直方图形式报告（0–24 小时、24–48 小时、48–72 小时、72 小时以上）。 示例：12 张工单超过 72 小时 = 需要立即分诊的积压队列。 基准：目标是没有超过最高 SLA 层级时限的工单；任何超过 72 小时的工单都应触发人工审查。 如果积压增长：按时长区间划分队列，并优先分配最早的工单，不论其优先级标签是什么。 类型：KPI 候选项（每日监控）。

升级率 定义：被升级到更高层级或专业团队的工单占比。 公式：（升级工单数 ÷ 工单总数）× 100。

如果升级率上升：按工单类别和客服进行细分。若大多数升级都由某个类别驱动，通常说明知识库存在缺口。 类型：诊断指标（如果培训项目与其挂钩，也可以成为 KPI）。

财务指标

每张工单成本 定义：支持总成本除以期间内处理的工单总数。 公式：（支持总成本：薪资 + 工具 + 管理费用）÷ 工单总数。 示例：每月 25,000 美元支持成本 ÷ 1,400 张工单 = 每张工单 17.86 美元。 基准：不同行业和渠道的范围差异很大；应跟踪自身趋势，而不是设定绝对目标。 如果每张工单成本上升：检查工单量是否下降（固定成本分摊到更少工单上），或 AHT 是否增加。 类型：KPI 候选项（每月）。

统计数据： Forrester 的研究持续将客户体验衡量列为首要投资重点，并指出持续衡量体验的组织更有条件提升客户留存率和收入——这正是应将 CSAT 和 NPS 视为真正 KPI，而不是可有可无的附加项的商业依据。

如何为团队设定现实的目标和基准

基准列表是起点，而不是终点。对于每周处理 200 张工单的五人团队，24 小时 MTTR 目标是合理的。但对于一个拥有 50 人、跨四个优先级层级处理 10,000 张工单的企业级服务台，这个目标几乎肯定不合适。下面的方法能帮助你以可重复的方式设定符合实际情境的目标。

建立基线。提取每项指标 90 天的历史数据。计算中位数（而不是平均值——异常值会使平均数偏离）。这个中位数就是你当前的绩效水平。
与同类团队进行基准比较。利用行业调查和 IT KPI 汇编，找出与你团队规模和行业相符的范围。确定你的基线在该范围中的位置。
设定 90 天改进目标。针对最弱的 KPI，争取提升 10–15%，而不是直接跃升到行业最佳。永远无法实现的激进目标，比完全没有目标更快打击团队士气。
进行季节性调整。如果你的工单量在第四季度会增长 40%，那么 11 月和 12 月的 MTTR 目标就应反映这一现实，而不是沿用第二季度基线。
建立置信区间，而不是单一数字。不要写“CSAT 必须达到 85%”，而应写“CSAT 目标：83–87%”。范围能够承认测量噪声，避免因某一周的下滑而恐慌。

遵循可重复的收集—清理—分析—行动流程，才能将帮助台数据转化为可衡量的业务增长，而不是变成没人查看的仪表盘。

指标	建议的美国目标范围	报告频率
首次响应时间（电子邮件）	不超过 1 小时	每日
首次响应时间（聊天）	不超过 5 分钟	实时
MTTR（标准优先级）	不超过 24 小时	每日
MTTR（高优先级）	不超过 4 小时	实时提醒
首次联系解决率	80%	每周
CSAT	80% 以上	每周得分
SLA 合规率	90%	每日仪表盘
积压（超过 72 小时的工单）	0	每日
重新打开率	低于 5%	每周
每张工单成本	跟踪趋势	每月

降低流失率与 CSAT 和 FCR 相关。这种表述能让高管层真正重视报告。*

何时使用滚动平均值，何时使用期间对比目标：CSAT 和 NPS 应使用 28 天滚动平均值，因为每周样本量通常太小，在统计上不具备意义。FRT 和 MTTR 则应使用期间对比（本周与上周、本月与上月），因为你需要快速发现运营变化。

如何设计每类受众都会真正使用的仪表盘

没人查看的仪表盘比没有仪表盘更糟糕，因为它制造了正在进行衡量的假象，却没有带来任何好处。解决办法是进行受众映射：每个群体只获取他们能够采取行动的指标。

受众与指标映射

客服需要个人视图：自己的 FRT、未关闭工单数、今天已解决的工单，以及其队列中的任何 SLA 违约提醒。除此之外什么都不需要。在没有背景信息的情况下向客服展示团队平均 CSAT，只会制造焦虑。

双手管理工作区项目和计时器

团队负责人需要运营全貌：FRT 分布（不仅是平均值）、按类别划分的 MTTR、按优先级层级划分的 SLA 合规率、重新打开率，以及每位客服工单数排行榜。只有与每位客服的 CSAT 配合使用时，排行榜才有价值，这样工作量和质量才能同时呈现。

支持经理需要趋势线和异常报告：每周 CSAT 趋势、积压工单时长热力图、按类别划分的升级率、每张工单成本的月环比，以及 FCR 趋势。最适合经理使用的客户支持仪表盘模板，会将顶层记分卡与按类别和客服进行下钻分析的功能结合起来。

高管需要一页摘要：CSAT 得分及趋势、SLA 合规率、每张工单成本，以及一个 NPS 数字。除非工单量与某项业务事件相关，否则他们不需要查看工单量。高管视图最多保留四到五个数字。

报告频率

实时仪表盘：FRT、SLA 合规率、未关闭工单数——客服和团队负责人始终实时查看
每日快照：通过电子邮件发送前一天的工单量、FRT 以及任何 SLA 违约的摘要——供团队负责人查看
每周复盘：CSAT、FCR、重新打开率、升级率、MTTR 趋势——经理在固定会议中查看
每月高管摘要：CSAT、NPS、每张工单成本、SLA 合规率，以及一段说明发生了什么变化及其原因的文字

每周复盘应留给趋势分析，而不是用于救火。

报告之前先确保数据正确

指标的可靠性取决于其背后的数据。使用客服编辑过的时间戳，而不是服务器记录的事件来计算首次响应时间，这不是测量，而是猜测。在构建仪表盘之前，先修复数据采集。

最低工单字段结构

每张工单都需要在创建或关闭时填充以下字段，而不是由客服手动填写：

created_at — 服务器时间戳，永远不可编辑
first_response_at — 客服首次发出的回复的服务器时间戳（不包括自动确认）
resolved_at — 状态变更为“已解决”时的服务器时间戳
assignee_id — 客服标识符
channel — 电子邮件、聊天、表单、电话、社交媒体
sla_type — 适用的 SLA 层级
priority — 低、普通、高、紧急
tags — 类别体系（见下文）
escalation_flag — 布尔值，当工单转移到更高层级时由自动化设置
reopened_count — 整数，已关闭工单收到新回复时由自动化递增
cost_center — 部门或产品线，用于按每张工单成本细分

如果上述任何字段缺失，或由客服手动填写，你的指标就会逐渐偏离。大多数字段都应在邮件转工单映射过程中自动设置，而不是事后补录。

标签和分类体系

标签应使用受控选择列表，而不是自由文本。自由文本标签会在一个月内产生 40 种“账单问题”的变体。对于大多数团队来说，包含五到十个顶级类别和两级子类别的受控分类体系就足够了。在可能的情况下，使用主题行关键词和发件人域名规则自动分配标签。

集成和市场扩展可以增加报告遥测数据，并自动填充字段，从而显著减少手动录入造成的偏差——无论使用哪个平台，这一原则都适用。

数据采集检查清单

[ ] 所有时间戳均由服务器生成，客服无法编辑
[ ] 已进行时区标准化（所有数据以 UTC 存储，显示时再转换）
[ ] 自动确认回复已从 FRT 计算中排除
[ ] SLA 规则中的工作时间配置正确
[ ] 升级标记由自动化设置，而不是由客服勾选
[ ] 已关闭工单收到入站回复时，重新打开次数会自动递增
[ ] 渠道字段由路由规则填充，而不是手动选择

专业提示： *在发布任何仪表盘之前，先对最近 30 天的工单执行一次数据质量审计。统计 first_response_at 或 resolved_at 为空的工单占比。

会误导指标的报告陷阱

最危险的帮助台报告，是那些看起来整洁，却衡量了错误内容的报告。以下错误一再导致糟糕的运营决策。

将原始工单数作为绩效指标跟踪。数量告诉你需求，而不是绩效。每周关闭 500 张工单的团队不一定比关闭 200 张的团队更好——如果前者的 CSAT 为 60%、重新打开率为 15%，那他们只是关闭了工单，并没有真正解决问题。始终将数量与质量指标配对。
平均响应时间，却不查看分布。平均 FRT 为 2 小时听起来可以接受，直到你发现 30% 的工单等待超过 8 小时。除了中位数，还要报告第 90 百分位 FRT。这一项改变就能揭示你面对的是系统性问题，还是少数异常工单拉高了平均值。
过度强调客服生产力，以牺牲 CSAT 为代价。单纯按照关闭工单数排名的排行榜，会推动客服快速关闭工单，而不是高质量地解决问题。某团队实施“每日关闭工单数”排行榜后，重新打开率在六周内从 4% 上升到 11%，因为客服在客户确认问题解决之前就将工单标记为已解决。每个生产力指标都应配合一个质量指标。
将升级工单混入正常流程指标。升级工单的复杂程度和处理时长与普通工单有根本差异。将它们纳入整体 MTTR 平均值会抬高数字，使标准层级的表现看起来比实际更差。应将升级工单作为独立报告群组。
完全忽略重新打开率。重新打开率是解决质量最清晰的信号之一，但许多团队从未跟踪它。重新打开率上升通常会提前两到三周预示 CSAT 下滑，让你有时间在客户开始流失前进行干预。
将 NPS 当作实时运营指标。NPS 是战略信号，不是每日数字。每周检查 NPS 并对单周波动做出反应的团队，只是在统计噪声上浪费精力。应每季度使用 NPS，并结合 CSAT 了解运营情况。

今天即可复制使用的实用仪表盘模板

下面的字段结构为电子表格或 SQL 导出提供了准确的列名，以及最常见计算所需的示例查询。它直接对应上文数据质量部分的工单字段结构。

电子表格字段结构和公式

列名	公式 / 来源	备注
`ticket_id`	系统生成	主键
`created_at`	服务器时间戳	UTC
`first_response_at`	服务器时间戳	排除自动确认
`resolved_at`	服务器时间戳	UTC
`frt_minutes`	`(first_response_at − created_at)`，以分钟计	仅计算工作时间
`mttr_hours`	`(resolved_at − created_at)`，以小时计	仅计算工作时间
`fcr_flag`	如果 `reopened_count = 0` 则为 1，否则为 0	布尔值
`aht_minutes`	系统记录的处理时长	不是挂钟时间
`cost_per_ticket`	`monthly_support_cost ÷ tickets_in_month`	每月重新计算
`csat_score`	调查回答（1–5）	通过 ticket_id 关联
`sla_met`	如果在 SLA 时间窗口内解决则为 1，否则为 0	布尔值
`channel`	路由规则	受控选择列表
`escalation_flag`	由自动化设置的布尔值	不是客服勾选框
`reopened_count`	自动递增的整数	触发 FCR 标记

SQL 示例代码片段

每张工单的 FRT（工作时间，以分钟计）：

SELECT ticket_id,
       DATEDIFF(MINUTE, created_at, first_response_at) AS frt_minutes
FROM tickets
WHERE first_response_at IS NOT NULL;

每位客服每天处理的工单数：

SELECT assignee_id,
       CAST(created_at AS DATE) AS ticket_date,
       COUNT(*) AS tickets_assigned
FROM tickets
GROUP BY assignee_id, CAST(created_at AS DATE)
ORDER BY ticket_date DESC, tickets_assigned DESC;

某一期间的 FCR：

SELECT
  SUM(CASE WHEN reopened_count = 0 THEN 1 ELSE 0 END) * 100.0 / COUNT(*) AS fcr_rate
FROM tickets
WHERE resolved_at BETWEEN '2026-01-01' AND '2026-01-31';

仪表盘标签页布局

客服标签页：个人 FRT、未关闭工单、今天已解决的工单、SLA 违约提醒——组件：数字卡片 + 提醒横幅
经理标签页：FRT 分布直方图、MTTR 趋势线、CSAT 趋势 + 逐字评论流、SLA 合规率仪表盘、积压时长热力图、与每位客服 CSAT 配对的每位客服工单数排行榜
高管标签页：CSAT 得分卡、NPS 数字、SLA 合规率、每张工单成本趋势——四个组件，不提供下钻

专业提示： 在文件名中加入日期，为仪表盘模板进行版本管理（例如 support_dashboard_v2_2026-02.xlsx），并保留上一版本一个季度。当指标目标发生变化时，你需要旧模板来解释为什么历史趋势看起来与新基线不同。

报告真正能带来回报的地方

最能从帮助台报告指标中获益的团队，并不是拥有最复杂仪表盘的团队，而是那些选定两三个指标、清理好数据，并在固定的每周会议中进行复盘的团队，而且会议中有人对相应数字负责。

对于大多数小型和中型团队而言，FRT 与 CSAT 是投资回报率最高的组合。FRT 易于采集、容易理解，并且直接受客服控制。CSAT 则通过告诉你速度是否转化成了良好体验来闭环。积压工单时长是早期值得重点关注的第三项指标，因为不断增长的积压，是团队开始落后的最早警告信号，通常早于其他指标反映问题。

能够放大这一切效果的文化变化很简单：不要再通过报告审查指标，而要开始在对话中审查指标。幻灯片上的数字不会改变任何事情。团队负责人询问“为什么我们的 FRT 在周二下午出现峰值？”，并得到真实答案——产品中断、路由配置错误、两名客服生病缺勤——这才是将衡量转化为改进的过程。Forrester 关于 CX 投资重点的研究也印证了这一点：持续衡量并配合组织层面的后续行动，才是能够提升客户留存的团队与只会跟踪留存率的团队之间的区别。

Deskhero 从第一天起就为你提供可用于报告的数据

如果你的团队仍在手动导出 CSV、拼接电子表格，或发现一半的 first_response_at 字段为空，那么问题通常出在平台，而不是流程上。这正是切换到专用帮助台能够迅速收回成本的情况。

Deskhero

Deskhero 能在几分钟内将任意 Gmail 或 Microsoft 365 邮箱变成共享工单队列，并提供服务器记录的时间戳、由自动化设置的字段，以及内置的工单洞察地图，无需手动录入数据即可生成本指南中的指标。AI 会根据你批准的知识库起草回复，依据路由规则自动填充标签，并记录每个自动化操作，让审计追踪保持清晰。eM Client 客户案例记录了平台自动处理数据采集后，团队能够实现的效率提升。30 天免费试用无需信用卡——从这里开始，导入本指南中的电子表格字段结构，在试用期结束前即可拥有一个可运行的仪表盘。

来源

以下参考资料用于编写本指南。关于 CX 衡量背后的商业依据，请参阅 Forrester 文章；关于 CSAT/NPS 数据采集，请参阅调查设计指南；关于收集—清理—分析—行动方法，请参阅数据增长指南。

常见问题

服务台报告的关键指标有哪些？

核心服务台指标包括首次响应时间、解决时间（MTTR）、首次联系解决率、CSAT、SLA 合规率、积压工单时长、重新打开率、升级率、每位客服处理的工单数以及每张工单成本。如果你是从零开始构建报告，应先从 FRT 和 CSAT 入手。

IT 帮助台有哪些好的 KPI？

根据 IT KPI 框架的建议，还应将这些指标与正常运行时间、员工满意度等部门 IT 指标结合起来，以获得完整背景。

应该多久发送一次 CSAT 调查？

在工单关闭后 30 分钟内发送 CSAT 调查，可以获得最高响应率和最准确的反馈。有效的调查设计会将问题控制在一到两个，并始终同时跟踪响应率和得分——较低的响应率会使即使很高的 CSAT 得分也不可靠。

良好的首次联系解决率是多少？

将其计算为无需后续联系或重新打开即可解决的工单占比，并按工单类别细分，以找出解决质量最薄弱的地方。

如何计算每张工单成本？

将某一期间的支持总成本（薪资、工具、管理费用）除以同一期间处理的工单总数。例如，每月成本 25,000 美元除以 1,400 张工单，等于每张工单 17.86 美元。应跟踪月环比趋势，而不是与某个绝对数字进行基准比较，因为每张工单成本会因行业、渠道组合和团队规模而显著不同。

支持经理必备的帮助台报告指标