編輯導語：你是否在抖音刷到過提升學歷、理財或找副業(yè)等相關(guān)的視頻？這些推送給我們的課程或訓練營，它的項目是如何定位的？訓練營MVP產(chǎn)品模型又是什么？從1-N的產(chǎn)品模型設(shè)計你了解多少？本文將圍繞這幾個問題展開講述，推薦對此感興趣的朋友閱讀。

一、訓練營項目定位

在使用抖音短視頻時，經(jīng)常會刷到某某課程0元領(lǐng)取、某3天特訓營只需1元錢等相關(guān)課程推送視頻，常見的如提升學歷、找副業(yè)、理財股票等科目方向。用戶端可以分為以下幾個步驟：

1. 進入相關(guān)課程詳情頁；
2. 報名；
3. 加學姐微信（可以理解銷售、助教、運營等人員）；
4. 加群；
5. 直播課程；
6. 付費大課；
7. 沒有付費可以參加下次訓練營。

以上訓練營的步驟與特點與傳統(tǒng)的廣告推送相比，雖然運營步驟相對多了幾步，但得到了更多緩沖的機會，也更加貼合用戶的體驗，后決策的順應(yīng)心理。

傳統(tǒng)的投放業(yè)務(wù)，其產(chǎn)品的客單價較高，投放的費用同樣較高，更多依賴銷售個人轉(zhuǎn)化能力。不過用戶意向度高，相對容易轉(zhuǎn)化，但短期如不能夠轉(zhuǎn)化，后期轉(zhuǎn)化也比較吃力，主要也是因為銷售會把更多精力會放在最新的線索上。而業(yè)務(wù)一旦暫停投放，也就相對應(yīng)的暫停了業(yè)務(wù)。

而訓練營的業(yè)務(wù)定位就是通過低價小課引流，在開始群內(nèi)幾天的直播運營，課后集中進行轉(zhuǎn)化。相比較與直接銷售跟進轉(zhuǎn)化，做了一個緩沖，平臺為自己爭取了一個展示的契機，同時也將用戶決策的過程由即時決策變成延遲決策。用戶因此也不會有即時決策帶來的壓迫感。

舉一個形象的例子：SEM投放就像足球場上后場球員拿到了球后的直接長傳到了前鋒球員，如果前鋒球員可以將球打進那么即轉(zhuǎn)化成功，而如果如果不能及時打進也基本就喪失了本次機會。

而訓練營像足球場上的中場球員，后場球員拿到了球后，傳給了中場指揮官球員，可進可退，可攻可守，節(jié)奏自控。將整場比賽的進程掌握在自己手中。

二、訓練營MVP產(chǎn)品模型

?1. 業(yè)務(wù)模型

教育行業(yè)中訓練營業(yè)務(wù)在當前市場上已經(jīng)比比皆是，而且在部分教育科目上，相對應(yīng)的轉(zhuǎn)化效果也得到了相應(yīng)的市場驗證。因此針對于剛介入，或者想要嘗試通過訓練營業(yè)務(wù)尋找新的增長點的教培行業(yè)來說，可以根據(jù)訓練營MVP模型，驗證當前科目的市場行情。

MVP是最小可行產(chǎn)品（Minimum Viable Product）的簡稱，想要確定MVP模型，需要先找到訓練營業(yè)務(wù)中的關(guān)鍵路徑：

學員報名–>添加學姐微信–>拉進群–>學員上課–>課上轉(zhuǎn)化–>不能轉(zhuǎn)化則留存繼續(xù)相關(guān)運營

2. 產(chǎn)品模型

通過關(guān)鍵路徑再進行逐一拆分，看看哪些環(huán)節(jié)需要產(chǎn)品介入：

