专项话题►工作教会我那些事儿

如何做客户至上的产品体验

序言

笔者从2019.9年开始从事toB做产品体验优化的工作，现在是2024.5回顾这快四年的经历，总体感觉还是非常充满挑战且有意义的一段经历。
时间回到2019年因组织架构调整，我也在思考我的未来职业规划，因之前从事多年运维工作，还是希望能结合之前的工作经历，当时也和很多同学有探讨了关于toB业务的运维方向未来发展，发现会逐步往深往精发展，但个人兴趣更多希望去解决一些复杂的问题从面入手，正好内部有机会做产品体验优化工作，了解了一下大概工作内容还是与自己的职业规划比较契合，从此开始入行做这里。
说这段经历比较有挑战的点是，譬如运维工作行业内是有很多标杆的如Google，但做产品体验优化小的公司没这职位，大的公司都在做但都基于自己的应用场景，所以没有太多前车之鉴，还有一个比较有意思的是，当时我们组织在扩张时面试很多候选人是比较难在短时间说清我们是做什么的，不像市场招聘运维岗位负责XX产品，候选人很快能够了解具体的工作内容，所以整理了这篇文章是想回顾总结一下，希望能说清我们如何做产品体验优化的过程。

一 开篇

1.1 什么是体验

我们从什么是“体验” 说起 ，在不同的行业不同的人对体验的看法都是不一样的，后来笔者在一本书《客户体验至上》中找到这样一段描述 “客户整体体验来自他的五个感官（视、听、触、闻、味），通过大脑加工后，产生 “逻辑”与 “情感” ，最终留在脑海中的印象”，其实体验就是能给那些人留下深刻印象的事儿。

譬如，加拿大某地的路灯，除了通过颜色还通过形状来告知当前道路通行的状态，他照顾了各种人群如色弱的人，考虑的很细节，其实笔者从书上看到这个案例，是给我留下深刻印象的。

回到以笔者所在的云服务行业竞争还是非常的激烈，同质产品做的都非常不错，产品都已经超过给人留下深刻印象的阶段，所以想把这里做好还是非常难的，我们要找到突破口，做深再做广。

1.2 产品用户画像

很多时候我们喜欢用“痛点”来形容这个突破口，痛点的意思是“它通常指的是尚未被满足的、广泛渴望的需求，有时也直接指需求本身。”

之前在我们维护的用户微信群中，相同的产品控制台，有的用户说界面太臃肿，有的用户说界面很实用，这里用户都站在自己的角度来看同一个问题时就会有这样的冲突，所以在找到用户痛点前，我们还要知道用户是谁，这里有几种分析方式：

  • 按用户属性是个人还是企业用户
  • 按用户消费额度，是中长尾还是大客户
  • 人工分析用户反馈的工单
  • 调研问卷

这几种方式通常可以辨别，用户买产品的用途是学习、是工作、还是为一些商业活动，再根据用户的画像对产品体验做细节的优化。

1.3 体验三大要素

一个成熟的产品从用户切入是一个突破点，从产品可以从这三点切入：

  • 场景体验
  • 交互体验
  • 感知体验

二 如何做产品的体验

2.1 如何做产品的体验

商业的本质是交换，而且是基于人们对价值的认识的等价交换，所以我们卖云产品是需要能帮助客户解决他们在商业上所遇到的问题，以下两句来自《李想产品实战16讲》中，笔者非常认可:

  • 关注用户价值，超越用户需求
  • 把组织当产品来做

本文主要介绍的是如何做客户至上的产品体验，其实与李想产品实战16讲中第一点的观点是一致的。 这里也介绍了近几年我们的思考和一些方法。

2.1.1 建立度量指标 & 目标

因为云服务后端有百款产品，每个产品有相应的技术团队负责，如何让他们整齐划一，这里从管理角度就需要用到度量指标和目标，让大家在相同的时间点内力往一处用。

度量指标
首先，我们要找到一个衡量体验的度量指标，引用彼得德鲁克的一句名言(如果无法度量他就无法管理他，If you can’t measure it, you can’t manage it)，业界也很多类似的度量指标，可以供自己业务参考，譬如：

  • 净推荐值（NPS，net promoter score）
  • 用户满意度（CSAT，customer satisfaction score）
  • 用户费力度（CES，customer effort score）

我们在初期主要用的是工单作为度量指标（用户在使用云产品时遇到问题，反馈的Case单），因为工单如果减少站在用户角度就意味着产品使用更加顺滑，工单的减少还会降低一线人员的服务压力，将更多的经历服务于有价值的事情上，还会为公司节约很多工单产生的费用带来的成本，一举多得的事。

