编者导语:笔者总结了一个产品库嵌入式频道APP功能开发项目的经验，分享了这类项目设计和实施过程中的经验和步骤。让我们来看看。

这是根据客户的项目需求编写的工作说明。

客户拥有优秀的供应链资源，他们希望将资源整合打包成独立的“资源包”放在各种目标渠道app中，卖给渠道用户，与渠道共享。我把我在这类项目的设计和实施中的经验和步骤分享给大家，希望对你有所帮助。

在开工前，明确需求方的核心目标，将更有利于项目目标的实现。

我是按照供应链从上游到下游的顺序整理的。这种整理的优点是它更适合过程序列，并且这是一种更符合逻辑和更直观的整理思想。

1.供应商进场(进场)

供应商通常有两种方式加入系统:

1)供应商自行入驻——填写相关信息——平台审核——入驻成功。

这种情况是基于平台(项目需求方)对供给方有更好的控制，供应商愿意主动服从平台的规则，即平台(项目需求方)拥有主导话语权。

2)平台直接开户，线下分发给供应商。

这种情况一般是线下投资行为占多数，尤其是因为市场因素，线下投资合同差异较大，平台(项目需求方)需要“邀请”供应商入驻，即供应商拥有主导话语权。

一般是在确认平台(项目需求方)拥有供给方话语权后，选择相应的方式确认需求。

同时，两种方式在信息收集的力度上有很大差距。独立结算是强催收，平台是弱催收。考虑到成本(时间和金钱)，不建议两者兼顾，尽量明确项目目标，选择推广。

2.产品池的生产

1)发布

供应商进入后，可以发布自己的产品，提供自己的产品。需要注意的是，这个价格是B2B交易的价格，即平台与供应商之间结算的价格。

这里需要搞清楚的背景是:平台是中间商赚取差价的生意，所以一笔交易发生时，涉及两个结算阶段，需要梳理清楚。

商品的定价建议是包邮价格。如果要开发二级邮费结算，性价比不高(投入产出比不高)，对于供应商来说也会增加运营成本。平台在考虑卖家会根据最终供应商的情况来拆分订单。如果不容易估算运费，最终结果大概率会是保守的运费设定，即过多的运费会转移到买方。

2)审计和定价

供应商发布成品后，进入平台审核阶段。审核时，平台需要提供统一的对外销售价格。这个需求场景是有的渠道统一价格供应，有的渠道独立价格供应。

统一价格的存在，还可以防止商品因缺乏基本售价而无法销售，这是一种便于操作的保底价格。

价格设定完成审核后，产品将进入平台总产品池。

3.渠道管理

如前所述，业务需要满足多个渠道的投放，所以有一个模块可以在系统后台创建和管理渠道。一般渠道档案信息包括渠道名称、联系人和联系人电话号码。

新的渠道建成后，为了满足外部系统的接入，系统需要增加一个新的入口环节，这是一个固定的环节，也是用来识别用户的来源，然后确认展示产品的范围和价格。

4.渠道子产品池

渠道产生的时候，为了方便个性化的运营需求，需要给渠道分配一个子产品池。平台可以在平台产品池中挑出一部分产品在渠道子产品池中销售，支持子产品池中产品的自主定价。

子池中的商品定价只针对销售端，结算价格仍用于与供应商结算。如果平台定价低于结算价格，平台会产生费用。这里的无限定价权为平台提供了更大的操作空空间，当然也存在同样的风险，需要提前向项目需求方说明。

平台需要对渠道的产品池中的产品进行第二次提价，以保证平台的利润。这里要考虑的成本包括:支付成本、平台服务成本、渠道业务成本，综合评估后再增加。

5.渠道交付

产品页面放入渠道APP时，一般是以H5或小程序的形式进入。具体效果是在目标渠道app首页增加一个金刚区的入口，渠道会员点击进入我们的系统页面，显示相应的产品或话题。

这个过程不需要二次登录，所以为了实现免登录跳转，需要考虑会员数据的对接。

6.渠道用户

1)成员数据对接