• 報名–>配置落地頁產(chǎn)品，此落地頁需要有表單的功能邏輯；
• 添加學姐微信–>報名成功之后，需要給學員呈現(xiàn)學姐二維碼，此邏輯也在落地頁產(chǎn)品實現(xiàn)；
• 拉進群–>此環(huán)節(jié)需要學姐將學員拉進一個微信群，進行統(tǒng)一維護，此環(huán)節(jié)不需要產(chǎn)品支持；
• 學員上課–>需要有上課直播間，市面上標準化直播間產(chǎn)品很多，隨便選擇一款（小鵝通、網(wǎng)易直播、騰訊課堂等等）即可；
• 課上轉(zhuǎn)化–>需要有交易平臺產(chǎn)品，能夠支持在線購買相應(yīng)的課程產(chǎn)品，而這個環(huán)節(jié)，通常直播產(chǎn)品平臺就會提供相對應(yīng)功能進行搭配使用，當然平臺會進行抽成；
• 不能轉(zhuǎn)化則留存繼續(xù)相關(guān)運營–>可以重新體驗訓練營。

抽象產(chǎn)品模型：

1. 落地頁產(chǎn)品（支持報名與展示微信）；
2. 直播上課產(chǎn)品；
3. 商品付費。

3. 模型搭建落地

（1）落地頁產(chǎn)品

落地頁產(chǎn)品需要圖片展示，產(chǎn)品架構(gòu)主要分為三個方面：

• 【設(shè)計頁面】：有一個可視化頁面，并需要配置域名鏈接。
• 【報名表單】：學員可以在可視化頁面上，通過輸入手機號進行報名。
• 【付費】（可選）：如果想提升用戶的意向程度，可以設(shè)置付費報名，通常訓練營的價格不會超過10元錢。
• 【學姐二維碼】：展示，報名之后需要指引學員下一步可以走向的操作。

（2）直播上課產(chǎn)品

直播上課產(chǎn)品架構(gòu)最核心的內(nèi)容版塊就是上課環(huán)節(jié)：

• 【教務(wù)運營端】：屬于業(yè)務(wù)環(huán)節(jié)，需要創(chuàng)建直播間、布置直播間（課程圖、課程內(nèi)容大綱、相關(guān)活動說明信息等）、幫助講師上傳課件、利用教務(wù)身份和學員互動等。
• 【講師端】：講師需要有單獨的入口進入直播間，可以通過軟硬件進行推流。以視頻直播、操作課件、共享屏幕等方式進行授課。
• 【學員端】：通過學員端鏈接進入直播間，可以和講師申請連線互動、文字互動、隨進隨走。

（3）商品付費

直播課通常都是3天左右，在第2天或者在第3天的時候，講師講完課或者課中就開始直播帶貨，同時運營銷售人員也開始在直播間和微信群中開始進行活躍轉(zhuǎn)化。直播間可以直接下單、群內(nèi)開始推一些促銷類的文案，此時學員如果對課程比較感興趣，就會進行付費下單。

此部分最核心的就是：【商品】、【服務(wù)】。

【商品】：通過鏈接發(fā)送到群中，用戶通過支付寶或者微信進行支付，支付之后可以生成訂單。同時下單之后可以享受該商品的服務(wù)。

【服務(wù)】：下單之后，用戶會立即享受該付費的產(chǎn)品。這個最順暢的選擇也依然是在該直播平臺中進行，但為了更好的服務(wù)用戶，通常會引入APP等其他客戶端進行學習。

三、從1-N產(chǎn)品模型設(shè)計

不是所有課程都適合訓練營模式，也不是所有課程都能夠通過訓練營業(yè)務(wù)模型使該業(yè)務(wù)線達到盈利的狀態(tài)。而是否決定該業(yè)務(wù)線繼續(xù)下去，通過MVP模型就可以得到驗證。

一旦該訓練營模式得到了驗證，接下來就需要規(guī)?；柧殸I模型，將訓練營的優(yōu)勢繼續(xù)放大，形成可復制、可延展的、數(shù)據(jù)可追蹤的形態(tài)。產(chǎn)品模型開始了從1-N的迭代設(shè)計，那么在MVP模型基礎(chǔ)之上設(shè)計，需要迭代的環(huán)節(jié)如下：

