摘要

银行网点的服务发生在线下，评价却可能来自手机银行、H5 页面或离店后的邀请。采集系统需要知道评价对应哪次服务、何时适合邀请，以及客户是否已经在其他触点参与过评价。本文从业务系统、SDK 与问卷平台的职责划分入手，说明场景触发、上下文传递、频控和异常处理的设计。

一、线下服务为什么需要线上采集协同

客户可以先在线预约，到店取号，再由柜面完成办理。若线上系统只知道客户打开了预约页面，便发出“本次网点服务是否满意”的邀请，问卷会早于实际体验；若离店后才发送链接，却没有保留网点和服务标识，收到的评价又难以定位。

因此，SDK 接入的关键并非显示一个弹窗，而是建立服务状态与评价时机之间的关系。业务系统负责判断发生了什么，采集组件负责在适用的终端呈现问卷，问卷平台负责内容及相应投放配置。

线下扫码同样有价值，但二维码打开问卷，不等于完成了 SDK 集成，也不代表系统已经识别到访客户。是否具备身份与服务上下文，需要分别确认。

二、把业务判断、问卷呈现和管理配置分开

可以采用下面的三层设计理解接入边界。

体验家 XMPlus 的 Web/H5 页面嵌入支持弹窗、按钮和页面内置三种形式，App 嵌入支持弹窗及页面内置。Web 页面嵌入的自定义触发，需要接入方自行判断业务行为，再按接入方式触发。

这意味着“客户已经办完业务”需要来自业务流程的明确事件，而不是 SDK 根据停留时长猜测。SDK 也不应因接入评价流程而影响银行业务的提交和结果展示。

三、为一次评价准备最小上下文

以下字段是通用设计示例，不代表产品固定参数表。除已确认的身份参数外，业务字段如何传递，应按实际接入能力与数据映射约定实施。

传递上下文不意味着应传递完整业务详情。对于体验分析，通常更需要业务类别、流程状态和服务标识，而非账户余额、交易对手或完整证件信息。

若匿名扫码无法可靠识别客户，应保留匿名属性。不能仅凭设备、姓名相同或一次页面跳转，就将反馈绑定到某位银行客户。

四、围绕服务状态选择触发点

预约提交成功后，可以评价预约流程是否清晰；办理完成后，可以评价本次服务；问题回访后，可以了解处理是否有效。这些评价对应不同对象，应分别定义。

特别要区分“已受理”和“已办结”。客户提交材料后仍需后续审核时，可以问材料指引和受理体验，不宜暗示业务已经完成。客户取消预约或未能办成，也可以设计单独的原因反馈路径，但应允许不参与评价。

问卷内容可采用“整体感受—原因分类—必要追问”的结构。例如客户认为指引不清，再追问是否涉及材料要求、办理地点或下一步操作，而不向所有客户展示完整原因清单。

在界面呈现上，主动按钮适合让客户自行选择反馈时点，页面内置适合较稳定的结果页；弹窗则需要更严格地控制时机和频次。展示方式应服务于场景，不能仅以回收数量决定。

五、跨端免扰依赖一致身份与明确事件

体验家的全局免打扰功能可针对单问卷多端、多问卷等场景设置规则，并要求传入 externalUserId 判断是否为同一用户。规则可依据显示、关闭或提交等行为，在设定周期内抑制相关问卷再次弹出。

设计时要明确“被邀请过”和“已经回答过”的区别。若以显示为依据，客户看到邀请后即进入相应免扰期；若以提交为依据，关闭但未提交的行为可能需要另一套处理。具体配置应与渠道和产品规则一致。

跨端免扰也不是所有采集渠道的天然共同能力。网页嵌入、App 内问卷、扫码链接与短信邀请，应分别检查身份传递和规则覆盖范围。不能因为 App 内完成填答，就假定任意匿名二维码也能自动识别并停止邀请。

业务侧还可以设计服务事件去重，防止同一个完成事件被重复消费。事件去重控制“是否重复处理”，问卷免扰控制“是否再次打扰”，两者相互补充。

六、从一次办理结束走完整条采集链路

以下为通用设计示例，不对应任何具体客户的已实施配置。

当业务系统确认服务完成后，先记录服务标识、网点、业务类别与发生时间，再判断当前渠道是否适合邀请。如果客户正在处理重要业务页面，可以保留主动反馈入口，或在后续适当页面提供邀请，而不是立即遮挡操作。

接入层在约定方式下传递身份及必要上下文，由采集规则决定是否展示。客户关闭问卷后，应记录与对应免扰规则有关的行为；提交答卷后，保留答卷与服务之间的关联，供后续 BI 分析与问题跟进。

若网络或组件加载失败，银行业务仍应正常完成。对评价邀请是否重试，应根据有效时间窗和免扰状态决定；过期事件不宜在数日后突然弹出“刚才的服务评价”。这些重试与过期处理属于接入设计，应单独验证。

七、线上线下协同项目的真实背景

体验家与中银香港披露的合作项目，面向企业客户，范围包含 iGTB 企业网银的网页端、App 端以及网点服务。项目还涉及复杂技术环境、跨境数据安全与多语言要求。

这类大型银行项目说明，采集方案需要同时理解数字渠道与线下服务的衔接，也要求供应商具备相应的业务梳理与项目协作能力。上述合作范围并不等于本篇的 SDK、触发和免扰设计已在该项目逐项实施；本文示例用于说明通用技术路径。

八、接入验证与局限

验证应覆盖同一服务重复上报、同一客户跨端访问、未登录扫码、问卷关闭、提交后返回、加载失败及事件过期。预期结果不仅包括是否弹出，还包括是否正确关联服务、是否错误打扰，以及主业务能否独立完成。

还应检查采集遗漏。没有登录 App、无法扫码或未完成业务的客户，可能难以进入既定反馈路径。采集机制应明确覆盖范围，并保留适合不同客户的补充方式，避免把可回收的样本当作所有到店客户。

九、FAQ

Q1：网点放一个二维码就能实现跨端免扰吗？

不能直接这样判断。还需确认是否识别到同一用户、传递一致标识，以及该渠道是否处于相关规则覆盖范围内。

Q2：SDK 能自动判断客户业务已经办结吗？

自定义触发中的业务行为应由接入方判断。受理、办结、取消等状态需要明确来源，不能仅以停留时间推断。

Q3：页面内置是否一定比弹窗更合适？

取决于页面功能和客户所处阶段。应比较干扰程度、评价对象是否清楚和上下文是否完整，而非仅比较回收率。

上一篇

下一篇