目标
有了度量指标后要看如何落实，即目标。这里有两种设置目标的方式：

  • 方式一：万人工单量，分子是工单量、分母为产品使用的人数，譬如10万人（9-12月） 1800工单量（9-12月均值），最终就是1800/100000 = 0.018 * 10000 = 180 单 ，那么180就是2020年的基准值，表示1万人会反馈180单，在基准值基础上2021年下降50%= （180 * 0.5），到2021年我们的工单要达到每万人工单反馈量90单，下降50%。
  • 方式二：绝对值，首先需要有基准值，在基准值的基础上下降百分比。

举个具体的例子，我们按产品取工单反馈量最多的头部产品前17名，譬如叫TOP17工单折半项目，以当前是2024年1月，我们取2023.9-12月4个月工单的均值作为基准值（这里可以排除10月，因为放假的原因通常是全年工单的低点） 在此基础上下降50%，作为我们项目的目标，这样一来每个产品的基准值不一样，但下降指标是相同的也就拉平了各个产品的目标，让大家往一个方向走。

2.1.2 建设体验的文化

我们希望能从各种维度来提升产品体验，就好比花长的好和精心照顾有关当然和花土壤也有一定的关系。

我们负责的产品涉及的部门也比较多，更多希望能从文化角度来让大家更重视产品体验，所以我们也以游戏的方式，设置了很多产品体验奖项，奖项从发现问题、采纳问题、解决问题、响应耗时长、解决后整理成优秀案例的方式，让做体验从被动变为主动，从推动到自愿参与再到积极分享解决问题后的案例等方式来提升我们的产品体验。

2.2 如何挖掘体验的问题

2.2.1 发现问题的渠道

我们的核心度量指标是工单，但工单的视角还是有局限，所以我们需要更多的渠道立体化的视角来发现我们体验的不足，会通过以下两种方式：

被动反馈渠道（提供渠道，等待用户来反馈使用中的体验问题）

  • 工单问题反馈渠道 （如电话工单、在线工单）
  • NPS & 满意度问卷
  • 用户之声 （https://cloud.tencent.com/voc/）
  • 群运营：我们会邀请各产品一些高频反馈工单用户、对云产品技术有追求的用户邀请到群中，直接倾听用户的反馈。

主动挖掘问题

  • 体验走查：对产品使用进行随机测试，因为我们做体验发现在各个渠道反馈的问题频繁不断，但又不是太致命的问题，希望通过体验走查能把一些很基础的体验问题消灭。
  • 产品体验：结合用户使用产品的问题，有针对性的挖掘产品中的问题。
  • 竞品分析：针对用户反馈的问题 & 产品主功能 & 用户使用产品路径 等几个维度有针对性的做竞品分析。
  • 用户核心路径 ：以用户视角体验产品，并重点体验用户使用产品必经路径中常见的常见反馈问题。
  • 产品协同问题： 某个问题发生在A产品，但A产品内部又调用了B、C、D等产品的问题。

2.3 挖掘体验的例行工作

讲了很多提升体验的方式与方法，这里再介绍一下如何实践：

2.3.1 人工分析

借助BI分析
不同渠道来的体验问题，我们还是需要人工分析的。这里我们借助了公司的BI报表，所有的问题进来后会进行归档，举一个具体的例子一个用户反馈：

1
我登录不了云服务器，现象是22端口连接失败，之前没问题，也使用了腾讯云提供的工具进行排查是没问题的。

类似这种问题就会归档到云服务器产品，我的归档标签为（产品-问题分类-子问题分类） 这样我们就可以根据TOP的问题来依次分析问题是什么，问题引发的根因是什么。

画像分析
系统会根据用户的消耗进行标识用户级别，可以用过用户的级别问的问题能看到，消费越高的都是一些头部公司相对来说技术能力更强，问题偏重于对产品的性能或功能方面需求；而消耗比较低的用户更多是新手、学生等用户偏多，更多是学习目的。

用户核心路径挖掘
一方面我们会看工单中用户反馈的问题，针对用户反馈产品问题中的高频模块，我们还会以用户视角来体验用户使用产品的过程，并重点关注那些使用产品必经路径，容易出问题的模块。

产品协作类问题

问题的定义
产品协作类问题，譬如A产品为用户入口，A产品又集成了B、C、D产品，但用户是不清楚后面的组织架构的，通常会以产品入口为准来反馈问题，这种我们称为产品协作类问题。

问题的解决
解决这类问题，首先要描述问题、汇总用户的问题数据、用户的期望解决方案、同等功能友商的体验，再拉各产品进行讨论，分清解决问题不同产品的边界和预期时间。

2.3.2 自动化分析