跳转到商城指定H5页面的频道需要实现单点登录。我们的系统需要预先知道信道的成员信息，或者双方需要就成员信息切换方法达成一致。这里有两点需要注意:

2)渠道用户的信用和支付

渠道用户进入商城H5页面的核心目的是消费，消费会涉及支付。大部分的落地方案都是会员用积分(代币)支付。这是两个系统交互较少的解决方案，也是我们的系统需要做出最多限制的解决方案。

首先，我们需要限制每个用户持有的积分(代币)总数，其次，我们需要限制渠道中可用积分(代币)的总数。

最后，需要限定授权积分(代币)的有效期(结算期)。只有通过上述限制，才能保证平台的资金安全，不会出现超兑(我们跟渠道谈了1000w的业务，结果是2000w货)。

将被使用的方案的另一部分是接口将带来成员的点。这个场景主要是限制通道的总赎回额度和赎回期限。这种落地方式一般都是在两个系统准备维持长期关系的前提下遇到的，但现实情况是大家对维持长期关系的信心都不大。

支付密码一般建议遵循渠道会员的支付密码，但需要注意两个前提条件:

如果前提条件不满足，那么八仙就要漂洋过海，各显神通，比如手机验证码、邮箱验证码、随机预设密码(短信发送)等等。

6.废除该法案

因为这个渠道的用户感知到所有商品都是平台供货，但实际发货是来自供应商，需要根据供应商分单传递会员订单，买家端显示为一个主订单，有多个物流子订单。这是商业模式造成的，无法避免。

但是需要注意的是，这里需要处理好订单状态关系，这样会比一般的商城订单多一个一半发货的订单状态。如果叠加逆向过程，足以导致项目失败，所以这里需要大量的沟通和妥协。

1)统一性

有些渠道app会要求用户体验的一致性，体现在商城系统中就是用户只能看到一个个人中心和一套订单页面。

但是为了满足这个需求，双方需要几天的联调时间，而且由于两个系统分属不同的维护团队，出现问题时会出现更多权责划分不清的问题，平台协调成本更高。

因此，建议前期增加多方沟通的机会，同时在界面开发时明确双方的开发责任并写入书面文档，有助于项目的上线和后期维护。

2)退款和退货

一般这种需求都是消费渠道系统的会员积分，所以商品是不退的。当然，如果需要退货，需要与渠道APP系统对接的工作会翻倍。

这里没有共性，要看具体情况。建议适可而止，因为这里的逻辑可以很简单，也可以很复杂。如何表达复杂的逻辑并得到项目干系人的认可是一门艺术，但令人沮丧的是，当我们实现复杂的逆向逻辑时，用户最终使用的频率很低，甚至低到完全可以手工解决的程度。

所以这是一个平衡点，没有最佳答案，但只要确认的答案是目前最合适的。

3)购物车

一般建议不要保留购物车功能，尤其是渠道系统已经有购物车的情况下。原因和上面说的两人中心差不多，会给会员造成困扰。如果合并购物车功能，渠道系统会有较大的变动量(需要对接产品数据)，一般会因为非技术原因无法落地。

这是一个理想的实现场景描述，实际落地会有调整。

APP首页给金刚区分配了一个入口。会员可以点击进入产品H5，查看指定的产品列表。会员可以立即添加汽车(没有购物车功能，无需打开订单流程)或购买产品。密码与原APP会员的支付密码相同。付款后，在订单中心查看已购商品订单及相关订单进度信息。

目前像这样的需求有两种场景，不同场景下的项目处理思路会有所不同，做个补充说明，供参考。

产品到渠道的APP服务于节日，与线下的商业模式挂钩。可能这个端午节的员工福利是给你的，下一个中秋节又是另外一个服务，所以是一次性服务，对信贷和系统对接的深度会有影响。

产品池是渠道APP的资源补充，渠道APP可能没有销售模块。在这种情况下，两个系统的关系将是长期关系，两个系统的对接深度将比第一种情况更深。前期考虑会更多，项目周期会更长。

希望我的分享对你有帮助。

本文由@瑞剑钉锤原创发布。每个人都是产品经理。未经许可，禁止转载。

图片来自Unsplash，基于CC0协议。