次の方法で共有

マルチテナント ソリューションの価格モデル

  • [アーティクル]

適切な価格モデルにより、テナントの数が増えたり新しい機能を追加したりしても、収益性を維持することができます。 商用のマルチテナント ソリューションを開発する際の重要な考慮事項は、製品の価格モデルを設計する方法です。 このページでは、検討できる価格モデルと、関連するトレードオフについて、技術的な意思決定者向けのガイダンスを提供します。

製品の価格モデルを決定するときは、サービスを提供するために、顧客の "価値に対する利益" (ROV) と "売却済商品の原価" (COGS) のバランスをとる必要があります。 より柔軟な商用モデル (ソリューション用) を提供すると、顧客の ROV が増える可能性がありますが、ソリューションのアーキテクチャと商業上の複雑さも増す可能性があります (そのため、COGS も増加します)。

ソリューションの価格モデルを開発する際に考慮すべき重要な考慮事項は、次のとおりです。

  • COGS はソリューションから得られる利益よりも高くなるか?
  • ユーザーの増加や使用パターンの変化に基づいて、COGS が時間の経過と共に変化する可能性はあるか?
  • 価格モデルの運用に必要な情報の測定と記録は、どの程度の難しさか? たとえば、顧客が行った API 呼び出しの数に基づいて顧客に請求する予定の場合、それぞれの顧客が行った API 呼び出しをどのように測定するかを特定したか?
  • 収益性は、顧客がソリューションを限定的に使用するようにしていることに依存しているか?
  • 顧客がソリューションを過剰に使用している場合、それはもう利益にならないことを意味するか?

収益性に影響を与える、いくつかの重要な要因があります。

  • Azure サービスの価格モデル。 ソリューションを構成する Azure またはサードパーティのサービスの価格モデルは、どのモデルが収益性が高いかに影響を与える場合があります。
  • サービスの使用パターン。 ユーザーは、勤務時間中にしかソリューションにアクセスする必要がない場合や、多数のユーザーのごく一部に過ぎない場合があります。 使用量が少ないときに未使用容量を減らすことで、COGS を減らすことができますか?
  • ストレージの増加。 ほとんどのソリューションは、時間の経過と共にデータを蓄積します。 データが多いほど、データの保存と保護にかかるコストが高くなり、テナントあたりの収益性が低下します。 記憶域クォータを設定したり、データ保持期間を適用したりできますか?
  • テナントの分離。 使用する テナント モデル は、テナント間の分離レベルに影響します。 リソースを共有する場合に、テナントがサービスをどのように過剰に利用したり悪用したりする可能性があるかを考慮する必要がありますか? テナントの分離レベルは、すべてのユーザーの COGS とパフォーマンスにどのように影響しますか? 一部の価格モデルは、リソース割り当てに関する追加の制御なしでは、収益性は高くありません。 たとえば、定額料金モデルを維持できるようにするために、サービス調整の実装が必要な場合があります。
  • テナントのライフサイクル。 たとえば、顧客解約率が高いソリューションや、より多くのオンボーディング作業が必要なサービスは、使用量ベースのモデルを使用して価格を設定した場合は特に、収益性が低下する可能性があります。
  • サービス レベルの要件。 より高いレベルのサービスを必要とするテナントは、ソリューションにもはや収益性がないことを意味する場合があります。 顧客のサービス レベルの期待と義務について明確にして、それに応じて価格モデルを計画できるようにすることが重要です。

一般的な価格モデル

マルチテナント ソリューションでよく使用される価格モデルは多数あります。 これらの価格モデルのそれぞれには、関連する商業上の利点とリスクがあり、アーキテクチャに関する追加の考慮事項が必要です。 これらの価格モデルの違いを理解しておくことが重要です。そうすることで、ソリューションが進化しても収益性を維持できるようになります。

注意

ソリューションに複数のモデルを提供することも、モデルを組み合わせることもできます。 たとえば、ユーザー数がかなり安定している顧客にユーザーごとのモデルを提供したり、使用パターンが変動している顧客に従量課金モデルを提供したりできます。