腾讯云涉及的产品比较多，所以要分析的工单量还是非常大的。通常经过一段时间的分析会发现增量工单中存量已知问题占比最多，但还是会有少量的增量问题，所以也会通过一些方式做自动化分析，譬如我们会导出前一周的工单（部分工单还在处理中，未结单）状态为己结单，通过对文本进行分词、去停用词、专注一些核心关键或用户描述的实例ID，进行聚类再进行分析，理论某一个问题的关键字，问题不解决的情况下，每日关键字出现的数量是有一个大概范围的，如果同比或环比关键字出现大幅增长或减少肯定是有原因的，我们再做具体的分析，这样会解决我们大量的时间与人力，同时相应的关键字数据也会关联到需求中，当问题解决我们也可以观察解决后关键字的在工单中的走势，来评估问题修复的效果。

2.3.3 智能客服 & 工具

用户通过工单渠道反馈问题，常规的工单渠道包括电话、售后客服、群、站内消息（MC）等渠道，我们会将一些已知问题或可能因为用户环境导致的问题通过智能客服和工具来解决。

  • 智能客服：用户在提问题时，智能客服会根据用户的问题与后端的问答库进行匹配，并给出对应问题的答案，这样一来也可以减少一定量的工单触达到人工。
  • 工具: 我们发现很多用户遇到问题和用户所在的环境有很大的关系，譬如本地网络环境、本地防火墙、远程服务端客户设置错误导致的问题，所以我们也会整理一些排障的工具，用户在触达人工客服前，提前通过排障工具的检测告知用户原因和对应的解决方案。

智能客户 & 工具 可以用比较低的成本，帮助用户解决那些我们已知的问题，效果还是非常不错的。

三 如何解决体验类的问题

我们可以从各个渠道发现问题，但问题多了如何跟进解决又变成了新的问题，所以我们也改造了我们的需求管理系统。

3.1 优化需求管理流程

以下为需求管理流程（图片有点模糊，因为我本身表达从轮廓上介绍一下着系统，如需要清晰图片可以联系笔者获取）。 我个人比较喜欢这张图，从最开始的基础功能慢慢迭代到目前样子，谈及过程还是非常有意义的。

https://doc.weixin.qq.com/flowchart/f3_AMIAjQY0ACkXqXrk7MoTSaJb4ki5t?scode=AJEAIQdfAAovBnS9GNAKgAUgbdAFw

从使用系统的角色上可以分为三种：

  • 提需求人：抓住用户问题的本质，并能把需求描述清楚
  • 需求经理：横向看各产品间协作问题，并深入挖掘问题的本质，“就像百年前福特去问他们的顾客他想要什么，而通常顾客会说我需要一匹更快的马”。
  • 产研：给出产品的规划，并结合售后、售前和产品规划，不断迭代产品。

不同的角色在流程上主要的工作，如下：

提需求人
提需求人更多是一线和架构师，他们直接对接客户，这里我们更加鼓励他们提需求，但人多了难免需求质量,譬如偶提需求人会直接截取用户群中的需求，并很简单的方式描述用户要做什么，类似这样的需求是不行的，因为信息通过流程传递过程时，让后端同学很难抓住需求本质要解决的问题，即便能明白大概意思，但实现上一些用户对结果的要求比较个性，需求实现后发现并没有完全解决用户的问题，所以这里我们也设置需求反馈模版、需求标签：

  • 需求模版：主要想解决的问题是让信息更加规范，并突出需求的重点和需求的辅助信息。
  • 需求标签：我们会对过往的需求进行分析、对问题聚类并设置标签，譬如客情标签、跨产品系统问题、攻坚客户等。

需求经理
负责需求的审核、需求合并、共性问题聚类、需求分类、需求的整个生命周期管理和相关数据运营等。

产研
需求的采纳与否、排期、实现与反馈等。

3.2 建立度量指标 & 目标

度量指标
需求流程有两个重点指标：

  • 落地率（需求实现量）： 以月为单位，譬如当前9月1日，我们会取过往6个月（3.1-8.31）的有效（重复需求、被拒绝需求除外）需求数据作为分母，已经实现的作为分子来统计落地率。当然这6个月的数据也是经过计算得出，我们分析过平均一个需求开始到上线后的平均时间，同时考虑一些复杂的需求，最终确定统计周期为过往的6个月。
  • 响应SLA：这里我们看的更多是从一线到最终产品经理采纳的耗时，因为需求量比较大、涉及的产品比较多、一个需求实现与否比较极端情况需要多个产品一起来探讨决定，所以我们要把这时间控制在一个合理的范围内。譬如过往7个工作日的需求量作为分母，已采纳作为分子来统计这里响应时间是否在一个合理区间内。

目标
落地率这里我们还会对需求做分类，并对不同分类的需求落地率区分对待，并定期晾晒这里不同产品的落地率情况。与落地率相比响应sla是一致的譬如7个工作日内要达到90%以上的响应率。

3.3 如何聚焦价值

关于需求管理如何聚焦价值，这里有三个重点：

