运营案例复盘:拼团项目

总结不在于回顾与记录,而在于在复盘中可以得到经验教训,得到更快速的成长。总结虽然很费脑力,但作为一项工作中最具收获的环节,怎么可以放弃呢,所以我拖到今天,还是把总结奉上了。

一、项目介绍

我们的产品是微信活动营销工具,商家可以在管理后台创建诸如大转盘、投票的互动活动。此次部门准备拓展商业促销类活动类型,也就是电商常见的砍价、秒杀活动,便于有卖货需求的商家做促销活动。我负责拼团的项目。拼团的玩法由来已久,但在拼多多的影响下,在微信又刮起了一股浪潮,借助微信的强大社交属性,开展拼团活动的确是做促销的不二选择。

项目成员包括4人,一个喜欢用PS开车的设计师,一个爱提需求的后端,一个顶着全部门最快称号的前端,一个鸡蛋里挑骨头的测试,以及一个对改需求乐此不疲的产品经理。拼团从今年6月份立项,花了3周半的时间才完成需求文档第一版,文档经过多次修改,7月底进入开发阶段,10月中正式上线。

二、需求分析

(一)前期调研

一开始只是确定了要做带支付的拼团,但拼团的玩法很多,需要先确定拼团的底层玩法是什么。因此我对比了相关竞品的拼团玩法,包括嵌入在商城的拼团,拼团app,还有提供拼团活动的工具型产品。在这一步,只是查看这些竞品的底层玩法,而在后期进行业务流程设计时我又再度查看。

(二)定位

经过对主流拼团玩法的调研,结合自身产品的情况,确定了拼团的底层玩法采用当前主流的“达到参团人数后全员都能以拼团价购买的形式”,主打的特色在于能快速创建一款可变现的拼团活动。并将该活动取名为“天天拼团”,那时是想着像腾讯的天天游戏系列那样,如果做出多个该类型的活动,那一致性的前缀,其实是有助于增强产品关联和用户认知的(虽然很土)。销售对外也能说“做电商促销就用我们的天天系列”,想想觉得还挺爽。

三、业务流程

(一)业务板块

确定好对拼团的定位后,我开始考虑一个带支付的拼团,都需要哪些底部板块,才能维持活动的自运转。可以分为营销设置,支付设置,商品管理,发货设置,退款退货,以及拼团最重要的分享逻辑。

营销设置,第一版只挑选最为核心的功能,后面的功能再迭代。

支付设置有两种,成团前付费有利于商家快速变现,但不利于推广,尤其是缺乏背书的中小商家,利用第三方的拼团工具,其实较难取得粉丝信任。因此我们推出另一种支付模式“成团后付费”,即满团后再进行支付,但由于不限制每个人都付费,所以可能会造成客户流失和收入损失。前者更适合变现,后者更适合推广。双管齐下,由商家来选择。虽然增加了开发难度,但我们认为是值得的。

运营案例复盘:拼团项目

底部模块

(二)用户流程

在确定底层板块后,梳理用户流程就很轻松了。从用户进入首页到完成支付,过程基本与一般电商的购物路径无异,但由于我们定位为快速创建,所以缩减了许多设置与路径。

运营案例复盘:拼团项目

用户流程图节选

四、页面交互设计

节选首页,订单页和商品详情。

运营案例复盘:拼团项目

交互稿节选

五、推广策略

在10月中旬已经上线,但并没有大力推广,等到宣传双十一新活动时再一起推广,因为拼团+双十一带来的效果是翻倍的。包括在官网和商家后台增加banner位,在活动类型新增类别“商业促销类”,提前两周发布拼团的宣传推文。

六、经验总结

根据以上的复盘,我发现有以下的不足和改进方案。

1.调研耗时太长

竞品分析当时做的比较乱,因为我不了解项目,也并不清楚需要调研哪些方面,所以花了很多时间去调研,效率不高,效果也不好。现在回头看调研的资料,发现可分为梳理拼团的玩法,不同玩法的优劣势,营销设置,用户流程等。现在回顾,其实面对一个陌生的领域,不应该马上进入细节,而要先思考框架,如果无法找到框架,也可以列出所有信息,用自下而上提炼的方法找到框架,然后再开始细节。这样做,一方面可以提高调研的效率,一方面也可以使调研资料更有条理,便于后期回看。

2.做产品定位主观因素强

做产品定位时虽然有思考,但主观因素较强,对实际的环境缺乏了解。现在看来,其实拼团产品更大的意义是在于丰富了我们的商业促销类活动,带动高级版本的销售。而对用户而言,由于我们产品的定位本身就是轻量级,所以也无法提供一个带有完整设置(物流、商品管理等)的拼团产品。因为这个限制是无法改变的,所以更应该思考,在这种限制下去做此项目,用户是否买单。

这给我的一个启发是,做产品定位需要做环境分析(比如SWOT分析法,适用于宏观环境分析),作为一个子产品,它相对母产品的战略定位是什么。战略定位其实就限制了很多东西了。以下是我后来利用swot做的分析。

运营案例复盘:拼团项目

swot分析

3.技术无法实现导致屡次修改方案

支付环节是调整次数最多的。由于是调用微信支付接口,微信的支付逻辑是到了开发阶段才发现某些地方走不通,而且不是一次性发现,是开发过程中才不断曝光,因此屡次调整文档。耗费了较多时间。但这个也是只有在开发过程中才能发现,无法完全避免。

4.商家场景多样化甚至互为矛盾,无法全部满足

举例子说明。当商家的剩余库存小于开团要求人数时,是否允许粉丝开团?如果不允许,会造成库存浪费。如果允许,则要求商家必须及时补充库存。后来我们采用后者,因为考虑到商家的诉求应该是尽量清空库存,所以我们的逻辑做成只要有库存,就能开团,但是当最后一个粉丝提交订单时,需要判断库存是否够全组人扣,如果不够,则提交订单失败,并提醒其通知商家添加库存。

后来有一个商家因为这个逻辑找过来,说我的库存的确就这么点了,你们还让人能开团,这不合理。

当时设计时的确没考虑到这种情况,我当时认为大多数商家应该都是供过于求的,并且是可以快速补货的。现在我已经想到了两全其美的办法,但仍不能掩盖我没有真实了解电商行业的事实。我在第一次考虑时,自认为那应该是大多数人的场景,然而那只是我的一厢情愿,没有现实依据。准确的判断来源于充分的依据,在于你对用户的了解程度。

这个给我的启发是,在遇到多样化的场景时,应该考虑主要场景并去满足,而次要的场景,应该衡量交互成本、开发成本后再看是否要满足,但如果是与主要场景矛盾,那就应该重新斟酌是否要兼容了。当然,对于场景的考量,必须建立在准确判断上,否则做出的都是错误决策。

weinxin
我的微信
这是我的微信扫一扫

发表评论

您必须才能发表评论!