共用方式為


多租用戶解決方案的定價模式

良好的定價模式可確保隨著租用戶數目的增長和新增功能而保持盈利。 開發商業多租用戶解決方案時的重要考慮是如何為您的產品設計定價模型。 在本文中,我們會提供技術決策者關於您可以考慮的定價模式和相關取捨的指引。

瞭解獲利

當您決定產品的定價模式時,需要平衡客戶的價值回報(ROV)與銷售的商品成本(COGS)來提供服務。 提供更靈活的商業模型可能會增加客戶的ROV,但也可能會增加解決方案的架構和商業複雜度,因此也會增加COGS。

當您開發解決方案的定價模型時,請考慮下列問題:

  • COGS 會高於您從解決方案中賺取的利潤嗎? 不穩定的定價模式方法可能會持續一段時間,但從長遠來看是不可持續的。
  • COGS 會隨著用戶成長或使用模式變更而改變嗎? 建立 COGS 和成長的模型,以瞭解您的 COGS 是否會在成長時導致解決方案虧損。
  • 測量 和記錄操作定價模式所需的資訊有多困難? 例如,如果您打算根據客戶的 API 呼叫數目來向客戶收費,請務必識別如何測量每個客戶所進行的 API 呼叫。
  • 您的定價模式是否不鼓勵使用您的產品? 避免您的定價模式可降低客戶從產品中達成的潛在價值的情況,例如,讓一般活動成本很高。 此結構會建立不相符的獎勵,並可能導致對客戶發出混合訊號。
  • 如果客戶過度使用解決方案,這是否表示您不再盈利? 如果您擔心濫用,請設置防護措施,例如速率限制。

有一些關鍵因素會影響您的獲利率:

  • Azure 服務定價模型。 組成解決方案的 Azure 或第三方服務的定價模型可能會影響哪些模型可獲利。

  • 服務使用模式。 使用者可能只需要在工作時間存取您的解決方案,或者可能只有一小部分高容量使用者。 當使用量不足時,您可以減少未使用的容量來減少 COGS 嗎?

  • 記憶體成長。 大部分的解決方案都會隨著時間累積數據。 更多數據表示儲存和保護數據的成本較高,可降低每個租用戶的獲利率。 您可以設定記憶體配額或強制執行資料保留期間嗎?

  • 租戶隔離 您使用的租用模型會影響租用戶之間的隔離等級。 如果您共用資源,您是否需要考慮租戶可能過度使用或濫用服務? 租用戶隔離層級將如何影響您的COGS和每個人的效能?

    如果沒有資源配置的其他控制,某些定價模式就無法獲利。 例如,您可能需要實作服務節流,使一般費率定價模式可持續。

  • 租客生命週期。 例如,具有高客戶流失率的解決方案,或需要更多上線工作的服務可能會遭受較低的獲利能力,特別是如果它們使用以消費為基礎的模型定價。

  • 服務等級需求。 需要更高層級服務的租用戶可能表示您的解決方案不再有利可圖。 您必須清楚瞭解客戶的服務等級期望和您擁有的任何義務,以便據此規劃定價模式。 請考慮針對具有不同服務等級需求的客戶使用不同的定價層。

常見的定價模式

有許多常見的定價模式經常與多租用戶解決方案搭配使用。 每個定價模式都有相關聯的商業權益和風險,而且需要額外的架構考慮。 請務必瞭解這些定價模式之間的差異,如此一來,您就可以確保解決方案在發展時保持盈利。

注意

您可以為解決方案提供多個模型,或將模型結合在一起。 例如,您可以為擁有相當穩定用戶號碼的客戶提供每個使用者模型,也可以為有變動使用模式的客戶提供取用模型。

選取定價模型時,請考慮從客戶的觀點來看有什麼意義。 如果您的定價模式太複雜或抽象,他們可能會難以估計其成本。 旨在將您的定價系結至承租戶的商業架構。

以耗用量為基礎的定價