1. 訓練營管理部分

訓練營管理的產(chǎn)品體系包括：訓練營管理、營期管理、學員管理、上課數(shù)據(jù)管理。

（1）訓練營管理

場景：主要區(qū)分不同的訓練營科目，每一方向的訓練營都可能是一個獨立的運營項目。

結(jié)構(gòu)：

• 【訓練營名稱】：訓練營項目名稱。
• 【科目分類】：當前項目隸屬于整體業(yè)務(wù)的體系科目分類。例如：考證類、學科類、技能類等。
• 【訓練營相關(guān)簡介設(shè)置】用于打造完整的訓練營商品結(jié)構(gòu)，用于前端呈現(xiàn)。包括：詳情頁、簡介、講師相關(guān)信息、原始價格、相關(guān)配圖。

（2）營期管理

場景：每一個訓練營的業(yè)務(wù)都是可持續(xù)運營的，那么同一個訓練營中就會存在多個營期

結(jié)構(gòu)：

• 【營期名稱】：可以自行配置。
• 【營期時間】：包括課程起止時間、投放起止時間。一個營期的周期從為該營期招生開始，到該營期課程結(jié)束。對于學員來講，需要知道上課周期。對于運營業(yè)務(wù)來講，需要了解招生時間段。
• 【直播課程】：需要配置為學員上課的直播間數(shù)據(jù)。

（3）學員管理

場景：學員下單報名之后，相關(guān)的數(shù)據(jù)都會進入對應(yīng)的營期當中。因此學員管理是在營期下一層結(jié)構(gòu)下

結(jié)構(gòu)：

• 【用戶名】【手機號】【報名時間】：此類都是學員基本信息，學員報名一刻時都會獲取到。
• 【微信】：學員報名之后都會添加學姐微信（建議是企業(yè)微信）。之后，學姐盡量將微信也同步到學員管理，方便后續(xù)管理學員。
• 【分配學姐】：起初，學員報名之后，會固定某一個學姐。但是后面由于規(guī)模擴大，同一營期的學員一個學姐無法進行承接。因此會有分配策略，此處學姐只看自己所負責的學員即可。
• 【渠道】：需要標記該學員報名的渠道來源。運營也不僅僅會投放抖音，也會有其他相關(guān)渠道。此處可以統(tǒng)計不同渠道相關(guān)的學員質(zhì)量。
• 【是否轉(zhuǎn)化】：標記學員是否最終轉(zhuǎn)化了大課?？山y(tǒng)計核心數(shù)據(jù)大課轉(zhuǎn)化率。

（4）上課數(shù)據(jù)管理

場景：雖然訓練營上課僅為3-4天，但是這幾天的上課數(shù)據(jù)、作業(yè)數(shù)據(jù)、表單數(shù)據(jù)等其他數(shù)據(jù)，對于后續(xù)的轉(zhuǎn)化分析漏斗也是重要的分析環(huán)節(jié)。

結(jié)構(gòu)：

• 【直播數(shù)據(jù)】：學員直播課程的出勤時間。
• 【作業(yè)數(shù)據(jù)】：學員在直播課完成作業(yè)的情況。（通常是選擇題10道以內(nèi)為佳）
• 【表單數(shù)據(jù)】：主要在課前調(diào)研學員的一些基本情況，方便后續(xù)為學員提供精準服務(wù)。

2. 落地頁管理部分

落地頁管理部分包括：落地頁模塊管理、投放規(guī)則管理。

（1）落地頁模塊管理

場景：每個訓練營都有各自的落地頁，而同一個落地頁也不一定會一直使用，不同渠道針對不同的落地頁，可能也會有不同的效果。

結(jié)構(gòu)：

