帮你用响应时长指标而不被它反过来绑架。
文中核心拆解是：首次响应时长容易被博弈成数字游戏——自动回复也算「响应」，于是指标漂亮但问题依旧，客户的实际体验毫无改善。正确用法是与解决时长配对考核，并区分通道：生产事故按分钟计，一般咨询按工作时段计，低价值请求不必抢秒回。最容易出现误用的地方是给所有请求统一目标，逼得团队把资源浪费在低价值请求的快速回复上，真正的事故反而被挤压，最后所有人都成了输家，包括客户自己。
相比把 FRT 单独当团队绩效的普遍做法，这篇明确它适合做诊断指标而非绩效指标，两者混用必然催生刷数据，指标一旦背上网格化考核，水分只是时间问题。
建议你把现有响应目标按通道拆开重审一遍，砍掉统一的秒回要求，把省下的注意力还给事故响应。
—— FDEChina编辑部 · 实战派
定义
首次响应时长（first response time，FRT）指从客户发起请求（工单、消息、告警）到收到首次人工或有效系统响应的时长，是服务响应性的基础指标。
展开
FRT 容易被博弈成数字游戏：自动回复也算「响应」，于是指标漂亮但问题依旧，客户的实际体验没有改善。正确的用法是把它与解决时长（time to resolution）配对考核，并区分通道设定目标：生产事故的响应按分钟计，一般咨询按工作时段计，低价值请求不必抢秒回。
常见误用是给所有请求统一 FRT 目标，逼得团队把资源浪费在低价值请求的快速回复上，真正的事故反而被挤压，最后所有人都成了输家，包括客户自己。它与事件严重度分级天然配套：分级决定了每类请求该多快响应，两者必须引用同一张表。定位上，FRT 适合做诊断指标而非团队绩效指标——单独考核响应速度，必然催生自动回复式的水分，客户能感觉出来，信任反而受损。响应承诺要与分级和资源配套，才能长久。响应快慢是承诺问题，更是优先级分配问题。