一些公司会将洗护服务纳入公司的福利制度，员工可以通过小程序进行多家比价，线上下单、购物、线下送洗享受清洗服务。本文作者对如何以 API 方式快速接入多家洗涤品牌商家进行了分析，希望对你有帮助。
一、需求背景
Z公司为员工引入日常洗护福利，目前将市场上头部清洗品牌列入该企业福利平台引入计划中，员工可以在自家的小程序上进行多家比价，线上下单、购物、线下送洗享受清洗服务。
二、产品结构图
分辨供应商的产品是否是非标准性商品，比较直观的判断是看供应商行业的市场小众市场。
平台需要展示多个同类型产品，就必须对其产品进行梳理、拆分、整合；才能梳理出平台自身分类的标准，使用产品映射是解决此类问题的一个常用的方法；在洗护的项目中其映射表包含三层：一级分类、二级分类、三级分类；第一层级为洗护场景内最大分类，二级分类标识同类产品下的属性，三级分类为最SKU细颗粒度；映射表格中以最小库存颗粒维度取并集。（如下图，以洗鞋为例）
同样是洗鞋，供应商1和供应商2对不同鞋的材质的第一层分类是不一样的， 映射表单是以供应商提供产品的最小颗粒度取并集来构建的 ，但是由于大分类的不同，最终还是导致产品无法整合。
标准性因素：
整合：同类型品牌的商品适用于整合的情况下也是需要查看商品本身的属性，是否是市面上可以标准化的商品，比如用车、比如购物；可以通过某种同一维度将其统一起来。
四、系统订单的整合
系统订单的整合是品牌商家是否能成功接入的核心点，对不同品牌商家的业务流程进行梳理就会发现不同的业务机制就会导致出不同的订单状态。
从沟通的两家头部洗护公司来看，一家是洗前有人工上门核验清洗物品且与客户确认订单价格，一家是是送洗前无人工核验清洗物直接线上下单，送至清洗工厂后才由清洗工人核验。就是核验的前后不同导致订单就形成了不同的状态，且对应的客服运维也不一样。
针对此类复制情况我选择的处理方式如下：
梳理各品牌商家的订单状态；
做平台订单状态的映射；
映射后对应场景、物流情况给出相应的客服服务和消息通知；
通过上图的关系，后期我们整合更多同行业但不同品牌的商家入驻；且业务流程和订单状态的设计可以复用起来，提高对接效率；在沟通过程中也会因业务流程中订单的收付款原因而导致系统无法对接，最终没有入驻的商家也有，但是其沟通效率提高，由产品经理和研发经理可以很快速评估对接的可行性，不浪费双方的时间。
五、产品流程图
通过对业务流程的梳理和订单状态映射后，确认可以对接的品牌商家后，就可以设计产品流程图了，通过产品流程图可以梳理出多品牌商家在平台上业务运转的逻辑：
其中纵向的主要集中在两大逻辑：下单、完成订单的主流程；退单、撤单的逆向流程；
横向的需要考虑的对接的渠道： 用户端 的展示、商品在 运营端 的留痕、客服操作、与 供应商 的数据传送；
其逻辑已通过上线验证完成，如下图（涉及平台和品牌方名称需模糊处理）具体流程细节在此处不重要，是根据具体的业务来定制的。
逆向流程的重点在于款项的退回：
需考虑到收款方、支付类型、支付方式、支付平台规则等因素，其对应的撤单、理赔等退款流程、退款实施时间、确认退款时间都不一样；
需考虑订单未完成前和订单完成后都可能存在逆向流程，服务类型的消费与购买物质商品还有差别，服务商品下单支付完货款后其业务流程并没有结束，而是刚刚开始；
订单完成后的较主流程更为简单，可以理解为品牌商家售后对客户的服务，可以不用体现在线上订单中，可以较灵活的处理。
以商家发起退款为例（如下图）
六、总结
截止到项目交付已成功接入了3家品牌商，由于是企业福利平台其规模已经满足员工使用，后期除非对接的商家有退出，大概率不会再多增加入驻商家。但其总结的产品流程进行提炼、改造的经验可以复用到其他行业的对接中，为商家合作以API方式接入提供参考。
本文由 @bell-wang 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
