創業以來我覺得專心做好自己的事情是最重要的事,別人講什麼也都懶得管和解釋,加上 meepShop 還有一堆東西要不斷進化。不過一直以來我們的收費方式,總是被人用一些話術混淆,這點就讓我悶了很多年,每次講到都讓我有點情緒。年末了很多事開始步上軌道,就來聊聊我們的收費邏輯是什麼,為什麼這對商店是相對好的。

先說我 6 年前設定收費方式的初衷,為什麼一直以來很少人用這方式收費

1.不想用方案綁功能

我會希望提供相對完整的功能,商店成功的機率就會變大,所以如果和多數平台一樣都用方案去綁定功能,就會讓功能的使用受到方案的限制,像 A 方案少 20 個功能、B 方案少 10 個功能、選到了 C 方案才不會減少功能;而且平台要 push 使用更高的方案,就會需要把強大的功能放在相對高的方案裡,結果經常因為要一個功能就必需升級方案,而增加負擔、同時又有很多功能是現階段用不到的,過程就像這樣:

  • 強的功能→放最高的方案
  • 最高的方案→抽%
  • 結果就是:強的功能→抽%

舉例來說現在一頁式的銷售方式能讓剛創業、要轉型的商店更有機會成功,或是像折扣多樣化的折扣才能因應不同行銷需求,但就被放在相對高的方案裡,對商店來說不能選用這些功能成功機率就降低許多,但硬選又會超過負擔。

2.比較功能好累呀

那時做男裝打算自己開官網,接著就開始找平台,雖然最後是自己架 (更慘);但在找的過程中真的超累,比較要用哪個平台就已經很累了、每個平台又一堆方案、一堆方案又綁不同功能 (那時代還是沒太多開店平台、沒太多功能,就已經比得很累了,更何況是現在),所以我就想用個簡單的方式讓賣家選購,只要依照自己營運的規模去考慮方案。

3.當生意很好時不要一直被抽 %

因為以前在通路平台被抽很兇,生意很好的時候也沒因此淨利變高,反而還下滑;後來官網自己架時主要是付伺服器和流量的費用,雖然也因營收增長費用增加,但費用占營收比卻是下降的,這個我就可以接受只要不是”等比例的增加”,例如:營收 30 萬時付 1 萬占比 3%,營收到了 300 萬占比應該是 2.5%、600萬是 1.5% 以此類推,這樣就能讓利潤最大化,有資金能運用在其它營運項目上,所以自己做平台時就在想能不能不抽%。

依照這個近乎 ”理想” 的邏輯,收費就變得困難

所以在不綁功能、不持續抽 % 的原則下,設計了很久於是有了這些結果:

1.確認至少不要賠錢,才有流量超量費

如果「你沒有一個方式在商店變大時,能等比增加收入那一定會賠錢」,撇除想先用短期賠錢補貼方式搶市場的情況,這個是平台軟體基本的原則,所以大部份的平台都直接用抽%來解決、另外也從金流的分潤裡和金流公司 share,除了不賠錢還能讓平台利潤最大化。

如果不以抽 % 為手段那要怎麼收費才行?

軟體服務除了開發、維護成本外,最大的開銷就是流量和伺服器的錢,即使不去精算開發/維護成本,伺服器及流量遇到了大賣家或用了不太對的方式營運,流量就很容易賠到爆表 (想像一下 lativ 突然要用你的系統,然後付 6,000 元),伺服器很難找到一個衡量標準估算出一個商店用多少,所以就只能以流量超標做收費,至少在這個部份不會賠到錢,偶爾收到的流量超額也能回補伺服器的費用,這些年下來真的付到流量的商店比例很少。

2.push 方案才抽%

6,000 元是我精密計算後,比較能 cover 一般使用下伺服器和流量的金額,同時商店數量多時能有利潤 cover 人事/維護成本,所以我們也需要 push 這個方案,本來想是不是開 6,000 方案就好,但考慮到剛經營的商店初期資金比較吃緊,就加開 2500 元方案,也才會有抽 %,是希望大家生意好的能升級到 6,000 金神燈的方案。

「所以我們抽 % 的目的,不是為了不斷抽 % 賺錢。」

3.如何 cover 開發新功能和功能本身確實有成本? app store 擴充市集

開發新功能也需要錢,有的功能上線後也會增加每個月的成本,所以我們才想用擴充市集的方式,一些功能可以用選購的方式真的有需要再選用,不適合就卸載不用再付費,也不會因為想要用某個功能卻因現有方案無法使用,結構上就比較像 shopify ,我們這部份的收入就能拿來開發、優化系統架構;但好笑的是我們新版本目前全部功能都沒有再額外收費,因為做 app store 的架構真的很難,當然未來還是會規劃要不然一直開發功能,又沒法多收一點錢真的會倒XD

然後被說成

1.我們要抽 % 是為了想賺錢

