在淘宝做直播中,也是有一些不要踩到的雷区的,对于这些雷区,各位踩到了可能就会要求强制下线了,在本文中,九头蛇电商就跟大家来说说淘宝直播中需要避免的那些雷区,来帮大家避免踩到相关的雷区。
直播这个领域,一直是互联网管理比较严格的地区,提供直播的平台,必须取得执照,才能提供直播服务,作为国内电商第一平台,淘宝直播有着世界先进的防违规技术,别说在直播间贴个二维码了,你敢露一点事业线,你的直播间就会在10秒内立即被下线,并收到处罚通知,所以,如何在直播间不踩雷,就成为了核心必修课。
我先讲一下直播间的审核,如果想要获得淘宝首页的公域浮现权,直播必须要先做预告,预告会审核标题、主图,还有直播间挂的商品。
在这个过程中有一个注意点,就是必须在开播前一天的下午16:00之前做预告,这样第2天的直播才会有浮现权,才会有公域上的生效。
其次,不管是直播间的内容也好,还是直播间的场景也好,开播后的10分钟,可以查看淘宝主播APP,如果没收到违规提示,说明直播没问题,就会获得公域浮现权。
我们来看一下直播间的雷区:
第一,不能出现政治元素,包括支持国货、反对日货等都叫做政治元素;
第二,不能涉黄、涉毒、涉赌。特别是涉赌这块,比如和观众互动,猜中送东西,这是不允许的,但是现在有一种直播间流量很大,权重很高,就是算塔罗牌的,这是可以的。
第三,不得进行敏感表演,比如跳艳舞,或者扭一扭晃一晃这种都是不行的,这都算敏感表演。
还有直播间的整体装修,简单来讲就是明亮大方,千万不要贴牛皮藓盒各种大字报,这种都是不行的。
还有就是直播间千万不要挂机,如果空镜头超过15分钟,直播间也会被降权,直播间可以有画外音,比如女装直播时要换衣服,可以让助理通过画外音的方式跟粉丝聊天。
我们接着看对主播的着装要求,具体请看下方配图,如果做内衣直播,只能拿在手上比划一下,但是在胸前比划是不行的。
还有主播的行为要求,其实就是一句话,你能想象到的出格的事都不能做,你可以自己开脑洞想像一下。
最后就是主播的语言要求,就是不能讲粗话、脏话,并且禁止聊政治话题、色情话题、播放侵权影视作品。
比如说主播播得累了,请大家看部电影或者动画片,休息放松10分钟,这也是不行的。
还有就是禁止攻击、谩骂、调戏、骚扰、传播不实报道,说白了就是只能粉丝骂你,你绝对不能跟他对骂,所以做直播时,一定要注意尽量不要踩到这些雷区。
作者分享了自己处理badcase的过程,完整走完case处理流程,基本上就能形成一个闭环,避免自己成为处理问题的传话筒”。
一个产品经理在日常工作中不可避免的内容就是处理业务badcase,但是往往很多时候在接到用户问题反馈后,PM在处理的过程中无意识地把自己的角色变成了很多研发口中的传话筒”。
下面举个栗子:
问题反馈人:XXX地方功能不好用/有XXX问题。
PM:(收到问题后直接将问题截图给研发处理)
研发:我试了一下没问题啊。
PM:(找问题反馈人传话说没有问题,啊再试下)
问题反馈人:还是有啊(再次截图)。
PM:(收到反馈人的二次反馈,再次直接截图用户反馈的问题给研发处理)
研发:……
如果大家在处理badcase的过程中有传话筒”经历,那么大家一定一定要改变这种问题处理思维方式。时间长了这个传话筒的角色很容易被pass或者优化掉,同时也很难提高自己的业务能力水平。
今天和大家一起分享一下,我自己总结的处理流程,主要分以下六个步骤进行:
清晰、完整地陈述问题;
亲自验证问题存在的真实性;
了解对应功能的整体流程;
排查问题可能产生的原因并给出对应的解决方案;
找对应的研发或相关人员去解决修复并自测;
告知给反馈人及相关人员处理结果。
接下来详细说明一下每个步骤描述及注意事项:
一、清晰、完整地陈述问题
很多时候PM接到的用户反馈仅仅是一句XXX功能不能用”,PM在接到这句话之后要什么呢?
应该弄清楚问题在什么条件下发生的:什么用户,用什么设备,在什么场景,什么流程环节,出现什么问题,导致的结果是什么?是否还有其他场景也同样出现?
这些问题完全弄清楚之后才叫清晰、完整地陈述问题”。
二、亲自验证问题存在的真实性
用户反馈的问题是真是假?是否真的存在?是不是用户手机的问题?或者是网络不好?或者遇到公司后台在修改系统平台?……自己一定一定要自己验证测试一遍,验证问题是否真实存在。
排除个人场景下的异常情况,不然可能存在其实没什么问题,听信一句用户反馈就直接报到研发那里;如果研发测试之后,没有任何问题,这会让你很尴尬。
三、了解对应功能的整体流程
有时候用户反馈问题的功能,PM自己都不清楚到底怎么用。复杂的系统下,每个场景流程很多时候是不同的。
当PM自己都不知道流程怎么使用的时候,很难去排查问题原因所在。尤其是对于中间刚接手业务的PM来说,一定要多了解业务,多熟悉业务流程,可以通过多看之前的产品需求文档(PRD),重点看里面的业务流程图。然后自己对着流程图操作几遍,或者多和业务研发聊聊业务流程,快速掌握自己负责的整体业务流程。
四、排查问题可能产生的原因并给出对应的解决方案
排查问题产生的原因这一步有点难。判断是建立在很熟悉业务的前提之下的,一般的badcase产生的原因可能是参数缺失,参数传值错误或者其他流程环节问题关联导致的。PM在处理badcase过程中最大的价值,是通过分析原因之后,提炼出引发问题的可能原因,并能给出对应的解决方案。
五、找对应的研发或相关人员去解决修复并自测
一个PM在处理badcase找研发沟通处理问题时,除了完整、清晰地陈述问题之外,如果能直接给到RD引起的可能原因,并且给出对应的解决方案,研发对于你的表现一定是有惊喜之感的。
步骤四真的很多PM都做得不好,研发也会因此而吐槽产品是传话筒”一样的存在。因为你前面的排查原因可以让研发人员更快定位问题所在,大大节约了排查时间。
另外,在研发定位问题并且修复之后,一定要自己测试一遍,确认问题已经完全修复完毕。
六、告知给反馈人及相关人员处理结果
在互联网职场有句话比较火事事有回音,件件有着落”。
既然用户已经反馈了,一般都会在等处理结果,PM在处理的过程中要做好做事形成闭环,达到最后的结果有着落。别把case跟着跟着就丢了,把最后的处理结果反馈给问题的上报人。
以上六步就是我在处理badcase时,所走的步骤流程。完整走完case处理流程,基本上就能形成一个闭环,避免自己成为处理问题的传话筒”,在这里和大家一起分享一下。
留言与评论(共有 条评论) |