取用模型有時稱為 隨用隨付PAYG。 隨著服務使用的增加,您的營收會增加:

顯示隨著消費層級增加的營收增長圖表。

當您測量耗用量時,可以考慮簡單的因素,例如要新增至解決方案的數據量。 或者,您可以將使用屬性組合在一起。 取用模型提供許多優點,但很難在多租使用者解決方案中實作。

優點: 從客戶的觀點來看,使用解決方案所需的最低前期投資,因此此模型具有低的進入障礙。 從服務操作員的角度來看,隨著客戶的使用量和營收增加,您的裝載和管理成本會增加。 這項增加可讓它成為可高度調整的定價模式。 當解決方案中使用的 Azure 服務也以取用為基礎時,取用定價模式特別適合使用。

複雜度和營運成本: 耗用量模型仰賴使用量的精確測量,以及依租使用者分割此使用量。 這很具挑戰性,特別是在具有許多分散式元件的解決方案中。 您必須保留計費和稽核的詳細耗用量記錄,以及為客戶提供方法來存取其取用數據。

風險: 消費定價可促使您的客戶降低系統使用量,以降低成本。 此外,耗用量模型會導致無法預測的收益數據流。 您可以藉由提供 容量保留來減輕這種情況,客戶會事先支付某種程度的使用量。 身為服務提供者的您,可以使用此營收來投資解決方案的改進,以減少營運成本,或藉由新增功能來增加價值報酬。

注意

實作和支援容量保留可能會增加應用程式內計費程序的複雜性。 您可能也需要考慮客戶如何取得退款或交換其容量保留,而這些程式也可以增加商業和營運挑戰。

每位用戶定價

每位用戶定價模式牽涉到根據使用服務的人數向您的客戶收費:

顯示隨著用戶數目增加而增加營收的圖表。

每位用戶的定價模式非常常見,因為它簡化了多租戶解決方案的實施。 不過,它們與數個商業風險相關聯。

優點: 當您向每位使用者收取客戶費用時,您可以輕鬆地計算和預測您的收益串流。 此外,假設您對於每個使用者都有相當一致的使用模式,則營收會以與服務採用相同的速率來增加,這可讓您隨著成長而調整此模型。

複雜度和營運成本: 每個使用者模型通常很容易實作。 不過,在某些情況下,您需要測量每位使用者的耗用量,這可協助您確保單一使用者的COGS保持盈利。 藉由測量耗用量並將它與特定用戶產生關聯,您可以增加解決方案的作業複雜度。

風險: 不同的使用者耗用量模式可能會導致獲利率降低。 例如,解決方案的重度使用者可能比輕度使用者花費更多。 此外,解決方案的實際傳回值 (ROV)不會反映在實際購買的用戶授權數目。 如果您的解決方案包含與使用者不直接相關的功能,例如傳送電子郵件給大量收件者,您的收入可能不會隨著 COGS 增加而增加。

每位活躍用戶定價

此模型與 每位使用者定價類似,但不需要客戶在預期的用戶數目上預先承諾,而是只會針對實際登入並使用解決方案的使用者收取費用:

顯示隨著作用中用戶數目增加而增加營收,而不是隨著用戶數目增加而增加的圖表。

您可以在任何合適的期間內測量這個值。 按月的計算期間很常見,然後此計量通常會記錄為 月活躍用戶MAU

優點: 從客戶的觀點來看,此模型需要低投資和風險,因為浪費最少;未使用的授權無法計費。 當營銷解決方案或為大型企業客戶拓展解決方案時,這會特別有吸引力。 從您作為服務擁有者的角度來看,月活躍用戶數更能準確地反映您的 ROV 給客戶。

複雜度和操作成本: 每位活躍使用者的模型都需要您記錄實際使用量,並將其納入發票提供給客戶。 測量每個使用者耗用量有助於確保單一使用者的COGS維持獲利率,但再次需要額外的工作來測量每個使用者的耗用量。

