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

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

當您決定產品的定價模式時，您必須 以銷售 的商品成本（COGS）平衡客戶 價值 （ROV）的回報，以提供服務。 提供更靈活的商業模型（適用于解決方案）可能會增加客戶的 ROV，但也可能會增加解決方案的架構和商業複雜度（因此也會增加您的 COGS）。

開發解決方案的定價模型時，您應該考慮的一些重要考慮如下：

• COGS 會高於您從解決方案中賺取的利潤嗎？
• COGS 會根據使用者成長或使用模式的變更，隨著時間變化，COGS 會隨著時間而變更嗎？
• 測量 和記錄操作定價模式 所需的資訊有多困難？ 例如，如果您打算根據客戶的 API 呼叫數目來向客戶收費，您是否已識別出如何測量每位客戶的 API 呼叫？
• 您的獲利率是否取決於確保客戶以有限的方式使用您的解決方案？
• 如果客戶過度使用解決方案，這是否表示您不再盈利？

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

• Azure 服務定價模型。 組成解決方案的 Azure 或協力廠商服務定價模式可能會影響哪些模型是有利可圖的。
• 服務使用模式。 使用者可能只需要在其工作時間存取您的解決方案，或可能只有少量的高容量使用者。 當使用量不足時，您可以減少未使用的容量來減少 COGS 嗎？
• 儲存體成長。 大部分的解決方案都會隨著時間累積資料。 更多資料表示儲存和保護資料的成本較高，可降低每個租使用者的獲利率。 您可以設定儲存體配額或強制執行資料保留期間嗎？
• 租使用者隔離。 您使用的租用模型 會影響租使用者之間的隔離等級。 如果您共用資源，您需要考慮租使用者如何過度利用或濫用服務？ 租使用者隔離層級將如何影響您的 COGS 和每個人的效能？ 如果沒有資源配置的其他控制，某些定價模式就無法獲利。 例如，您可能需要實作服務節流，使一般費率定價模式可持續。
• 租使用者生命週期。 例如，具有高客戶流失率的解決方案，或需要更高上架努力的服務，可能會降低獲利率，特別是如果他們使用以消費為基礎的模型來定價。
• 服務等級需求。 需要較高服務層級的租使用者可能表示您的解決方案不再有利可圖。 您必須清楚瞭解客戶的服務等級期望和您擁有的任何義務，以便據此規劃定價模式。

常見的定價模式

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

注意

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

以耗用量為基礎的定價

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

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

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

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

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

注意

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

每位使用者定價

每個使用者的定價模式牽涉到根據使用服務的人數向您的客戶收費，如下圖所示。

個別使用者定價模式很常見，因為其簡化在多租使用者解決方案中實作。 不過，它們與數個商業風險相關聯。

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

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

風險： 不同的使用者耗用量模式可能會導致獲利率降低。 例如，解決方案的大量使用者可能比輕量使用者花費更多。 此外，解決方案的實際傳回值 （ROV）不會反映在實際購買的使用者授權數目。

每一作用中使用者定價

此模型與 每位使用者定價 類似，但不會要求客戶在預期使用者數目上預先承諾，而是只針對實際登入和使用解決方案的使用者收取費用（如下圖所示）。

您可以在任何期間內測量這個值。 每月期間很常見，然後此計量通常會記錄為 每月作用中使用者 或 MAU 。

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

複雜度和營運成本： 每一作用中使用者模型都需要您記錄實際使用量，並讓客戶在發票中可供使用。 測量每個使用者耗用量有助於確保單一使用者的 COGS 維持獲利率，但再次需要額外的工作來測量每個使用者的耗用量。

風險： 就像每個使用者定價一樣，個別使用者的不同消費模式可能會影響您的獲利率。 相較于每個使用者定價，每一作用中使用者模型具有較不可預測的收益串流。 此外， 折扣定價 不提供刺激增長的實用方式。

每單位定價

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

此外，某些解決方案具有高度可變的使用模式，其中少數使用者對 COGS 造成不成比例的影響。 例如，在銷售給實體零售商的解決方案中，每店定價模式可能適用。

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

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

風險： 每單位定價模型的風險類似于每個使用者定價。 某些單位的不同耗用量模式可能表示您已降低獲利率，例如某些裝置或商店比其他裝置或商店更重的使用者。

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

您可以選擇以不同價格點提供不同層級功能的解決方案。 例如，您可能會提供兩個每月一般費率或每單位價格，一個是基本供應專案，其中一個是可用的功能子集，另一個則呈現解決方案功能的完整集合。 請參閱下圖。

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

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

優點： 功能型定價通常對客戶很有吸引力，因為它們可以根據所需的功能集或服務等級來選取階層。 它也提供您清楚的路徑，為需要它的客戶提供額外的功能或更高的復原能力。

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

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

免費價格

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

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

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

複雜度和營運成本： 所有複雜度和營運成本考慮都適用于以功能為基礎的定價模型。 不過，您也必須考慮管理免費租使用者所涉及的營運成本。 您可能需要確保過時的租使用者已下架或移除，而且您必須有明確的保留原則，尤其是免費租使用者。 將租使用者升階至付費層時，您可能需要在 Azure 服務之間移動租使用者，以取得較高的 SLA。 移至付費層時，請務必保留租使用者的資料和組態。

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

商品銷售價格的成本

