【痛需篇】

在体验的日常工作中，一系列的调研工作和旅程分析之后，会收集到从客户端反馈的各种痛点和需求，有针对产品的、服务的、流程的等等。通常对痛需的分析和整理工作都会有一套相对成熟的方法和工具，这里分享一段围绕痛点和需求的实操经验的“打油诗”，方便记忆。

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

那就先来说说痛点分析的思路吧。细化来说，痛点也是可以分类、区别对待的。首先，痛点是人为定义的吗？问题反映的量级大、频率高、投诉多，那它就一定是产品的痛点或者服务的痛点吗？其实不然，不完全是这样的。起初我们可以用这样的思路来确定哪些问题是痛点。但是确定完之后，痛点也是要被再次分类，并且深入分析的，才能确定这个痛点是真的、客观的且普遍存在的。

有些痛点呈现的表象是假的，或许只是产品或服务本身的设计初衷，但不能改，改了可能会出现更多无解的问题，那这个痛点，对于企业内部来说，就不需要重点关注。比如：某品牌手机的设置功能UI界面复杂，不如某品牌做得好、使用简单。这个产品使用的痛点确实被反映的量级大，甚至投诉多，那需要改吗？答案是不需要的，这或许就是品牌的调性。

而有些痛点是花了大成本设计出来的，即使它影响到了客户的体验感，企业也是可以用其他的爽点来弥补和冲抵的，使其产生更多的反向价值。也就是在体验旅程中的波峰与波谷的设计，是根据情感曲线的波动来实现的。比如：宜家家居里让顾客头痛的绕圈购物体验，就可以用最后的那一个1元的冰激凌来缓解相应的痛。下次你会继续光顾宜家吗？答案是会的，因为痛并快乐着。

所以，收集到痛点，不必紧张，更不要直接拿着去和业务讨论，毫无意义。真正能值得理论的痛点，首先是影响客户体验感的，其次就是产品或服务的真实缺陷和相关需求，并且反馈的量级足够大。

再来说说需求能够产生新的体验路径。何出此言呢？需求无处不在。整个体验旅程中，在体验之前、开始、期间、之后这四个阶段中的每一步、每一个点，都有需求的产生。

面对客户和用户的需求，首先我们要专业的分析出这些需求中哪些是真、哪些是假、哪些是客观、哪些是主观，并给出解决的优先级。但是某些需求还可能产生新的体验路径，这一点大家有注意到吗？不论是已经被满足的需求，还是未被满足的需求，在产生新的体验旅程的前期，都是有干预这个动作的。

还是拿宜家的绕圈购物来举例说说吧。不知道你有没有注意到，在整个绕圈的过程中，在某些路径上有分岔路，直接通向另外一个购物区域，甚至直接通到了宜家餐厅。这一点的做法就是让顾客在新的体验需求产生之前，就进行必要的干预，产生新的体验路径，目的是冲抵痛点，给顾客一个新的环境来增强和保持新鲜的体验感。那么，在这个新的子环境中，就会产生新的体验路径，又会暴露出新的问题和需求。所以，这就引出了下面的话题，我们该怎么根据现有的关键点和旅程路径设计出更好、更优地体验旅程呢？目的就是，冲抵痛点，干预需求。

【方案篇】

在一系列的痛需分析和调研问卷完成后，对于所得到的客户反馈结果，包括数据和信息，我们是需要以其为依据，形成调研分析报告的。而且，调研问卷中所涉及的关键点都是从痛点问题和需求提炼出来的，所以通过问卷的结果来验证的痛点和需求项是需要进行二次深入分析的，并制定出可行性的改善解决方案。

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

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

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

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

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

【沟通篇】

在体验改善的解决方案制定完成后，就要开始“奔走相告”了，完成方案推进的打通、协作和赋能。

汇报打通有技巧
客户视角是关键
协同合作易推进
赋能业务破谷仓

向上汇报这个动作，不用多说，大家都应该很清楚该怎么做，甚至向上管理也是现在企业中比较“崇尚”的管理方式，不要拍马屁就好。但是，在体验工作结果的汇报中，该怎么汇报才能让老板接受产品和服务的现状并支持你的解决方案，这方面还是需要一定的沟通技巧和方式的。

首先，你的汇报内容一定是以客户为中心的，是客户满意或者不满意的，是客户愿意买单或拒绝买单的，总之就是，一切以“客户说”为中心思想。

其次，你汇报的内容一定是客观、合理、符合业务发展和公司愿景的，甚至表现出的价值观也一定是和公司级匹配的。

最后，你的解决方案一定是可执行的，有监控有验证的，并不是空口无凭、任意推测而决定的。老板需要的是结果，而且这个结果是能够支撑他去说服和要求业务端改善和提升的。

还有一点，内容量不要过大，简单直接，结构清晰，比如：客户说什么，问题是什么，原因是什么，建议怎么改善，该怎么执行和验证，我们会怎么支持和配合，OK！