使用量ベースの価格

従量課金モデルは、"従量課金制" または "PAYG" と呼ばれることもあります。 サービスの使用が増えると、収益が増えます。

使用量の増加に応じて収益が増加することを示す図。

使用量を測定する際には、ソリューションに追加されるデータの量などの単純な要因を考慮することができます。 または、使用量属性の組み合わせを一緒に検討することもできます。 従量課金モデルには多くの利点がありますが、マルチテナント ソリューションに実装するのは難しい場合があります。

利点: 顧客の観点からは、ソリューションを使用するために必要な先行投資が最小限に抑えられているため、このモデルに新規参入する際の障壁は低くなります。 サービス オペレーターとしての観点からは、顧客の使用量と自分の収益が増加するにつれて、ホスティングと管理のコストが増加します。 この増加により、拡張性の高い価格モデルにすることができます。 従量課金モデルは、ソリューションで使用される Azure サービスも使用量ベースである場合に特に効果的です。

複雑さと運用コスト: 従量課金モデルは、使用量の正確な測定と、この使用量をテナントごとに分割することに依存しています。 これは、多くの分散コンポーネントがあるソリューションでは特に、困難な場合があります。 課金と監査のために詳細な使用量の記録を保持し、また顧客が使用量データにアクセスする方法を提供する必要があります。

リスク: 従量課金では、コストを削減するために、システムの使用量を減らすように顧客に動機付けをすることができます。 さらに、従量課金モデルは予測できない収益源をもたらします。 これは、"容量予約" を提供することで軽減できます。この場合、顧客は、一定レベルの使用量に対して前払いで支払うことになります。 サービス プロバイダーは、この収益を利用して、ソリューションの改善に投資したり、運用コストを削減したり、機能を追加して価値に対する利益を高めたりすることができます。

注意

容量予約を実装してサポートすると、アプリケーション内の請求プロセスが複雑になる場合があります。 また、顧客が払戻を受けたり容量予約を交換したりする方法の検討が必要な場合があります。また、これらのプロセスにより、商業上および運用上の課題が加わる可能性もあります。

ユーザーごとの価格

ユーザーごとの価格モデルでは、次の図に示すように、サービスを使用しているユーザーの数に基づいて顧客に課金します。

ユーザー数が増えるにつれて収益が増加することを示す図。

ユーザーごとの価格モデルは、マルチテナント ソリューションでの実装が簡単なため、非常に一般的です。 ただし、それらはいくつかの商業的リスクに関連しています。

利点: ユーザーごとに顧客に請求する場合は、収益源を簡単に計算して予測することができます。 さらに、各ユーザーの使用パターンに非常に一貫性があると仮定すると、収益はサービスの導入と同じ割合で増加するため、これはスケーラブルなモデルになります。

複雑さと運用コスト: ユーザーごとのモデルは実装が簡単な傾向があります。 ただし、状況によっては、ユーザーごとの使用量を測定する必要があります。これにより、1 人のユーザーの COGS が収益性を維持していることを確認するのに役立ちます。 使用量を測定し、それを特定のユーザーに関連付けることで、ソリューションの運用上の複雑さを高めることができます。

リスク: ユーザーの使用パターンが異なると、収益性が低下する可能性があります。 たとえば、ソリューションの使用が多いユーザーは、使用が少ないユーザーよりもサービスにコストがかかる可能性があります。 さらに、ソリューションの価値に対する利益 (ROV) は、購入したユーザー ライセンスの実際の数には反映されません。

アクティブ ユーザーごとの価格

このモデルは ユーザーごとの価格に似ていますが、予想されるユーザー数について顧客からの事前のコミットメントを要求するのではなく、一定期間にわたって実際にログインしてソリューションを使用したユーザーに対してのみ課金されます (次の図を参照)。

ユーザー数の増加ではなく、アクティブ ユーザー数の増加に伴って収益が増加することを示す図。