風險: 與每個使用者定價一樣,個別使用者的不同消費模式可能會影響您的獲利能力。 相較於每位用戶定價,以每位活躍用戶為基準的定價模式具有較不穩定的收入來源。 此外, 折扣定價 不提供刺激增長的實用方式。

每單位定價

在許多系統中,用戶數目不是對整體 COGS 影響最大的元素。 例如,在裝置導向的解決方案中,也稱為 物聯網IoT,裝置數目通常會對COGS產生最大影響。 在這些系統中,可以使用每單元定價模型,您可以在其中定義什麼是unit,例如裝置。 請參閱下圖。

顯示營收增加的圖表,因為裝置數目增加。

此外,有些解決方案的使用模式變化很大,少數使用者對 COGS 的影響會不成比例。 例如,在銷售給實體零售商的解決方案中,不論每個商店中的用戶數目為何,每個商店的定價模式可能都適用。

優點: 在個別使用者對 COGS 沒有顯著影響的系統中,每單位定價是代表系統調整方式和對 COGS 產生影響之現實的更好方式。 它也可以更好地使客戶的實際使用模式更加一致。 對於許多IoT解決方案,其中每個裝置會產生可預測且固定的耗用量量,這可以是可調整解決方案成長的有效模型。

複雜度和營運成本: 一般而言,每單位定價很容易實作,而且作業成本相當低。 不過,如果您需要區分和追蹤個別單位的使用量,例如裝置或零售商店,營運成本可能會更高。 測量每單位耗用量可協助您確保獲利率維持,因為您可以判斷單一單位的 COGS。

風險: 每單位定價模型的風險類似於每個用戶定價。 某些單位的不同消費模式可能意味著您的獲利能力下降,例如,如果某些裝置或商店比其他裝置或商店更頻繁地使用該解決方案。

以功能和服務等級為基礎的定價

您可以選擇以不同的價位提供具有不同功能層級的解決方案。 例如,您可能會提供三種每月固定費率或每單位價格,其中兩個提供基本方案,包含部分功能,第三種則呈現解決方案的完整功能集合。

此圖顯示營收在三個階層中逐步增加。

此模型也可能為不同的層級提供不同的服務等級協定。 例如,您的基本層可能提供 99.9% 的正常運行時間,而進階層可能會提供 99.99%。 使用啟用更高 可用性目標的服務和功能,即可實作較高的服務等級協定(SLA)。

雖然此模型在商業上可能很有説明,但確實需要成熟的工程實務才能順利執行。 仔細考慮,此模型可能非常有效。

優點: 功能型定價通常對客戶很有吸引力,因為它們可以根據所需的功能集或服務等級來選取階層。 它也提供您一條明確的途徑,向需要它的客戶推銷額外的功能或更高的復原能力。

複雜度和營運成本: 功能型定價模型可能很複雜,因為它們需要您的解決方案知道每個價格層可用的功能。 功能切換可以是提供特定功能子集存取的有效方式,但這需要持續維護。 此外,功能切換會增加額外負荷以確保高品質,因為有更多程式碼路徑要測試。 在某些層級中啟用較高的服務可用性目標可能需要額外的架構複雜度,以確保每個層級都使用正確的基礎結構集,而此程式可能會增加解決方案的營運成本。

風險: 如果層或選項太多,功能型定價模型可能會變得複雜且令人困惑。 此外,動態切換功能所涉及的額外負荷可能會降低您提供其他功能的速率。

免費價格

您可以選擇提供服務的免費層,並提供基本功能,而且沒有服務等級保證。 然後,您可以提供個別的付費層,其中包含其他功能和正式的服務等級協定(如下圖所示)。

此圖顯示收入從免費層的零元逐步增加到付費層的更高金額。

免費層也可能以限時試用的形式提供,在試用期間,您的客戶可能會有完整或有限的功能可用。 這稱為免費模型,這實際上是功能型定價模型的延伸

優點: 當解決方案是免費的時,很容易上市。

