一些公司會將洗護服務納入公司的福利制度，員工可以通過小程序進行多家比價，線上下單、購物、線下送洗享受清洗服務。本文作者對如何以 API 方式快速接入多家洗滌品牌商家進行了分析，希望對你有幫助。

一、需求背景

Z公司為員工引入日常洗護福利，目前將市場上頭部清洗品牌列入該企業福利平臺引入計劃中，員工可以在自家的小程序上進行多家比價，線上下單、購物、線下送洗享受清洗服務。

二、產品結構圖

三、供應商產品梳理：分辨是否屬于可標準化產品

分辨供應商的產品是否是非標準性商品，比較直觀的判斷是看供應商行業的市場小眾市場。

平臺需要展示多個同類型產品，就必須對其產品進行梳理、拆分、整合；才能梳理出平臺自身分類的標準，使用產品映射是解決此類問題的一個常用的方法；在洗護的項目中其映射表包含三層：一級分類、二級分類、三級分類；第一層級為洗護場景內最大分類，二級分類標識同類產品下的屬性，三級分類為最SKU細顆粒度；映射表格中以最小庫存顆粒維度取并集。（如下圖，以洗鞋為例）

同樣是洗鞋，供應商1和供應商2對不同鞋的材質的第一層分類是不一樣的，映射表單是以供應商提供產品的最小顆粒度取并集來構建的，但是由于大分類的不同，最終還是導致產品無法整合。

標準性因素：

整合：同類型品牌的商品適用于整合的情況下也是需要查看商品本身的屬性，是否是市面上可以標準化的商品，比如用車、比如購物；可以通過某種同一維度將其統一起來。

四、系統訂單的整合

系統訂單的整合是品牌商家是否能成功接入的核心點，對不同品牌商家的業務流程進行梳理就會發現不同的業務機制就會導致出不同的訂單狀態。

從溝通的兩家頭部洗護公司來看，一家是洗前有人工上門核驗清洗物品且與客戶確認訂單價格，一家是是送洗前無人工核驗清洗物直接線上下單，送至清洗工廠后才由清洗工人核驗。就是核驗的前后不同導致訂單就形成了不同的狀態，且對應的客服運維也不一樣。

針對此類復制情況我選擇的處理方式如下：

1. 梳理各品牌商家的訂單狀態；
2. 做平臺訂單狀態的映射；
3. 映射后對應場景、物流情況給出相應的客服服務和消息通知；

通過上圖的關系，后期我們整合更多同行業但不同品牌的商家入駐；且業務流程和訂單狀態的設計可以復用起來，提高對接效率；在溝通過程中也會因業務流程中訂單的收付款原因而導致系統無法對接，最終沒有入駐的商家也有，但是其溝通效率提高，由產品經理和研發經理可以很快速評估對接的可行性，不浪費雙方的時間。

五、產品流程圖

通過對業務流程的梳理和訂單狀態映射后，確認可以對接的品牌商家后，就可以設計產品流程圖了，通過產品流程圖可以梳理出多品牌商家在平臺上業務運轉的邏輯：

• 其中縱向的主要集中在兩大邏輯：下單、完成訂單的主流程；退單、撤單的逆向流程；
• 橫向的需要考慮的對接的渠道：用戶端的展示、商品在運營端的留痕、客服操作、與供應商的數據傳送；
• 其邏輯已通過上線驗證完成，如下圖（涉及平臺和品牌方名稱需模糊處理）具體流程細節在此處不重要，是根據具體的業務來定制的。

逆向流程的重點在于款項的退回：

• 需考慮到收款方、支付類型、支付方式、支付平臺規則等因素，其對應的撤單、理賠等退款流程、退款實施時間、確認退款時間都不一樣；
• 需考慮訂單未完成前和訂單完成后都可能存在逆向流程，服務類型的消費與購買物質商品還有差別，服務商品下單支付完貨款后其業務流程并沒有結束，而是剛剛開始；
• 訂單完成后的較主流程更為簡單，可以理解為品牌商家售后對客戶的服務，可以不用體現在線上訂單中，可以較靈活的處理。
• 以商家發起退款為例（如下圖）

六、總結

截止到項目交付已成功接入了3家品牌商，由于是企業福利平臺其規模已經滿足員工使用，后期除非對接的商家有退出，大概率不會再多增加入駐商家。但其總結的產品流程進行提煉、改造的經驗可以復用到其他行業的對接中，為商家合作以API方式接入提供參考。