"/>
关注并将「人人都是产品经理」设为星标 每天早 07 : 45 按时送达 作者:墨饕 题图来自Unsplash,基于CC0协议 全文共 XXXX 字,阅读需要 5 分钟 ——————/ BEGIN /—————— 4月8日,“学信网崩了”的消息,又冲上了微博热搜。 一时间,不仅是正在操心考研的同学们焦急万分,冲入微博吐苦水,各路吃瓜群众也纷纷玩梗留言,让微博上的讨论声格外热烈。 其实,对于网站、APP崩溃的事情,大众虽不说习以为常,但也见怪不怪。 毕竟,一年365天,还会有阴晴冷暖。一个产品持续运行几年,若只出过一两次崩溃问题,也算是智者千虑必有一失,是可以理解、原谅的。 就连头部产品,也难免出现崩溃的问题。 比如,近在眼前,10天前,电脑版微信出现故障的事情,也在微博上掀起了热烈讨论。 有趣的是,即使是微信这样一个几乎占领每台入网手机、拥有极高使用频率、以社交为核心的产品,在出现故障时,也会在微博上进行声明。 远不止微信,近年来,微博早已成为了著名的“报丧圣地”。 淘宝、B站等平台,在出现故障的时候,都多次登上了微博热搜。 甚至还有过多平台集体崩溃,纷纷涌入微博“报丧”的情景,一时间盛况空前。 别看“报丧”不是什么好事,若想做到为每个产品“报丧”,绝不是一件简单的事情。 这种事儿,不是谁都能做到的站在吃瓜群众的角度,“报丧”只是发泄一下不满、看个热闹。 但站在产品方的角度,这并不是一件小事: 在产品出现故障、且无法通过产品内的信息渠道与用户产生联系时,如何能尽快与用户建立连接、说明情况、缓解不满,并在产品完成维修后第一时间通知用户。 这就意味着,需要在产品之外,找到可以与大部分用户建立连接的途径。 可口可乐运营官史蒂夫·海尔曾经说过:“假使有一天,我一无所有,但我只要有可口可乐这个牌子,我就能重新发展与之相同的另外一个可口可乐公司。” 如果今天真出现了这个情况,他第一时间该做的事情,就是马上在公众社交媒体上发布一条消息:“可口可乐需要你的支持!” 当然,他第一时间发消息的渠道,应该会是国际版的微博——twitter。 无论twitter还是微博,之所以能承担起如此重任,不得不说,他们自身的一些特性,对“报丧”而言,可谓得天独厚。 1. 开放性1)信息自由流通 在产品出现故障、无法登录时,无论是产品官方主导的广而告之,还是用户之间热议引发的讨论热潮,归根结底,是建立在信息自由流通基础上的。 比如说,也会有其他用户,在微博之外的社交媒体,讨论某个产品崩溃了的事情: 你正在办理考研相关事宜,结果学信网崩溃了,你和你的同学,在微信里大吐苦水,抱怨学信网不靠谱。 无论你们讨论的多么激烈,讨论了多少句对话,你们讨论的信息,只有你们彼此知道。 不会被其他平台收录,不会与另外两个学生之间的微信抱怨,造成几何量级的相互影响。 即使你们是在微信群里讨论,看到信息、参与对话的,不过也就几十、几百人,传播的量级与速度有限。 但在微博中,官方发言、博友之间的相互讨论,在同一话题下,就有机会引发叠乘效应,引起更多人发表观点,将信息快速扩散。 只要信息本身质量足够,微博迅速传播的效应,将会最快让更多人知晓。 2)高覆盖率 如果你是十几年的老网民,我想你应该知道,过去也有另一个报丧圣地:贴吧。 但凡哪个网站崩了,哪个网游无法登陆,用户就会大量涌入贴吧当中,了解情况、吐槽服务器。 因为贴吧,在一定程度上,也具有和微博相似的特性。 但时至今天,贴吧已经不再是曾经的报丧圣地。 贴吧的活跃用户量,已经随时代的更迭,大不如前。 即使还能进行告知,但无人关注、无人讨论的情况下,这些信息,也就会不了了之。 当然,就算是微博,也一定有人不看。 不过,一来,由微博所引发的线上线下二次传播,可以覆盖到的群体,远不止微博用户本身。 二来,在崩溃这种突发情况下,能覆盖到大多数用户,就已经是最优解了。 3)便捷低成本 既然说到了贴吧,就不得不提及论坛。 尤其是彼时的NGA论坛,作为魔兽世界游戏玩家的专属论坛,在目标用户中拥有很高的覆盖率,它在当时,也承担起了对口“报丧”的重任。 遇到账号无法登陆的问题,玩家就会冲入NGA论坛,看看是不是服务器崩了,然后一起吐吐苦水。 这无疑是个有效的途径,在产品之外,额外建立一个与用户有效交流的平台。 但放在今天看,这毫无疑问是极为奢侈的事情。 NGA过去的兴盛,有着它时间、类型、市场的局限性。如果产品本身的类型不合适,或是产品的用户粘性不高,这个平台即使搭建出来,也无人问津。 而那些用户粘性高的产品,普遍在产品内部,就已经拥有了有效、快捷的信息公示、交流渠道。 虽然,产品故障崩溃几乎谁都会遇到。淘宝逃不开、微信逃不开、B站逃不开。 但是,对一个产品而言,它终究不是每天都要面对的问题。 若是为了产品某天崩溃的可能性,就搭建一个额外的交流渠道,无异于舍近求远、分流用户。 不仅得不偿失,而且极费工夫。 2. 时间性1)即时 对一个产品而言,尤其是拥有一定用户基础的产品而言,产品崩溃之后的那几分钟,或许是懵逼人数最多的时候。
如果他们短时间无法得到合理的解释、回应,不满的情绪自然发酵得很快。 而在微博上,就可以达到快速建立联系的效果。 特别是当下,微博已经挂上了“报丧圣地”的印象下,这一即时性会更为显著。 在某个常用软件无法登录之后,焦急的人们,可能会第一时间冲上微博,看看官方有没有说法,看看别人怎么评价。从而分辨,究竟是自己个人的使用问题,还是产品本身出现了故障。 2)持续 除了这部分正在使用产品、正在登录产品的用户外,一定还有很多用户,是后知后觉的。 在产品崩溃的这段时间里,他们随时有可能登录,随时有可能使用。他们的时间并不确定,可能集中在某个使用高峰时段,也可能随机分布在全天候。 但在他们遇到登录、使用问题的时候,他们却需要一个解释、一个承诺。 对于这些后知后觉、随机分布的用户,微博上信息的持续性,也能很好地对他们起到告知作用。 如果是大产品,崩溃的消息登上热搜,大家热议讨论,用户自然可以看到。 即使是小产品,发生崩溃的当下,讨论的人少,官方消息看到的人也不多。但这些声明、讨论,却也可以持续挂在那里,供后来的人了解情况。 3. 双向性1)沟通功能 在广而告之的同时,摆出冷冰冰的姿态,自然不是好的选择。 本就因为产品崩溃而感到不满的用户,更需要发泄与安慰。 而在微博上,良好的双向沟通功能,也能让产品方有机会,进一步安抚用户。 不仅是发布道歉声明,在评论中也可以与一些用户继续沟通,或是去其他人的微博下方说明情况,都可以轻松实现。 这既能缓解个别用户的过激情绪,避免带来问题扩大化,又能够为产品树立体贴用户的形象。 而且,不限于沟通,帮助个别用户解决崩溃时的特殊需求,在崩溃治疗后收集用户的反馈,也可以在微博上办到。 危机,也是机遇系统故障,对产品来说,自然是一种危机。 如果处理不当,会带来不小的损失。 最直接的,用户会对产品的可信度产生怀疑。尤其是对于经历两次以上崩溃的产品,更是如此。 而对于深度用户来说,这种失望更是强烈。
产品崩溃的时候,也是用户尝试竞品的时机,我们自然不希望看到。 但若崩溃已经发生,成为了既定事实,叹息已经无用。 如何从崩溃中尽力挽回用户,才是最应该去考虑的。 每一次崩溃,都是上天赐予的一个机会。 1. 聚拢额外关注产品崩溃,作为一个微负面话题,本就是容易引发讨论、容易玩梗的。 在这过程中,吸引比往日更高的关注,也自然而然。 只要官方措辞适当、引导得当,而且崩溃频率也不要太高,崩溃本身,是可以作为一个热点营销事件来运作的。 例如芒果TV,在APP崩溃的时候,借助适当的剧透,营造出“好奇却又看不到”的气氛。不仅没有因崩溃受损,反而还拉了一票吃瓜群众入坑。 2. 深度接触用户有些产品,因为自身属性问题,平时缺少与用户沟通的机会。 比如工具类产品,用户需要的时候拿起来用,不需要的时候不会看一眼。 或许只有在出现故障时,大家都去微博围观、吃瓜,才会和官方有这么个短暂的交流。 这是极为难得的机会,与用户在使用产品之外,产生交集。 如果利用好崩溃的机会,能让部分用户,摆脱把产品只当成工具的看法,产生情绪上的交流与认知。 3. 补偿出师有名在道歉之后,就要谈到补偿了。 如果你只把补偿当成是额外的成本,那它就是一次亏损。 但崩溃时的补偿,其实是一个不可多得的契机,让你的福利出师有名。 平日里,运营人都在想方设法地创造机会,编出100种节日,跟用户互动,让用户领福利。这个自然天降的福利契机,当然要抓起来。 比如B站,在崩溃之后,赠送所有用户1天大会员。 这种补偿是合情合理、有趣味性的。 不仅能让受损失的用户感受到补偿,还可以拉其他人来白嫖,起到挽回沉默用户、拉动新用户的效果。 4. 做好崩溃预案当然,以上种种,都建立在崩溃已经发生的基础上。并不建议主动搞崩溃,来玩负面营销。不要去试探用户的底线,小心有一天把自己玩没了。 但正因如此,建立崩溃应急预案,是非常有必要的。 毕竟,谁也不能保证,今年自己会不会崩。 与其在崩了之后,大半夜慌慌张张开会,琢磨一套磕磕绊绊的道歉词,倒不如提前准备好一套文案,商量好挽回用户的补偿,未雨绸缪。 老话说得好,机会留给有准备的人。 在哪天有需要的时候,就能派上用场。 写在最后想要成为“报丧圣地”,真不是一件容易的事情。 想要同时满足文中提到的几点特性,在国内,除了微博,几乎无人可以办到。 这也就是,每当有产品崩溃时,大家都第一时间涌入微博的原因。 若真有一天,微博自己崩了。热心用户和吃瓜群众,该去哪里狂欢呢? 各个平台零零散散,或许也难成规模。 我想,等微博活过来的时候,会给自己报丧: 把“微博崩了”,挂上微博热搜头条。 —————— / END / —————— 产品经理培训|产品运营培训|企业内训服务 请在公众号后台回复「培训」了解更多 ▼ 喜欢请分享&收藏,满意点个赞,最后点「在看」 ▼ 上一篇:打工人的2022:居家办公、抢菜、N+1、跳槽失败. 下一篇:【TypeScript教程】05—理解TypeScript中的类型注解 |