如何构建B端长效体验监测系统？来看贝壳的实战案例！

在新业务启航准备出海乘风破浪时，业务方和产研同学就开始思考一个问题：产品体验做得足够好吗？

为了回答这个问题，用研同学在研发阶段就开始进行 demo 测试，试点运营时期进行反馈追踪，上线初期进行可用性测试……可以说，不是在验证体验，就是在准备验证的路上。但这些回答都是片段性的，只能发现散落的关键点。

等到业务成熟运转且稳定后，各方负责人可能会发出灵魂一问：如何全面评价业务体验？此时，用研工程师意识到：建立长效全面的体验监测系统非常重要和必要。

什么是体验监测系统

麦肯锡给出的定义是：一个持续运转的观察系统。①能发现足够详细的旅程、触点、渠道方面的客户体验信息 ②能长期追踪客户体验变化和衡量改善措施的效果 ③能够为企业带来统一的审视客户体验的视角 ④能提供完整准确的体验数据，让组织基于数据而非主观直觉做出决策。通过这份定义，可以得出体验监测系统的几个特征：

• 覆盖度广，测量范围覆盖整个用户体验旅程和对应触点、渠道
• 数据化，检测结果应以可对比的数据为主
• 可长期复用，监测系统的数据口径、来源应保持一致，这样才能做到可追踪、可对比
• 可操作性强，监测结果便于组织进行对应业务决策

1. 认可度高的体验监测模型

定义和特征有了，那么成型的体验监测系统是什么样的？我们整理了目前认可度较高的体验模型：

谷歌 HEART 模型（C 端体验模型）。该模型由 5 个指标构成，分别是：

• 愉悦度（Happiness），指用户在使用产品过程中的主观感受，包括满意度、净推荐值(NPS)、视觉感受等
• 参与度（Engagement），指用户在一个产品中的参与深度，如刷抖音的日均时长
• 接受度（Adoption），反应产品对新用户的吸引，如订阅率、注册率等
• 留存率（Retention），衡量现有用户的活跃度，如活跃用户数等
• 任务完成度（Task success），指用户能顺利完成某项任务，如业主成功在贝壳网上进行卖房委托

阿里 PTECH 模型（B 端模型），由 5 个指标构成：

• 性能体验（Performance），如页面反应时长
• 任务体验（Task success）
• 参与度（Engagement）
• 清晰度（Clarity），指功能设计系统清晰度，用户能自主完成各项工作
• 满意度（Happiness）

更多阿里模型：

LIFT 模型（C 端模型），由 widerfunnel 公司开发，旨在提升转化率，主要有六大法则：

• 为你的价值主张优化，用户的使用动力=感知好处-感知成本
• 相关性优化，指实际页面与用户需求间的匹配
• 清晰度优化，指功能设计系统清晰度，用户能自主完成各项工作
• 焦虑感优化，减少页面不确定性带来的焦虑，如用户对品牌是否可信的焦虑等
• 注意力分散优化，减少把用户的注意力从主要的价值主张信息和用户召唤行为上引开的元素
• 紧迫感优化，让用户立刻采取行动

2. 模型应用问题

这些模型有衡量 C 端体验的，有针对 B 端产品的，在度量线上系统的用户体验方面表现优异，但存在 3 个问题导致他们并不适合贝壳这种极端复杂、线上线下交融的业务场景：

• 以衡量线上产品为主，视角单一，不能将业务作为整体，全面系统地考察线上线下、流程场景
• 只关注单一角色体验，而 B 端业务经常多角色多阶段频繁交互（如报销系统需要财务、员工、审计多方沟通），需要同时考察多角色体验，做到体验均衡
• 没有将与业务价值相关的体验指标纳入考核

因此，我们在贝壳探索了一条差异化的建立 B 端体验监测体系之路。

如何构建 B 端体验监测系统

监测系统的三大核心——测量指标、测量范围、测量用户，在搭建前需要按顺序逐一确定。

1. 确定测量指标

测量指标，指用于评价系统好坏的量化数据。在 B 端，可分为五类指标：