これは、意味のある期間であればいつでも測定できます。 月単位の期間が一般的であり、このメトリックは、多くの場合、"月間アクティブ ユーザー" または "MAU" として記録されます。

利点: 顧客の観点からすると、このモデルでは無駄が最小限であるため、投資とリスクが少なくて済みます。未使用のライセンスは課金対象ではありません。 これは、ソリューションをマーケティングしたり、大企業の顧客向けにソリューションを成長させたりするときに特に魅力的です。 サービス所有者としての観点からは、ROV は、月間アクティブ ユーザーの数によって顧客により正確に反映されます。

複雑さと運用コスト: アクティブ ユーザーごとのモデルでは、実際の使用量を記録し、請求書の一部として顧客が利用できるようにする必要があります。 ユーザーごとの使用量を測定すると、1 人のユーザーの COGS で収益性を維持するのに役立ちますが、その場合も、ユーザーごとの使用量を測定するには追加の作業が必要です。

リスク: ユーザーごとの価格と同様に、個々のユーザーのさまざまな使用パターンが収益性に影響を与える可能性があるというリスクがあります。 ユーザーごとの価格と比較すると、アクティブ ユーザーごとのモデルでは、予測できる収益源が少なくなります。 さらに、 割引価格 では、成長を刺激する便利な方法を提供しません。

ユニットあたりの価格

多くのシステムでは、ユーザー数は COGS 全体に最大の影響を与える要素ではありません。 たとえば、"モノのインターネット"、つまり "IoT" とも呼ばれるデバイス指向のソリューションでは、デバイスの数が COGS に最も大きな影響を与えることがよくあります。 これらのシステムでは、ユニットあたりの価格モデルを使用できます。このモデルでは、デバイスなどの "ユニット" を定義します。 次の図を参照してください。

デバイスの数が増えるにつれて収益が増加することを示す図。

さらに、一部のソリューションの使用パターンは非常に多様であり、一部のユーザーは COGS に不相応な影響を与えます。 たとえば、従来型の実店舗の小売業者に販売されるソリューションでは、店舗ごとの価格モデルが適切な場合があります。

利点: 個々のユーザーが COGS にそれほど影響を与えないシステムでは、システムのスケーリングと、結果として生じる COGS への影響の現実を表すには、ユニットあたりの価格が適しています。 また、顧客の実際の使用パターンに合わせて調整することもできます。 各デバイスで予測可能な一定量の使用が発生する多くの IoT ソリューションの場合は、ソリューションの成長に合わせてスケーリングするための効果的なモデルになる可能性があります。

複雑さと運用コスト: 一般に、ユニットあたりの価格は実装が簡単で、運用コストはかなり低くなります。 ただし、デバイスや小売店などの個々のユニットごとに使用量を区別して追跡する必要がある場合は、運用コストが高くなる可能性があります。 ユニットあたりの使用量を測定すると、1 つのユニットの COGS を特定できるため、収益性を維持するのに役立ちます。

リスク: ユニットあたりの価格モデルのリスクは、ユーザーごとの価格に似ています。 一部のデバイスや店舗が他のデバイスよりもソリューションの使用量が多い場合のように、一部のユニットで使用パターンが異なると、収益性が低下する場合があります。

機能およびサービスレベル ベースの価格

さまざまな価格帯でさまざまな機能レベルを備えたソリューションを提供することも選択できます。 たとえば、毎月定額またはユニットあたりの 2 つ価格 (1 つは利用可能な機能のサブセットを備えた基本的なプランで、もう 1 つはソリューションの機能の包括的なセットを示す) を提供する場合があります。 次の図を参照してください。

3 つのレベル間で収益が段階的に増加することを示す図。

このモデルは、レベルごとに異なるサービス レベル アグリーメントを提供する場合もあります。 たとえば、Basic レベルでは 99.9% の稼働率が得られますが、Premium レベルでは 99.99% の稼働率が得られる可能性があります。 より高いサービス レベル アグリーメント (SLA) は、より高い 可用性の目標を実現するサービスと機能を使用して実装できます。