複雜度和營運成本: 所有複雜度和營運成本考慮都適用於以功能為基礎的定價模型。 您也必須考慮管理零租客戶所涉及的營運成本。 您可能需要確保過時的租戶已下架或移除,而且您必須有明確的資料保存政策,尤其是針對免費租戶。 當你將租戶移到付費層級時,可能需要在 Azure 服務間遷移租戶的資料或工作負載,以獲得更高的 SLA。 當你轉到付費階層時,保留租戶的資料和設定也很重要。

風險: 您必須確保提供足夠高的 ROV,以讓租戶考慮切換至付費層級。 此外,將解決方案提供給免費層的客戶的成本必須受到付費層的獲利率所涵蓋。

商品銷售價格的成本

您可以選擇為您的解決方案定價,讓每個租使用者只支付其組成解決方案之元件份額的成本,而沒有增加的獲利率。 此模型也稱為 傳遞定價反向收费,有時用於不設為利潤中心的多租用戶解決方案。

圖表顯示隨著時間變化而收益變化,且使用量變更為相符。

銷售成本模型非常適合內部使用的多租戶解決方案。 每個組織單位都會對應至租使用者,而且您的 Azure 資源成本必須分散在兩者之間。 如果營收來自於銷售其他取用或增強多租用戶解決方案的產品和服務,那麼這也是適當的。

好處: 由於此模式不包含任何額外的利潤,因此租戶的成本較低。

複雜度和營運成本: 類似於消費模型,所銷售商品價格的成本取決於 使用量 的準確測量,以及依租使用者分割此使用量。 追蹤耗用量可能具有挑戰性,特別是在具有許多分散式元件的方案中。 您必須保留計費和稽核的詳細耗用量記錄,以及為客戶提供方法來存取其取用數據。

針對內部用的多租戶解決方案,租戶可能會接受粗略的成本估算,並對計費稽核有較靈活的要求。 這些寬鬆的需求可降低操作解決方案的複雜性和成本。

風險: 銷售商品價格的成本可能會促使您的租使用者降低其系統使用量,以降低成本。 不過,由於此模型會用於非利潤中心的應用程式,因此這可能並不相關。

固定費率定價

在此模型中,您會以固定費率向租戶收取,讓他們可以在一定的時間內存取您的解決方案。 不論其使用服務數量、用戶數目、連線的裝置數目或任何其他計量,都適用相同的定價。

圖表顯示不論使用量為何,收入維持一致。

這是實作和讓客戶瞭解的最簡單模型,而且通常會由企業客戶要求。 不過,如果您需要不斷增加新功能,或租戶耗用量增加但沒有任何額外收入,它就很容易變得無法獲利。

優點: 固定費率定價很容易銷售,而且客戶也很容易理解並預算。

複雜度和營運成本: 一般費率定價模式很容易實作,因為計費客戶不需要任何計量或追蹤耗用量。 不過,雖然並非必要,但建議您測量每一租使用者使用量,以確保您能準確地測量COGS,並確保您的獲利率維持不變。

風險: 如果您有大量使用解決方案的租使用者,則此定價模式很容易變得無利可圖。

折扣定價

定義定價模式之後,您可以選擇實作商業策略,透過折扣定價來激勵成長。 折扣定價 可以搭配使用量、每位使用者和每單位定價模式使用。

注意

除了新增更複雜的計費結構支援之外,折扣定價通常不需要架構考慮。 關於折扣商業權益的完整討論超出本文的範圍。

常見的折扣定價模式包括:

  • 固定定價。 不論購買或取用多少,每個用戶、單位或使用量都相同。 這是最簡單的方法。 不過,大量使用您解決方案的客戶可能會覺得他們應該透過獲得折扣來從規模經濟中受益。
  • 遞減價格方案。 當客戶購買或取用更多單位時,您可以降低每個單位的成本。 這在商業上對客戶更具吸引力。
  • 步驟定價。 隨著客戶購買更多,您可以降低每個單位的成本。 不過,您可以根據預先定義的數量範圍,在步驟變更中執行此動作。 例如,您可能會為前 100 位使用者收取較高的價格,然後為第 101 位至第 200 位使用者收取較低的價格,然後之後再次收取較低的價格。 這種方法比遞進定價更具盈利性。

