起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品庫外嵌渠道APP功能開發項目經驗總結
編輯導語：作者對一個產品庫外嵌渠道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可能沒有銷售模塊，這種情況下，兩個系統的關系將是長期關系，兩個系統的對接深度將會比第1種情況深入，前期需要考慮的也將更多，項目周期也更長。
希望我的分享對你有所幫助。
本文由 @瑞見釘錘 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議
大佬，我這邊正想開發這樣的app，針對外包公司交付、售后及預算方面能多給一些建議嗎？
尋找適合自身的傳播渠道也至關重要，而移動互聯網時代，市場從不缺渠道。