このモデルは商業的に有益である可能性がありますが、うまく機能するには成熟したエンジニアリング手法が必要です。 慎重に検討すれば、このモデルは非常に効果的です。

利点: 機能ベースの価格は、必要な機能セットまたはサービス レベルに基づいてレベルを選択できるため、多くの場合、顧客にとって魅力的です。 また、追加機能やより高い回復性を必要とする顧客にアップセルを行うための明確なパスも提供します。

複雑さと運用コスト: 機能ベースの価格モデルは、各価格帯で利用可能な機能をソリューションで認識する必要があるため、実装が複雑になる可能性があります。 機能の切り替えは、機能の特定のサブセットへのアクセスを提供する効果的な方法ですが、これには継続的なメンテナンスが必要です。 また、テストするコード パスが増えるため、フィーチャー トグルにより高品質を確保するためのオーバーヘッドが増えます。 一部のレベルでより高いサービス可用性の目標を有効にすると、レベルごとに適切なインフラストラクチャ セットが使用されるようにするために、アーキテクチャがさらに複雑になることがあり、このプロセスによってソリューションの運用コストが増加することがあります。

リスク: レベルやオプションが多すぎると、機能ベースの価格モデルが複雑で混乱を招く可能性があります。 さらに、機能を動的に切り替えることに伴うオーバーヘッドにより、追加機能を提供する速度が遅くなる可能性があります。

フリーミアム価格

基本的な機能を備え、サービス レベルの保証がない、Free レベルのサービスを提供することを選択することもできます。 その後、追加機能と正式なサービス レベル アグリーメントを備えた別の有料レベルを提供することもできます (次の図を参照)。

Free レベルでのゼロから、有料レベルでのより高い金額への収益の増加を示す図。

Free レベルは期間限定の試用版として提供される場合もあり、試用期間中、顧客は完全または限定された機能を利用できる場合があります。 これはフリーミアム モデルと呼ばれ、事実上 機能ベースの価格モデルの拡張です。

利点: 無料の場合、ソリューションを市場に投入するのは非常に簡単です。

複雑さと運用コスト: 機能ベースの価格モデルの複雑さと運用コストのすべての懸念事項が当てはまります。 ただし、無料テナントの管理に伴う運用コストも考慮する必要があります。 古いテナントがオフボードまたは削除されていることを確認しなければならない場合があります。また、無料のテナントの場合は特に、明確な保持ポリシーが必要です。 テナントを有料レベルに昇格させる場合、より高い SLA を取得するために、Azure サービス間でのテナントの移動が必要な場合があります。 また、有料レベルに移行するときは、テナントのデータと構成を保持することも重要です。

リスク: テナントが有料レベルへの切り替えを検討するのに十分な高さの ROV を提供する必要があります。 さらに、Free レベルの顧客にソリューションを提供するためのコストは、有料レベルの顧客からの利益率で賄う必要があります。

売却済商品の原価による価格設定

各テナントが Azure サービスの各自の利用分のコストのみを支払い、利益率を追加しないようにソリューションの価格を設定することができます。 このモデル (パススルー コストまたは価格 とも呼ばれます) は、利益センターを意図しないマルチテナント ソリューションで使用される場合があります。

使用量の変化に伴い、時間の経過と共に収益が変化する様子を示した図。

売却済商品の原価モデルは、社内向けのマルチテナント ソリューションに適しています。 各組織単位はテナントに対応し、Azure リソースのコストをテナント間で分担します。 また、マルチテナント ソリューションを使用または拡張する他の製品やサービスの売上から収益が得られる場合にも適している場合があります。

利点: このモデルには利益の追加マージンが含まれないため、テナントへのコストは低くなります。

複雑性と運用コスト: 消費モデルと同様に、売却済商品の原価による価格設定は、 使用状況の正確な測定 とこの使用量のテナント別の分割に依存します。 消費量を追跡することは、特に多くの分散コンポーネントがあるソリューションでは、困難な場合があります。 課金と監査のために詳細な使用量の記録を保持し、また顧客が使用量データにアクセスする方法を提供する必要があります。

