価格設定は、SaaS業界において最も議論の多いトピックの1つです。
料金だけでなく、どの価格設定モデルを使用するか。 ユーザーごとの課金にするのか。 定額にするのか。複雑な課金システムを作るのか。方法はたくさんあります。

ソフトウェアの販売(およびSaaSへの移行)の初期には、ユーザーごとの価格設定はかなり標準的なものでした。しかし、時間の経過とともに、企業は、ユーザーごとの課金がSaaSにとって常に効果的に働くとは限らず、成長を制限する可能性さえあることに気づき始めました。 一部の人々は、ユーザーあたりごとの価格設定を、使用すべきでない最悪の価格設定モデルの1つと見なしているほどです。

一方、顧客がアカウントに追加するすべてのユーザーに喜んで課金する企業はたくさんあり、ZoomなどMRRで数億円稼いでいる企業もあります。
この記事では、ユーザーあたりの課金設定はどのようなメリットやデメリットがあるのを解説していきます。

ユーザーあたりの課金体系とは?

名前が示すように、ユーザーあたりの課金体系は、サブスクリプションに追加するユーザー(またはシート)の数をベースにした請求を行う料金体系です。

たとえば、ユーザーあたり月額1,000円を請求する場合があります。 顧客が追加するユーザーが多いほど、支払う金額も多くなります。

ユーザーごとの価格設定の例
ユーザーあたりの価格設定は否定的な評判を得ていますが、それを使用している企業はたくさんあります。

Slackには、StandardとBussiness Plusの2つのプランがありま、それぞれにユーザーごとに独自の価格があります。

画像1

Salesforceは多くの製品と価格設定オプションを提供していますが、それらのほとんどはユーザーごとの価格設定モデルを採用しています。

画像2

上手の赤で囲んである部分に注目してくだっさい。最低価格プランで利用できるユーザー数を10ユーザーに制限しています。 その後からは次の階層にアップグレードする必要があります。

最後に、Asanaを見てみましょう。 Salesforceと同様に、複数のプランを提供しており、それぞれがユーザーごとに異なる価格になっています。

画像3

Asanaの興味深い点は、無料のプランがあることです。 ただし、その無料オプションには無制限の座席はなく、チームで15人を超えるユーザーを獲得したら、少なくともプレミアムプランに引き上げる必要があります。 

ユーザーあたりの課金設定に関する問題

一見すると、ユーザーごとの価格設定は魅力的に聞こえるかもしれません。顧客がアカウントに追加するユーザーが多いほど、より多くのお金を得ることができる、エクスパンション収益の増加に繋がります。

ただし。ユーザーごとの価格設定を行う前に、再考する可能性のある重要な点がいくつかあります。

ユーザーごとの価格設定は価格ショックを引き起こす可能性があります
Asanaの例に戻って、あなたがAsanaの無料バージョンを約1年間使用している中小企業であるとしましょう。チームには最大14人のユーザーがいますが、さらに3人追加して、合計17人になります。

すると、無料アカウントの15ユーザー制限を超えるため、月額0ドルから229ドル、または年払いの場合は一括で2241.96ドルになります(これは、アカウントにユーザーを追加しないことを前提としています)。

Asanaにとって、それは素晴らしいことです。しかし、顧客にとっては、少しイライラすることがあります。 (Asanaのように)値上げが行われることを知らせても、価格ショックは依然として存在します。

顧客が無料アカウントから有料アカウントに移行しない場合でも、ユーザーごとの価格設定で価格ショックが発生する可能性があります。もう一度Salesforceを見てみましょう。

彼らのEssentialsプランは月額$ 25から始まります。ただし、最大10人のユーザーを獲得したら、次のレベルにアップグレードする必要があります。これは、プロフェッショナルプランです。そして、それはユーザーあたり月額50ドル多くなります。たとえば、ユーザー数が10人から12人になったとしましょう。月額料金は、3倍以上になります。

スクリーンショット 2021-07-02 15.34.33

これは当然のことながら、顧客にいくらかの摩擦を生み出す可能性があります。 幸いなことに、これに対抗する方法はいくつかありますが、これについては後で説明します。

ユーザーごとの価格設定は、成長の可能性を制限する可能性があります
ユーザーごとの価格設定に反対する最も一般的な議論の1つは、「ユーザー数」はほとんどの企業にとって価値の指標ではないということです。

価値指標は、商品の価格設定が基づいている指標です。 Baremetricsの督促管理ツール(Recover機能)を例にとってみましょう。 その価値指標はMRRです。

画像5

Recoverに支払う金額はMRRがベースになります。これは、収益が多いほど、支払いの失敗によって失われる可能性のある収益が増えるためです。

お客様の収益が増加するにつれて、エクスパンションMRRも増加し、成長につながります。

代わりに、Recoverのユーザーごとの料金を使用する場合を想像してみてください。 それは意味がありません。 ユーザーあたり100ドルをRecoverに請求したとしても、ユーザーを追加する人にはそれほど価値がないため、成長の可能性は劇的に低下します。 それらはすべて同じパスワードを共有することができます。

