微信小游戏客服帕累托分析，先统一一件问题怎样计数，再按类别件数降序排列，计算每类与累计占比。WorkBuddy可用AI整理授权会话的来源明细与汇总草稿；结果用于看本轮记录集中在哪里，不预设二八规律，也不能把高频直接当成严重或必须先修。
运营收到一张主题清单：入口、活动、账号、进度。知道入口最多，并不能说明只处理入口就能覆盖大部分咨询；几类数量很接近时，选第一类与同时检查前三类的工作范围不同。
ASQ的帕累托图说明采用按数值降序排列的类别，并可计算累计比例。应用到客服，先把分类、度量和时间窗口写清，再计算分布；这个方法帮助解释数据集中度，不替代对问题后果的判断。
本轮只回答一个问题：在已经核过的客服问题记录里，头部几类合计占多少？不要把频数、工时和损失金额混进同一列，也不为凑一个八成结果临时合并类别。
知你AI助手可查询授权客户、历史会话和消息。先限定小游戏渠道和观察时段，读取相关完整沟通，为每件纳入问题保留来源、核心诉求与归类理由。一次关键词命中不直接当完整问题清单，还需确认查询条件与分页范围。
WorkBuddy按当前通用MCP配置完成授权后，可提出：“按我确认的本轮规则整理问题明细。同一玩家围绕同一诉求连续追问合并，明确不同诉求分开；每件对应一个类别。先列来源和归类理由，无法归类的单列给我确认，待明细核过后再汇总降序与累计占比。”
这里统计问题件数，不是玩家人数。一个玩家有两件不同问题，可分别计入；同一件问题的十条追问仍是一件。边界例子由主管统一，规则固定后再算，避免模型一边归类一边改变分母。
下图沿用MCP连接后台布局，明细及计算在AI客户端准备，不是产品内置帕累托报表。
以下类别、件数与比例全部虚拟。假定本轮明细已经人工核过，最终纳入50件问题，每件只归一个类别；其他无法确认的记录不混入本表，报告另写范围。分类描述的是求助内容，不表示已经查明故障原因。
| 类别 | 件数 | 本类占比 | 累计占比 |
|---|---|---|---|
| 入口位置说明 | 20 | 40% | 40% |
| 活动条件解释 | 12 | 24% | 64% |
| 账号切换求助 | 8 | 16% | 80% |
| 处理进度询问 | 6 | 12% | 92% |
| 其他已核类别 | 4 | 8% | 100% |
先验算20+12+8+6+4=50；每类占比用本类件数除以50。前三类累计为40件，40÷50=80%，所以可以说本轮前三类涵盖八成已纳入问题记录。
可用分析结论：“本轮50件记录中，入口类占40%；再纳入活动条件与账号切换，累计覆盖80%。若本轮目标是检查覆盖大部分记录的说明，可以分别复看这三类原话，确认是否存在可改内容。这个八成来自本次计数，不表示五类中的一类必然贡献八成，也不表示全部玩家有八成遇到问题。”
若只选第一类，实际覆盖是40%，不能为了体现聚焦就写成解决了大部分。下图是客户端核算流程示意，沿用虚拟数字；实际改进是否有效还需后续观察。
频数表说明从哪里开始复看能涵盖更多记录，不能证明补一段说明就会消除这些问题。先看原话是否确实指向同一缺口，再由对应岗位核实实际原因与可做动作。
低频但涉及明确权益或安全的个案仍按正式流程处理。知你AI助手帮助找回记录依据，WorkBuddy辅助计算；前后总量不同，比例变化要连同分母解释，不能把占比下降直接说成绝对数量减少。
不一定，按实际分布计算，不为了符合一个比例改动分类。
按预先确定的同一诉求规则合并，消息条数不直接当问题件数。
不是，这里分母是纳入的问题记录，不能替代全体玩家数据。
还要看后果、原因与资源，频数不能单独决定严重程度和排期。
同时比较实际件数、总量和口径，分母改变也会影响比例。
客服帕累托分析先做好明细，再计算类别件数、降序和累计比例。用能复算的结果说明一轮工作准备覆盖哪里，同时保留个案风险与业务核实，让问题统计成为具体讨论依据。
如果团队已经归纳出很多问题，却说不清一轮改进覆盖多少客服记录，可以了解知你AI助手官网，用AI整理授权会话的计数依据，再把问题分布做成可复算的分析表。
也可以扫码交流你的客服数据整理需求：
全渠道智能客服系统，聚合微信、小红书、抖音等平台咨询，支持自动回复与多客服协同。
知你AI助手官网 >AI 驱动的智能接待助手，基于知识库生成可确认的推荐回复，提升响应效率。
知你快回官网 >浏览器插件，为小红书、抖音、网页客服场景提供快捷话术库与 AI 自动回复。