社内向けのマルチテナント ソリューションの場合、テナントがコストの概算見積もりを受け入れ、課金の監査要件が緩和される可能性があります。 このように要件が緩和される場合、ソリューション運用の複雑性とコストが軽減されます。

リスク: 売却済商品の原価による価格設定では、コストを削減するために、システムの使用量を減らすようにテナントが動機付けられる可能性があります。 ただし、このモデルは利益センターではないアプリケーションに使用されるため、これは問題にならない可能性があります。

定額料金

このモデルでは、ソリューションにアクセスするために、一定期間、テナントに定額料金が請求されます。 サービスの使用量、ユーザー数、接続するデバイス数、またはその他のメトリックに関係なく、同じ価格が適用されます。 次の図を参照してください。

使用量に関係なく、一定の収益を示す図。

これは、実装が最も簡単で、顧客が理解できるモデルであり、企業の顧客から求められることがよくあります。 ただし、新しい機能を追加し続ける必要がある場合や、追加の収益なしでテナントの使用量が増加した場合は、収益性が悪くなりやすい可能性があります。

利点: 定額料金は簡単に販売でき、顧客が理解して予算を立てるのも簡単です。

複雑さと運用コスト: 課金対象の顧客は使用量の計測や追跡を必要としないため、定額価格モデルは簡単に実装できます。 ただし、必須ではありませんが、COGS を正確に測定し、収益性を維持するために、テナントごとの使用量を測定することをお勧めします。

リスク: ソリューションを頻繁に使用するテナントがある場合、この価格モデルは収益性が悪くなりがちです。

割引価格

価格モデルを定義したら、割引価格によって成長を促進するための商業戦略を実装することを選択することもできます。 割引価格 は、使用量、ユーザーごと、およびユニットあたりの価格モデルで使用できます。

注意

通常、割引価格では、より複雑な課金構造のサポートを追加する以外に、アーキテクチャ上の考慮事項は必要ありません。 割引の商業的利益の詳細については、このドキュメントでは扱いません。

一般的な割引価格パターンは次のとおりです。

  • 固定価格。 購入または使用された量に関係なく、ユーザー、ユニット、または使用量ごとに同じコストがかかります。 これが最も簡単なアプローチです。 ただし、ソリューションを頻繁に使用する顧客は、割引を受けることで規模の経済性の恩恵を受けるべきだと感じるかもしれません。
  • 減衰価格。 顧客が購入または使用するユニットが増えるほど、ユニットあたりのコストが減ります。 これは、顧客にとっては商業的により魅力的です。
  • ステップ価格。 顧客の購入が増えるほど、ユニットあたりのコストが減ります。 ただし、事前に定義された数量の範囲に基づいて、段階的な変更でこれを行います。 たとえば、最初の 100 人のユーザーの価格を高くし、次に 101 番目から 200 番目のユーザーに価格を下げ、その後でもう一度価格を下げることもできます。 これは、より収益性が高くなる可能性があります。

次の図にこれらの価格パターンを示します。

価格モデルに適用できるさまざまな割引価格を示す図。

非運用環境の割引

多くの場合、顧客は、テスト、トレーニング、または独自の内部ドキュメントの作成に使用できる非運用環境へのアクセスを必要としています。 非運用環境では、通常、使用の要件と運用コストが低くなります。 たとえば、多くの場合、非運用環境はサービス レベル アグリーメント (SLA) の対象ではなく、 転送率の制限 はより低い値に設定される場合があります。 Azure サービスでより積極的な 自動スケーリング を検討することもできます。