不断优化流程,识别重点问题
根据目标不断地优化流程。最开始我们的流程是不区分客户群、不区分问题类型的，而我们解决的是体验问题，所以也会把用户群进行打标、问题进行打标，并通过各个维度汇总为一些需求积分,根据积分从高到低排序进行与后端定期沟通，并持续关注重点需求的进展同步反馈一线（以下为当时做的一个在线表格demo)

推荐需求
一般产品以年为单位会有一个大概的Roadmap，但很多时候计划赶不上变化快。我们在需求中也会挖掘相对实时的数据，譬如把需求按行业进行分类，如游戏行业、教育、金融等等，以游戏行业为例，我们看到A、B两家公司对产品提的需求，了解需求背后的问题，并将汇总后的数据以报表形势推动给内部架构师，因为我们觉得同是游戏行业中多家公司有类似的需求，在当前的时间点应该是一个重点的需求，售价架构师在对客户时也会把类似的问题，需求价值推荐给用户，增加我们产品的购买力。这种相对于产品roadmap更加实时准确。

梳理需求规范
其实通过过往的数据我们发现一线人员会有不稳定或岗的情况，因为公司的产品太多，所以一线在反馈需求和需求上线同步用户，这里应该都有要响应的规范。如客情用户怎么上升、需求系统的释放用法，需求上下游接口人、需求进度等等。

四 体验前置

为什么要做体验前置，因为这里有上百款产品，随着产品功能的迭代，新老产品的交替，一些不好的体验问题总是会重复的出现，所以我们思考这些问题在设计产品时就能提前的规避，大概的思路是挖掘问题-》分析共性 -》整理原则 -》赋能产品经理。

4.1 问题分类

分类是让人容易记忆，分类后还可以提升解决问题的效率，最后更好的分析到修复后的效果。 但分类要根据自己产品的实际情况。我们每天还是会有大量的问题进入到需求流程中，这里我们会将问题分类两个大类和分类原则如下：

  • 体验升级（精准分类到此）: 锦上添花的问题，能让用户用着更爽加深他的印象，有意愿推荐产品功能的问题
  • 体验修复（默认分类到此）: 不能满足用户的基本诉求、逻辑不合理的问题等

交互体验

问题分类 解释说明
引导/提示不到位 文案提示、操作引导不到位
多端体验不一致 控制台、云助手、API等多端之间的体验不一致
产品间体验不一致 相似的功能（比如控制台的地域组件）不同产品体验不一致
不同区域体验不一致 比如国际站和国内站体验不一致
缺少模糊搜索/筛选能力 缺少模糊搜索或筛选功能
文案表达不够准确 文案表达不准确，误导或缺少文案说明
操作流程割裂 操作流程之间衔接不顺畅、割裂
缺少智能校验 缺少提前校验、自动校验
其它 定期再分类

场景体验

问题分类 解释说明
文档问题 文档相关的所有问题
功能缺失 产品功能缺失
缺陷 bug类问题
产品间协同问题 两个以上产品之间搭配使用的问题（比如各产品与云监控搭配）
性能问题 性能相关问题
其它 定期再分类

感知体验

问题分类 解释说明
未给用户选择权 替用户选择或未给用户多种选择
产品能力迭代慢于业界 与业界竞品或上游供应商之间的迭代相比较慢
复杂功能简易化 复杂功能需要简易化
功能层级过深 功能层级或入口较深，用户找不到
缺少终止/取消操作 流程开始后没法取消或终止
未给客户知情权 未及时告知客户进展或状态，导致信息不透明
其它 定期再分类

4.2 产品设计原则

原则其实就是指导个人或集体行为和决策的基本准则。我们会通过日常发现在不同产品重复出现的问题进行分类整理：

  • 标准组件
  • 产品功能
  • 产品计费
  • 活动运营
  • 合规率相关
  • 控制台交互类
  • API/SDK类

案例。

五 写在最后

如何做产品体验用一句话总结，我回想一下工作的过程更多是把无序变为有序的一个过程，以产品体验为例，让用户使用产品时更加顺滑、让产品在业界更有影响力，这里我们需要不断挖掘每个问题背后产生的原因，并定期把问题原因进行分类汇总，看会出现哪一类的问题，从产品规划上未来是否可以解决，短期存量问题如何处理，不同产品间问题如何对齐，让用户体验更加一致。

参考资料

  1. 李想产品16讲：
  1. 《客户体验至上》：https://blog.puppeter.com/2022/10/16/page-38/
  2. 《服务设计-用机制的体验赢得用户的追随》：https://blog.puppeter.com/2022/10/12/page-35/
  3. 《设计的缺陷》：https://blog.puppeter.com/2022/10/09/page-28/
  4. 《客户体验101 -从战略到执行》