月度复盘会上摆了两张纸。

左边是一张统计表，上面写着平均首次响应时长两小时十四分，比上个月快了十一分钟，看起来是件好事。右边是三段从聊天记录里摘出来的原话，最短的一段只有八个字：三天了，没人回我。

两张纸说的都是真事。表没算错，那三段话也没编。可放在一起，会议室里没人能解释清楚——如果平均两小时就能回，怎么会有人等了三天。

后来把两个数拆开看才明白：那张表算的，和我们真正想知道的东西，根本不是一回事。它算的是"所有消息平均等了多久"，我们想知道的是"具体某一件事，等了多久才有人真正接手"。

这两件事之间隔着好几个选择：时钟从哪一刻开始走、夜里和周末算不算、说一句"我问问"算不算回复、回一个"收到"算不算答复。每一个选择都会让最终的数字变一个样，而这些选择在统计表上是看不见的。

聊天记录导出之后，做效率分析不算难，难的是先把这些选择定下来。这篇就把这套流程从头到尾讲一遍。

一、平均和感受，差的不是数据是口径

先说清楚一件事：这类分析里最容易出的错，不是算错，是口径没定就开始算。

同一批记录，换四种口径，能算出四个不一样的结论，而且每一个都能自圆其说。对方感受到的"三天"，和表上写的"两小时"，差别主要来自三处。

第一处：平均藏住了两头。平均值是把所有间隔加总再除以条数。十条消息里九条三分钟回、一条隔了四十小时，平均值大约四小时出头——听起来还行，但那一条是真真切切等了四十小时的事。平均值天生会把长的藏起来，而事情出问题，几乎总是出在长的那些上。

第二处：群里"有人回了"和"我被回了"是两件事。一个二十人的项目群，一个人问了句报价什么时候能给，五分钟后另一个人回了个"在看"。从记录上看，这条消息有回复了，响应时长五分钟。可发起的人真正要的那个报价，可能两天后才出现。群里最不缺的就是回应，最缺的是答复。

第三处：跨夜那一刀。晚上十一点发的消息，第二天上午九点回，间隔十个小时。这十个小时里没有一个人在工作，但它照样被算进"响应时长"。如果这类消息多，整个平均值就被夜间撑大了；反过来，如果只截取白天的工作时段，又会把真实的长尾切掉。

所以这篇的顺序是：先定口径，再看分布，最后才写结论。顺序反了，后面全是返工。

二、第一个坑：时钟从哪儿开始走

起点看起来是明摆着的——从消息发出开始算。但真到表格里，这一步就有分歧。

起点必须是"对方发出那条消息"，不是"我看到的那条"。有些统计会从自己第一次打开会话的时间开始算，那样算出来的其实是"我处理得快不快"，不是"对方等了多久"。这两个数差得很远，尤其是消息集中在某几个时段到达的时候。

群聊里还要判断，这条消息到底是不是在问我。一个群里一天两百条消息，其中大部分是同步信息、通知、闲聊。把它们全算进响应时长，等于拿一堆不需要回复的消息去稀释真正需要回复的那几条，结论必然是"响应很快"。判断方法很土但有效：看有没有明确的指向——被@、被点名、被追问第二遍、或者上一条消息本身就是提问。这三种情况之外的消息，单独归一类，不参与时长计算。

还有一种容易被漏掉的情况：一件事换了个群继续聊。上午在项目群提的问题，下午拉到一个小群里解决。如果按会话分开算，项目群那条永远等不到回复，小群那条又没有起点。遇到这种，要在表里留一列备注，把它标成"已转移"，或者在统计时把两段拼起来算。留个标记比精确计算更重要——至少看表的人知道这里断过一次。

三、第二个坑：夜里、周末和节假日

聊天记录是二十四小时不休息的，人不是。

一条晚上十一点发出的消息，第二天九点回复，间隔十小时。如果这一批记录里夜间消息占比高，平均值会被抬高一大截，看起来像"响应很慢"，其实只是有人在半夜发了消息。

处理方式有两种，选一种，写清楚，全篇统一。

一种是按自然时间算，不做任何剔除。好处是简单、可复现、不需要额外数据；代价是夜里和周末的消息会污染结果。用这种口径，结论里必须写明"含非工作时间"，否则看的人一定会误解。

另一种是剔除非工作时间。好处是更接近"在工作时间里等了多久"；代价是需要一份工作日历——每天几点到几点算工作、周末算不算、法定节假日怎么排、调休怎么处理。聊天记录本身不带这份日历，得另外补。