下圖說明這些定價模式。

顯示可套用至價格模型之不同折扣定價的圖表。

非生產環境折扣

在許多情況下,客戶需要存取可用於測試、訓練或建立自己的內部檔的非生產環境。 非生產環境通常具有較低的耗用量需求和營運成本。 例如,非生產環境通常不受服務等級協定 (SLA) 的限制,而且 速率限制 可能會設定較低的值。 您也可以考慮在支援非生產工作負載的 Azure 服務上進行更積極的 自動調整

同樣地,客戶通常會預期非生產環境比生產環境便宜得多。 當您提供非生產環境時,有數種可能適合的替代方案:

  • 提供 免費服務層級,就像您可能已經為付費客戶所做的一樣。 這應該仔細監視,因為某些組織可能會建立許多測試和訓練環境,這會耗用額外的資源來運作。

    注意

    使用免費增值層級的限時試用通常不適合測試和訓練環境。 客戶通常需要其非生產環境在生產服務的整個期間內可用。

  • 提供服務的測試或訓練層,使用量限制較低。 您可以選擇將此層的可用性限制為擁有現有付費租用戶的客戶。
  • 為非生產租戶提供每位 使用者每個活躍使用者每單位 的折扣價格,且附帶較低或無服務等級協定。
  • 對於使用一般費率定價的租戶,非生產環境可能會包含在合約中。

注意

功能型定價通常不是非生產環境的好選擇,除非提供的功能與生產環境提供的功能相同。 這是因為租使用者通常會想要針對生產環境中可用的所有相同功能進行測試並提供訓練。

不盈利的定價模式

無法盈利的定價模式會比您賺取的收入來提供服務的成本更高。 例如,您可能會針對每個租戶收取固定費率,且您的服務不設任何限制,接著您會使用以使用量為基礎的 Azure 資源來建置服務,並且不設租戶使用量限制。 在這種情況下,您可能會面臨租戶過度使用您的服務的風險,從而使為他們提供服務無利可圖。

一般而言,您想要避免無法取得利得的定價模式。 不過,在某些情況下,您可能會選擇採用無利可得的定價模式,包括:

  • 正在提供免費服務,以促進成長。
  • 服務或附加元件功能會提供額外的收入來源。
  • 接待特定租戶可提供另一個商業價值,例如在新市場中將其作為主力租戶。

如果您不小心建立無利可圖的定價模型,有一些方法可以降低與其相關聯的風險,包括:

  • 透過使用限制來限制服務的使用。
  • 必須預訂容量。
  • 要求租用戶移至較高的功能或服務層級。 請考慮在有利可圖的服務層級上獨佔提供新功能,以鼓勵租用戶移動。

具風險定價模式

實作解決方案的定價模型時,您通常必須對其使用方式做出假設。 如果這些假設被證明是不正確的,或者使用模式隨著時間的推移而改變,那麼您的定價模型可能會變得無利可圖。 容易變得不賺錢的定價模式稱為 具風險的定價 模式。 例如,如果您採用定價模型,預期使用者自行限制他們使用解決方案的數量,則您可能已實作有風險的定價模型。

大部分的 SaaS 解決方案都會定期新增新功能。 這增加了用戶的 ROV,這也可能導致解決方案的使用量增加。 如果新功能的使用會推動使用量,這可能會導致解決方案變得無法利好,但定價模式不會將此納入考慮。

例如,如果您將新的影片上傳功能引入您的解決方案,其使用以耗用量為基礎的資源,以及使用者對此功能的接受程度高於預期,則請考慮您是否可以使用使用量限制功能與服務等級定價的組合來降低定價風險。

使用方式限制