在这一步中，除了向上汇报之外，还有与跨部门的沟通和协作，这一点同样重要，因为要确定方案的最终执行，实现由表及里的、打破谷仓效应的流程体系，并形成连通式的协同工作模式。

所以，打通、协同、赋能，是工作推进的关键三点。虽然现在大部分企业的管理模式都开始采用扁平化、去中心化、前中后台的组织结构等。但几十年的中国式管理是那么容易说变就变吗？

在所谓的扁平化管理中，依然有潜在的组织层级过多，信息流通断层，业务端之间的谷仓效应等现象。大家各自为战，坚守着自己的KPI，虽然都用OKR了，但是每个人的KR才是老板最看重的，所以都以个人为中心，甚至还没有到上一级的KR，下层就已经脱轨了。在这样的情况之下，体验工作这块业务所带来的解决方案，更是被各业务块看作是挑毛病、找错的一种挑衅方式而被拒绝，难以沟通和推进。

那么，该怎么做才能打通封闭的工作模式、实现协同的目标呢？

首先，先和各业务的负责人多多沟通，日复一日地介绍自己、介绍业务，让大家知道你是干什么的，是来辅助每个业务块从客户的角度来提升品牌的质量和品质的，而不是来挑毛病、来找麻烦的。

其次，上面的向上汇报你做完了吧，老板接受了吗？那就让老板下达指令吧！体验管理的工作一定是自上而下地宣贯和执行的。

再次，开始一轮一轮的组织会议吧。注意，第一次会议不要邀请老板，只和涉及需要改善的各业务块的负责人坐在一起，聊聊从客户端拿到的结果，聊聊解决方案中的建议，聊聊执行的思路和想法，看看大家的反应。第二次会议，邀请上老板吧，该表明一下上层的意思了。之后的会议，就好聊多了。

最后，把每次会议讨论的内容、结论和执行计划，都要发送到相关利益人手里，并积极配合各业务块开展改善性的工作，并监控整个过程，保持协同的状态。

至于赋能，其实在前面的操作中，如果都顺利的话，就已经能够展示出体验改善工作是能够赋能业务发展和提升的。对于业务端和中台是否能够反向赋能体验改善的工作，那就要看沟通完以后他们的理解能力和意愿了。

总之，沟通中一定要有情绪缓解和情感共鸣与传递，同理心、共情能力都要用起来。

【执行篇】

前面所说的每一个步骤，都是在为最后这一个阶段的落地执行和验证复盘而打下的基础。尤其是在从体验驱动的角度制定的改善性解决方案和内部之间一系列的沟通协同之后，执行和验证这一步就凸显得尤为重要了。这个阶段也是前面所有工作推进的验证，所以有一些技巧和重点可以分享一下。

落地改善推进难
优化迭代需及时
验证反馈成闭环
复盘ROX与重生

假设所有的推进工作都是一切顺利的，那么接下来就应该由内向外地实施改善性的解决方案，逐步落地到业务端的产品研发和服务流程中，然后到客户端的再次体验和反馈。这里需要多说一点，从体验的变化性和随机性来说，每一个解决方案的客户端验证，都不太可能是之前提出问题或反馈的原始客户能够参与的。

如果需要原始客户的参与，那一定要在前面的调研阶段对样本的选择做出明确的梳理和限定，以保证后续方案验证的准确性。但如果是正常随机性的方案投放，那就要计算参与验证的新客户群体的样本偏差和数据方差，以保证最终验证结果的相对准确性。否则，一个解决方案如果不能得到充分的样本验证，那它后续的可执行性和持久性就会大打折扣，方案本身的价值也不会充分地体现出来，这就会影响到管理层都很关注的ROX。

所以，解决方案的准确性是需要足够客户样本来支持的，但同时，也更加需要企业内部和前端各层人员的协同推进才能实现的。因此，从企业层面来说，及时收集客户的验证反馈是很重要的，获取渠道依然是通过客服、客诉、线上线下等方式，重点是要发现客户对改善点的反馈，维度不限。这样的目的是验证解决方案的可行性，做到及时优化和改进，以及产品和服务原始问题的解决程度和需求的满足程度。

在执行和验证的环节，需要再次强调一下，体验改善项目的推动者一定要积极配合业务端，保证上下左右的连通协作模式，以实时沟通的方式推进，及时止损。但是，在执行的过程中，肯定会出现新问题或旧问题未被验证的情况，那么，收集好，再次回到【开局篇】或【痛需篇】的内容，这样也就形成了体验工作的闭环，可以持续地循环下去，体验团队的赋能和驱动所产生的长期价值也就会越来越明显。这样改善项目的闭环多了，整个客户体验管理的闭环也就逐步完善了。

最后说一个在这一步需要用到的一个重要工具——复盘。复盘你的沟通、复盘你的执行、复盘你的思路、复盘你的错误、复盘你的解决方案等。复盘，就是在不断的迭代和升级。