編輯導(dǎo)語：作者對一個產(chǎn)品庫外嵌渠道APP功能開發(fā)的項目進行了經(jīng)驗總結(jié)，并向大家分享了此類項目設(shè)計與實施過程中的心得與踩過的坑，一起來看看吧。

這是基于一個客戶的項目需求，整理的工作筆記。

客戶擁有優(yōu)秀的供應(yīng)鏈資源，希望將資源整合打包成獨立的“資源包”投放到各個目標(biāo)渠道APP，面向渠道用戶銷售，與渠道分成。我將在此類項目設(shè)計與實施過程中的心得與踩過的坑分享與你，希望對你有幫助。

一、需求整理

在開工之前，明確需求方的核心目標(biāo)將會更有利于達成項目目標(biāo)。

• 能讓供應(yīng)商入駐進來、發(fā)布商品和管理訂單
• 平臺可以做中間商加價
• 按渠道區(qū)分展示商品和價格
• 不要做成一次性的系統(tǒng)，需要考慮后續(xù)新增渠道情況
• 平臺要對渠道進行風(fēng)險控制
• 平臺與渠道要做結(jié)算

二、落地功能梳理

我是按供應(yīng)鏈上游到下游的順序依次梳理，這樣梳理的好處是比較貼合流程順序，是更符合邏輯直覺的一種梳理思路。

1. 供應(yīng)商的入駐（進場）

需要給供應(yīng)商加入到系統(tǒng)內(nèi)的方式，一般分為兩種：

1）供應(yīng)商自行入駐–填寫相關(guān)資料–平臺審核–入駐成功。

這種情況是建立在平臺（項目需求方）對供應(yīng)側(cè)的把控力較好，供應(yīng)商愿意主動服從平臺規(guī)則進行入駐，即平臺（項目需求方）占優(yōu)勢話語權(quán)的情況。

2）平臺直接開設(shè)賬號，線下發(fā)放給供應(yīng)商。

這種情況一般是線下招商行為占大多數(shù)，尤其是因為市場因素，線下的招商合同差異性較大，平臺（項目需求方）需要“請”供應(yīng)商入駐，即供應(yīng)商占優(yōu)勢話語權(quán)情況。

一般在確認(rèn)出平臺（項目需求方）在供應(yīng)側(cè)話語權(quán)后，選擇對應(yīng)的方式進行需求確認(rèn)。

同時兩種方式在收集信息的強度上差距較大，自主入駐的是強收集，平臺創(chuàng)建的是弱收集，出于成本（時間、金錢）考慮不建議兩者兼顧，盡量明確項目目標(biāo)選擇一種推進。

2. 產(chǎn)品池的產(chǎn)生

1）發(fā)布

供應(yīng)商進入后，可以發(fā)布自己的商品并給出商品報價，這里需要注意的是這個價格是B2B交易的價格，即平臺與供應(yīng)商結(jié)算的價格。

在這里需要理解清楚的背景是：平臺是做中間商賺差價的業(yè)務(wù)的，所以發(fā)生交易的時候，涉及兩段結(jié)算，需要梳理清楚。

商品的定價建議是包郵價格，如果要做二級的郵費結(jié)算開發(fā)性價比不高（投入產(chǎn)出比不高），同時也會給供貨商增加較大的運營成本。平臺在考慮銷售端會根據(jù)最終供應(yīng)商情況拆單，情況如果是不容易估算運費，最終結(jié)果大概率將是保守運費設(shè)置，也就是過高的運費轉(zhuǎn)移到買家側(cè)。

2）審核&定價

供應(yīng)商發(fā)布完成商品，進入到平臺審核環(huán)節(jié)，審核時平臺需要提供統(tǒng)一的對外銷售價，這個需求的場景是部分渠道是統(tǒng)一價供應(yīng)，部分渠道是獨立價格供應(yīng)。

統(tǒng)一價格的存在同時能防止商品因為缺失基礎(chǔ)銷售價而無法售賣，屬于一種方便運營的保底價格。

設(shè)置完價格，審核完成，商品則進入到平臺總產(chǎn)品池。

3. 渠道管理