顧客のユーザー数が1人であろうと20人であろうと、それらの追加ユーザーがいるだけでは必ずしも価値が上がるとは限りません。

ユーザーごとのユーザー価格設定では、成長は販売できるシート数に依存します。 そしてその時点では、それは小売業のようであり、SaaSビジネスモデルの多くの利点が失われています。

ユーザーあたりの従量課金のみの価格設定が独立することは珍しい

ユーザー数での課金体系を作用させるには、ほとんどの場合、ユーザーごとの価格設定を別のSaaS価格設定モデルと組み合わせる必要があります。

これまでに示したすべての例で、企業はユーザーごとの価格設定だけに依存しているわけではありません。 SlackとAsanaが最も近いですが、どちらも機能が追加された複数のプランがあります。

Salesforceには、さまざまなプランレベルと、アドオン製品およびサービスがあります。ただし、例外もあります。 たとえば、SEOPowersuiteはライセンスのみで厳密に課金しています。

画像6

しかし、それらは特殊ではあります。 競合他社を見ると、ユーザーごとの価格設定のみを使用している場合はごくわずかです。

ここまで読まれた方は、ユーザー数での課金体系の価格設定の考え方に完全に反対しているように思われるかもしれません。 ただし、この価格設定モデルが理にかなっている場合もあります。

ユーザーあたりの従量課金体系はいつ効果を発揮するのか?

ユーザーあたりの価格設定は、SaaS企業にとってすべて悪いわけではありません。 以下が理にかなっているいくつかの状況です。

チーム向けに構築されたSaaS

複数のユーザーを持つことで付加価値を得る製品を販売する場合、ユーザーごとの価格設定は非常に理にかなっています。 これは通常、チームベースのSaaS製品に当てはまります。

Slackはこれの最も良い例の1つです。 Slackを単独で使用している人は誰もいません。
ただし、Slackはユーザーごとに課金するだけではなく、アクティブユーザーごとに課金されます。 つまり、Slackを積極的に使用しているユーザーに対してのみ料金を支払うということです。 アクティブユーザーと非アクティブユーザーを定義する方法は次のとおりです。

スクリーンショット 2021-07-13 15.57.19

これは、ユーザーごとに課金する企業にとって最良のシナリオです。 問題は、このような形態が標準化されていないことです。 ほとんどの場合、SaaS企業は、ユーザーがログインするか製品を使用するかに関係なく、顧客のアカウントに追加されたすべてのユーザーに対して課金しています。

プロジェクト管理ソフトウェアは、ユーザーごとの価格設定が理にかなっている場合のもう1つの例です。 AsanaTrelloMondayはすべて、ユーザーごとの価格設定の形式を持っています。

スクリーンショット 2021-07-13 16.00.53

人々はこれらのツールで一緒にプロジェクトに協力するので、ユーザーごとの課金を正当化されます。

ただし、CRMツールも良い例です。 CRMソフトウェアを使用すると、複数の人が連絡先を追加し、取引で共同作業を行い、顧客関係を管理します。PipedriveInsightlyStreakなどのツールはすべて、チームのユーザーごとの価格設定があります。

スクリーンショット 2021-07-13 16.03.06

繰り返しになりますが、重要なのは、このSaaS価格設定モデルを使用するには、追加のユーザーが付加価値を持っている必要があるということです。 ユーザーごとの価格設定の代替案について話すときに、これについて詳しく説明します。

キーポイント
チームベースのSaaS製品を提供している場合は、ユーザーごとの課金が理にかなっています。 価格を正当化するのに十分な価値があることを精査してください。

エンタープライズSaaS製品

ユーザー数での課金体系を使用しているほとんどの企業を見ると、それらの多くが企業または中規模の顧客をターゲットにしていることがわかります。

偶然ではありません。KeyBancのある調査によると、SaaS企業の33%が、主要な価格指標として「シート数」(またはユーザー数)を選択しました。

画像10

正直、その数に少し驚きを隠せなかったので、どのような種類の企業が調査されているのかを確認してみました。すると、調査対象の企業のほとんどがエンタープライズ/ミッドマーケットに焦点を当てていることがわかりました。

画像11

エンタープライズSaaS企業はより多くの顧客をターゲットにしているため、これらの数値は理にかなっています。 顧客が多いということは、潜在的なユーザーが多いことを意味します。これは、ユーザーごとに課金する場合の収益が増えることを意味しています。

キーポイント
これらエンタープライズ/ミッドマーケットのいずれにも該当しない場合、ユーザーごとの価格設定に依存することは、成長への正しい道ではない可能性があります。 例外はありますが、ほとんどのSaaSビジネスでは、成長のために製品の価格を設定するためのより効率的な方法があるはずです。

ユーザーあたりの課金体系の代替は?

ユーザーごとに課金する以外の方法でSaaS製品の価格を設定する方法を探している場合は、他にもたくさんのオプションがあります。 ぜひ、SaaS価格設定モデルというブログ記事をご参考ください。

この記事では、7つの異なるSaaS価格設定モデルについて詳しく説明しているので、ぜひチェックしてみることをお勧めします。