两种都能用，最怕的是混着用：算 A 组的时候剔了夜间，算 B 组的时候没剔，然后拿两组去比。这样比出来的差异，全部来自口径，跟实际快慢没有关系。

还有一层更细的：跨夜标记要单独留一列。不管用哪种口径，都建议在原表里加一列，把"起止时刻跨越了非工作时间"的条目标出来。这样随时可以两种口径各算一遍，互相印证。这个动作成本很低，但能救回很多次争论。

四、第三个坑："我问问"算不算回复

这是四个坑里影响最大的一个。

一个典型场景：对方问"这批货什么时候能到"，回了一句"我问问仓库"。从记录上看，五分钟响应，非常漂亮。可对方要的是到货时间，这一句把等待转给了另一个人，计时停了，等待没停。

所以终点要分两个：

首次回应：第一条有人说话的时间。这个数反映"有没有人接住"，有意义，但它非常容易被"收到"“在看”"稍等"撑得很好看。

实质答复：真正把对方要的信息给出来的那条。这个数才反映"事情推进了没有"，但它需要人判断，没法完全靠机器算。

建议两个都记，分两列。看的时候先看实质答复，首次回应只作为参考。如果只留一个，留实质答复——哪怕判得粗糙，也比一个漂亮的首次回应有用。

判断"算不算实质答复"，可以先用一个小办法：把这一轮里对方最后没有再追问的那一条，找出来。对方不再追问了，通常意味着拿到了他想要的；对方又问了一遍、换了说法再问、或者干脆去问别人，说明前面那些都不算答复。这个办法不完美，但比数回复条数靠谱得多。

五、第四个坑："收到"和"答复"不是一回事

接上一条。很多人想用一个简单规则把"收到"过滤掉，比如"少于五个字不算回复"。这个规则会误伤。

“行”、“可以”、“明早九点”、“已发”——都只有三四个字，但每一个都是有效答复。反过来，"收到，我这边看一下稍后回复您"有十几个字，什么信息都没有。

字数判断不了这件事。可行的做法是先人工标一小批，把判断标准沉淀成样例：

从记录里挑出三十到五十条来回，逐条标上"算实质答复"或"不算"，标的时候把理由写在旁边。标完再看，你会发现标准其实很一致，只是之前没写出来——通常是三条：有没有给出对方要的那个信息、有没有给出明确的时间、有没有把责任接过去并说清下一步。

把这三条写成两三句说明，附在统计结果后面。以后谁来算，都按这个来。这比任何自动规则都稳。

六、先写一张口径卡，再动手算

上面四个坑，对应的其实是四个决定。把这四个决定写成一页纸，就是口径卡。四行就够：

起点：对方发出消息的时刻，群聊只统计被@、被点名、被追问、或本身是提问的消息。

终点：分两个，首次回应与实质答复，实质答复的判定按附的样例说明。

排除项：哪类消息不计入（通知类、同步类、系统消息）、非工作时间如何处理（按自然时间算，或按工作日历剔除）、跨会话转移的如何处理（标出，拼接或单列）。

单位与精度：分钟，四舍五入到整分；时间段以什么时区为准。

这张卡一定要放在结果的第一页，而不是附录。原因很实际：没有口径的数字，谁都可以用自己的理解去解读，然后得出和你相反的结论。有了口径卡，讨论就会从"我觉得没那么慢"变成"这个口径下算出来是这样，要不要换个口径再算一遍"——后者是能推进的对话。

还有一条纪律：口径一旦改了，全部重算，不要新旧混比。混比出来的"环比改善"最不可信。

七、不看平均，看三个数

平均要看，但不能只看平均。真正有用的是三个数。

第一个：中位数。把所有间隔从小到大排，取正中间那个。中位数比平均值诚实得多——它不受极端值影响。如果中位数是八分钟、平均值是两小时，那说明大部分人回得很快，少数几条拖了很久。这个组合背后的管理含义，和"平均两小时"完全不一样。

第二个：长尾。把间隔最长的十条单独拉出来看，一条一条看它们为什么长。是被转派了没人接、是跨了周末、是问题本身需要等外部答复、还是压根就被漏掉了。十条里有六七条是同一个原因，那才是真正要改的地方。这也是这类分析最有价值的部分——平均值告诉你"整体还行"，长尾告诉你"问题在哪"。

