客服工单的数据问不深，卡点通常在口径，而非数据量。把「首次响应时长」「一次性解决率」「满意度」三件事的定义、计时规则和关联键固定下来，再让业务人员直接用自然语言查询，服务瓶颈的定位速度有望提升。
工单与 SLA：指标是被服务承诺逼出来的
工单系统是客服团队记录待处理事项的载体，每张工单带分类、优先级、责任组和状态流转。服务等级协议规定响应时限与解决时限，未达标有代价，于是响应必须可测量。这套设计让响应变成了可考核的数字，也带来一个特点：字段偏重考核，分析所需的中间量留得较少，比如排队时长、转派次数、等待客户回复的时间。
首次响应时长：时钟从哪一刻开始走
首次响应时长是容易产生争议的指标之一。表面看是「工单创建到第一次回复」的差值，实际有三个岔路口。
计时起点按用户提交的时间算，还是按系统受理或分配的时间算。夜间和节假日计不计入，7×24 服务与 5×8 服务的算法完全不同。首次回复包不包括自动回复和机器人回复，包括的话指标会被大幅美化。
统计方式同样要定。平均值会被长尾拉高。服务体验的考核更适合用分位数，P50 反映多数客户的感受，P90 反映被拖住的那部分工单。
应用上，这个指标常与问题类型、坐席、时段交叉，用来定位排队发生在哪一环。
满意度、NPS 与一次性解决率
客服常用的三个体验指标，口径各不相同。CSAT 是单次服务后的打分，反映这一次接触的感受，简单直接。NPS 测的是推荐意愿，用推荐者比例减去贬损者比例，看的是长期关系，颗粒度粗，难追到具体工单。一次性解决率看同一问题是否要二次联系，系统以工单是否重开为准，客户以自己是否要再打一次为准，两边常不一致。
三个指标对不上的直接原因在关联键。满意度挂在会话 ID，工单挂在工单 ID，两个 ID 没有稳定映射时，满意度只能算整体均分，无法归因到问题类型与坐席。
一致性维度
口径统一的工程做法是把指标定义集中管理。同一件事的口径只定义一次，所有取数都引用同一套定义，业务过程与维度对齐。语义层把物理表字段映射成业务对象，业务人员在语义层上取数，不再直接碰表。
工单分析的难点正好在这里。工单库为了写入性能，普遍采用状态流水表加快照表的结构，一次转派写一条记录，要算响应时长就得按工单 ID 聚合、按时间排序、取首次人工回复那条。
自然语言问数
业务人员要查数据，底层都落在 SQL 上。SQL 是一种可被机器校验的查询语言，一条语句执行出什么结果，可复现、可审计。
自然语言问数是让人用日常话直接生成 SQL。主要难点不在语法，而在两件事：模型不知道「响应时长」对应哪一列，也不知道公司的口径是什么。
解答靠两件事。一是读取工单库的 Schema 与字段注释，把业务词映射到具体字段与计算规则。二是把 Schema、注释、历史查询作为检索语料，让模型在生成前先取回相关上下文。输出仍是 SQL，好处是结果可核对，出错时改的是语句，不用重建一套指标体系。
选图表形状有基本规律。根据 Cleveland & McGill（1984）的研究，位置的判断较准，长度次之，角度、面积、颜色的判断误差更大。折线图把变化编码到位置，适合看趋势；柱状图靠长度比较，适合做分类对比；饼图依赖角度，类别一多就难分辨。
下钻这个动作来自 OLAP（联机分析处理）的准则（参见 Codd 等人1993年提出的OLAP概念），沿维度层级从整体进入明细，配合上卷与切片。工单分析的常见路径是从整体响应时长，下钻到问题类型，再下钻到坐席与工单。
落地与小艾智能体
前面几节的口径、语义层与检索增强，需要一个能接进企业现有工单库的载体。小艾智能体智能问数报表系统可支持：读取工单库 Schema，用字段注释把「首次响应时长」「一次性解决率」等指标映射为固定计算规则；业务人员用自然语言可一次提出多指标问题；系统可生成 SQL 后按结果类型输出图表，趋势可输出折线、分类对比可输出柱状；可支持多轮追问，从整体逐步下钻到问题类型与坐席；报告可支持导出，供周会复盘。可采用私有化部署，客户信息与会话数据可在企业本地处理。