前面提到，業(yè)務(wù)需要滿足多個渠道的投放，所以在系統(tǒng)后臺需要有可以創(chuàng)建與管理渠道的模塊。常規(guī)渠道建檔信息包括渠道名稱、聯(lián)系人、聯(lián)系人電話。

在新建渠道后，為了滿足外部系統(tǒng)的訪問，系統(tǒng)需要新增一個入口鏈接，這個鏈接為固定鏈接，同時也用于識別用戶來源進而確認(rèn)展示的商品范圍與價格。

4. 渠道子產(chǎn)品池

當(dāng)渠道產(chǎn)生后，為了方便個性化的運營要求，需要給渠道分配一個子產(chǎn)品池，平臺可以將平臺產(chǎn)品池的商品摘出一部分到渠道子產(chǎn)品池進行售賣，并支持對子產(chǎn)品池的商品做獨立定價。

子商品池商品定價僅針對銷售側(cè)，在與供應(yīng)商結(jié)算時仍然是用結(jié)算價結(jié)算，如果平臺定價低于結(jié)算價，平臺是有成本產(chǎn)生的。這里的無限制的定價權(quán)為平臺提供更大的操作空間，當(dāng)然同時也存在同等的風(fēng)險，這是需要提前跟項目需求方說明的。

平臺需要對渠道的產(chǎn)品池內(nèi)的商品進行二次加價，保證平臺的利潤。這里需要考慮的成本包括：支付成本、平臺服務(wù)成本和渠道商務(wù)成本，做綜合評估后做出加價。

5. 渠道投放

當(dāng)商品頁面投放到渠道APP，一般會以H5形式或者小程序形式進入，具體效果為在目標(biāo)渠道APP首頁金剛區(qū)內(nèi)添加入口，渠道會員點擊進入我們的系統(tǒng)頁面并展示對應(yīng)的商品或?qū)ｎ}。

這個過程是無需二次登錄的，所以為了實現(xiàn)免登錄的跳轉(zhuǎn)，我們需要考慮的是會員數(shù)據(jù)的對接。

6. 渠道用戶

1）會員數(shù)據(jù)對接

渠道跳轉(zhuǎn)到商城指定H5頁面需要實現(xiàn)單點登錄，需要我們系統(tǒng)提前知道渠道的會員信息或者雙方需要約定一種會員信息交接方式，這里需要注意的是兩點：

1. 要保證會員不會員重復(fù)在我方系統(tǒng)創(chuàng)建。
2. 我方系統(tǒng)的會員不會對應(yīng)到渠道方的多個會員，簡單理解就是會員信息需要不重不漏。

2）渠道用戶的授信與支付

渠道用戶進入商城H5頁面的核心目的是消費，而消費就會涉及到支付，大多數(shù)落地方案是會員使用積分（代幣）進行支付，這是兩個系統(tǒng)交互較少的解決方案，也是我方系統(tǒng)需要做出最多限制的方案。

首先我們需要限制每個用戶進入所持有的積分（代幣）總額，其次我們需要限制渠道總的可用積分（代幣）總額。

最后還需要限制授權(quán)積分（代幣）的有效期（結(jié)算期），通過上述的限制才能保證平臺的資金安全，不會出現(xiàn)超額兌換（跟渠道談的是1000w的業(yè)務(wù)，結(jié)果被兌換出2000w的貨物）。

還有一部分會用到的方案是接口會帶過來會員的積分，這種場景主要限制的就是渠道的總兌換額度和兌換周期。這種落地方式一般是建立在兩個系統(tǒng)準(zhǔn)備維持長期關(guān)系的前提下會遇到，而現(xiàn)實情況是大家對長期關(guān)系的維持基本都沒有太大信心。

支付密碼一般建議沿用渠道方的會員支付密碼，但需要注意有兩個前提：

1. 兩個系統(tǒng)的密碼加密方式一致
2. 渠道系統(tǒng)同意外放會員密碼

如果前提條件不滿足，那就八仙過海，各顯神通了，比如：手機驗證碼、郵箱驗證碼、隨機預(yù)設(shè)密碼（通過短信發(fā)放）等等。

