H5客服求助率比较，要让求助人数与实际使用人数属于同一活动、同一周期和同一对象范围，再按人数去重计算。千问办公可用AI整理授权沟通中的求助记录；参与人数由业务方提供。先分清用户变多与求助比例上升，才知道该补人还是查体验。
活动咨询从二十人增加到三十人，接待压力确实变大；但如果同期参与人数也明显增加，仅看咨询人数不能判断流程变得更难。运营需要同时回答两个问题：本次要接待多少人，以及每批参与者中有多少人主动来求助。
本文采用一项明确的内部口径：指定活动周期内，已确认参与该活动且因使用问题主动咨询的去重人数，除以同周期实际参与人数。售前随便问问、其他活动的用户和客服单方面通知不进入分子。若团队另选报名人数作分母，就明确叫报名用户求助率，不能与实际参与口径混比。
同一个人连续发五条消息、隔天再追问同一问题，本例仍算一名求助者。计算前先确认：
知你AI助手可查询授权范围内的客户、历史会话和消息。团队提供获准使用的参与对象对应关系，限定H5渠道与活动周期，再让千问办公查找沟通中的实际求助。AI不能从客服记录中补出未联系过的参与者，更不能把渠道全部客户当成活动分母。
千问办公官方连接器说明支持自定义MCP服务。按当前连接方式完成授权后，可以提出：“以这份已核活动范围为准，整理主动提出使用问题的客户，保留原话、消息时间和对象对应依据。合并同一人的多次求助，其他活动及仅咨询购买条件的记录另列；身份不明和未读完的对象标待核。”
下图为MCP连接后台布局示意；求助率整理在AI客户端完成，不是产品内置的H5使用统计报表。
历史检索还需检查分页和实际覆盖。使用非空消息关键词时，当前说明限定最近半年；不应只搜一个“不会用”，就宣称找到全部求助。对选定对象读取必要上下文，再确认他问的是哪次活动、什么操作。
以下活动、人数和消息全部虚拟。假定团队已核齐两个可比周期的参与名单与授权沟通，身份对应完整，使用相同求助定义。
| 观察项目 | 甲期 | 乙期 |
|---|---|---|
| 实际参与人数 | 200 | 500 |
| 主动求助的去重人数 | 20 | 30 |
| 求助率 | 20÷200＝10% | 30÷500＝6% |
乙期多了十名求助者，人工接待量上升；求助率则从百分之十降到百分之六，降低四个百分点。两件事可以同时成立，既不能说客服不忙，也不能单凭求助人数增长认定体验恶化。
再看一个反例：若乙期参与人数仍是二百，求助者三十名，比例就是百分之十五，需要进一步检查求助主题是否集中在同一流程。两个算例的三十人相同，业务含义不同，差别就在分母。
示例客户-王先生先说“报名后找不到入口”，次日又问同一入口，计一名；示例客户-刘女士只问另一个活动的价格，不进入本活动分子。无法确认活动归属者先补核，不为了得到完整百分比随意算入或剔除。
下图为AI客户端辅助复核流程，全部原话与状态均为虚拟示例。
知你AI助手帮助找回沟通依据，千问办公辅助去重、分类与复算。接待负责人按绝对人数与事项难度安排资源；运营按高频主题检查入口、提示和规则说明。求助率下降，也可能伴随入口难找导致用户没有来问，仍要结合其他反馈验证。
结论写出分子、分母、周期与未覆盖项。参与名单拿不到、身份对应不完整或只读到部分消息时，先报告已核人数和问题线索，不输出全活动求助率。先挑一个数据来源明确的活动走通，再按同一口径持续观察。
那是每人消息量，不是本文按去重求助人数计算的求助率。
不能单独判断，还要核参与人数、求助主题及数据覆盖。
客服MCP不提供完整活动名单，参与人数和可靠对应关系需另行准备。
本文人数口径算一名，三个问题可另外计入事项分析。
不可以，先报告已核范围与缺项，补齐必要覆盖后再比较。
H5客服求助率先对应同一群体，再去重人数和复算比例。接待资源看实际负担，体验改进看求助主题；把分母来源与数据缺口写清，AI整理结果才便于运营使用。
如果你希望在日常AI工具里查询H5客服记录并复核业务问题，可以访问知你AI助手官网，了解与本文场景相关的产品能力。
也可以扫码交流你的客服与运营需求：
全渠道智能客服系统，聚合微信、小红书、抖音等平台咨询，支持自动回复与多客服协同。
知你AI助手官网 >AI 驱动的智能接待助手，基于知识库生成可确认的推荐回复，提升响应效率。
知你快回官网 >浏览器插件，为小红书、抖音、网页客服场景提供快捷话术库与 AI 自动回复。