今のところ、ユーザーの価格設定と同様の結果を得ることができる3つのオプションについて説明しますが、いくつかの欠点はありません。

使用量ベースの従量課金

ユーザーあたりの価格設定の魅力の1つは、ユーザーあたりの収益を時間の経過とともに増やすことができることです。 ただし、それを行うには、顧客がシートを追加する必要があります。 良い代替手段は、使用量ベースの価格設定です。

それは、顧客がどれだけ使用しているかに基づいて製品の価格を設定するときです。 たとえば、EmailOctopusは、所有しているEメールサブスクライバーの数に基づいて課金されます。

画像12

Stripeは、各カードの請求の一定の割合を請求します。 したがって、顧客からの請求が多ければ多いほど、Stripeはより多くの収益を得ることができます。

画像13

ユーザーあたりの料金と同様に、ユーザーあたりの平均収益(ARPU)は、使用量ベースの料金で時間の経過とともに増加するはずです。

画像14

この価格設定モデルは、一部のビジネスで他のビジネスよりもうまく機能します。 使用量に基づいて製品の価格を設定する方法について興味がある方は、試してみる価値があるかもしれません。

これを行うには価値指標を定義することから始めます。 価値指標は、顧客が製品から最大の価値を得る場所に基づいている必要があります。 EmailOctopusの場合は送信されたメールの数であり、Stripeの場合は処理できるトランザクションの数です。

価値指標が何であるかをすでに知っている可能性は十分にあります。 ただし、そうでない場合は、製品の使用状況データを確認したり、顧客を調査したりすることもできます。
適切な価値指標を選択したかどうかの優れたリトマス試験は、価格設定ページで理解するのがいかに簡単かということです。

たとえば、Baremetricsの場合は、価格設定がMRRに基づいていることは明らかです。

画像15

ただし、Keapの価格を見ると、価値指標が何であるかはそれほど明確ではありません。

画像16

価値指標を定義したら、それを中心に価格設定を構築する方法を見つけます。 Stripeのようなアクションごと、またはEmailOctopusのようなバケットごとに、Baremetricsのようなスライディングスケールにすることができます。 それはすべてあなたのビジネスによります。

アクティブユーザーごとの料金

ユーザーごとに課金するように設定されている場合、Slackルートを使用してアクティブなユーザーに対してのみ課金すると、おそらくより多くの顧客が幸せになってくれます。

Stripeを使用している場合は、Servicebotなどのツールを使用して、アクティブユーザーごとの料金を設定できます。

画像17

この価格戦略は、会社全体または部門全体で使用することを目的とした製品を販売する場合に役立ちます。

たとえば、BambuSociabbleなどの従業員擁護ソフトウェアは、通常、総ユーザー数に基づいて価格設定されます。 ただし、多くの場合、アカウントに追加されたすべてのユーザーがアカウントを長期間使用することにはなりません。 そのため、顧客は非アクティブなユーザーに料金を支払うことになります。

もちろん、すべてのユーザーに請求すると(少なくとも短期的には)、より多くのお金を稼ぐことができます。 しかし、私の経験から、特に価格が高いと感じた場合、企業は未使用のソフトウェアにそれほど長い間支払う傾向はありません。

顧客を長期的に維持したい場合(SaaSで作業している場合はそうすべきです)、顧客が固執することを奨励する方法で製品の価格設定を検討することをお勧めします。

追加のユーザーをアドオンとして提供する

これは、ユーザーごとの課金と価値ベースの価格設定の間の幸せな媒体です。 価格設定モデル全体をユーザー数に集中させるのではなく、より意味のある価値指標を選択し、アドオンとして追加のユーザーを提供します。

この価格戦略は、特に製品が厳密にチームベースではない場合、ほとんどのSaaS企業にとってはるかに理にかなっています。

この良い例はAhrefsです。彼は最近、追加のユーザーに料金を支払うオプションを追加しました。

画像18

Ahrefsの価値指標はすべてSEO分析に関連しているため、ユーザー数に基づいて価格戦略全体を決定することには意味がありません。

同時に、チーム全体で1つのパスワードとアカウントを共有することは、一部の企業にとって問題になる可能性があるため、アドオンとしてユーザーを追加することができます。 これにより、Ahrefsの収益を拡大する機会が生まれます。

このアプローチは、次の2つが当てはまる場合に効果的でしょう。
1. 顧客があなたの製品から得る価値は、彼らが彼らのアカウントに持っているユーザーの数に依存していない。

2. 顧客のサブスクリプションに追加のユーザーを含めることには、ある程度の価値がある。

追加のユーザーに課金する唯一の理由が、より多くのお金を稼ぐことができるようにするためである場合は、それを再考することをお勧めします。

ユーザーあたりでの課金体系を採用するべきか?

この記事では、ユーザーあたりの課金体系の良い面、悪い面をカバーしてきました。

ユーザーあたりの価格設定は、一部の人が思っているほど悪くはありません。 しかし、ほとんどのSaaS企業にとって、より優れた価格設定モデルと、私が述べたようなより効果的な代替手段があります。

したがって、「ユーザーごとの価格設定はあなたに適していますか?」の最適解は。。。。

。。。 場合によります。