B端企业中体验从业者的职场局经验系列分享(五)

0 评论 1165 浏览 2 收藏 10 分钟

B端企业中,体验从业者在职场中会遇到各种各样的问题。作者结合自己的相关经验,总结了沟通和执行方面的一些问题,希望对你有所启发。

接着上篇文章的节奏,“B端企业中体验从业者的职场局经验系列分享(四)”,让我来继续说说体验从业者在职场中还有哪些局?

一、沟通篇

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

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

向上汇报这个动作,不用多说,大家都应该很清楚该怎么做,甚至向上管理也是现在企业中比较“崇尚”的管理方式,不要拍马屁就好。

但是,在体验工作结果的汇报中,该怎么汇报才能让老板接受产品和服务的现状并支持你的解决方案,这方面还是需要一定的沟通技巧和方式的。

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

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

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

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

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

所以,打通、协同、赋能,是工作推进的关键三点。

虽然现在大部分企业的管理模式都开始采用扁平化、去中心化、前中后台的组织结构,等。但几十年的中国式管理是那么容易说变就变吗?

在所谓的扁平化管理中,依然有潜在的组织层级过多,信息流通断层,业务端之间的谷仓效应等现象。大家各自为战,坚守着自己的KPI,虽然都用OKR了,但是每个人的KR才是老板最看重的,所以都以个人为中心了,甚至还没有到上一级的KR,下层就已经脱轨了。

在这样的情况之下,体验工作这块业务所带来的解决方案,更是被各业务块看作是挑毛病、找错的一种挑衅方式而被拒绝,难以沟通和推进。

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

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

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

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

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

至于,赋能,其实在前面的操作中,如果都顺利的话,就已经能够展示出体验改善工作是能够赋能业务发展和提升的。

对于业务端和中台是否能够反向赋能体验改善的工作,那就要看沟通完以后他们的理解能力和意愿了。

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

二、执行篇

前面所说的每一个步骤,都是在为了最后这一个阶段的落地执行和验证复盘而打下的基础。

尤其是在从体验驱动的角度制定的改善性解决方案和内部之间一系列的沟通协同之后,执行和验证这一步就凸显得尤为重要了。

这个阶段也是前面所有工作推进的验证,所以有一些技巧和重点可以分享一下。

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

假设所有的推进工作都是一切顺利的,那么接下来就应该由内向外地实施改善性的解决方案,逐步落地到业务端的产品研发和服务流程中,然后到客户端的再次体验和反馈。

说到客户的再次体验和反馈,这里需要多说一点。

从体验的变化性和随机性来说,每一个解决方案的客户端验证,都不太可能是之前提出问题或反馈的原始客户能够参与的。

如果需要原始客户的参与,那一定要在前面的调研阶段对样本的选择做出明确的梳理和限定,以保证后续方案验证的准确性。

但如果是正常随机性的方案投放,那就要计算参与验证的新客户群体的样本偏差和数据方差,以保证最终验证结果的相对准确性。

否则,一个解决方案如果不能得到充分的样本验证,那它后续的可执行性和持久性就会大打折扣,方案本身的价值也不会充分的体现出来,这就会影响到管理层都很关注的ROX。

所以,解决方案的准确性是需要足够客户样本来支持的,但同时,也更加需要企业内部和前端各层人员的协同推进才能实现的。

因此,从企业层面来说,及时收集客户的验证反馈是很重要的,获取渠道依然是通过客服、客诉、线上线下等方式,重点是要发现客户对改善点的反馈,维度不限。

这样的目的是为了验证解决方案的可行性,做到及时优化和改进;以及产品和服务原始问题的解决程度和需求的满足程度。

在执行和验证的环节,需要再次强调一下,体验改善项目的推动者一定要积极配合业务端,保证上下左右的连通协作模式,以实时沟通的方式推进,及时止损。

但是,在执行的过程中,肯定会出现新问题或旧问题未被验证的情况,那么,收集好,再次回到开局篇或痛需篇的内容,这样也就形成了体验工作的闭环,可以持续的循环下去,体验团队的赋能和驱动所产生的长期价值也就会越来越明显。

这样的改善项目的闭环多了,整个客户体验管理的闭环也就逐步完善了。

最后说一个在这一步需要用到的一个重要工具,复盘。

复盘你的沟通,复盘你的执行,复盘你的思路,复盘你的错误,复盘你的解决方案,等等。

复盘,就是在不断地迭代和升级。

专栏作家

杠叔@体验践行者,微信公众号:杠叔体验管理,人人都是产品经理专栏作家。体验管理独立咨询师、客户体验管理专家。

本文原创发布于人人都是产品经理,未经作者许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!