您可以選擇為解決方案定價，讓每個租使用者只支付其 Azure 服務共用營運成本，而沒有增加的獲利率。 此模型也稱為 通過成本或定價 ，有時用於不打算成為利潤中心的多租使用者解決方案。

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

優點： 由於此模型不包含任何額外的利潤利潤，因此租使用者的成本會較低。

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

針對內部面向的多租使用者解決方案，租使用者可能會接受約略成本估計，並有更寬鬆的計費稽核需求。 這些寬鬆的需求可降低操作解決方案的複雜性和成本。

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

一般費率定價

在此模型中，您會為租使用者收取一般費率，以取得解決方案的存取權，一段時間。 不論其使用服務數量、使用者數目、連線的裝置數目或任何其他計量，都適用相同的定價。 請參閱下圖。

這是實作和讓客戶瞭解的最簡單模型，而且通常會由企業客戶要求。 不過，如果您需要繼續新增新功能，或租使用者耗用量增加而不需要任何額外收入，它很容易變得無法取得收益。

優點： 一般費率定價很容易銷售，而且客戶很容易瞭解和預算。

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

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

折扣定價

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

注意

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

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

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

下圖說明這些定價模式。

非生產環境折扣

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

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

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

  注意

  使用免費層的限時試用版通常不適合測試和定型環境。 客戶通常需要其非生產環境，才能在生產服務的存留期內使用。

• 提供服務的測試或定型層，使用量 限制 較低。 您可以選擇將這一層的可用性限制為具有現有付費租使用者的客戶。
• 為非生產租使用者提供每位 使用者 、 每位使用中使用者 或 每單位 定價的折扣，且服務等級協定較低或沒有服務等級協定。
• 對於使用 一般費率定價 的租使用者，非生產環境可能會交涉為合約的一部分。

注意

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

不穩定的定價模式

無法盈利的定價模式會比您賺取的收入來提供服務的成本更高。 例如，您可能會針對每個租使用者收取一般費率，而您的服務沒有任何限制，但接著您會使用以使用量為基礎的 Azure 資源來建置服務，而不需要個別租 使用者使用量限制 。 在此情況下，您可能會面臨租使用者過度使用服務的風險，因此，使其無法提供服務。

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

• 正在提供免費服務，以啟用成長。
• 服務或附加元件功能會提供額外的收益串流。
• 裝載特定租使用者可提供另一個商業價值，例如在新市場中將其作為錨點租使用者。

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

• 透過 使用限制來限制服務的使用。
• 需要使用容量保留。
• 要求租使用者移至較高的功能或服務層級。

具風險定價模式

實作解決方案的定價模型時，您通常必須假設其使用方式。 如果這些假設結果不正確，或使用模式隨著時間而變更，則您的定價模式可能會變得不穩定。 風險變得不穩定的定價模式稱為 具風險的定價 模式。 例如，如果您採用預期使用者自行限制其使用解決方案金額的定價模式，則您可能已實作具風險的定價模式。

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

例如，如果您將新的影片上傳功能引入您的解決方案，其會使用以耗用量為基礎的資源，而使用者對此功能的接受率高於預期，請考慮使用限制 與 功能與服務等級定價 的組合 。

使用方式限制

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

注意

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

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

速率限制

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

在某些情況下，通常會使用速率限制，包括下列各項：

• REST API。
• 非同步工作。
• 不區分時間的工作。
• 執行成本高昂的動作。
• 產生報表。

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

定價模型生命週期

和解決方案的任何其他部分一樣，定價模型都有生命週期。 隨著應用程式隨著時間的發展，您可能需要變更定價模式。 這可能是由變更客戶需求、商業需求或應用程式內功能變更所驅動。 一些常見的定價生命週期變更包括下列各項：

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

一次實作和管理許多不同的定價模式通常很複雜。 這也令您的客戶感到困惑。 因此，最好只實作一或兩個具有少量層的模型。 這可讓您的解決方案更容易存取且更容易管理。

注意

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

變更定價模式時，您必須考慮下列因素：

• 租使用者會想要移轉至新的模型嗎？
• 租使用者是否很容易移轉至新的模型？
• 新的定價模式是否會讓您的服務面臨風險？ 例如，您是否正在移除目前正在保護重要資源的速率限制，以避免過度使用？
• 租使用者是否有明確的路徑可遷移至新的定價模式？
• 您將如何防止租使用者使用較舊的定價模式，以便淘汰它們？
• 在改變定價模式時，租戶是否可能會受到 帳單衝擊 （對非預期帳單的負面反應？
• 您是否監視服務的效能和使用率，以取得新的或變更的定價模式，以確保持續獲利率？
• 您是否能夠清楚地將新定價模型的 ROV 傳達給現有的租使用者？

參與者

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

主體作者：

• 丹尼爾·斯科特-倫斯福德 |合作夥伴技術策略師

其他投稿人：

• Bohdan Cherchyk |適用于 Azure 的 FastTrack 資深客戶工程師
• John Downs |適用于 Azure 的主要客戶工程師 FastTrack
• 查德·基特爾 |首席軟體工程師
• Paolo Salvatori |適用于 Azure 的主要客戶工程師 FastTrack
• 阿森·弗拉基米爾斯基 | 適用于 Azure 的主要客戶工程師 FastTrack

若要查看非公用LinkedIn設定檔，請登入 LinkedIn。

下一步

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