• 效率指标，如费力度（CES）/节点任务完成时长，用于衡量 B 端用户（一般是企业内员工）的工作效率与整体系统的人力成本
• 体验指标，如满意度（CSAT），用于衡量 B 端用户的工作体验/系统使用体验
• 留存指标，如离职率（内部使用的系统）/续费率（商用产品）/NPS，用于衡量 B 端系统对实际业务的适应性
• 性能指标，如响应速度、崩溃事故率，用于衡量系统产品的稳定性
• 业务指标，这个在不同 B 端系统间差异很大。如贝壳的 B 端新房系统，关注流程安全性（退单资金可追回）；为贝壳加盟商服务的店东系统，关注店东赋能指数；为内部产研服务的中台系统，关注服务稳定性、能力完善度。业务指标与系统的定位和关键目标相关，因此建议在全盘摸底业务后确定

由于不同 B 端系统的功能、应用场景、用户等差异很大，因此可根据实际情况组合上述指标，形成更贴合业务的测量体系。

2. 确定测量范围

B 端业务一般有较长的使用链路和较复杂的功能，在搭建系统前，需要确定：

• 测量业务的哪些环节，要覆盖整个业务链路，如关注整个新房业务从获客开始一直到回款完成的全流程；还是只关注某几个关键业务节点，如只关注业财税一体化相关的流程
• 测量业务的哪些部分，是关注线上产品系统，还是评价线下流程设计，抑或探寻整个业务的所有影响点。

测量范围越大，越能发现“隐匿的冰山”，触达业务核心问题。但随之带来的问题是：①测量成本增大 ②发现的问题类别复杂，权责难以落实到部门，落地困难。

3. 确定测量用户

B 端业务的用户角色一般多于 C 端，以新房系统为例，按使用频率可分为主使用者、次使用者等，按参与角色又可分为信息录入角色、审核角色、维护角色等。在确定测量指标和测量范围后，根据不同用户角色对业务的贡献度、参与度，考虑将哪些角色纳入监测系统。

指标、范围、用户都确定后，B 端监测体系也就自然的建立起来。

贝壳B 端体验监测系统

接下来，我们简单介绍下贝壳的 B 端体验监测系统的构建思路。

在贝壳，B 端体验监测系统经历了三个重要阶段：

第一阶段

从功能点出发建立产品满意度系统，如下图所示（部分业务流程由于保密原因，做了修改或隐匿）。

△ 图 1 早期二手满意度架构（仅包含部分内容）

特点是：①架构清晰，基本按照功能架构 ②次序明确，一级影响因素（大产品功能）与二级影响因素（大功能下的小功能、细节设计等）层层递进。

之所以采用这样的架构和内容，是因为：①早期建立监测体系时，产品同学往往参与意愿更强烈，提供的资料和需求更多 ②只有产品问题能确定落地，其他问题总会被推诿 ③产品槽点多，只专注这个区域就挖不完宝。

这样的体系好处是：①问题明确，低满意度产品模块可快速找到对接人，容易落地 ②结构简单，背景知识少，设计满意度系统认知和时间成本低，可以先跑起来 ③合作部门少，只需要和重点模块产品打交道，项目推动更省力 ④可计算出每个模块对整体产品满意度的贡献值，帮助产品同学发现优先改进点。

劣势是：①只能发现单个模块的问题，陷入谷仓效应 ②以产品功能为骨架，可能漏掉其他用户关注的业务、运营问题 ③产品框架不符合用户关注习惯，部分打分可能与实际情况有出入 ④题量较大，完成难度大。

第二阶段

考虑到产品满意度系统的问题，我们在此基础上进行了监测系统的优化：从服务设计理论出发，建立场景式满意度系统，如下图所示（部分业务流程由于保密原因，做了修改或隐匿）。

△ 图 2 早期新房满意度架构（仅包含部分内容）

这样的监测系统特点是：

• 场景化，按照用户的实际业务场景设计问题，与产品结构分离
• 地图式，参考整体业务流程，不仅考虑单个业务场景，还要考虑场景间的衔接，即从服务设计理论出发，关注每个触点和整个旅程
• 多角色，贝壳 B 端的大部分业务，都需要都各角色协同完成，如果只关注某一角色，可能导致不能发现核心问题
• 多指标，采用满意度、费力度、NPS 多种定量指标，因为业务上对某些 B 端角色更关注作业效率或完成度等，此时需要同时应用多种监测指标，保证结果有价值

这样的体系好处是：①可以发现整个业务流程的单点问题与衔接问题 ②从用户角度出发设计问题，用户回答顺畅准确 ③指标更符合业务需求 ④能发现不同角色的分工问题，是否存在某个角色工作负荷过高。