• 【落地頁模板名稱】：為落地頁模板命名。
• 【落地頁鏈接】：每一個可配置的落地頁，都是一個前端可視化的落地頁。因此這里需要是一個標準化的頁面鏈接。后續(xù)使用中，會通過規(guī)則設(shè)定添加一些參數(shù)。

（2）投放規(guī)則管理

場景：在實際業(yè)務(wù)中，每次招生投放的需求都會有細小的差別。包括每次投放的價格、時間、分配的學姐、設(shè)置的渠道等。

結(jié)構(gòu)：

【投放渠道】：每個訓練營都需要有特定的投放渠道。為了更好的統(tǒng)計該渠道投放效果，需要在投放之前給改落地頁鏈接配置好確定的渠道。例如：utm_medium=douyin(抖音)。

【價格】：設(shè)置本期投放的訓練營價格。一般0-9.9元以內(nèi)，0元與1元比較普遍，如果需要特別提高用戶的門檻就設(shè)置為9.9元，如果需要更多的用戶量，可以設(shè)置為0元。

【配置學姐】：為學員報名之后，服務(wù)的學姐微信?？梢允前凑毡壤竺麛?shù)分配，也可以按照渠道進行分配。

【落地頁信息】：自定義配置落地頁相關(guān)說明。

3. 訂單管理部分

訂單管理包括：小課訂單、大課訂單。

場景：訓練營業(yè)務(wù)核心的報名數(shù)據(jù)，分別是訓練營小課訂單、轉(zhuǎn)化后的大課訂單。

結(jié)構(gòu)：

大、小課訂單管理。

【訂單基本信息】：【訂單號】【訂單狀態(tài)】【支付價格】【支付時間】【支付平臺】。

【商品信息】：訓練營及營期、大課商品相關(guān)商品信息。

【用戶基本信息】：【用戶名】【手機號】。

【運營業(yè)務(wù)信息】：【分配學姐】（大課商品除外）【渠道來源】。

4. CRM系統(tǒng)

CRM系統(tǒng)包括：CRM系統(tǒng)、學姐微信管理。

場景：進一步規(guī)范業(yè)務(wù)數(shù)據(jù)體系，報名過訓練營小課的用戶可以進入CRM系統(tǒng)體系。因為從戰(zhàn)略層考慮，訓練營業(yè)務(wù)對于CRM只是其中的一個用戶數(shù)據(jù)來源入口，可以服務(wù)更多的業(yè)務(wù)形態(tài)，同時進入CRM之后通過后續(xù)的客戶體系流轉(zhuǎn)，可以延長相應(yīng)用戶價值。

結(jié)構(gòu)：

【CRM系統(tǒng)】：此處為一整套用戶流轉(zhuǎn)體系。包括用戶線索的分發(fā)、跟進、成單、公海等角度去設(shè)計。本文集中討論訓練營業(yè)務(wù)，CRM請關(guān)注后續(xù)的文章分享。

【學姐微信管理】：之所以將微信學姐管理也納入進crm體系，主要是因為，學姐大概率也是在crm系統(tǒng)中銷售的角色。因此將學姐和銷售進行合并，也是最大化利用了相關(guān)資源。

四、總結(jié)

在初期訓練營模型中，無論是報名-上課-轉(zhuǎn)化，都可以通過第三方工具配合進行使用，甚至有的第三方平臺可以提供一體化的產(chǎn)品服務(wù)，使用者只需要提供落地運營即可。此階段主要是驗證該方向是否能夠達成盈利狀態(tài)。通常ROI>1.5就基本可以繼續(xù)執(zhí)行。

而后期由于業(yè)務(wù)范圍、規(guī)模擴大，可以將訓練營產(chǎn)品模型化，將一些列數(shù)據(jù)都保存在自己的平臺，同時也可以做一些個性化規(guī)則，詳細可以參考本文相關(guān)細節(jié)。

本文主要是站在產(chǎn)品的角度去分析訓練營項目架構(gòu)，后續(xù)將會分享一些關(guān)于訓練營運營思路的文章。

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

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