B端企业中体验从业者的职场局经验系列分享（四）

在B端企业体验从业者日常的工作有很多，在一系列调研工作和旅程分析之后，还会遇到来自客户的各种痛点和需求。本文将继续说说体验从业者在职场中还有哪些局？一起来看看吧。

接着上篇文章的节奏，“B端企业中体验从业者的职场局经验系列分享（三）”，让我来继续说说体验从业者在职场中还有哪些局？

一、痛需篇

在体验的日常工作中，一系列的调研工作和旅程分析之后，会收集到从客户端反馈的各种痛点和需求，有针对产品的，有针对服务的，还有针对流程的，等等。

通常对痛需的分析和整理工作都会有一套相对成熟的方法和工具，这里分享一段围绕痛点和需求的实操经验的“打油诗”，方便记忆。

• 客户痛需定性难
• 角度维度要明确
• 深度细化找重点
• 产服流程是关键
• 客户视角同理心
• 深挖痛需辨真伪
• 二次分析需谨慎
• 明确触点关键点

那就先来说说痛点分析的思路吧。

细化来说，痛点也是可以分类、区别对待的。

首先，痛点是人为定义的吗？问题反映的量级大、频率高、投诉多，那它就一定是产品的痛点或者服务的痛点吗？

其实不然，不完全是这样的。

起初我们可以用这样的思路来确定哪些问题是痛点。

但是确定完之后，痛点也是要被再次分类，并且深入分析的，才能确定是否这个痛点是真的客观的且普遍存在的。

有些痛点呈现的表象是假的，或许只是产品或服务本身的设计初衷，但不能改，改了可能会出现更多无解的问题，那这个痛点，对于企业内部来说，就不需要重点关注。

比如：某品牌手机的设置功能UI界面复杂，不如某品牌做得好、使用简单。

这个产品使用的痛点确实被反映的量级大，甚至投诉多，那需要改吗？答案是不需要的，这或许就是品牌的逼格。

而有些痛点是花了大成本设计出来的，即使它影响到了客户的体验感，企业也是可以用其他的爽点来弥补和冲抵的，使其产生更多的反向价值。

也就是在体验旅程中的波峰与波谷的设计，是根据情感曲线的波动来实现的。

比如：宜家家居里让顾客头痛的绕圈购物体验，就可以用最后的那一个1元的冰激凌来缓解相应的痛。下次你会继续光顾宜家吗？答案是会的。

痛并快乐着嘛。

所以，收集到痛点，不必紧张，更不要直接拿着去和业务讨论，毫无意义。

真正能拿到桌面上理论的痛点，首先是影响客户体验感的，其次就是产品或服务的真实缺陷和相关需求，并且反馈的量级足够大。

再来说说需求能够产生新的体验路径。

何出此言呢？需求无处不在。

整个体验旅程中，在体验之前、开始、期间、之后这四个阶段中的每一步、每一个点，都有需求的产生。

面对客户和用户的需求，首先我们要专业地分析出这些需求中哪些是真，哪些是假，哪些是客观，哪些是主观，并给出解决的优先级。

但是某些需求还可能产生新的体验路径，这一点大家有注意到吗？

不论是已经被满足的需求，还是未被满足的需求，在产生新的体验旅程的前期，都是有干预这个动作的。

还是拿宜家的绕圈购物来举例说说吧。

不知道你有没有注意到，在整个绕圈的过程中，在某些路径上有分叉路，直接通向另外一个购物区域，甚至直接通到了宜家餐厅。

这一点的做法就是让顾客在新的体验需求产生之前，就进行必要的干预，产生新的体验路径，目的是为了冲抵痛点，给顾客一个新的环境来增强和保持新鲜的体验感。

那么，在这个新的子环境中，就会产生新的体验路径，又会暴露出新的问题和需求。

所以，这就引出了下面的话题，我们该怎么根据现有的关键点和旅程路径设计出更好、更优的体验旅程呢？

目的就是，冲抵痛点，干预需求。

二、方案篇

在一系列的痛需分析和调研问卷完成后，对于所得到的客户反馈结果，包括数据和信息，我们是需要以其为依据，形成调研分析报告的。

而且，调研问卷中所涉及到的关键点都是从痛点问题和需求提炼出来的，所以通过问卷的结果来验证的痛点和需求项是需要进行二次深入分析的，并制定出可行性的改善解决方案。

对于调研结果的报告形成和改善问题的解决方案制定，系统化的方法有很多，这里更多的还是分享执行过程中的经验。

• 数据呈现可视化
• 痛需转换客户说
• 完善旅程找内因
• 方案客观易可行

那么，从细节上如何对调研结果进行总结和分析呢？分享以下几点经验：

• 选定数据的分析维度和方法，根据业务的需求也好，老板的要求也罢，总之需要一个确定的角度来对数据进行分类和统计。
• 需要有足够的耐心和业务经验来归纳总结客户给出的各种文字信息类的反馈，能够抓住重点，提炼核心，并且不主观。
• 针对数据类的结果多以可视性强的图形化方法来呈现，而文字信息类的反馈则多以量级或类型的百分比来呈现。
• 所有总结类的陈述不能过于主观的加以臆断和下结论，尤其是客户反馈的产品或服务的问题，对于业务端是很敏感的，可多以客观推测的方式和同理心的角度来做出合理的分析。

接下来就是制定解决方案的初稿了，这一项需要相对丰富的业务知识和经验，能够对业务端所被涉及到的问题环节都非常的清楚和掌握，至少是业务流程、前中后台的结构和做事能力。

这里也有几点建议如下：

• 每一条方案，都应该具备数据的支持、原因的分析、可行性的建议和方法、执行过程中的监管和后期的验证，以及相应的风险管理和应急预案。
• 方案必须是客观的、符合业务端现阶段的能力范围，尤其是某些改善提升类的方案，需要和业务端紧密配合并协同实施。
• 方案都是单向性的，也就是说，这样做了，就会更好。而不是可对比性的，否则即是，伤害性不大，侮辱性极强，会直接打击业务端的信心，甚至会出现方案被抵触、无法推进的情况。
• 如果不懂业务、没有业务执行经验的人，请不要参与解决方案的制定。

​Read More