网站客服评价下降，先比较业务类型与评价覆盖，再看同类咨询的服务表现。复杂售后占比增加，即使每类好评率都没变，总好评率也可能降低。负责人应把构成变化、真实体验问题和未评价样本分开核查，再决定改流程还是补接待资源。
团队上月主要回答购买入口和基础功能，本月开始承接更多退款争议与故障咨询。月底看到总好评率降低，直接要求所有客服加强话术，未必能解决实际问题：有可能某类服务确实变差，也可能复杂业务在评价中的份额增加，两种情况还可能同时存在。
第一步固定指标定义。好评率使用好评数除以有效评价数；没有提交评价的人，不自动计入好评或差评。再统一前后时间范围、服务范围和评价分类。邀请对象发生变化，也要记录，否则同一个指标名称下面可能已经换了一批人。
知你客服的统计入口包含客服评价与评价反馈，可查看好评、中评、差评及邀请等信息，帮助团队先对应原始数量。业务场景的归类与下面的构成计算，需要负责人另外整理核对，不是后台自动生成一张归因报表。
下图为实际统计入口的布局示意，数值全部虚拟。
假设两个相同长度周期内，团队已核齐下列有效评价，并按同一标准将会话分成基础咨询和复杂售后。表中人数与业务均为虚拟，仅用于说明计算。
| 业务场景 | 上期好评数与评价数 | 本期好评数与评价数 |
|---|---|---|
| 基础咨询 | 72／80，90% | 18／20，90% |
| 复杂售后 | 12／20，60% | 48／80，60% |
| 合计 | 84／100，84% | 66／100，66% |
两类各自的好评率都没有变化，总体却从百分之八十四降到百分之六十六，下降十八个百分点。直接原因是本例有效评价里复杂售后的占比上升，不能据这个总数认定每位客服都退步了。
也不能反过来说服务没有问题。复杂售后长期只有六成好评，仍值得检查具体等待与处理体验；但要改进哪件事，需要读取反馈与原会话。这个算例只解释总率如何随构成变化，不提供行业水平或人员考核标准。
先看每类评价数量和好评率，再检查该类用户实际经历了什么。若基础咨询自身也下降，就回看答案是否过期、首次回应是否说明下一步；若复杂售后数量增加但处理标准未变，则需讨论资源、跨部门协查和进展沟通。
建议整理一份可复核清单：
知你客服支持按条件找回历史会话与消息上下文，主管可把反馈线索与实际接待对应。下图展示历史回看的界面布局，消息均为虚拟；示意图不代表系统会自动完成评价与会话的一一匹配。
若反馈只写了“不满意”，先核实可用背景，不替客户补出原因。涉及退款到账、故障修复等结果，仍要查看对应业务记录，不能把客服说正在处理当作已经完成。
对负责人汇报时，可以并列总好评率、分类好评率、各类评价数量及未覆盖情况。这样能看见客户实际评价的总体体验，也能判断变化是否来自业务构成；不能只挑有利的分组来解释下降。
样本很少的类别先列原数，不急着比较名次。如果某类本期只有两份评价，一份差评就会明显改变比例，应结合连续观察与原文复核。分类规则本期发生调整，也要按同一版本重核可比较记录，不能把改类造成的变化写成服务改善。
不一定，业务构成与评价覆盖变化也会影响总率，先看同类表现。
不能。未评价是未获得反馈，应与有效评价分开记录。
各类在评价中的份额变了，较低好评率类别占比增加就可能拉低总体。
仍要回看复杂售后的真实体验，确定等待、解释或处理环节的改进事项。
统计与会话提供核查依据，业务归类、原因判断和行动仍需负责人确认。
网站客服评价下降，先核定义与覆盖，再把业务构成和同类表现放在一起检查。保留总量，回读原话，用具体接待问题安排改进，才能避免只盯一个分数调整团队。
如果团队希望把网站服务评价与接待记录放在一起复核，可以访问知你客服官网，了解与本文场景相关的产品能力。
也可以扫码交流你的客服与运营需求：
全渠道智能客服系统，聚合微信、小红书、抖音等平台咨询，支持自动回复与多客服协同。
知你AI助手官网 >AI 驱动的智能接待助手，基于知识库生成可确认的推荐回复，提升响应效率。
知你快回官网 >浏览器插件，为小红书、抖音、网页客服场景提供快捷话术库与 AI 自动回复。