同様に、多くの場合、顧客は、非運用環境が運用環境よりも大幅に安価であることを期待しています。 非運用環境を提供する場合は、適切と思われるいくつかの代替手段があります。

  • 有料の顧客に対してすでに行っているような、 フリーミアム レベルを提供します。 これは注意深く監視する必要があります。組織によっては、運用するために追加のリソースを使用する、多くのテストとトレーニングの環境を作成する可能性があるためです。

    注意

    フリーミアム レベルを使用した期間限定の試用版は、通常、テストとトレーニングの環境には適していません。 顧客は通常、運用サービスの有効期間中は、非運用環境を利用できる必要があります。

  • サービスのテストまたはトレーニング レベルを、使用制限を低くして提供します。 このレベルの可用性を、既存の有料テナントを持つ顧客に制限することもできます。
  • 非運用テナントには、サービス レベル アグリーメントが低いかまったくない状態で、 ユーザーごと、 アクティブ ユーザーごと、または ユニットあたり の割引価格を提供します。
  • 定額料金を使用しているテナントの場合、契約の一部として非運用環境が取り決められる場合があります。

注意

機能ベースの価格は、通常、提供される機能が運用環境で提供されるものと同じでない限り、非運用環境には適していません。 これは、テナントでは通常、運用環境で使用できるものと同じ機能すべてについてテストし、トレーニングを行う必要があるためです。

収益性の悪い価格モデル

収益性の悪い価格モデルでは、得られる収益よりもサービスの提供に多くのコストがかかります。 たとえば、サービスの制限なしでテナントごとに定額料金を請求することもありますが、その場合は、使用量ベースの Azure リソースを使用し、テナントごとの 使用制限なしでサービスを構築します。 このような状況では、テナントがサービスを過剰に使用するため、サービス提供の収益性が悪くなるリスクがあります。

通常、収益性が悪い価格モデルは避けたいでしょう。 ただし、次のような状況では、収益性が悪い価格モデルを採用することもできます。

  • 増加を可能にするために無料のサービスが提供されている。
  • サービスまたはアドオン機能によって追加の収益源が提供される。
  • 特定のテナントをホストすると、新しい市場のアンカー テナントとしてそれらを使用するなど、別の商業的価値が得られる。

誤って収益性が悪い価格モデルを作成した場合、それらに関連するリスクを軽減するためのいくつかの方法があります。

  • 使用制限を使用してサービスの使用を制限します。
  • 容量予約の使用を要求します。
  • テナントに上位の機能またはサービス レベルに移行するよう要求します。

リスクの高い価格モデル

ソリューションの価格モデルを実装するときは、通常、それがどのように使用されるかについて想定する必要があります。 これらの想定が正しくないことが判明した場合や、使用パターンが時間の経過と共に変化した場合、価格モデルの収益性が悪くなる可能性があります。 収益性が悪くなるリスクのある価格モデルは、"リスクのある価格" モデルと呼ばれています。 たとえば、ユーザーがソリューションを使用する量を自分で制限すると予想される価格モデルを採用する場合は、リスクの高い価格モデルを実装している可能性があります。

ほとんどの SaaS ソリューションは、定期的に新しい機能を追加します。 これにより、ユーザーに対する ROV が増加し、ソリューションの使用量も増加する可能性があります。 これにより、新しい機能の使用によって使用量が多くなる場合、ソリューションは収益性が悪くなりますが、価格モデルではこれが考慮されていない可能性があります。

たとえば、使用量ベースのリソースを使用する新しい動画アップロード機能をソリューションに導入し、その機能のユーザーによる取り込み量が予想よりも多い場合は、 使用制限 と 機能およびサービス レベルの価格の組み合わせを検討してください。

使用制限

"使用制限" を使用すると、価格モデルの収益性が悪くなるのを防いだり、1 つのテナントがサービスの容量を過剰に使用したりするのを防ぐためにサービスの使用を制限したりできます。 これは、1 つのテナントがリソースを過剰に使用することで他のテナントのエクスペリエンスに影響を与える可能性があるマルチテナント サービスで、特に重要になる可能性があります。

注意

使用制限を適用していることを顧客に知らせることが重要です。 顧客に使用制限を知らせずに制限を実装すると、顧客の不満につながります。 つまり、使用制限を前もって特定し、計画することが重要です。 目標は、制限を計画し、必要になる前に制限を顧客に伝えることです。

