ビジネスモデルのスライドでは、「誰が、何に対して、どの単位で支払い、事業者が何を提供するのか」をひと目で説明します。成長予測を並べる前に、この関係を1枚に整理しましょう。販売する単位が曖昧なままでは、聞き手は売上予測を判断できません。
まず取引条件を明確にし、小さな計算例で確かめます。そのうえで、事業の情報から編集可能なピッチ資料のたたき台を作成できます。入力するのは確認できた事実です。プレゼン作成ツールは説明の整理を助けますが、価格を決めたり、顧客がその価格を受け入れると証明したりするものではありません。
購入から提供まで、1件の取引をたどる
顧客になるかもしれない相手に事業を説明すると考えてみてください。「拡張性のあるプラットフォームで収益化します」だけでは、取引の姿が見えません。「独立系の修理事業者が、予約管理と作業調整のために月額料金を支払います」なら、購入者、支払い、サービスが分かります。
スライドの中心になるのは、次の4つの問いです。
- 誰が支払うのか。 サービスを使う人と支払う顧客が異なる場合は、区別して示します。
- 何を単位に課金するのか。 アカウント、利用者、取引、案件など、単位を具体的にします。
- いつ請求するのか。 月ごと、年ごと、注文完了時、合意した案件の節目などを示します。
- 何を提供する必要があるのか。 商品やサービスに加え、提供に必要な主な作業や費用を示します。
Sequoiaの事業計画の構成例でも、ビジネスモデルは独立した項目として扱われています。ピッチ資料でも役割を分けましょう。市場規模は機会の大きさ、トラクションは実際に起きた進展、ビジネスモデルは現在または計画中の取引の仕組みを説明します。
サブスクリプションを計算できる例で示す
独立系の修理事業者向けに、顧客の予約を調整する架空のサービスを考えます。事業者アカウント1つにつき月額150米ドルで、スタッフ5人まで利用できます。追加ユーザーの料金は、この例には含めません。以下の条件と金額はスライドの作り方を説明するための架空の設定であり、実際の顧客実績ではありません。
支払うのは修理事業者です。スタッフ5人がソフトウェアを使っても、5件の契約になるわけではありません。課金単位は「事業者アカウント1つ・1か月」です。
| モデルの要素 | 例の条件 |
|---|---|
| 購入者 | 独立系の修理事業者 |
| 提供するもの | スタッフ5人まで使える予約管理・作業調整ソフトウェア |
| 料金 | 事業者アカウント1つにつき月額150米ドル |
| 請求 | 毎月。この例では初期費用なし |
| 仮定した直接提供費用 | 稼働中のアカウント1つにつき月額30米ドル |
| その他の費用を引く前の残額 | 1アカウントにつき月額120米ドル |
稼働中のアカウントが20件なら、月額料金の合計は20 × 150米ドル = 3,000米ドルです。提供費用を上記のとおり仮定すると、20 × 30米ドル = 600米ドルがその20件への提供にかかり、その他の事業費用を引く前に2,400米ドルが残ります。
この2,400米ドルは純利益ではありません。製品開発、営業、管理、税金などの費用はまだ含めていません。また、事業規模が変わっても1件あたり30米ドルで提供できると示したわけでもありません。スライドには「その他の費用を引く前の残額」と書き、費用の仮定は補足資料に残します。
20アカウントの計算は、モデルの仕組みを説明するものです。実際に20社を獲得していなければ、現在の実績ではなく例示であることを明記します。仮定による掛け算を「達成した売上」という見出しの下に置いてはいけません。
提供する価値と支払いを逆向きの矢印で描く
このサブスクリプションの例なら、修理事業者と予約管理サービスの2つを図の中心に置けます。一方の矢印でサービスが購入者に届く方向を、もう一方で月額150米ドルのアカウント料金が事業者に戻る方向を示します。
図の下に「料金150米ドル − 仮定した提供費用30米ドル = その他の費用を引く前に120米ドル」という短い計算を添えます。価格の横には課金単位を必ず置きます。「150米ドル」だけを大きく見せ、「事業者アカウント1つ・1か月」を省くと誤解を招きます。
見出しは「修理事業者がアカウント単位で月額料金を支払う」といった具体的な文にできます。その下にサービスの説明、価格、計算を収めれば、別のグラフは不要です。将来の料金案や詳しい費用モデルは補足スライドに回します。
口頭では、例えば次のように説明できます。「支払うのは事業者で、スタッフ5人までが同じアカウントを利用します。この例では月額150米ドルです。直接提供費用を1アカウントあたり30米ドルと置くと、開発、営業などの費用を引く前に120米ドルが残ります。次に検討すべきなのは、この仮定を顧客や費用の記録が裏づけるかどうかです。」
この描き方は、足りない情報も見つけやすくします。支払いの矢印に名前を付けられないなら、支払う人か課金単位が曖昧かもしれません。提供に多くの人手が必要なのに「ソフトウェアへのアクセス」だけを描けば、重要な作業が隠れてしまいます。
収益の仕組みに合わせて図と計算を変える
取引手数料型の事業では、別の図が必要です。架空のマーケットプレイスで、1か月に200米ドルの予約が30件完了したとします。顧客の支払総額は6,000米ドルです。この例の取り決めでは、提供者が85%の5,100米ドルを受け取り、マーケットプレイスが15%の900米ドルを手数料として受け取ります。
聞き手には、マーケットプレイスを通過する取引総額と、そこに残る手数料の両方を見せる必要があります。取り決めを説明せずに6,000米ドル全体を「当社の売上」と呼ぶと、仕組みが分からなくなります。「予約取引額」と「マーケットプレイスの受取手数料」を使い分けましょう。実際の財務報告は、その会社に適用される会計処理に従います。
この例で決済と調整の費用が1予約あたり7米ドルなら、合計210米ドルです。900米ドルから引いた690米ドルは、その他の事業費用を引く前の残額です。無関係に見える3つの大きな数字を並べるより、「6,000米ドル → 5,100米ドル + 900米ドル」という分岐図のほうが関係を説明しやすくなります。
案件単位のサービスは、さらに単位が異なります。固定価格2,400米ドルの案件は、契約した1件の成果物であり、毎月継続するサブスクリプションではありません。含まれる作業、支払い時期、別見積もりになる変更を説明します。提供に専門スタッフの作業が20時間必要なら、顧客が固定額を払う場合でも、その時間は費用と対応能力の説明に含めます。
事業に合う例を選びましょう。収益源を多様に見せるためだけに、サブスクリプション、広告、ライセンスを追加する必要はありません。未検証の案はそう明記し、現在の収益の仕組みと分けます。
モデルの見え方を変える条件を示す
短い説明では、必ず一部の詳細を省きます。そのうち、聞き手の判断を変える条件は戻しましょう。年額契約と月払い契約では請求時期が違います。案件価格は範囲に左右されます。取引手数料が、返金されていない完了済み予約にだけ適用されることもあります。
サブスクリプションの例なら、30米ドルという提供費用にサポート、ホスティング、外部サービスの利用料が含まれるかを確認します。顧客によってサポートの負担が大きく異なると、平均値だけでは費用の高い顧客層が見えません。別の補足表で仮定を示せば、主スライドを混雑させずに済みます。
価格設定と、顧客が支払う意思を示す証拠も区別します。「提案中の月額料金は150米ドルです」と「現在20社が月額150米ドルを支払っています」は違う主張です。計画には前者を使い、後者は実際の顧客記録がある場合にだけ使います。
値上げ、割引、無料期間があると、アカウント数だけで売上を計算する方法は正確ではなくなります。実際の事業を説明するときは、実際の契約条件を使います。単純な例は計算を追いやすい点で役立ちますが、会社の記録の代わりにはなりません。
ピッチ全体の中で役割を決める
ビジネスモデルは、聞き手が取引を理解できるだけの前提を得た位置に置きます。先に顧客の課題と提供する商品・サービスを説明しておけば、支払いの仕組みから、利用実績や提供に必要な資源へ自然につなげられます。
会社紹介プレゼンでは、同じ内容を「何を提供し、顧客がどう購入するか」という短い実務的な説明にできます。資金調達のピッチでは、売上、提供費用、拡大の関係をさらに詳しく聞かれるかもしれません。どちらでも、中心となる取引は分かりやすく保ちます。
スライドのたたき台を作るときは、支払者、課金単位、提供内容、支払い時期、計算例、未解決の仮定を別々の項目で入力します。宣伝文句を1ページ並べるのではなく、名前の付いた2本の矢印と1つの計算を指定しましょう。作成後は、各価格に単位が付き、仮定の数字が仮定のまま示されているか確認します。1度見た聞き手が、その事業の仕組みを自分の言葉で説明できる1枚を目指します。
