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

這是基于一個(gè)客戶的項(xiàng)目需求，整理的工作筆記。

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

一、需求整理

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

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

二、落地功能梳理

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

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

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

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

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

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

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

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

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

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

1）發(fā)布

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

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

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

2）審核&定價(jià)

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

統(tǒng)一價(jià)格的存在同時(shí)能防止商品因?yàn)槿笔ЩA(chǔ)銷售價(jià)而無法售賣，屬于一種方便運(yùn)營的保底價(jià)格。

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

3. 渠道管理

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

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

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

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

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

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

5. 渠道投放

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

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

6. 渠道用戶

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

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

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

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

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

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

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

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

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

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

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

6. 拆單

因?yàn)樵撉烙脩舾兄獮槿可唐肥瞧脚_供應(yīng)的，但是實(shí)際發(fā)貨是供貨商發(fā)貨，所以需要對會員的訂單進(jìn)行按供貨商拆單流轉(zhuǎn)，買家端展示為一個(gè)主訂單多個(gè)物流子訂單。這是商業(yè)模式導(dǎo)致的，無法避免的。

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

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

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

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

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

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

2）退款退貨

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

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

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

3）購物車

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

四、最終實(shí)現(xiàn)

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

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

五、補(bǔ)充說明

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

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

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

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

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

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