两个实用的运营产品设计解析——预售、红包

人人都是产品经理 • 8年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

营销活动产品设计更多需要加上运营的思维，以吸引用户，获得更多流量，而流量的转化则是商城或者平台的价值所在。在众多的营销活动中，预售和红包是两种对用户来讲“边际效应”较大的促销方式，对忠实用户和新用户都有一定的吸引力，尤其是充值送红包还可以在短期内实现一定量的资金沉淀，在此，结合自己参与的预售和充值送红包的产品设计，来跟大家分享一下，欢迎交流指正。

预售

涉及到的用户角色：

商家：发布预售商品，提交预售商品的详情资料。
平台：添加预售商品、设置预售规则、审核商家提交的预售商品、结算。
买家：浏览预售商品、支付定金、提交订单、支付尾款、等待收货。

具体流程根据各平台的规则不同而略有不同。而整个环节的关键点在订单的“状态问题”和“结算问题”以及“库存问题”。

预售订单的状态问题：预售订单若分为“定金订单”和“尾款订单”，定金订单需要增加“待付尾款”的状态，无论程序猿在数据库中做何种合并，买家付完定金后，生成尾款订单，前台总订单状态则应为“待付尾款”，此后，总订单状态则随着尾款订单的状态改变而改变。

需要说明的是，程序猿在预售订单状态的调取中，可以在数据库中增加临时状态来代替“逻辑控制”，由于平台本身的订单状态并没有“待付尾款”，利用逻辑控制就容易造成状态混乱，笔者在实际案例中，就遇到商家发货时订单在前端的显示没有问题，而在导出时，状态就出现了混乱。

预售订单的结算问题：预售订单的结算在数据库中，相当于将两条订单合并为一条订单来向商家结算，如果操作不当则容易出现“对不上账”的情况：商家看到订单已结算，对账时发现，每笔订单总有被少结算一部分的金额，该部分金额即是定金的金额，由于程序猿在合并订单时因为不读取定金订单的状态就忽略了结算定金的金额。

库存问题：关键在于预售的库存怎么设计，是设计一个预算范围内的加库存进行预售，也就是准备预售的商品数量，这种做法对整个后台的改动较小，但是在后期统计由于虚拟的库存，要注意统计数据的问题；还有一种就是不限定预售量，这样的话，即使库存为0也可以继续销售，但是对后台的改动就比较大，开发成本会很高。

后台：如果预售商品是在平台的商品库中选择，就要通过预售商品的ID来进行标记选择，如果预售商品是新导入则在后台设置导入的功能（批量导入），同时设置预售商品列表，在预售商品列表中随时可以编辑和管理预售商品。后台操作的关键在于预售时间的设置，预售时间之前、预售时间内、预售时间后，商品在库的显示状态及定价必须通过运营人员进行准确把握。

预售规则：预售商品的一般规则是先支付定金，定金一般不予退款，天猫商城的预售商品也是如此。设置尾款的支付时间，同时提醒用户及时支付尾款，若超时不支付，则订单自动取消，不予退款。

预售商品的吸引力在于价格的便宜，相当于另一种形式的团购，因为预售同时为商家提供足够的备货时间，合适的商品、合适的价格，足以让预售活动达到预期目的。

充值送红包

充值送红包为本人所在电商平台正在运行的项目，第一天上线，就吸引了大批的充值用户。平台送出一亿的红包，吸引大概5亿的充值数量。主要方式是充值抽奖，靠运营资源的整合。

项目将红包抽奖门槛金额设置为：600元，每充一次600元或者600的倍数，即可获得一次抽奖机会，一人一天可以充多次，红包活动的吸引力在于红包金额的诱惑力，充600最多可以获得666的红包，这是项目一上线便能够吸引大批用户充值的原因。

红包充值中的关键在于红包抽奖概率的算法：不同金额的红包数量是一定的，但是在活动期间内每天分配的数量和概率需要均等，切不可在第一天就让所有人抽中了最高金额的红包，如此便会导致接下来的时间内，用户的充值热情不高，而是每天都要让用户看到抽到最大红包的希望，如此便会热情不减。这种红包产品的弊端在于，“烧钱”成本太高，要有足够的预期能带来可观的销售量，才值得去尝试。

分享红包

这种红包的设计对于拉新来说有很大的好处，同时也能带动活跃沉寂的老用户。我们常见的分享红包设计有滴滴打车、百度外卖、百度糯米、美团等等，在O2O行业最为流行，其原因在于02O行业的盛行和红火。同时得益于朋友圈的传播，比如，今天早上在朋友圈就看到朋友分享的百度糯米红包满30减10元，吸引我去点击跳转如下：