河北省软件开发，全民拼团创新颠覆模式全民拼购，无论成败，皆有所获，

向大伙儿们问好，我是的门门（）这期门门给大伙儿讲讲大家一直非常感兴趣的商业模式——全民拼购

全民拼购模式说明

1.拼单方式：

①“10人团”中抽“3人”;

②中奖者可获得:

A.等值的产品/购物券;

B.(商品价格)10%的“分红积分”;

C.(商品价格)的“购物基金”;

D.(商品价格)5%的“购物金”(前提是该用户拥有“购物基金”，

且奖励不超过“剩余的购物基金”;

不中奖者可获得:

A(商品价格)5%的零钱奖励:

B.(商品价格)5%的“购物金”;

2.拼单规则说明：

①“分红积分”作为“参与平台利润分红的凭证”，不能提现为零钱，同时每月1-5号用户可以将积分用户兑换产品或者转入/转出至“积分池”，6-24号则只

能转入但不能转出“积分池”，25-30号为结算期，需“冻结积分池”，用户不能转入和转出“分红积分”，平台会根据“可分配利润”与“总分红积分”数进

行加权分红。(另:每次转入“积分池”的数量必须为“整百”。)

②“购物基金”可视为“待返金额”，如A用户获得了100个“购物基金”，后续A参与继续拼团后，将以零钱形式返还“购物基金”，直到返完为止。

③新用户参与，成为“1天有效期”的推广员;

用户当天有参与，平台赠送“1天推广员有效期”;

(举例:新用户A参与某个拼团活动，总共可获得2天的推广员有效期。)

④拼团隐藏规则:1.当天次参与拼团并且排位，必不中;

(举例:A→B→C→D→E→…，蓝色为当天非参团，红色为当天参团，则C为此团的“不中奖人”。

2.新人参与且排位，必不中;

(举例:A→B→C→D→E→F.…，蓝色为当天非参团，红色为当天参团，绿色为新用户，则C为此团的“不中奖人”。)

附:1.2版本新增功能大纲

1中奖规则:可设置中奖XX几次后，之后XX几次必不中奖

2、新增订单管理，当未成团的订单后台也能看到

3、关联产品限制:后台可自定义设置实物产品数量(多10个)

4、自动成团:当活动团时间到了还未达到参团人数，系统机器人自动补齐活动人数(必须后台手动开奖)

5未中奖新增赠送积分:赠送商城积分

6限制用户每天参团次数:每天可参团的次数

7每日分红:每天晚上0点结算

分销利润分配(按商品价格)

①推广奖励:2级分销---2.5%，1%;

②店铺奖励:(等级由高到低分别为)5%、4%、3%、1.5%;

③区域奖励:省代2.5%、市代1.5 区代1%;

前端产品/价格展示

前端直接展示“99元/299元/399元/599元…”拼团区，用户根据所选价格直接进入选择，可供选项有“A产品/B产品/C产品/购物券”，用户只能选其一

点点关注，近我者富，评论点赞，多赚千万。搜索，千篇商业方案解析给你听！了解电商软件、商业模式等相关信息的读者，可详细咨询

扩展资料：

首先，从整个业务角度考虑

明确自己是做产品还是项目：

【项目】是客户的；

【产品】是公司自己的。

【项目】满足特定人群或者使用者需求，更偏向于个性化；

【产品】满足特定应用场景或者特定行业领域的需求，更加具有兼容性。

【项目】侧重于时间驱动，因为时间就是成本，满足交付任务即可；

【产品】侧重于功能驱动，更注重体验。

【项目】是以客户的需求为驱动，按照客户的需求进行定制开发；

【产品】是为了满足市场某一痛点可产生的，对于产品的性能以及快速迭代扩展的要求更高。

【项目】型公司可以赚到钱，但赚的是“人头钱”。一般项目公司都是按照工时收费，比如X元/人/天，人/天越多，项目总收入越多。项目越多，需要人越多，人数不够往往需要进行项目排期，公司的总收入也是和人头息息相关。一旦项目太多，人数不够，营收就陷入瓶颈，项目就处于停滞延期状态。

【产品】型公司赚的是产品的使用费或其他增值费，一个很小的团队，只要产品足够好，客户足够多，营收往往不可估量，人均创造价值远大于项目型公司。

再从需求本身考虑

产品客户越多，收到的需求越多，个性化需求也就越多，那么到底要不要接受客户的需求？

首先理解客户提的到底是需求还是方案

需求：我饿了

方案：我想吃馒头

当客户说的是“我想吃馒头了”一定要继续追问到具体原因，只有知道需求了，才能判断到底要不要实现；

然后判断需求的适用度

通用需求：适用于大部分客户，可以做到产品里；

假需求：要说服客户放弃；

真需求，但通用性很差：个性化需求，其他客户不存在此类需求，要和客户商讨有没有更好的处理方法。

后从产品设计层面考虑

同样通用型需求，实现方案可以是针对单个客户定制，也可以做成通用型功能。

在考虑的时候，一定尽量往通用型设计方向考虑，我们接定制开发的目的

是为了积累对行业的经验，完善我们的产品适用度。

假如碰到不知道怎么做成通用型产品的时候：

不妨想想把我们的产品转化为平台PasS产品，或加强API能力，避免未来产品升级对定制开发部分的影响。

是否可以做出可配置的方案来尽量满足所有人的个性化需求

举个简单的例子，我做思拓云投票的时候，这个一个很简单的在线投票选举软件，遇到客户提了一个需求：希望用户投票前必须关注他们的公众号，以此来增加公众号的粉丝量。

同时，也提出了解决方案：客户投票账户的ID和他们提供的公众号账号相互绑定，每次用户投票前调用接口去判断用户是否关注他们的公众号。

拿到这个需求，假如说按项目来做，客户提的方案是可行的，将对应账户ID和公众号账号写死在系统里即可。

如果按照产品来看，这种实现方式只适合一个客户，不满足产品设计的初衷。

那到底要不要做？

做，很明显这是一个通用型需求，加强我们API能力，如果将投票账户ID和公众号绑定功能做成可授权的。每个账号可自己去授权绑定不同的公众号，这样即可满足所有客户。

那么从项目转型到产品需要注意什么？

加强API能力，即便定制，也要只做边界内的定制，边界外找成熟产品，没有就找第三方系统集成商做（某大佬建议）。

合适的时机，定制开发的比例越高，越要尽早转型做产品开发，很多项目性公司都是产品开发出来后，几年不更新产品，一直在项目中根据客户提的需求改产品功能，复用性极差。到后期就是堆人头，边际效应递减，人均产值下降，而且项目开发组与销售部门摩擦越来越大，几千万营收就出现瓶颈。

产品和项目不是相互独立的，是相辅相成的关系，产品的开发是可以通过一个个项目去完成。通过项目不断迭代开发，推进产品版本的更新。要注意的是尽量做通用型需求，产品设计也要考虑普适性。