第三个：落在约定时限内的比例。如果团队内部对某类问题有约定，比如询价当天回、故障两小时内给方案，那就直接算"有多少条落在这个时限内"。这个数比平均时长直观得多，也更容易被接受——它对应的是一句人能听懂的话：十单里有七单按时，三单超时。

三个数放在一起，才是一幅完整的图。单看任何一个，都能得出偏的结论。

八、Excel 里怎么落：一行一件事，不是一行一条消息

导出的记录到了表格里，第一件事不是套公式，是换一种组织方式。

原始记录是一行一条消息。这个结构没法算时长——一条问句和它的答复隔着几十行，中间还夹着别人的话。要先把结构改成一行一件待答复事项：

几个实操上的注意点：

时间列要先统一格式。有的记录带秒、有的不带，有的导出后变成了文本，直接相减会出错。先全列转成统一的时间格式，再算差值。

间隔用两个时间列相减，单位统一到分钟。别混着用小时和分钟，也别在中间四舍五入两次。

群聊里的发送者字段一定要保留。少了它，就没法判断"这条是不是被问的那个人回的"——而这个判断，恰恰是区分"有人接住"和"被正确的人接住"的关键。

别删原始导出文件。加工后的表是你的理解，原件才是事实。两者都要留，并且文件名要能看出哪个是原件、哪个是加工件。

九、按问题类型分组，比按人排名有用

分组方式决定了这份分析会被怎么用。

按问题类型分组，是最稳妥也最有用的。询价、故障、审批、资料这几类的天生难度完全不同：询价可能等外部报价，故障可能等配件，审批可能等另一个人。分成四组各看各的中位数，才能看出哪一类是真的慢。

按人排名要谨慎。原因有三：一是样本太小，一个人一个月可能只经手二十单，二十单的差异说明不了什么；二是分工不同，有人接的全是难单；三是一旦排名，讨论就会从"流程哪里卡住"变成"谁不行"，而后者解决不了任何问题。

如果确实想看个体差异，把门槛设高一点：同一类问题、样本在二三十单以上、时间跨度覆盖完整周期，再拿出来看。达不到这三条，就别下结论。

还有一条经常被忽略：跨部门的事项要单独归一组。它们的时长里有一大半不在本部门手里，混在总表里既拉高了平均，也说不清责任在哪一环。单列出来，反而能看出流转在哪一步停住——那才是可以改的地方。

十、导出这一步，三个格式各管一段

分析的基础是导出的记录本身。这一步用 EchoWe，它支持 HTML、PDF、Excel 三种格式，三种在这个流程里各管一段。

Excel 拿来算。后面所有的表格加工、分组、算间隔，都从这份开始。导的时候范围要一次框准：时间窗按分析周期定，会话按参与的事项定，宁可多带几个群，也别在算到一半发现少了一个。

HTML 拿来核。表格里的每个数字，最后都可能被问"这条是怎么算的"。HTML 保留了原始顺序和上下文，能直接翻回那一段看前后说了什么。这一步看着多余，实际上是这份分析能被相信的原因。

PDF 拿来讲。要给不参与分析的人看结论时，PDF 最省事——排版固定，不会因为对方用什么软件打开而变形。

三个格式用同一批范围导出，文件名里带上日期区间，别都叫"聊天记录"。这一点在后面会反复救你。

十一、结论怎么写，才不会被一句话推翻

同样一份数据，写法不同，被接受的程度差很远。

不要写"团队响应偏慢"。这句话的问题不是说错，是没法核对——慢是相对什么慢、慢多少、慢在哪一段，全都没说。而且它一定会换来一句"我觉得没那么慢"，然后讨论就停在那里。

换成带范围的写法：在这三十七件待答复事项里，一半在十二分钟内得到了实质答复，最长三件超过三十小时，三件都发生在转派之后，其中两件跨了周末。

这句话长，但它每一段都能被核对：范围是三十七件、中位数十二分钟、长尾三件、归因是转派和跨周末。看的人可以不同意结论，但他没法说"这个数不对"——因为他知道这个数是怎么来的。

结论只写数据能撑住的那一层。数据能说明"这三件等了很久，且都发生在转派之后"；数据不能说明"转派机制有问题"，那是推断。推断可以写，但要写成"值得进一步看的点"，而不是结论。

这条界限看着保守，其实是在保护这份分析的可信度。一次把推断当结论写，下次这份表就没人信了。

十二、必留的三样东西