使用制限は、多くの場合、より高いレベルでより多くの使用量を提供するために、 機能およびサービス レベルの価格と組み合わせて使用されます。 制限は、システムのボトルネックやパフォーマンスの問題を引き起こすコア コンポーネントが過剰に使用された場合に、それらを保護するためにも一般的に使用されます。

転送率の制限

使用制限を適用する一般的な方法は、API または特定のアプリケーション関数に転送率の制限を追加する方法です。 これは、 調整パターンとも呼ばれています。 転送率の制限は、継続的な過剰使用を防ぎます。 これらは、定義された期間にわたって API への呼び出しの数を制限するためによく使用されます。 たとえば、API は 1 分間に 20 回しか呼び出すことができず、これよりも頻繁に呼び出されると、HTTP 429 エラーが返されます。

転送率の制限がよく使用される状況には、次のようなものがあります。

  • REST API。
  • 非同期タスク。
  • 時間の影響を受けないタスク。
  • 実行に高いコストがかかる操作。
  • レポートの生成。

転送率の制限を実装するとソリューションの複雑さが増す可能性がありますが、Azure API Management などのサービスでは、 転送率の制限ポリシーを適用することでこれを簡単にすることができます。

価格モデルのライフサイクル

ソリューションの他の部分と同様に、価格モデルにはライフサイクルがあります。 アプリケーションが時間の経過と共に進化するにつれて、価格モデルの変更が必要になる場合があります。 これは、顧客のニーズの変化、商業的要件、またはアプリケーション内の機能の変更によって引き起こされる場合があります。 一般的な価格ライフサイクルの変更には、次のようなものがあります。

  • まったく新しい価格モデルの追加。 たとえば、現在 定額モデルを提供しているソリューションへの 従量課金モデル の追加。
  • 既存の価格モデルの廃止。
  • 既存の価格モデルへのレベルの追加。
  • 既存の価格モデルのレベルの廃止。
  • 価格モデルの機能の使用制限の変更。
  • 機能およびサービス レベルの価格モデルの機能の追加または削除。
  • 企業-消費者間 (B2C) 商用モデルから企業間 (B2B) 商用モデルへの変更。 この変更により、企業の顧客向けの新しい価格構造が必要になります。

通常、多くの異なる価格モデルを一度に実装および管理することは複雑です。 また、これは顧客を混乱させます。 そのため、レベル数の少ない 1 つまたは 2 つのモデルのみを実装することをお勧めします。 これにより、ソリューションへのアクセスが容易になり、管理が容易になります。

注意

価格モデルと課金機能は、システムの他の部分と同じように、理想的には自動テストを使用してテストする必要があります。 価格モデルが複雑になるほど、より多くのテストが必要になるため、開発と新しい機能のコストが増加します。

価格モデルを変更する場合は、次の要因を考慮する必要があります。

  • テナントは新しいモデルに移行したいか?
  • テナントは新しいモデルに簡単に移行できるか?
  • 新しい価格モデルでは、サービスがリスクにさらされるか? たとえば、現在重要なリソースが過剰使用されないようにしている転送率の制限を取り除いている?
  • テナントには、新しい価格モデルに移行するための明確なパスはあるか?
  • 廃止できるように、テナントが古い価格モデルを使用しないようにするにはどうすればよいか?
  • 価格モデルを変更すると、テナントは "パケ死" (予期しない請求に対する否定的な反応) する可能性があるか?
  • 継続的な収益性を確保できるように、新規または変更された価格モデルのサービスのパフォーマンスと使用率を監視しているか?
  • 新しい価格モデルの ROV を既存のテナントに明確に伝えることはできるか?

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

その他の共同作成者:

  • Bohdan Cherchyk | FastTrack for Azure のシニア カスタマー エンジニア
  • John Downs | プリンシパル ソフトウェア エンジニア
  • Chad Kittel | プリンシパル ソフトウェア エンジニア
  • Paolo Salvator | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

ソリューション内のテナントごとに 使用量を測定する 方法を検討します。