转化率 回复率 满意度 均响 首响 客单价分别是什么

做电商客服或运营，早晚会遇到这种场面：老板丢来一张报表问「为什么这周满意度掉了」，你看着六个指标缩写发懵，不知道哪个口径对应哪件事。这篇不堆概念，按「这个数在算什么、分子分母怎么取、什么情况会失真」的方式把六个指标逐个拆开，最后给一套从数据异常倒推到具体环节的排查顺序。

做电商客服或运营，早晚会遇到这种场面：老板丢来一张报表问「为什么这周满意度掉了」，你看着六个指标缩写发懵，不知道哪个口径对应哪件事。更麻烦的是，同一个词在不同团队里算法不一样，你说的是进店人数做分母，他以为是发起咨询的人数做分母，两个人吵半天其实都没错。

这篇不堆概念，按「这个数在算什么、分子分母怎么取、什么情况会失真」的方式把六个指标逐个拆开，最后给一套从数据异常倒推到具体环节的排查顺序。目标很简单：下次开会你能说清自己报的数是怎么算出来的。

先把六个指标分成三组：漏斗、响应、价值

六个指标一起盯只会让人头大，先分组。分组的意义不是学术分类，而是排查时你知道先看哪一组、后看哪一组。三组之间是因果链，不是并列关系：响应快慢影响客户体验，客户体验影响认不认这次服务，服务感受又会影响买不买、买多少。

漏斗组

转化率、客单价，回答「来的人买不买、买多少」，属于结果层指标

响应组

首响、均响，回答「我们回得快不快」，属于过程层指标，客服能直接控制

结果组

回复率、满意度，回答「客户认不认这次服务」，介于过程和结果之间

因果方向

响应组变化通常先于结果组变化，结果组变化通常先于漏斗组变化，倒着查往往查不出原因

记住这个顺序：报警时先看响应组，因为它最灵敏也最可控；再看结果组，判断客户感受有没有真的变差；漏斗组放最后，因为它受促销、流量来源、大盘环境影响太大，客服能动的空间有限。想先查术语定义可以去 /ai-dict 对照。

逐个说口径：分子分母到底取什么

这六个指标真正容易吵架的地方全在分母和边界条件上，不在公式本身。下面按指标逐个说清楚取数时最容易踩的坑，团队内最好把每条规则写进文档，别靠口头约定。

首响和均响要一起看：首响反映最差体验，均响反映整体水位。均响好看但首响很差，说明大部分会话回得快，但有一批客户被晾了很久，这批人恰恰是满意度杀手。反过来首响还行但均响很差，说明开头接住了但后续拖沓。

• 转化率的分母在跨部门对齐前一定要确认，运营看的和客服看的经常不是同一个数
• 回复率的自动回复规则建议写成一句话贴在工作台上，全组执行同一个版本
• 均响做报表时同时给出中位数，避免少数超长会话把平均值带偏
• 满意度指标旁必须标注未评价的处理方式，否则月度对比没有意义
• 客单价注明含退或不含退，退货率高的类目这两个数能差出一截

指标异常时的排查顺序

指标掉了不要第一时间找人问责，先走一遍排查顺序。下面这套顺序在真实团队里比盯着单一数字有用得多，核心思路是从「是不是数变了」开始，逐层缩到「业务哪里变了」。

1. 第一步：确认口径有没有变换客服分组、换统计时间段、自动回复开关改动、评价入口位置调整，都会让数字跳一下却不代表业务滑坡。先拉出原始日志核对，别急着下结论。
2. 第二步：看响应组是否同步变化满意度或回复率掉的同时，看首响和均响有没有一起升高。如果响应没变而满意度掉了，问题可能在商品、物流或话术，不在响应速度。
3. 第三步：拆时段和问题类型把异常指标按小时段和咨询类型拆开，看是不是集中在某个班次、某类问题（比如退换货、发票）。这一步能把问题从「整体变差」缩到「某个环节变差」。
4. 第四步：最后才看转化率和客单价这两个受促销节奏和流量来源影响大，客户端能动的空间有限。如果是接口或工具不稳定导致的延迟，先到 /tools/speed-test 量一条基线，再决定换工具还是调排班。

要注意这套顺序有个不适用的情况：如果是大促当天或流量结构突然变化，因果链会被打乱，这时候先看大盘再谈客服指标，别把大盘波动当成客服绩效问题。另外团队人数极少（比如三个人轮班）时，个别会话就能让均值大幅波动，这时候更该看绝对值而不是比率。