第一样：口径卡。起点、终点、排除项、单位，四行。这份东西决定了所有数字的含义，丢了它，剩下的表就成了一堆无法解读的数值。

第二样：原始导出文件。包括 Excel 原件和 HTML。加工表可以重做，原件重做不了——记录会被清理，会话可能被解散，那个时间点的完整状态只有那一刻有。

第三样：剔除与分组的说明。剔了哪些消息、为什么剔、分了哪几组、每组多少条、哪些事项标了"转移"或"未解决"。这份说明最不受重视，但它决定了别人能不能复核你的结果。

三样东西放在同一个文件夹里，命名带上周期，比如"效率分析_2026第10期"。下个周期再做，直接照着这份的口径走，两次结果才有可比性。

十三、避坑十条

一、别从"我打开会话的时间"起算。那算的是自己的处理速度，不是对方的等待。

二、别把群里的通知类消息算进响应时长。一堆不需要回的消息会把结论稀释成"很快"。

三、别忘了跨夜。十小时的间隔里可能一个人都没在工作，不标出来就会被误读。

四、别把两种夜间口径混着用。一组剔了、一组没剔，比出来的差异全部来自口径。

五、别把"我问问"当答复。计时停了，等待没停。

六、别用字数过滤"收到"。三四个字的有效答复会被误伤，十几个字的空话会漏过去。

七、别只报平均值。中位数、长尾、按时比例，三个数一起看才有意义。

八、别按人排名就下结论。样本不到二三十单、分工又不一样，排名说明不了什么，还容易把讨论带偏。

九、别删原始导出文件。加工表是理解，原件是事实，两者都要留。

十、别新旧口径混着比。口径改了就得全部重算，混比出来的"改善"最不可信。

十四、归档路径建议

效率分析_2026第10期/ ├── 01_原始导出/ │ ├── 聊天记录_20260901-20260930.xlsx │ ├── 聊天记录_20260901-20260930_原貌.html │ └── 聊天记录_20260901-20260930.pdf ├── 02_口径/ │ ├── 口径卡.md │ └── 实质答复判定样例.md ├── 03_加工表/ │ ├── 待答复事项_明细.xlsx │ └── 分组结果_按问题类型.xlsx ├── 04_长尾归因/ │ └── 超时事项_逐条说明.md └── 05_结论/ ├── 本期结论_带口径.md └── 待进一步看的点.md

两个地方值得单独留意。02 这一层不能省，它是所有数字的解释器，缺了它，第三层和第五层都没法被别人复核。04 这一层最容易偷懒，但长尾归因才是这份分析真正的产出——平均值告诉你整体还行，长尾告诉你下一步该动哪里。

十五、常见问题

问：记录导不全，算出来的数还准吗？

答：不全的时候，绝对数值不能用，但结构性的结论仍然有参考价值——比如"三件超时的都发生在转派之后"这个规律，不会因为少了几条消息就消失。前提是你要在结论里写明范围，别拿部分样本去说整体。

问：一定要剔除周末吗？

答：不一定。两种口径都能用，关键是写清楚、全篇统一。如果业务本身周末也在跑，那就别剔，但要在结论里说明。

问：只有聊天记录，没有工单系统，做得出来吗？

答：做得出来。上面那套流程不需要工单系统，需要的只是一张能一行一件事的表，和一份写得清楚的口径。数据粗糙一点没关系，口径清楚就行。

问：这个结果能不能用来做工作表现的依据？

答：不建议。这类数据能说明流程卡在哪一环，说明不了某个人的工作状态——分工不同、接的单子难度不同、样本又小。用它来改进流程是有价值的，用它来给人下判断，误差会很大。

问：多久做一次比较合适？

答：跟着业务节奏走。有明确服务承诺的，一个月一次；项目制的，一个项目结束做一次；没有强制要求的，一个季度一次就够。做得太密，样本小、噪音大，反而看不出东西。

结语

回到开头那两张纸。它们后来被放在了一起：统计表下面补了一行口径，原话旁边标了事项编号。会议室里那场争论没有继续，因为大家终于在看同一件事——不是"到底快还是慢"，而是"那三件为什么慢了三十小时"。

聊天记录导出之后能做的事情很多，但它不会自动变成结论。中间隔着几个必须自己做的决定：从哪一刻起算、夜里怎么处理、什么才算答复、结论写到哪一层为止。

把这些决定写下来，那份表才站得住。写不下来，它就只是一张看起来很专业的纸——而一张看起来很专业的纸，往往比没有纸更危险。