实例讲解拼团活动如何设计

　　本文主要是作者结合最近两周做的拼团活动，来细说拼团背后的逻辑，按拼团的整个流程来讲解。
　　营销手段除了优惠券，还有拼团这种常见模式。提起拼团，大家自然而然地想到拼多多，在流量红利已经触底的情况下，以拼团这种新模式杀出一条血路。
　　传闻今年3月份，拼多多月GMV已经达到400亿的规模，交易额超过京东的13（京东月GMV约1100亿）。
　　页面上的发起拼团或去拼团按钮大家都看的到，但是否真正思考过其背后的逻辑。
　　接下来我将结合最近两周做的拼团活动，细说拼团背后的逻辑，按拼团的整个流程来讲解。
　　一、创建拼团活动
　　拼多多的所有商品都有拼团模式，淘宝、京东或其他平台只有部分商品有拼团模式，两种后台设计肯定不同。因本人此次负责的项目是后者，故以此种类型谈如何创建拼团活动。
　　实例设计
　　创建拼团活动页
　　创建拼团活动的过程中，至少包含以下元素：拼团活动时间、成团有效时间、成团人数、每人限购、可开团商品和拼团活动状态。
　　1。拼团活动时间
　　可开团商品的拼团活动时长，如一个商品的拼团活动时间为6月28日00：00：00至7月3日00：00：00，这个时间段内，该商品可开团，用户进入商品详情页可发起拼团或参与拼团。
　　2。成团有效时间
　　用户开团后与其他人组团的时间，该时间内没有组团成功将拼团失败，系统自动退款。特别注意的是：因为引入了这个字段，会有某用户对某商品的实际拼团结束时间。
　　实际拼团结束时间发起拼团时间成团有效时间（发起拼团时间发起拼团人的支付时间）
　　什么意思呢？
　　举个例子来讲：若该商品的拼团活动时间为6月28日00：00：007月3日00：00：00，成团有效时间为24小时，则7月3日0点以后，该商品不可再开团，但已开的团用户还可以参团，即该活动实际在7月4日00：00：00结束拼团促销。
　　3。成团人数
　　凑够多少人满足拼团条件，限制条件为至少2人。
　　4。每人限购
　　每人最多购买多少件，拼团商品因价格较便宜，根据预算看是否需要配置该字段。
　　5。关联商品
　　前面四个字段都属于拼团活动的基本属性字段，我们要把这些字段关联到具体某一个商品上或多个商品上，并设置拼团价。
　　拼团活动商品创建成功后，商品就被分为普通商品和拼团商品（在商品表里也会有一个字段来标记和区分），拼团活动列表新增一条记录。
　　实例设计
　　拼团管理列表页
　　6。拼团活动状态
　　未开始：拼团活动开始时间当前时间；
　　活动中：拼团活动开始时间当前时间且拼团活动结束时间当前时间；！当前时间且拼团活动结束时间
　　已结束：拼团活动结束时间当前时间；
　　已失效：活动中状态的活动商品手动点击已失效按钮，变为已失效，活动提前结束。
　　未开始状态的活动商品可全部字段编辑，活动中状态的活动商品只能延长拼团活动结束时间。
　　值得注意的是：已结束与已失效的区别在于：已结束是活动到期后自然结束的，已失效是指商家主动提前结束。已结束和已失效的活动商品需要再次发起活动，重新新增一次。
　　在C端怎样展示就看具体的产品设计，在自己负责的项目中，拼团商品我给了2个入口：拼团专场和全部商品列表，是拼团商品的有拼团标签。
　　实例设计
　　拼团入口
　　二、用户发起拼团
　　用户在拼团商品详情页发起拼团活动，生成一条团单记录和订单记录，后台分别对应团单列表和订单列表。
　　商品详情页、订单填写页
　　订单详情页
　　1。团单列表
　　不同的拼团状态，订单ID个数和已参团人数不同，假设成团人数为3人。
　　待成团：发起者发起拼团但未支付，订单ID有该用户的下单数据，发起拼团时间和拼团结束时间为空（此团未开成功，自然不存在发起拼团时间和拼团结束时间之说，发起者支付成功才意味着开团成功），已参团人数为0。
　　拼团中：发起者支付成功，开团成功，已参团人数为1。拼团中状态的订单不可取消，需拼团成功后才可取消。
　　拼团成功：成团人满且都支付成功，此时一个团购ID对应三个订单ID。
　　拼团失败：成团有效时间内，成团人数未满，拼团失败，系统自动退款。
　　特别说明的是，C端拼团商品详情页【和其他人拼团】的数据取自团单数据，不是订单数据。
　　实例设计
　　团单列表
　　2。拼团订单列表
　　拼团商品的订单可合并在普通订单列表，增加一个订单类型字段用于区分，拼团订单列表有查看同团订单跳转链接。
　　订单列表
　　三、拼团页分享
　　拼团的一个显著特点是通过分享进行老带新，更多利用社交关系促进订单转化。这个环节要考虑的是，分享出来的这个拼团活动状态不同，用户看到的页面也不同。
　　拼团失败和拼团成功分别对应活动已结束（不是商品的拼团活动结束时间，是发起人创建的这个拼团活动的结束时间）和人数已满两种情况。
　　大概流程如下：
　　用户进入拼团分享页逻辑
　　到此，一个完整的拼团活动差不多结束了。文中所有的原型图仅供参看，具体视业务而定。
　　四、总结
　　看过一句话：
　　开发的工作迭代是：接需求C再接需求再Coding
　　产品的工作迭代是：实践总结再实践再总结
　　所以本文的最后部分还是总结，每项需求、每周周报都要复盘与总结，现在尽量做到日日总结。
　　1。无论C端、B端，场景要尽可能穷尽，逻辑要尽可能严谨
　　需求不是做完一遍就结束，通常这样只能解决表层问题，场景完善、异常情况多思考、反复问自己才能想到。场景通常越挖越深，越深越宽，呈倒三角模式。
　　比如：在拼团活动商品的下单支付处，要增加该团是否已结束和拼团人数是否已满两个逻辑。这种场景在将一个拼团活动分享到一个微信好友群很常见，多个用户会同时进到该团并下单支付，这和普通商品不同。
　　这点是自己在反复回顾整个拼团流程中领悟到的。
　　2。学会及时地决断
　　我们通常会遇到这样的场景：技术觉得这个功能做着没啥大用，而且实现又麻烦，或者是因为某些原因被迫砍掉一部分需求；或者技术的看法和你的看法不一样；或者在开发的过程中，技术提出了另外一种更好的方案，之前是你没想到的，这时该怎么办？
　　这么多的变化，不可能事事去请教导师或领导，对方会觉得你没有主见，自己必须要学会及时地决断。
　　比如：在做需求时，我将发起人创建拼团活动的支付时间，作为这个活动发起拼团时间，技术说用下单时间就好。当时觉得下单时间和支付时间并无区别，便说可以。
　　后来细细想，如果是下单但未支付成功的团单，都没有开团成功之说，何来发起拼团时间呢。便又去找技术说明这点。
　　最后，说一下自己近期对产品的领悟：做产品最核心的竞争力是产品思维和项目跟进能力，不是会画原型、写文档（想起自己刚做产品时，整天沉浸在画原型中无法自拔，觉得自己画的好看）。产品教给我们的一直都是解决问题的能力，这种做事思路与方法可以解决很多实际的生活问题。
　　我很喜欢苏杰的一句话，他说：
　　我做的互联网产品是我的产品，我写的书是我的产品，我发起的一个线下组织也是我的产品。产品其实没有具体的形象，只要满足某种需求，提升用户体验，就是一个产品，这就是一种产品的思维。
　　只要你能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发起一批人，将这个任务完成，并持续不断以主人翁的心态去跟踪、维护这个产物，那么，你就是产品经理。