月底核对绩效的那一天争论总是从同一个问题开始自动回复先接住、后来人工接手的那批会话业绩到底算谁的。算给人工团队觉得机器白上了算给机器客服觉得自己在给系统擦屁股。这篇把归属口径、提成基数和防内耗规则三件事说清楚口径定下来之后当月不再改。## 三种归属口径先选一种写下来**全归人工。**机器接住的会话也计入接待人。优点是简单适合人少、AI 只做兜底的团队代价是个人贡献模糊谁勤谁懒看不出来。**按实际接手算。**只有人工真实介入的会话才计入个人量机器独立完成的会话不计。这是多数团队用得比较顺的一种口径清楚也解释了客服在忙什么。**分段计分。**机器接住的算基础分人工接手的算进阶分两类分值不同。适合会话量大、分工细的团队缺点是规则复杂考核表要先做出来。不管选哪种三件事必须写进制度口径名称、统计范围、生效时间。口径一改当月的数据就失去可比性所以定了就撑满一个考核周期。**口径要能被人讲出来。找一位客服口头复述一遍规则他能讲明白才说明这套口径是可执行的。## 提成基数怎么定成交归因先定规则。**谁最后促成的成交提成算给谁。机器先应答、人工后促成的算人工的机器独立完成、买家直接下单的算进团队池。**归因窗口写明白。**咨询之后多久内的成交算数需要写清比如「咨询后一周内下单计入」。窗口不写月底就会有扯不清的账。**团队池按参与度分。**机器带来的成交提成进团队池按当月每人的实际接手量和问题复杂度二次分配而不是简单平分。平分的结果是干多干少一个样内耗就从这里开始。**别把 AI 做成降薪的理由。**同样的提成比例用 AI 之后人均产出变高是效率的红利不该直接按比例下调客单价。要调也要提前一个周期说明。**提成表先做样例。用上个月的数据按新口径重算一遍看每个人各拿多少差异过大的口径不要急着上线。## 数据从哪来三个数字先对齐接待量。**按会话算还是按消息条数算全团队要统一。掺了两种口径的报表对比就是错的。**自动回复触发量。**机器独立完成、没有人工介入的会话数这部分要能单独拉出来否则「AI 干了多少」永远说不清。**转人工量。人工真正接手的会话数也就是分配给个人的那部分。这个数字要能追溯到具体的人工坐席。三个数字每月固定一天核对做成一张对账表表头标注统计范围与时间区间三个月后回看不会认错数字。客服对数据有疑问的在这个窗口提改完再定稿。事后补提的一律进下月避免月底反复改表。用这套带统计与日志的本地方案触发量、转人工量能从后台直接读出来绩效核算不用靠人工估算争议会少很多。## 避免内耗的五条规则规则公开。**口径、数据来源、计算方式全员可见。看不见的规则天然会被往坏处想。**数据可申诉。**留一个固定的对账窗口允许客服提异议。申诉有回应制度才有人信。**不搞零和。**AI 省下来的时间用来处理复杂问题和售后争议不是用来减人的理由。把这一点讲在明处团队才不会抵制工具。**把 AI 的定位写进制度初版。**它是分担重复问答的同事不是盯着每个人打卡的监工。定位没在开头讲清楚后面每次谈绩效都要重新解释一遍。**给新口径设一个观察期。**上线后按月回顾一次口径不合适就调整但调整要提前一个考核周期公布不能月底突袭。## 参考文章- 微信 FAQ 自动应答的搭建方法- 自动回复延迟的设计取舍