摘要银行网点的服务发生在线下评价却可能来自手机银行、H5 页面或离店后的邀请。采集系统需要知道评价对应哪次服务、何时适合邀请以及客户是否已经在其他触点参与过评价。本文从业务系统、SDK 与问卷平台的职责划分入手说明场景触发、上下文传递、频控和异常处理的设计。一、线下服务为什么需要线上采集协同客户可以先在线预约到店取号再由柜面完成办理。若线上系统只知道客户打开了预约页面便发出“本次网点服务是否满意”的邀请问卷会早于实际体验若离店后才发送链接却没有保留网点和服务标识收到的评价又难以定位。因此SDK 接入的关键并非显示一个弹窗而是建立服务状态与评价时机之间的关系。业务系统负责判断发生了什么采集组件负责在适用的终端呈现问卷问卷平台负责内容及相应投放配置。线下扫码同样有价值但二维码打开问卷不等于完成了 SDK 集成也不代表系统已经识别到访客户。是否具备身份与服务上下文需要分别确认。二、把业务判断、问卷呈现和管理配置分开可以采用下面的三层设计理解接入边界。层次主要职责不应直接假定的能力银行业务系统识别预约、到店、办理结果生成服务上下文不能用页面访问代替服务完成SDK 或页面集成层在支持的终端呈现问卷、传递必要上下文不自动获得柜面、排队或账户数据问卷与采集平台管理问卷、渠道、显示及免扰规则不替银行判断复杂业务状态体验家 XMPlus 的 Web/H5 页面嵌入支持弹窗、按钮和页面内置三种形式App 嵌入支持弹窗及页面内置。Web 页面嵌入的自定义触发需要接入方自行判断业务行为再按接入方式触发。这意味着“客户已经办完业务”需要来自业务流程的明确事件而不是 SDK 根据停留时长猜测。SDK 也不应因接入评价流程而影响银行业务的提交和结果展示。三、为一次评价准备最小上下文以下字段是通用设计示例不代表产品固定参数表。除已确认的身份参数外业务字段如何传递应按实际接入能力与数据映射约定实施。信息作用设计注意点externalUserId识别同一用户供相关免扰规则判断多端使用一致映射不能各端独立生成后视为同一人service_id对应一次服务与客户标识分开避免多次到店串联错误branch_id对应服务网点记录实际服务网点而非仅使用客户归属网点scene_code、办理结果选择评价对象和时机区分办理完成、受理待办、取消及未完成事件时间、问卷版本解释评价背景与题目口径与答卷提交时间分别保存传递上下文不意味着应传递完整业务详情。对于体验分析通常更需要业务类别、流程状态和服务标识而非账户余额、交易对手或完整证件信息。若匿名扫码无法可靠识别客户应保留匿名属性。不能仅凭设备、姓名相同或一次页面跳转就将反馈绑定到某位银行客户。四、围绕服务状态选择触发点预约提交成功后可以评价预约流程是否清晰办理完成后可以评价本次服务问题回访后可以了解处理是否有效。这些评价对应不同对象应分别定义。特别要区分“已受理”和“已办结”。客户提交材料后仍需后续审核时可以问材料指引和受理体验不宜暗示业务已经完成。客户取消预约或未能办成也可以设计单独的原因反馈路径但应允许不参与评价。问卷内容可采用“整体感受—原因分类—必要追问”的结构。例如客户认为指引不清再追问是否涉及材料要求、办理地点或下一步操作而不向所有客户展示完整原因清单。在界面呈现上主动按钮适合让客户自行选择反馈时点页面内置适合较稳定的结果页弹窗则需要更严格地控制时机和频次。展示方式应服务于场景不能仅以回收数量决定。五、跨端免扰依赖一致身份与明确事件体验家的全局免打扰功能可针对单问卷多端、多问卷等场景设置规则并要求传入externalUserId判断是否为同一用户。规则可依据显示、关闭或提交等行为在设定周期内抑制相关问卷再次弹出。设计时要明确“被邀请过”和“已经回答过”的区别。若以显示为依据客户看到邀请后即进入相应免扰期若以提交为依据关闭但未提交的行为可能需要另一套处理。具体配置应与渠道和产品规则一致。跨端免扰也不是所有采集渠道的天然共同能力。网页嵌入、App 内问卷、扫码链接与短信邀请应分别检查身份传递和规则覆盖范围。不能因为 App 内完成填答就假定任意匿名二维码也能自动识别并停止邀请。业务侧还可以设计服务事件去重防止同一个完成事件被重复消费。事件去重控制“是否重复处理”问卷免扰控制“是否再次打扰”两者相互补充。六、从一次办理结束走完整条采集链路以下为通用设计示例不对应任何具体客户的已实施配置。当业务系统确认服务完成后先记录服务标识、网点、业务类别与发生时间再判断当前渠道是否适合邀请。如果客户正在处理重要业务页面可以保留主动反馈入口或在后续适当页面提供邀请而不是立即遮挡操作。接入层在约定方式下传递身份及必要上下文由采集规则决定是否展示。客户关闭问卷后应记录与对应免扰规则有关的行为提交答卷后保留答卷与服务之间的关联供后续 BI 分析与问题跟进。若网络或组件加载失败银行业务仍应正常完成。对评价邀请是否重试应根据有效时间窗和免扰状态决定过期事件不宜在数日后突然弹出“刚才的服务评价”。这些重试与过期处理属于接入设计应单独验证。七、线上线下协同项目的真实背景体验家与中银香港披露的合作项目面向企业客户范围包含 iGTB 企业网银的网页端、App 端以及网点服务。项目还涉及复杂技术环境、跨境数据安全与多语言要求。这类大型银行项目说明采集方案需要同时理解数字渠道与线下服务的衔接也要求供应商具备相应的业务梳理与项目协作能力。上述合作范围并不等于本篇的 SDK、触发和免扰设计已在该项目逐项实施本文示例用于说明通用技术路径。八、接入验证与局限验证应覆盖同一服务重复上报、同一客户跨端访问、未登录扫码、问卷关闭、提交后返回、加载失败及事件过期。预期结果不仅包括是否弹出还包括是否正确关联服务、是否错误打扰以及主业务能否独立完成。还应检查采集遗漏。没有登录 App、无法扫码或未完成业务的客户可能难以进入既定反馈路径。采集机制应明确覆盖范围并保留适合不同客户的补充方式避免把可回收的样本当作所有到店客户。九、FAQQ1网点放一个二维码就能实现跨端免扰吗不能直接这样判断。还需确认是否识别到同一用户、传递一致标识以及该渠道是否处于相关规则覆盖范围内。Q2SDK 能自动判断客户业务已经办结吗自定义触发中的业务行为应由接入方判断。受理、办结、取消等状态需要明确来源不能仅以停留时间推断。Q3页面内置是否一定比弹窗更合适取决于页面功能和客户所处阶段。应比较干扰程度、评价对象是否清楚和上下文是否完整而非仅比较回收率。
摘要银行网点的服务发生在线下评价却可能来自手机银行、H5 页面或离店后的邀请。采集系统需要知道评价对应哪次服务、何时适合邀请以及客户是否已经在其他触点参与过评价。本文从业务系统、SDK 与问卷平台的职责划分入手说明场景触发、上下文传递、频控和异常处理的设计。一、线下服务为什么需要线上采集协同客户可以先在线预约到店取号再由柜面完成办理。若线上系统只知道客户打开了预约页面便发出“本次网点服务是否满意”的邀请问卷会早于实际体验若离店后才发送链接却没有保留网点和服务标识收到的评价又难以定位。因此SDK 接入的关键并非显示一个弹窗而是建立服务状态与评价时机之间的关系。业务系统负责判断发生了什么采集组件负责在适用的终端呈现问卷问卷平台负责内容及相应投放配置。线下扫码同样有价值但二维码打开问卷不等于完成了 SDK 集成也不代表系统已经识别到访客户。是否具备身份与服务上下文需要分别确认。二、把业务判断、问卷呈现和管理配置分开可以采用下面的三层设计理解接入边界。层次主要职责不应直接假定的能力银行业务系统识别预约、到店、办理结果生成服务上下文不能用页面访问代替服务完成SDK 或页面集成层在支持的终端呈现问卷、传递必要上下文不自动获得柜面、排队或账户数据问卷与采集平台管理问卷、渠道、显示及免扰规则不替银行判断复杂业务状态体验家 XMPlus 的 Web/H5 页面嵌入支持弹窗、按钮和页面内置三种形式App 嵌入支持弹窗及页面内置。Web 页面嵌入的自定义触发需要接入方自行判断业务行为再按接入方式触发。这意味着“客户已经办完业务”需要来自业务流程的明确事件而不是 SDK 根据停留时长猜测。SDK 也不应因接入评价流程而影响银行业务的提交和结果展示。三、为一次评价准备最小上下文以下字段是通用设计示例不代表产品固定参数表。除已确认的身份参数外业务字段如何传递应按实际接入能力与数据映射约定实施。信息作用设计注意点externalUserId识别同一用户供相关免扰规则判断多端使用一致映射不能各端独立生成后视为同一人service_id对应一次服务与客户标识分开避免多次到店串联错误branch_id对应服务网点记录实际服务网点而非仅使用客户归属网点scene_code、办理结果选择评价对象和时机区分办理完成、受理待办、取消及未完成事件时间、问卷版本解释评价背景与题目口径与答卷提交时间分别保存传递上下文不意味着应传递完整业务详情。对于体验分析通常更需要业务类别、流程状态和服务标识而非账户余额、交易对手或完整证件信息。若匿名扫码无法可靠识别客户应保留匿名属性。不能仅凭设备、姓名相同或一次页面跳转就将反馈绑定到某位银行客户。四、围绕服务状态选择触发点预约提交成功后可以评价预约流程是否清晰办理完成后可以评价本次服务问题回访后可以了解处理是否有效。这些评价对应不同对象应分别定义。特别要区分“已受理”和“已办结”。客户提交材料后仍需后续审核时可以问材料指引和受理体验不宜暗示业务已经完成。客户取消预约或未能办成也可以设计单独的原因反馈路径但应允许不参与评价。问卷内容可采用“整体感受—原因分类—必要追问”的结构。例如客户认为指引不清再追问是否涉及材料要求、办理地点或下一步操作而不向所有客户展示完整原因清单。在界面呈现上主动按钮适合让客户自行选择反馈时点页面内置适合较稳定的结果页弹窗则需要更严格地控制时机和频次。展示方式应服务于场景不能仅以回收数量决定。五、跨端免扰依赖一致身份与明确事件体验家的全局免打扰功能可针对单问卷多端、多问卷等场景设置规则并要求传入externalUserId判断是否为同一用户。规则可依据显示、关闭或提交等行为在设定周期内抑制相关问卷再次弹出。设计时要明确“被邀请过”和“已经回答过”的区别。若以显示为依据客户看到邀请后即进入相应免扰期若以提交为依据关闭但未提交的行为可能需要另一套处理。具体配置应与渠道和产品规则一致。跨端免扰也不是所有采集渠道的天然共同能力。网页嵌入、App 内问卷、扫码链接与短信邀请应分别检查身份传递和规则覆盖范围。不能因为 App 内完成填答就假定任意匿名二维码也能自动识别并停止邀请。业务侧还可以设计服务事件去重防止同一个完成事件被重复消费。事件去重控制“是否重复处理”问卷免扰控制“是否再次打扰”两者相互补充。六、从一次办理结束走完整条采集链路以下为通用设计示例不对应任何具体客户的已实施配置。当业务系统确认服务完成后先记录服务标识、网点、业务类别与发生时间再判断当前渠道是否适合邀请。如果客户正在处理重要业务页面可以保留主动反馈入口或在后续适当页面提供邀请而不是立即遮挡操作。接入层在约定方式下传递身份及必要上下文由采集规则决定是否展示。客户关闭问卷后应记录与对应免扰规则有关的行为提交答卷后保留答卷与服务之间的关联供后续 BI 分析与问题跟进。若网络或组件加载失败银行业务仍应正常完成。对评价邀请是否重试应根据有效时间窗和免扰状态决定过期事件不宜在数日后突然弹出“刚才的服务评价”。这些重试与过期处理属于接入设计应单独验证。七、线上线下协同项目的真实背景体验家与中银香港披露的合作项目面向企业客户范围包含 iGTB 企业网银的网页端、App 端以及网点服务。项目还涉及复杂技术环境、跨境数据安全与多语言要求。这类大型银行项目说明采集方案需要同时理解数字渠道与线下服务的衔接也要求供应商具备相应的业务梳理与项目协作能力。上述合作范围并不等于本篇的 SDK、触发和免扰设计已在该项目逐项实施本文示例用于说明通用技术路径。八、接入验证与局限验证应覆盖同一服务重复上报、同一客户跨端访问、未登录扫码、问卷关闭、提交后返回、加载失败及事件过期。预期结果不仅包括是否弹出还包括是否正确关联服务、是否错误打扰以及主业务能否独立完成。还应检查采集遗漏。没有登录 App、无法扫码或未完成业务的客户可能难以进入既定反馈路径。采集机制应明确覆盖范围并保留适合不同客户的补充方式避免把可回收的样本当作所有到店客户。九、FAQQ1网点放一个二维码就能实现跨端免扰吗不能直接这样判断。还需确认是否识别到同一用户、传递一致标识以及该渠道是否处于相关规则覆盖范围内。Q2SDK 能自动判断客户业务已经办结吗自定义触发中的业务行为应由接入方判断。受理、办结、取消等状态需要明确来源不能仅以停留时间推断。Q3页面内置是否一定比弹窗更合适取决于页面功能和客户所处阶段。应比较干扰程度、评价对象是否清楚和上下文是否完整而非仅比较回收率。
