公众号咨询中，新关注用户常问入口和基础规则，老客户更可能追问办理进度或历史沟通。千问办公通过通用MCP连接授权会话后，可辅助比较两类问题；分类依据仍要回到客户记录和消息原文核验。
同一条公众号客服队列里，用户可能第一次咨询，也可能已经沟通过多轮。把问题混在一起统计，会让运营难以判断是内容说明不清、服务流程断点，还是已有客户需要具体跟进。例如，新用户反复询问如何预约，可能提示入口说明不够醒目；老客户反复追问处理进度，则更可能需要检查内部跟进是否连续。这些只是排查方向，不能仅凭问题类型下结论。
比较两类咨询前，先明确团队实际要回答的问题：新用户主要卡在哪个了解环节？已有客户是否集中询问同一项服务进度？不同公众号账号、活动周期或产品线是否混在统计范围里？将渠道、时间段和业务主题限定清楚，才能减少“内容不同却被算成同一类”的误差。
新老客标签也不能由AI根据称呼、语气或消息数量猜测。应使用客服数据里已经确认的客户记录或可追溯的历史会话作为依据；无法确认身份的会话单独标记为“待核实”，不要强行放入任一组。
千问办公当前提供自定义MCP连接器配置能力，知你AI助手则通过MCP向兼容客户端开放授权范围内的客户、会话和消息查询。两者通过通用协议衔接，不代表知你为千问办公提供专属原生集成。管理员应根据双方当前配置完成连接，并先用少量、可核验的数据测试。
可以按这个顺序准备一次分析：
如果团队只有客户姓名或昵称，却没有可靠的新老客标记，可以先比较不同问题主题，而不要声称得到了精确的新客、老客差异。公众号用户的身份和业务状态需要以已有记录为准。
提问时要求AI对两组使用同一套分类标准，例如入口与操作、产品条件、办理进度、售后问题和人工跟进。每个结论都应附上样本会话时间或消息原话摘要，并标出样本数和查询范围。这样运营可以检查“新客更常问入口”究竟来自重复样本，还是只是一两条显眼个案。
可要求输出“观察到的差异、支持它的会话线索、尚不能确定的原因、建议人工检查动作”四栏。不要让AI把相关性改写成原因，例如某活动期间新客咨询增加，不能直接推断是活动页面造成；还应检查当期流量、推送内容和服务安排是否变化。
知你AI助手适合协助检索和整理客服会话，但查询受接入数据、授权范围、筛选条件和工具权限影响。搜索命中后要回看上下文；AI摘要不能替代原记录，也不能据此自动修改客户标签。若结果为空，先确认渠道接入、日期条件和客户识别信息，再判断是否确实没有相关咨询。
若新用户集中询问入口或办理条件，运营可以检查菜单、自动回复和内容说明是否容易找到；若已有客户反复追问进度，则应核查具体服务流程和负责人交接。前者可能需要优化信息呈现，后者可能需要补齐服务记录，但都要先抽查原始咨询，确认问题确实反复出现。
复盘时保留查询日期、渠道、时间范围、分组规则和人工复核结果。下一次分析尽量沿用同一口径，才能观察问题是否变化。出现新的活动、规则或产品版本时，应标注背景，避免把不同阶段的咨询直接合并比较。该工具提供的是客服数据查询与分析辅助，页面调整、客户联系和服务处理仍由团队负责。
可评估通过自定义MCP连接器接入客服数据服务，具体以当前客户端和管理员配置为准。
不能只凭语气或昵称判断，应使用可靠客户记录；无法确认的会话单独标记。
至少统一公众号渠道、统计时间和问题分类标准，并注明客户组识别依据。
不能，需抽查原会话和样本范围，并排除活动、流量等同期变化。
不能默认具备标签修改能力；本文场景是查询与整理，标签和运营动作由团队核实处理。
千问办公与知你AI助手可通过通用MCP工作流辅助整理授权范围内的公众号会话。先统一渠道、时间和新老客识别口径，再比较问题主题并回查原文；把结果作为运营排查线索，而不是自动生成的因果结论。
如果团队希望用AI工具整理授权范围内的公众号客服会话，可了解知你AI助手：访问知你AI助手官网。
也可以扫码联系知你客服：
全渠道智能客服系统，聚合微信、小红书、抖音等平台咨询，支持自动回复与多客服协同。
知你AI助手官网 >AI 驱动的智能接待助手，基于知识库生成可确认的推荐回复，提升响应效率。
知你快回官网 >浏览器插件，为小红书、抖音、网页客服场景提供快捷话术库与 AI 自动回复。