聰明一點的算一下就會知道收費邏輯是什麼,和為什麼我們抽 % 賺不到什麼錢,因為通常營業額到了 25 萬,為了不再被抽 % 就會升級到金神燈然後就免 %,但有的競品會直接忽悠說我們都是有抽 %,但這兩者是完全不同的:

  • Meepshop:抽 % 是有上限的 → 最後會變零
  • XX:想用這賺錢的會把抽 % 放在高級方案→ 變成是無上限的

對比如果生意好會用的功能多,也就會選最高方案然後就變成抽 % 無上限

2.只有我們抽 %

這點這兩年競品就不敢講了,因為早已經改成抽 % (笑),但我還是要說一下,這兩者抽%目的性不同:

  • Meepshop:是為了 push 方案
  • XX:能最大化利潤

但就是有人利用商店對抽% 的的反感,一直說 meepShop 有抽 % 這件事,但從沒有人解析為什麼金神燈沒抽 %、只說是高一階的方案所以才不抽 %

3.只有我們在收流量費

實際算看看就知道,我直接用實驗商店的情況來算,營收 880 萬的那個月,實驗商店超量費用是 10,311 元

  • Meepshop:用流量 = 超量費是 10,311 元
  • XX:用抽 % = 880 萬* 0.5 % ~ 5 % = 4.4 萬 ~ 44 萬

所以 meepShop 的收費方式,商店每個月就能多出 43 萬 (44 萬減 1 萬) 可以運用,不論是投入廣告、產品、行銷、人事等等都超好用,我一想到如果實驗商店現在每個月要被抽 44 萬那種心情…..我們都算是毛利偏高的還是會很痛,那毛利低一點的是能賺什麼錢,還不如去通路平台。

再倒算回來如果我們改用抽 % 的話約 0.12%;如果真要賺錢,我們抽比業界低 就 0.4% 好了,變成可以收到 35,000 元,比流量能多收到 3 倍,3 倍這對公司營運有多重要!

又如果抽 5% 一間商店就能賺 44 萬每個月,相對我們要找到 44 間 880 萬的商店,而且都有超量到 10,000 元才能有一樣的營收,哪個比較容易、哪個利潤較多?有時講到為什麼我們收流量費我就很想說,如果覺得收流量不對,那我們改收 5% 好了XD。

但還有一件更重要的事必需想好,才能真正用這個收費模式

一般來說如果直接用這個方式收費,經營的風險是很高的,弄不好很容易掛掉,所以才沒有人這樣收費。

賺不多對公司、對客戶長期來說都不見得是好事,但如果不要用抽 % 去最大化利潤,又沒有能彌補利潤的方式,這個收費模式就沒法成立,這才是最困難的地方。

思考了很久我得到一個解答就是”營運效率”,運用效率去降低成本獲得利潤,這也是為什麼一直以來我很重視效率、思考,這不是說用時間去換、狂加班,反而我們一直都很少在加班,也很少在用 dead line、壓時間去開發,其實多數講的”效率”很狹義,也是我覺得比較”虛”的,真正的效率應該是「發明」不是”減”而是”加”的概念,這個和經濟學有關係,可以從 View、文化、思維、目標、行銷等等去達到,就不多講了要講又是一大篇。

總之…..

我不會說 meepShop 都是最好、最便宜,因為永遠都有更便宜的,賣家考慮自己的規劃選用適合的,每個競品都有各自的長處;我也不會說我們永不漲價或最高方案永不抽 % 這種鬼話,畢竟競品已經漲了好幾輪 (我都有截圖,因為知道一定會漲,說永不抽 % 的我也有截XD),時代不停在變化你不可能預測所有事情,但我也知道價錢變動對品牌來說是很不利的,所以一開始精算再精算去避免漲價這件事,從成立 7 年來我們還沒漲過價,6,000 元也還是沒抽 %,也沒去弄一個新方案來抽 %,不過有把 600 元拿掉因為現況不太適合。

講完了,悶了這麼多年終於一次講完,爽!總被說成我們靠這些抽 %、流量賺錢,然後用一堆的話術包裝扭曲我們的收費模式。不過想想我自己也要負責,因為價格方案我也一直不知道怎麼解釋才清楚,總不能把上面這一大串打上去,不過最近有想了一下方向,接下來會針對費用頁面重新設計解說、試算一下,讓賣家能更清楚這樣的收費模式是否適合自己,也希望這種特殊的收費模式能讓大家多一種選擇、提供相對完整的功能更有機會成功。

[註]本文經作者 MEEPSHOP CEO JACK 授權刊登。文章轉載於 開店平台收費模式分析 – 對電商最好的方式


作者簡介:

MEEPSHOP CEO JACK

JACK 為什麼寫 blog?經歷一些事,才慢慢從 100% 瘋狂創業路上稍做停歇,想留下些什麼,還有寫給我的朋友;最後,我寫的文章信不信由你,我只是想給真正想創業、在創業的人一些方向。

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.