使用量限制 可讓您限制服務的使用量,以防止您的定價模式變得不穩定,或防止單一租使用者耗用不成比例的服務容量。 這在多租用戶服務中尤其重要,其中單一租用戶可能會過度消耗資源來影響其他租用戶的體驗。

注意

請務必讓客戶知道您套用使用量限制。 如果您實作使用量限制而不讓客戶知道限制,則會導致客戶不滿。 這表示請務必事先識別及規劃使用限制。 目標應該是規劃限制,然後在客戶需要之前將限制傳達給客戶。

使用量限制通常與 功能和服務層級定價搭配使用,以提供較高層級的使用量。 限制也常用來保護核心元件,如果過度耗用,將會導致系統瓶頸或效能問題。

速率限制

套用使用限制的常見方式是將速率限制新增至 API 或特定應用程式函式。 這也稱為 節流。 速率限制可防止連續過度使用。 它們通常用來限制對 API 的呼叫數目,在定義的時段內。 例如,API 每分鐘只能呼叫 20 次,如果呼叫頻率高於此值,它將傳回 HTTP 429 錯誤。

下列案例通常包括速率限制:

  • REST API。
  • 異步任務。
  • 不具時間敏感性的工作。
  • 執行成本高昂的動作。
  • 產生報表。

實作速率限制可以增加解決方案的複雜度,但 Azure API 管理 等服務可以藉由套用速率限制原則來簡化此作業。

定價模型生命週期

和解決方案的任何其他部分一樣,定價模型都有生命週期。 隨著應用程式隨著時間的發展,您可能需要變更定價模式。 這可能是由不斷變化的客戶需求、商業需求或應用程式內功能的變更所驅動。 請考慮以下常見的價格生命週期變動:

  • 新增全新的定價模型。 例如,將 耗用量定價模型 新增至目前提供 一般費率模型的解決方案。
  • 淘汰現有的定價模式。
  • 將階層新增至現有的定價模型。
  • 取消現有定價模型中的一個級別。
  • 變更定價模型中功能的使用量限制。
  • 功能和服務等級定價模型新增或移除功能。
  • 從企業對消費者(B2C)商業模式變更為企業對企業(B2B)商業模式。 這項變更接著需要為您的商務客戶建立新的定價結構。

一次實作和管理許多不同的定價模式通常很複雜。 這也令您的客戶感到困惑。 所以,最好只實作一兩個模型,並分幾個層級。 這可讓您的解決方案更容易存取且更容易管理。

注意

應該測試定價模型和計費功能,在理想情況下使用自動化測試,就像您系統的任何其他部分一樣。 定價模式越複雜,需要測試越多,因此開發和作業複雜度的成本將會增加。

變更定價模式時,請考慮下列因素:

  • 合約含意。 如果租用戶已根據特定定價模式簽署合約,請確定您不會意外違反這些合約。
  • 吸引力。 清楚地將新定價模型的 ROV 傳達給您現有的租使用者。 請確定您讓新模型更具吸引力,讓租使用者想要移轉至新的模型。 決定如何阻止租用戶使用您計劃淘汰的舊版定價模型。
  • 時程表。 為租使用者提供大量變更的通知,讓他們做好準備。
  • 移轉過程。 讓租用戶輕鬆移轉至新的模型。
  • 降低定價風險。 評估每個新的定價模式,以瞭解其是否具 風險。 例如,移除目前保護重要資源不受過度使用之速率限制時,請小心謹慎。 在整個變更中,監視服務的效能和使用率,以確保持續滿意度和獲利率。
  • 降低帳單衝擊風險。 定價模式的變化可能會導致 帳單衝擊,這是對非預期帳單的負面反應。 清楚且主動地傳達定價模式變更。 在變更前後計算或模擬每個租用戶的帳單,以便偵測租用戶在變更後會支付更多費用的情況。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者:

其他投稿人:

若要查看非公開的 LinkedIn 設定檔,請登入 LinkedIn。

下一步

請考慮如何測量解決方案中租用戶的 耗用量