服务号模板消息发出后，运营和客服应只把已进入客服会话、且能由用户原话或已核实名单关联的咨询作为跟进线索。AI Agent可按授权数据整理问题、原话与待核事项；通知送达、阅读、办理结果和具体触发关系仍需从相应业务系统确认。
模板消息负责向符合条件的服务号用户发送通知；客服会话记录的是用户实际进入接待渠道后的沟通。两者有关联的前提，是团队能够凭用户明确提及的内容，或经核验的客户名单、时间和通知批次建立对应关系。只因为某段时间咨询变多，并不能证明这些咨询由某次模板消息引起。
因此，先定义本次要找的事项：用户是否不清楚通知中的办理条件、需要确认下一步、反馈链接或内容问题，还是提出了与通知无关的新需求。若消息中没有清楚提到通知，也没有可靠名单可核对，应把会话列为“来源未确认”，不要强行归入模板消息反馈。
开始查询前，建议由公众号运营提供最小的核对信息：
这一步是确定检查口径，不表示查询工具能读取公众号模板配置、送达回执或点击数据。发送记录、客户会话和办理状态来自不同数据源，分析时应分别标明。
知你AI助手可通过通用 MCP 能力，为兼容的 AI Agent 提供已授权的客户资料、历史会话和消息查询。WorkBuddy 官方文档说明可以添加自定义 MCP 服务；这表示客户端支持连接外部服务，不代表知你为 WorkBuddy 提供专属原生集成。实际可查内容仍取决于知你账号权限、服务号数据是否接入及查询条件。
查询时把任务说具体，例如：“在指定服务号和时间范围内，找出客户明确提到通知主题或办理事项的客服会话。按客户问题整理原话、消息时间、客服已说明的内容、仍需业务核实的字段；没有明确依据的标为未关联，不推断阅读、点击、办理或通知来源。”如果结果跨多页，应注明检索范围，并打开候选会话核对上下文，不把首批返回内容称为全部反馈。
下面的示意流程只展示如何从问题定位到人工核验；客户、账号和消息均为虚拟示例。
每条候选会话应保留能够回查的依据，而不只是模型归纳的一句话。可让 AI 按以下字段输出：
例如，用户问“提醒里说要补材料，具体还缺哪份”，可以整理为“材料要求待核，需运营确认适用条件”；不能据此断言用户已提交、通知已送达或事项未完成。若会话同时提到其他服务问题，应拆成独立事项，避免一条通知主题覆盖整段沟通。
示意清单中的客户、原话和数量均为虚拟内容；实际结论必须回到授权会话和业务记录复核。
正式处理前，运营应抽查不同问题类型的原始会话，检查消息时间、说话人、通知关联依据和客服答复是否一致。名单关联不完整、用户没有提及通知或多个通知同期发送时，应保留不确定状态；少量会话也不能代表所有收件人的反应。
确认后再决定由客服补充说明、由运营核对通知条件，还是把其他业务问题交给对应岗位。需要回访时，先确认客户身份、联系目的和最终文字，并按团队授权流程执行。知你AI助手适合帮助团队查找服务号沟通记录、整理明确问题和待核事项；它不能从会话中推算送达率、打开率或办理转化，也不会替负责人核销业务状态。
不能仅凭客服会话判断阅读状态，应查看公众号或业务系统提供的记录。
不能直接认定。需要用户表达或已核实名单等依据建立关联。
WorkBuddy支持自定义MCP连接；具体配置和授权需按双方当前说明完成。
不能。办理状态应由对应业务系统或责任岗位核验。
不可以。应注明筛选范围、分页情况和人工抽查结果。
服务号模板消息后的客服工作，应从用户实际发起的会话出发。用 AI Agent 找出明确的问题和原话，再核对通知关联及办理事实，最后由运营和客服安排下一步；不要把时间相关性当成触达结果。知你AI助手可以帮助整理授权沟通记录，业务判断仍由负责人完成。
如果团队需要从服务号客服会话中整理通知相关问题，可访问知你AI助手官网了解产品详情。
