这是基于一个客户的项目需求，整理的工作笔记。
客户拥有优秀的供应链资源，希望将资源整合打包成独立的“资源包”投放到各个目标渠道APP，面向渠道用户销售，与渠道分成。我将在此类项目设计与实施过程中的心得与踩过的坑分享与你，希望对你有帮助。
在开工之前，明确需求方的核心目标将会更有利于达成项目目标。
我是按供应链上游到下游的顺序依次梳理，这样梳理的好处是比较贴合流程顺序，是更符合逻辑直觉的一种梳理思路。
需要给供应商加入到系统内的方式，一般分为两种：
1）供应商自行入驻–填写相关资料–平台审核–入驻成功。
这种情况是建立在平台（项目需求方）对供应侧的把控力较好，供应商愿意主动服从平台规则进行入驻，即平台（项目需求方）占优势话语权的情况。
2）平台直接开设账号，线下发放给供应商。
这种情况一般是线下招商行为占大多数，尤其是因为市场因素，线下的招商合同差异性较大，平台（项目需求方）需要“请”供应商入驻，即供应商占优势话语权情况。
一般在确认出平台（项目需求方）在供应侧话语权后，选择对应的方式进行需求确认。
同时两种方式在收集信息的强度上差距较大，自主入驻的是强收集，平台创建的是弱收集，出于成本（时间、金钱）考虑不建议两者兼顾，尽量明确项目目标选择一种推进。
1）发布
供应商进入后，可以发布自己的商品并给出商品报价，这里需要注意的是这个价格是B2B交易的价格，即平台与供应商结算的价格。
在这里需要理解清楚的背景是：平台是做中间商赚差价的业务的，所以发生交易的时候，涉及两段结算，需要梳理清楚。
商品的定价建议是包邮价格，如果要做二级的邮费结算开发性价比不高（投入产出比不高），同时也会给供货商增加较大的运营成本。平台在考虑销售端会根据最终供应商情况拆单，情况如果是不容易估算运费，最终结果大概率将是保守运费设置，也就是过高的运费转移到买家侧。
2）审核&定价
供应商发布完成商品，进入到平台审核环节，审核时平台需要提供统一的对外销售价，这个需求的场景是部分渠道是统一价供应，部分渠道是独立价格供应。
统一价格的存在同时能防止商品因为缺失基础销售价而无法售卖，属于一种方便运营的保底价格。
设置完价格，审核完成，商品则进入到平台总产品池。
前面提到，业务需要满足多个渠道的投放，所以在系统后台需要有可以创建与管理渠道的模块。常规渠道建档信息包括渠道名称、联系人、联系人电话。
在新建渠道后，为了满足外部系统的访问，系统需要新增一个入口链接，这个链接为固定链接，同时也用于识别用户来源进而确认展示的商品范围与价格。
当渠道产生后，为了方便个性化的运营要求，需要给渠道分配一个子产品池，平台可以将平台产品池的商品摘出一部分到渠道子产品池进行售卖，并支持对子产品池的商品做独立定价。
子商品池商品定价仅针对销售侧，在与供应商结算时仍然是用结算价结算，如果平台定价低于结算价，平台是有成本产生的。这里的无限制的定价权为平台提供更大的操作空间，当然同时也存在同等的风险，这是需要提前跟项目需求方说明的。
平台需要对渠道的产品池内的商品进行二次加价，保证平台的利润。这里需要考虑的成本包括：支付成本、平台服务成本和渠道商务成本，做综合评估后做出加价。
当商品页面投放到渠道APP，一般会以H5形式或者小程序形式进入，具体效果为在目标渠道APP首页金刚区内添加入口，渠道会员点击进入我们的系统页面并展示对应的商品或专题。
这个过程是无需二次登录的，所以为了实现免登录的跳转，我们需要考虑的是会员数据的对接。
1）会员数据对接
渠道跳转到商城指定H5页面需要实现单点登录，需要我们系统提前知道渠道的会员信息或者双方需要约定一种会员信息交接方式，这里需要注意的是两点：
2）渠道用户的授信与支付
渠道用户进入商城H5页面的核心目的是消费，而消费就会涉及到支付，大多数落地方案是会员使用积分（代币）进行支付，这是两个系统交互较少的解决方案，也是我方系统需要做出最多限制的方案。
首先我们需要限制每个用户进入所持有的积分（代币）总额，其次我们需要限制渠道总的可用积分（代币）总额。
最后还需要限制授权积分（代币）的有效期（结算期），通过上述的限制才能保证平台的资金安全，不会出现超额兑换（跟渠道谈的是1000w的业务，结果被兑换出2000w的货物）。
还有一部分会用到的方案是接口会带过来会员的积分，这种场景主要限制的就是渠道的总兑换额度和兑换周期。这种落地方式一般是建立在两个系统准备维持长期关系的前提下会遇到，而现实情况是大家对长期关系的维持基本都没有太大信心。
支付密码一般建议沿用渠道方的会员支付密码，但需要注意有两个前提：
如果前提条件不满足，那就八仙过海，各显神通了，比如：手机验证码、邮箱验证码、随机预设密码（通过短信发放）等等。
因为该渠道用户感知为全部商品是平台供应的，但是实际发货是供货商发货，所以需要对会员的订单进行按供货商拆单流转，买家端展示为一个主订单多个物流子订单。这是商业模式导致的，无法避免的。
但是需要注意的是，在此处需要处理好订单状态关系，这个会比一般的商城订单多出一种发到一半的订单状态。如果再叠加上反向流程，是足够导致项目失败的，所以在此处需要大量的沟通与妥协。
1）统一性问题
部分渠道APP会要求用户体验的一致性，在商城系统里面体现为用户只能看到一个个人中心，一套订单页面。
但是为了满足这一需求，付出的是双方多日的对接联调时间，而且因为两套系统归属不同的维护团队，在出现问题的时候，会有较多的权责划分不清晰问题，平台方协调成本较高。
所以建议在前期有条件情况下，增加多方沟通机会，同时在接口开发的时候定义清楚双方的开发责任并落实到书面文档，这都对项目的上线与后期维护产生帮助。
2）退款退货
一般此类需求是对渠道系统的会员积分进行消耗，所以货品不退。当然如果需要退货，需要与渠道APP系统对接的工作将翻倍。
这里没有共性，需要视具体的情况而定，建议适可而止，因为这里的逻辑可以很简单也可以很复杂，如何表达复杂逻辑且能让项目相关方认可就是一种艺术，但是令人沮丧的是当我们实现了复杂的反向逻辑，用户最终使用的频率却非常低，甚至低到完全人工就能解决的级别。
所以这是一个权衡的点，没有最佳答案，但只要确认出的答案那一定是当下最适合的。
3）购物车
一般建议不保留购物车功能，尤其是渠道系统已经有购物车情况下，原因与上述说的双个人中心类似，会给会员造成困扰，如果合并购物车功能，渠道系统的改动量较大（需要对接商品数据）一般会因非技术原因导致无法落地。
这是一个理想的实现场景描述，实际落地会有调整。
渠道APP首页金刚区分配一个入口，会员点击进入商品H5查看指定的商品列表，会员可以加车（如无购物车功能则无需拆单流程）或者立即购买商品，密码沿用原APP的会员支付密码。支付后在订单中心查看已购商品订单和相关订单进度信息。
关于类似这样的需求，目前常遇到的是两种场景，在不同的场景下项目处理思路也会有所不同，所以做下补充说明，以供参考。
产品池给到渠道APP是服务于节日的，这个跟线下的商业模式挂钩，可能这个端午节的员工福利让你做，下个中秋节就是另外一家服务了，所以是一次性的服务，这个对授信与系统对接深度都会产生影响。
产品池是对渠道APP的一种资源补充，渠道APP可能没有销售模块，这种情况下，两个系统的关系将是长期关系，两个系统的对接深度将会比第1种情况深入，前期需要考虑的也将更多，项目周期也更长。
希望我的分享对你有所帮助。
本文由 @瑞见钉锤 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
关注微信
