又是被客户DISS的一天
在产品经理的日常工作中,与客户的沟通是不可避免的,而在这个过程中,面对客户的质疑和不满也是常有的事。本文通过一个真实的案例,讲述了产品经理如何在一次沟通会议中遭遇客户的不满,并从中反思和总结经验。
产品经理的日常工作,跟客户的沟通必不可少,被客户DISS也成了“日常”。
昨天又一次被客户在沟通会上DISS了,之所以用“又”是因为它就像北京的大雾(或大霾)一样,指不定哪天就来了。
天无三日晴,心无三日宁。要想做产品,学会理和情。
小提示:为了完整复原”事情原貌“,今天分享内容较多,且与本人工作相关性比较强。如果你无法有效理解内容,不是你的错;如果你不想”浪费时间“阅读,也不是你的错。(但最后的反思与总结两部分内容,希望对你有帮助)。
背景
客户是一家刚新签不久的成交客户,旗下有3-4家子公司,每家子公司有100-200人。签约时,因现有系统无法满足需求,故而给客户二开了两个需求(其中之一就是又跟研发同学吵了一架)。
二开:指基于现有系统进行二次定制开发,一般潜台词是付费定制,只专属于某个客户所需。
当初愿意二开的两个原因是:
- 需求合理,且是通用性需求,不局限于此客户使用;
- 客户愿意将签约时间由1年延伸至5年。
起因
周一时,销售跟实施同学找我沟通,客户其中一家子公司,又有一个需求不满足,期望让我看看是否有解决方案。
客户有部分白领员工的上班工时规则比较特殊:
- 每天出勤总工时以打卡时长为准,而不是班次时间。比如7:00来,21:00走,是13.5小时(扣除休息0.5小时);
- 每个月总出勤时长,只要超过每月的标准工时,就不会有惩罚;
- 每月标准工时 = 当月工作日天数 * 8小时;
- 每月总出勤工时 = 当月每天出勤时长之和
注意:上面是当时实施同学转述的概要信息,并非完整信息。
客户期望结果是:
- 员工可以实时查看,自己当月总出勤工时是多少,还有多少差异工时,从而把控自己的工时进度;
- 管理员也可以实时查看员工的工时情况,便于有效进行管理;
实施目前所能提供的方案有两个弊端:
- 数据不透明:员工无法有效实时且便捷查看工时,必须自己根据每天的打卡与出勤情况,自行计算;
- 操作繁琐:管理员要看到数据,必须每次先操作一次归档,将截止当天的数据进行一次计算才可以同步至另一个模块查看;
经过一轮沟通后,基于目前系统逻辑,确实无法有效解决上述两个问题。于是,他们就回去跟客户反馈,我也没再跟进。
经过
周三时(即2天后),销售又给我发了一个文档,问我:“境哥,这个可以二开吗?”
上述截图信息,不是没截全,而是完整文档如此。所以对于产品经理来说,一定是满头的问号脸。
我说:“规则相对复杂,一般二开人日比较高,所以需要看下客户,是否真要评估?如果需要,则需单独写个需求文档,补全对应规则。比如怎么定义员工有晚餐,要扣除30分钟出勤时长,每月标准工时、每月实际出勤工时的定义等。”
销售说:“好的,那我跟客户沟通下时间,咱们拉个会。”
跟客户约定了周五上午10:30-11:30沟通。
会上
周五(即又1天后)上午10:30,我、销售、实施跟客户的采购、3位子公司的HR开会,会议因客户其中一个HR晚到,延误了大概10分钟。
第一轮:”正常”开始
先是销售同学介绍了大概背景。
“各位老师好,针对XX子公司的白领弹性工时,系统无法满足问题,今天我来了咱们技术的同学跟大家沟通下,咱们是否有更好的解决方案?”
实施同学补充到:“境哥,背景就是那天跟你说的那个标准工时的问题,目前我们是在工资模块搭建了一个自定义公式,每天将考勤月报数据进行归档后,同步至工资。但每天操作比较繁琐,并且标准工时的计算只能是整月,而不是截止至今天。”
“嗯,目前系统确实没办法有效解决,咱们需要聊下需求规则,看看是否还有别的方案?”我说道。
第二轮:切入正题
其中一位客户(即需求提出者)说:“我们的规则很简单,就是员工弹性上班,只要核心时段在岗就不会有异常,每月最终看总出勤工时,如果超过标准工时即可。现在系统无法满足,所以XX说拉你们技术的人看看,有什么解决方案。”
我说:“咱们班次8:30-17:00,员工10:00来,也不会有迟到,是吧?”
她说:“是的,文档里都有描述。”
我说:“咱们是怎么定时标准工时的?是按照法定标准日历的工作日天数,还是按当月排班的天数?”
她说:“就是日历上的工作日天数。”
我说:“如果遇到法定调休工作日,也正常算,是吗?比如10月、9月法定放假后,都会有调休的工作日。”
她说:“是的。”
我说:“好,如果员工有请假的时候,咱们是怎么计算工时的?比如全天、半天或几小时。”
她说:“我文档里都有写。”她边说边开始分享屏幕,并把鼠标拉到文档的那句话,并说到:“各种申请假期都是从8:30开始,17:00截止。”
我说:“举个例子。如果员工请假全天,那当天的实际出勤时长是8小时,还是?”
她说:“8小时。”
我说:“如果请假半天呢?比如请假上半天,回来是否还需要打卡?”
她说:“我们要求员工回来必须打卡,请假时长和出勤时长就是员工当天总出勤时长。”
我说:“如果按小时请假8:30-10:00,员工却在9:30打卡上班,晚上17:00打卡下班,那9:30-10:00既是请假时间,又是打卡范围内的时间,咱们期望怎么处理?”
她没有回复我的问题,而是会上问了另一个子公司的HR:“XX,你们那边是怎么处理的?”
对方回复到:“我们这边没有这个问题,按原则说,肯定不能重复计算时长。”
我追问到:“目前我们可能不一定可以去重,这个必须处理吗?”
第三轮:客户被激怒了
她说:“你们到底有没有认真对待我们的需求?你们有没有提前做准备?我们今天几个人开会,需要的是一个解决方案,而你在这东一句西一句的问,很多问题我文档里都有写,你们也不认真看,你们可以分享今天会议做了什么准备吗?当时实施很快,运行一个月下来,员工反映比较强烈,今天把采购一起拉上,就是需要一个解决方案,你们内部到底有没有重视我们的需求?”
销售紧急补充到:“咱们的需求我们肯定重视,我们内部也沟通多好几次,但技术伙伴有咱们的需求规则有些需要了解,也是期望了解清楚后,可以有个好的解决方案。这个问题是怪我,没有提前梳理一个文档,提前发给咱们这边,那你看咱们今天是先这样,我们梳理好问题后再沟通,还是继续沟通清楚后,境哥看看能不能直接给出一个解决方案。”
说实话,此时我心里也有了些许情绪波澜,但强制自己压住情绪。
“耐心”地解释道:“因为咱们之前的方案,基于现状肯定不行,所以我需要回到需求本身,了解清楚你们的细节规则后,才可能评估是有有新的方案。我提问的逻辑是从每月标准工时的定义,到每月实际出勤工时的定义,最后就可以得出一个当月差异工时。但实际出勤工时会涉及到每天怎么计算,请假怎么算,加班怎么算,外出怎么算,出差怎么算等细节问题。那咱们今天是继续沟通,还是梳理个问题清单后再沟通?”
她说:“继续吧。”
第四轮:DISS后的小心翼翼
我心里的情绪缓少了些许,但小心翼翼的情绪多了一些。所以就选了一个最容易切入的问题。
继续问道:“文档里提到员工当天有晚餐,就要扣除30分钟实际出勤时长,怎么定义有晚餐?系统可能需要规则。”
她说:“你们系统可以有个地方,让员工每天勾选一下,有晚餐,或没晚餐。有就扣,没有就不扣。”
我的情绪又起了波澜,但我理解她对系统认知的有限性,耐心的回答到:“这个可能不太行,咱们是否可以有别的定义?比如每天晚上打卡时间超过9点就算有晚餐。”
她说:“好像也可以,每天晚上打卡超过7点就算。”
我说:“如果员工当天有请假,比如请假上半天,那晚上打卡超过7点,也还是正常算晚餐吗?主要是考虑请假时,要不要有什么特殊逻辑,因为有的企业在扣款或补贴时,都会考虑请假的情况。”
因为有了前面被DISS的经历,所以我开始刻意补充为什么问。
她说:“不用,不管是否请假,只要吃晚餐就扣。”
第五轮:渐入佳境
我说:“好,那咱们员工有外出、出差什么的吗?”
“有。”
“咱们外出、出差的最小单位是天,还是小时?”
“外出可以按小时或半天,最少0.5小时,出差只能一天。”
“那外出、出差时,是否需要打卡?还是直接申请就可以了?”
“不需要打卡,审批就行。”
“那外出、出差时长,最后也算出勤工时,对吧?”
“是的”
“好的。最后,再给你们对齐下需求。”
第六轮:收尾阶段
“咱们期望员工可以看到哪些数据?是只要每月标准工时、实际出勤工时、差异工时就行,还是必须有每天明细?”
“主要是每月统计数据,每天明细最好也有。”
“咱们期望员工在哪里查看?比如手机端、电脑端”
“如果手机端麻烦的话,咱们可以先在电脑端,至少先让员工可以查看。”
“好,那管理员端呢?”
“管理员也一样,可以看到员工的工时情况。”
“咱们有几个管理员?”
“现在有4个,我是管理全部员工,还有3个考勤专员,XX是管理XX,YY是管理YY。”
“好的,那我这边基本了解清楚了,我今天会梳理方案,预计下周一下班前跟你们一个回复。”
此时,销售问道:“那老师们还有其他需要沟通的问题吗?如果没有,我们下周一给咱们一个答复。”
“没有了,咱们今天就到这吧。”
“好的,拜拜。”我说道。
会议结束后,我花了周五大半天的时间,重新梳理了方案以及预估人日,准备下周一给客户报价,咱们未完待续。
反思
首先,会议目标不一致。客户预期目标是沟通会上有解决方案,而我的预期目标是沟通清楚需求。这就造成双方预期目标,在会议开始前就有了偏差。
第二,信息差严重。客户会认为需求提前已经同步给我们的实施、销售同学,你开会前一定是知道了全部信息,而当我问到一些细节问题时,她会觉得你不用心,你没做准备工作。
第三,思维方式差异。客户对系统是“小白”级别用户,她们的思维方式不会非常严谨,都是基于问题和“需求”展开,属于感性思维;而产品经理的思维方式,跟研发、测试打交道较多,就会形成“专业化”思维,确保逻辑闭环、规则明确,属于理性思维。
第四,沟通方式。沟通能力对产品经理是一项关键软技能,如果你无法有效提问和沟通,容易激发客户的防御心理,产生一种被“咄咄逼问”的感觉,情绪累积到一定程度后,就会产生像男女朋友之间的吵架模式,从一个点转移到一条线,开始细数你的“不是”,你的产品的“不是”。
最后,情绪管理。沟通能力是可以有效提升,前提是你需要懂得情绪管理。比如在客户情绪激动时,你不能继续火上浇火,你一定要控制自己的情绪,其次才是解决客户的情绪,最后才是沟通需求与规则。
总结
第一,提前做好问题清单。如果产品规则复杂时,跟客户沟通前,一定提前梳理好问题清单,并提前发给客户,让对方心理有预期,也让客户看见你的诚意。比如案例中,对我而言,所需提问的内容,基本上就是一个公式:差异工时 = 实际出勤工时 – 标准工时,只要把每个定义沟通清楚,基本就结束了,但对客户来说,你就是在”瞎问“。
第二,对齐目标与预期。会议开始时,提前跟客户就目标、预期先达成共识,再开始沟通需求与细节。比如案例中,开会前双方预期就存在较大差异,而没有达成共识。
第三,提前与客户同步你的想法与意图。比如案例中,提问开始前,应该先解释说“咱们现在的解决方案是有问题的,这条路不通,所以我可能需要花一点时间,提前跟你们沟通清楚原始需求,我会从标准工时、实际出勤工时的计算逻辑开始沟通,最后跟你们对齐你们的预期,然后我在基于今天的沟通情况,提供咱们一个解决方案,你看可以吗?”
第四,提问时,多解释“为什么问”。比如“咱们班次请假时间从8:30-17:00开始计算,但我们系统会有三种的请假方式,所以可能需要跟你确认下规则,否则影响实际出勤工时的计算。”
第五,不要连续追问超过3次,否则容易激发防御心理。如果一个问题需要多轮询问时,一旦超过3轮后,最好就缓冲一下,比如垫一句“这块场景可能有点复杂,但又比较重要,所以需要问的细致些。”
最后,不要问让用户“难堪”的问题。有时,你心理会预设用户“傻白甜”(比如如果员工晚餐就扣减30分钟的问题),期望展现你的“专业性”,结果往往会导致客户在这“输”的(比如请假时间与打卡时间重叠计算问题),全在别的地方找补回来。
写在最后
产品经理每天的日常工作,都在跟不同人打交道,他们角色、岗位不同导致立场跟思维方式有差异,我们不应该采取“专业化”、“标准化“的手段,抱着一种“我要赢你”的心态进行沟通,否则一定会产生各种吵架、DISS。
比如跟研发、测试沟通,他们需要的是严谨、闭环、合理的确定性,而会忽略用户场景、用户频次,甚至企业成本;
跟设计沟通,他们需要的是用户场景、设计感、审美,而会忽略产研实现成本;
跟销售沟通,他们需要的是达成目标,完成签单,而会忽略你的感受以及企业的成本,只要可以签约,即使承诺需求而“浪费”产研资源也无所谓(典型的公地悲剧);
跟客户沟通,他们需要的是解决问题,而会忽略你的逻辑、规则以及成本。
所以,作为产品经理,你就需要跟不同人沟通,采取不同沟通策略。有时需要“小白思维”,有时需要“老板思维”,有时需要“产品思维”,而有时只需要“正常人思维”(即常识判断),真正做到“见人下菜碟”。
今天所分享的全部内容,本质就是产品经理的两大软能力的体现:同理心、沟通能力。
我还有很长一段路要走,虽然好像已经工作多年,却还在这方面反复跌倒。
咱们未完待续。
专栏作家
邢小作,微信公众号:产品方法论集散地,人人都是产品经理专栏作家。一枚在线教育的产品,关注互联网教育,喜欢研究用户心理。
本文原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自 Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
有效沟通对于一个产品经理来说是很重要的一件事
是的,还在路上,分享的目的也是为了总结、反思
不管从事什么行业,出来赚钱只要不是大甲方多多少少都会受点气,这也很正常。
是的,所以情绪控制、沟通技巧、同理心就很重要,也是需要不断总结、反思