劣势是：①结构复杂，需要对业务非常熟悉，前期准备工作非常耗费人力与时间成本 ②发现的问题难以归类，解法需多方协同（如运管人员审核压力过大，需要同时优化产品逻辑和增加数据对接准确性）③合作部门多，项目推动难度大 ④调研对象多、覆盖范围广，后期数据分析、结论产出耗费精力多。

第三阶段

由于二代系统耗费精力过多，贝壳 er 们在此基础上又进行了改良，建立自动化触点式体验监测系统，以数据看板+人工分析形式运转。

这样的监测系统特点是：

• 触点式，定义体验旅程节点后，在每个节点分发体验调研问卷，抓取数据
• 自动化，系统识别后自动分发调研问卷，自动处理数据
• 可视化，数据看板形式展现

贝壳 B 端体验监测系统的这三个阶段，代表了三种思想的转变：从先跑起来，到精细测量，再到自动化分发，越来越全面，越来越省力。

1. 新房 B 端满意度系统

新房是一个多角色参与的复杂系统，参与的角色包括：购房客户、新房经纪人、客发经理（负责宣传楼盘、与开发商谈判拿盘、系统内录入楼盘资料等）、驻场（在楼盘现场处理经纪人带看事宜、录入各项数据、同步销控信息等）、运管（负责审核成交数据、解决流程问题等）、财务（负责回款跟踪等）、法务（负责确认合同条款、合作归档等）……

整体流程也非常复杂，从接待客户到完成回款，一共有 20 多个环节，每个环节都要耗费 1~3 个角色的大量精力。如何测量这个系统的用户体验，就是个非常头痛的问题。

面对这个硬核满意度任务，我们给出的解决方案是：

• 区分角色，调研重要的角色，同时做好角色交叉和互斥项，做到角色对照、角色完整调研，同时能合并查看不同角色如何在同一流程中通力合作
• 区分流程，按照实际作业流程，铺成整体问卷脉络，如按照业务进展区分为录合同、审核合同、配置项目、传递项目、审核报备等模块，作为满意度一级指标，类似地图一样有明显前进性
• 区分场景，问卷中按照使用场景和场景中的任务来描述满意度问题，如“审核报备的工作麻烦吗？”，摒弃“XX 功能体验满意吗”这种脱离场景的表述
• 区分指标，使用费力度、满意度、NPS 三大指标共同描述新房业务体验，将 B 端业务更关注的人效指标也纳入监测范围

最终产出了一个包含 4 种最重要角色（经纪人、案场等）、22 个流程节点、3 类指标（满意度、NPS、费力度）的新房体验监测系统，如下图所示（部分业务流程与业务数据由于保密原因，作了修改或隐匿）。

△ 图 3 新房体验监测系统示意

其中 NPS 与全体满意度作为整体指标，描述新房系统各角色的总体感知和体验情况；费力度与流程满意度作为单节点指标，描述不同节点的业务感知和体验情况。未来，在业务持续发展过程中、业务方遇到整合问题以及项目有了全局落地的能力后，我们也会增加针对整体业务和针对单个节点的业务指标（如回款安全性、流程可跟踪性），将体验监测与商业价值挂钩，进一步提升 B 端体验的势能。

B 端体验监测系统的搭建建议

通过贝壳的例子，可以发现 B 端体验监测系统往往比 C 端更复杂，对创建者的业务理解程度有更苛刻的要求。无论搭建还是落地，都需要较高人力和时间成本，因此建议大家在设计 B 端体验监测系统前做到：

• 充分熟悉业务，能清晰理解业务定位与商业核心价值点，知道整个业务的运转过程和参与角色，这是确定测量指标、测量范围、测量用户的前提；
• 协同一线的业务同学，保证整个创建系统过程都有业务专家进行指导与纠错，建立的监测系统能切实帮助业务；
• 灵活组合 5 类 B 端体验指标（效率指标、体验指标、留存指标、性能指标、业务指标），不一定每个模型都要全部包含；
• 分阶段前进，设计前要综合考虑能投入的最大资源，不要一味追求完美。

结语

B 端监测体验系统的建立与运行，是复杂的长期性工作，也是对用研团队专业性和业务理解程度的挑战，愿大家勉力前行。

欢迎关注作者微信公众号：「贝壳KEDC」