6. 拆單

因為該渠道用戶感知為全部商品是平臺供應(yīng)的，但是實際發(fā)貨是供貨商發(fā)貨，所以需要對會員的訂單進行按供貨商拆單流轉(zhuǎn)，買家端展示為一個主訂單多個物流子訂單。這是商業(yè)模式導(dǎo)致的，無法避免的。

但是需要注意的是，在此處需要處理好訂單狀態(tài)關(guān)系，這個會比一般的商城訂單多出一種發(fā)到一半的訂單狀態(tài)。如果再疊加上反向流程，是足夠?qū)е马椖渴〉?，所以在此處需要大量的溝通與妥協(xié)。

三、踩坑教訓(xùn)與經(jīng)驗總結(jié)

1）統(tǒng)一性問題

部分渠道APP會要求用戶體驗的一致性，在商城系統(tǒng)里面體現(xiàn)為用戶只能看到一個個人中心，一套訂單頁面。

但是為了滿足這一需求，付出的是雙方多日的對接聯(lián)調(diào)時間，而且因為兩套系統(tǒng)歸屬不同的維護團隊，在出現(xiàn)問題的時候，會有較多的權(quán)責(zé)劃分不清晰問題，平臺方協(xié)調(diào)成本較高。

所以建議在前期有條件情況下，增加多方溝通機會，同時在接口開發(fā)的時候定義清楚雙方的開發(fā)責(zé)任并落實到書面文檔，這都對項目的上線與后期維護產(chǎn)生幫助。

2）退款退貨

一般此類需求是對渠道系統(tǒng)的會員積分進行消耗，所以貨品不退。當(dāng)然如果需要退貨，需要與渠道APP系統(tǒng)對接的工作將翻倍。

這里沒有共性，需要視具體的情況而定，建議適可而止，因為這里的邏輯可以很簡單也可以很復(fù)雜，如何表達復(fù)雜邏輯且能讓項目相關(guān)方認(rèn)可就是一種藝術(shù)，但是令人沮喪的是當(dāng)我們實現(xiàn)了復(fù)雜的反向邏輯，用戶最終使用的頻率卻非常低，甚至低到完全人工就能解決的級別。

所以這是一個權(quán)衡的點，沒有最佳答案，但只要確認(rèn)出的答案那一定是當(dāng)下最適合的。

3）購物車

一般建議不保留購物車功能，尤其是渠道系統(tǒng)已經(jīng)有購物車情況下，原因與上述說的雙個人中心類似，會給會員造成困擾，如果合并購物車功能，渠道系統(tǒng)的改動量較大（需要對接商品數(shù)據(jù)）一般會因非技術(shù)原因?qū)е聼o法落地。

四、最終實現(xiàn)

這是一個理想的實現(xiàn)場景描述，實際落地會有調(diào)整。

渠道APP首頁金剛區(qū)分配一個入口，會員點擊進入商品H5查看指定的商品列表，會員可以加車（如無購物車功能則無需拆單流程）或者立即購買商品，密碼沿用原APP的會員支付密碼。支付后在訂單中心查看已購商品訂單和相關(guān)訂單進度信息。

五、補充說明

關(guān)于類似這樣的需求，目前常遇到的是兩種場景，在不同的場景下項目處理思路也會有所不同，所以做下補充說明，以供參考。

產(chǎn)品池給到渠道APP是服務(wù)于節(jié)日的，這個跟線下的商業(yè)模式掛鉤，可能這個端午節(jié)的員工福利讓你做，下個中秋節(jié)就是另外一家服務(wù)了，所以是一次性的服務(wù)，這個對授信與系統(tǒng)對接深度都會產(chǎn)生影響。

產(chǎn)品池是對渠道APP的一種資源補充，渠道APP可能沒有銷售模塊，這種情況下，兩個系統(tǒng)的關(guān)系將是長期關(guān)系，兩個系統(tǒng)的對接深度將會比第1種情況深入，前期需要考慮的也將更多，項目周期也更長。

希望我的分享對你有所幫助。

本文由 @瑞見釘錘 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于CC0協(xié)議