摘要

银行网点收集到的低分，往往同时涉及等待、材料、柜面解释和线上操作。要判断问题发生在哪里，需要把一次服务作为分析单元，关联反馈、业务类型、网点和时段，再用 BI 展示分布与变化，让数据分析 Agent 辅助组织问题和证据。本文围绕数据粒度、关联模型、分层看板与分析验证，说明如何建立一条可追溯的分析链路。

一、为什么一个网点总分解释不了服务问题

同样一句“办理太慢”，可能来自排队等待，也可能来自材料补交、系统处理中断或客户未理解后续步骤。如果把这些评价合并成一个月度均分，管理者只能看到分数变化，难以决定应该调整排班、完善材料清单，还是改进办理后的解释。

另一个问题是服务结构不同。业务简单、办理时间短的网点，与承担较多复杂业务的网点，评价背景可能不同。直接比较总分，容易把业务构成差异解释成服务能力差异。

因此，分析首先要回答三个问题：评价针对哪次服务、这次服务经历了什么、比较对象是否具有相近背景。AI 对文本的总结，需要建立在这些信息之上。

二、以一次服务为粒度建立数据模型

可以将数据分成服务记录、反馈记录和网点属性三部分。下面是通用设计示例，字段名用于说明数据关系，不代表某个产品的固定接口。

service_id标识一次服务，response_id标识一份答卷，两者不能混用。同一客户可能多次到店，同一次到店也可能办理多项业务，仅用客户编号关联，会把不同服务混在一起。

数据关联前需要检查键是否唯一。假设一条服务记录匹配到三条流程明细，直接关联反馈后再计数，原本一份答卷可能变成三行。正确处理方式是先把流程明细汇总到约定粒度，再与反馈关联；多条原因标签也应单独统计，避免把标签行数当作答卷数。

体验家 XMPlus 的多表联合支持通过相同的唯一字段匹配数据，数据看板则基于数据集进行分析和可视化。落地时仍需由项目方明确服务标识、字段来源和粒度，不能把“能够关联”理解为业务数据已经自动准备完整。

三、先固定指标口径，再解释分数变化

满意度可以使用均分，也可以使用满意率，但必须固定题目、量表和有效回答规则。若采用五级量表，并约定四分、五分属于满意，则：

满意率＝四分与五分的有效回答数÷该题有效回答数×100%

未回答该题的记录不计入分母，也不能补成零分。若问的是推荐意愿，则应按 NPS 的推荐者、被动者和贬损者分类计算，不能用推荐题均分替代 NPS，更不能从评论情绪推算 NPS。

网点比较应同步显示样本量、业务结构和采集渠道。某网点本月的复杂业务占比上升，即使每类业务的满意率都未变化，总体满意率仍可能下降。可先比较相同业务，再观察总体构成，不急于对网点排名。

等待时长也需要固定起止点。例如“取号至开始办理”与“预约至办理结束”衡量的是不同过程。客户认为等待过长，是主观体验；系统记录的等待分钟数，是客观过程，两者可以关联观察，但不能互相替代。

四、按总行、分行和网点组织分析视图

分层看板的意义，是让不同岗位看到与其行动范围匹配的信息。

例如，管理层发现“材料说明不清”反馈增加，可以先按业务类型拆分，再检查是否集中在某类材料要求或某段时间。网点负责人则需要知道具体客户遇到了什么，才能安排核实和解释。

筛选视图与访问权限需要分别配置。隐藏某个筛选选项，不等于限制了数据访问；可见明细、导出范围与 Agent 调用范围，都需要对应岗位权限进行验证。

五、数据分析 Agent 如何参与证据链

Agent 适合将自然语言问题拆成分析步骤，例如：“近四周哪些网点的等待体验变化较大？请按业务类型分组，列出样本量，并说明还需要核实什么。”

一个可审查的工作流程可以分为：确认题目与时间范围、选择数据集、检查缺失与重复、计算分组指标、提取原始反馈、输出判断与待验证事项。指标结果与文本解释应分开保存，方便发现计算错误和推断过度。

体验家 MCP 提供问卷信息查询、问卷列表获取和答卷详情读取等能力，可连接 AI 客户端开展反馈分析。这里的 Agent 是调用数据并执行分析任务的工作方式，不意味着它天然知道银行业务规则，也不意味着有权读取所有业务系统。

输出结果至少应保留时间范围、过滤条件、样本量、指标口径和可回查的记录标识。对银行场景，还应控制发送给分析工具的字段和反馈原文，避免将与分析无关的账户、交易或身份信息放入上下文。

六、以等待体验为例完成一次分析

以下为通用设计示例。假设某网点在午间出现较多等待低分，可以先建立“网点—业务类型—时段—等待区间”的分析切片，观察低分是否集中在特定组合。

第一步，确认这些评价针对等待过程，而非整体办理结果。第二步，核对取号与开始办理的时间记录，剔除无法确定起止点的样本。第三步，在同类业务内观察等待区间与评分分布，同时回看低分原文，区分等待过长、叫号不清和多次转介等原因。

若反馈集中于“转介后重新排队”，改善方向可能是衔接流程；若主要集中于特定时段的等待，才进一步核查服务资源和到店需求。两类问题都表现为低分，但需要不同的行动。

调整后应继续使用相同题目与口径，并检查业务构成是否变化。前后分数改善可以提示效果，却不能单独证明改善由某项措施造成。

七、验证与局限

上线分析前，可以用一组人工核对过的样本验证：重复服务记录是否造成答卷放大、缺失评分是否错误进入分母、网点调整后历史记录是否被重新归属，以及 Agent 的数字是否能回到原始数据。

只有愿意评价的人才会形成样本；只在成功办理后发问，还可能遗漏中途退出和未能完成业务的客户。分析时应记录这些覆盖限制。对于样本较少的网点，宜展示分布和观察状态，避免将偶然波动写成稳定结论。

这套分析链路的价值，在于将“网点分数下降”拆成可以核实的问题，并让每个判断都能回到具体服务与反馈。

八、FAQ

Q1：银行网点可以直接按满意度排名吗？

需要先检查业务类型、调查时点、渠道和样本量是否可比。总分适合提示问题，排名需要更充分的比较条件。

Q2：Agent 能直接确定低分根因吗？

它可以整理关联和提出待验证解释。根因判断还需要业务记录、流程核查或进一步研究，不能把相关性写成因果关系。

Q3：为什么既要 service_id，又要客户标识？

前者区分一次服务，后者关联同一客户的多次经历。两者解决不同问题，应按分析目的分别使用。