1.1.1 银行业（以某全国性股份制商业银行为例）

银行领域根据具体业务不同，又可进一步细化成零售、对公以及信用卡三大核心场景。出于对客户反馈天然的敏感度，银行属于较早建立起完备的客户服务呼叫体系的领域。但正如前文所述，随着金融行业整体环境种种变迁，加之银行各业务场景对应不同目标客群、业务旅程的实际情况，仅仅只是“听”客户抱怨和投诉是远远不够的。如何更快、更精准地捕捉到顾客心声，同时做到及时反馈和改善，成为更契合数字化转型背景的选择。

由此，实现对客户体验动态化、数字化、可视化、长效化的监测和管理体系，成为当下银行业落地体验管理的基本诉求。以该银行零售业务场景为例：项目实施前，该银行以建立零售各类业务全流程的体验监测体系为目标，期望实现：

以常态化、多渠道的调研形式触达全量客户，
能对收集到的调研数据做智能分析与可视展现，
实现调研问卷内容与各内部指标相关联，
以内外部各项指标数据交叉验证客户痛点并给予优化方向。

基于上述预期最终达成客户体验监测、监测结果分析、旅程痛点识别、客户旅程优化，优化结果验证的完整闭环。

尽管项目期望十分“丰满”，但实际交付过程中遇到的困难却十分“骨感”，比如：

如何规划各业务旅程上线的先后顺序？

站在业务部门的角度，从0到1的构建数字化体验管理系统无疑会为阶段性的工作成果汇报中添上点睛一笔，但常规而言项目交付周期一般要4个月左右，如果批量上线，反而不利于项目整体做精、做深。

实施建议：针对于此，项目交付团队给出“组合上线”的建议，优先规划和部署拳头产品相关的体验管理体系，再逐步完成行内其他核心产品的相关上线规划，直到最终实现数字化体验管理体系覆盖行内全场景、全业务。

在“O+X”数据融合分析的过程中，应如何处理O-Data？

对银行来说，运营数据（O-Data）多取自核心业务系统中，如果按流水来计算，其体量庞大程度可想而知。也因此，银行专用的应用系统通常有算力集群要求（一般集群由上百台服务器组成），以此为银行提供算力服务、处理大量数据。

而相较于银行专用的应用系统，普通应用系统算力上常常只有几台服务器支撑，在进行运营数据（O-Data）与体验数据（X-Data）的融合分析时，大数据运算上可能面临瓶颈。

实施建议：行内算力平台将流水数据加工成指标后再给到CEM平台中进行BI可视化呈现。为了后期数据呈现精准，在项目初期就对数据的应用方式做出合理规划也十分有必要。

如何化解银行内部流程错综复杂对项目实施的影响？

相较于其他行业的体验项目落地，银行业首先是各类申请时间较长，其次由于网络环境相对复杂（一般以开发、办公、生产为主至少3个网络端且彼此分离），再加上有疫情等外界因素的交互影响，一项普通的定制开发需求正常只需1个月就能交付，在银行领域可能需要花费2-3倍时间。

而在该银行体验管理项目交付过程中，这类问题却很少实现，原因在于交付团队基于项目实施经验，为资源协调预先提供了一系列优化建议。

实施建议：首先是采用敏捷+瀑布的混合式迭代，需快则快，需标准则标准；其次是识别核心干系人，针对某些流程缓慢的里程碑节点在实施阶段申请绿色通道，做足沟通与风险管理，确保在项目的关键路径上不出现明显的延期。

在陆续解决项目实施阻碍后，项目高质效推进、最终顺利上线。如今，距离项目交付已经过去1年半，而数字化体验管理的诸多价值点也在该银行的持续实践中被印证，例如：

顾客体验数据回收率超出预期：日常回收率达到6%，高峰期回收率达7%，而业界平均水平还停留在2~3%。在兼顾免打扰的同时，全行全年客户投诉量仅为1例（投诉原因为系统应用层面问题），整体服务水准维持较高水平。
促进形成有效的客户体验监督与管理机制：随着该银行的数字化体验管理平台落地，对多源客户体验数据的有效感知与管理成效显著，体验管理成为行内重点战略之一。项目同时得到银保监和行内高管的认可。
以智能预警机制，缩短客户体验管理周期：借助体验管理平台预警模块，完成客户经理、产品和总行业务层的穿透和打通，实现客户心声实时传递，真正助力构建以客户为中心的服务体系，进一步优化行内整体客户体验水平，提升了银行内部问题从发现到解决的精准度和及时率。