SaaS+ 企業をゼロから構築する場合でも、既存の企業を組み込み製品やサービスで収益を上げられるビジネスに変えたい場合でも、知っておく必要のある 6 つの重要な概念は次のとおりです。
これらの概念は技術的な意味合いを持ちますが、アーキテクチャ上の決定であると同時にビジネスロジック上の決定でもあります。創業チームは、これら6つの問題について共通の視点を持つ必要があります。これらの概念について一致することで、製品ロードマップ、コアとなる技術アーキテクチャ、価格戦略、そして製品マーケティングが推進されます。
SaaS企業の収益を10倍にするには、最初から適切な基盤を整える必要があります。SaaS+ハウスの基盤を正しく構築すれば、今後数年間で内部を比較的簡単にリフォームできるでしょう。
1. すべては取引を中心に展開する
SaaS+において、ショッピングカート機能とトランザクションレベルの柔軟性は、2つの重要な技術要素です。なぜなら、収益の大部分は通常、プラットフォーム上の資金の流れに左右されるからです。トランザクション技術を構築する際には、いくつか考慮すべき点があります。
- マルチマーチャントカート：1回の取引で複数の加盟店を考慮すると、ショッピングカートの構築は複雑になる可能性があります。しかし、最初からこの処理に対応できるようにカートを設計しておくと、チェックアウト時に複数のSaaS+製品を販売する際に大きなメリットが得られます。具体的には、この技術により、ユーザーは単一の取引として認識できますが、実際には各ベンダー間で複数の取引が同時に発生しています。これは、組み込み保険などの規制対象商品を販売する場合に特に重要です。
- 分割取引／支払いテクノロジー：マルチマーチャントカートの代替として、分割取引と分割支払いテクノロジーがあります。この機能により、チェックアウト時に完全に単一の取引が可能になりますが、各関係者への正味支払額を瞬時に関連付け、取引後に受取人に適切な資金を動的に分配することで決済するという負担が生じます。これは当初はより洗練されたソリューションと見なされることが多いですが、保険のように元の取引が実際の保険会社と行われなければならない規制対象商品には適していません。現実的には、マルチマーチャントカートと分割取引機能の両方を初日から構築する必要があります。
エンドユーザーにとって、すべてはチェックアウト体験に集約されます。特定の取引がマルチマーチャントカートテクノロジーを活用しているか、分割取引ツールを活用しているかに関わらず、その選択はエンドユーザーにとって意識されることなく、同時にチェックアウト時に販売される多種多様なSaaS+製品に対応できる必要があります。
例：SportsEngineでは、顧客が1つのショッピングカートで決済を行うコマースシステムを構築しましたが、実際には各商品は個別に購入されます。顧客は支払い情報を一度入力するだけで、プラットフォームがカードで複数の取引をバックグラウンドで開始します。そのため、例えば、ミネソタホッケーとUSAホッケーへの登録を1つのステップで行い、保険とユニフォームの購入も同時に行うことができます。1つのカート、1つのチェックアウト…つまり、4つの独立したベンダーが連携するのです。
Etsyでは、顧客が1回の取引で複数の販売者から購入することも可能です。マーケットプレイスは、支払いを複数の販売者とEtsy自身の間で分割します。DoorDashの単一販売者ショッピングカートでは、1つのレストランから複数の料理を追加できますが、2つの異なるレストランから注文する場合は、別々に注文する必要があります。
テッククランチイベント
サンフランシスコ | 2025年10月27日～29日
2. 人間の単一インスタンス
データをサイロ化させないでください。一人につき一つのプロフィールを作成し、プラットフォーム上のあらゆる場所で利用しましょう。つまり、一人につき一つのプロフィール、一つの支払い方法、一つの背景画像、そして一つの評価システムです。各人のプロフィールと情報がプラットフォーム全体で利用できるようにデータモデルを構築しましょう。これがプラットフォームの力です。
顧客はユーザー情報を共有したくないという理由で、サイロ化を勧めてくることがよくあります。しかし、その要求には最後まで耐えなければなりません。プラットフォームの力は薄れ、同じ人間がプラットフォーム内に何度も存在すると、データはすぐに扱いにくくなってしまいます。
「コアプロフィール」データはプラットフォーム全体で共有される一方で、各顧客がユーザープロフィールに独自かつプライベートなデータを追加でき、そのデータが顧客自身のものとなるような構造を構築しましょう。ほとんどの顧客は、これを受け入れられる解決策と見なすでしょう。
「単一の人間」であることのメリットは計り知れません。お客様は一度情報を入力するだけで、更新内容はコアプロフィールに反映されます。ログインすればいつでも簡単に情報にアクセスできます。そして、情報は双方向に流れます。プロフィールが拡大するにつれて、様々なソースから提供されるデータによって、すべてのお客様はユーザーをより正確に把握できるようになります。
例：建設ソフトウェアプラットフォームは、この優れたユースケースの一つです。電気技師が参加すると、1社または複数の建設会社と提携関係にある可能性があります。その電気技師を1社または複数の建設会社に所属させましょう。これは電気技師と建設会社双方にとってメリットとなります。電気技師は、どの会社からでも支払いを受けるために、銀行口座情報を一度入力するだけで済みます。身元調査も一度だけで済み、建設会社も簡単に利用できるようになります。
3. 親子データモデル
データ管理において、親子関係とは2つのファイル間の関係を指します。親子階層は、データソース内の階層情報を整理するために使用され、単一のアカウントで複数のプロファイルを作成できるようになります。SaaS+企業では、親子関係を構造化するようにデータを設計する能力が非常に重要です。データモデルを検討する際には、ドメインを確認し、どのような親子関係が存在するのか、そしてそのエコシステムをどのようにモデル化するかを理解する必要があります。
例：USAホッケーはミネソタホッケーの親組織であり、ミネソタホッケーは第2地区ホッケーの親組織であり、第2地区ホッケーはミネソタ州スティルウォーターとミネソタ州ローズビルのホッケーの親組織です。ホッケーには、全国、州、地区、そして地域の階層構造があります。これらの組織がどのように関連し、情報を共有するかが、親子データモデルです。
4. 姉妹実体関係
姉妹組織とは、同じ親組織を持つ複数の組織です。これらの組織が、より広い階層構造の中でどのように情報を共有できるかを検討する必要があります。どのようなデータを相互に共有できるでしょうか？人々が必要とするデータのレイヤーはどれでしょうか？どのデータレイヤーがプラットフォームを最も強力にするでしょうか？
例：複数の構成にわたる姉妹団体に対応する必要がありました。ミネソタ州スティルウォーターのユースホッケーチームは、ミネソタ州ローズビルのライバルチームと状況に応じたデータを共有する必要がありました。姉妹団体のデータ共有エンジンがなければ、チームの総合順位や選手の統計的リーダーは正確には表示されません。
また、単一のコミュニティの姉妹団体にも対応しました。例えば、ある家族に異なるスポーツをする子供がいる場合、両親はそれらのスケジュールをすべて一つの家族カレンダーに集約し、スポーツの費用を一つのクレジットカードで支払うことができます。
この概念は業界によってさまざまな形で現れますが、あらゆる SaaS+ 環境に必然的に存在します。
5. 共有支払いウォレット機能
共有ペイメントウォレット機能を使用すると、複数の加盟店やプロファイルで使用できる単一の決済ファイルを作成できます。顧客は支払い情報を一度入力するだけで、すべての購入を単一のアカウントで管理できるため、非常に便利です。チェックアウトは迅速かつ統一されており、ポイントや特典も活用できます。
この機能はエンドユーザーからますます求められており、それには十分な理由があります。この技術はSaaS+プラットフォームにも同様に有用です。エンドユーザーが複数の加盟店や取引形態で単一の決済方法を利用すると、その支出行動に関する膨大な情報が得られます。最終的に、プラットフォームはエンドユーザー向けにオファーや体験をより適切にカスタマイズできるようになります。この機能は、ロイヤルティを高めるリワードプログラムやポイントプログラムなどのツールの基盤にもなります。また、エンドユーザーとその好みの決済方法を真に理解できれば、決済処理インターチェンジ・アービトラージ（決済処理の裁定取引）の大きなメリットも得られます。
例：ShopifyとAmazonは、共通の決済ウォレットを採用しているプラットフォームの有名な例です。各プラットフォーム上の各販売業者にアカウントを持つ必要はもうありません。単一の決済ウォレットを使って買い物ができます。
6. 収益オーケストレーション層
SaaS+の収益源を持つ新しい垂直型ソフトウェアプラットフォームを構築する場合、ビジネスやテクノロジーを特定のベンダーに縛り付けるのは愚かなことです。プラグアンドプレイで接続でき、パートナーやベンダーをバックグラウンドでシームレスに切り替えられるようにする必要があります。
この機能により、あるベンダーから別のベンダーへボリュームを動的に移動することで、コストを可能な限り低く抑え、承認率を可能な限り高め、その他の戦略的な取り組みを実現できます。このメリットは非常に大きく、パートナーの誠実さと積極性を維持できます。
長年にわたり、こうした動的なベンダーオーケストレーションは独自に構築する必要がありましたが、私たちはまさにそれを実現しました。今では、お客様に代わってこれを実現する企業が存在します。Rally Venturesでは、このコンセプトを強く信じており、決済処理ベンダー向けにJustiFi、身元調査・本人確認ベンダー向けにYardstik、保険ベンダー向けにVertical Insureを開発・立ち上げました。
例: 収益オーケストレーション レイヤーの最もよく知られた例の 1 つは、旅行予約アプリケーションの Kayak です。
Kayakは旅行業界全体の最上位に位置しています。オーケストレーションレイヤーとして機能し、アグリゲーター、航空会社、ホテル、その他無数のソースから料金情報を取得します。これにより、消費者はあらゆる旅行取引において、常に最良の料金で旅行を楽しめることが保証されます。
結局のところ、これらのアーキテクチャ上の決定はすべて、より多くの取引と資金の流れを促進するためのものです。確かに、顧客にとって優れたプラットフォームの構築に役立ちますが、究極的には資金の流れを促進するためのものです。SaaS+プラットフォームにおいて、最も重要な統計データはエンドユーザーの取引数です。
取引件数の増加は、収益化される資金の流れ、本人確認の増加、チェックアウト時の保険契約販売数の増加、そしてチェックアウト時に販売される付加的な商品やサービスの増加を意味します。こうした活動はすべて収益にプラスに働き、コアとなるSaaS事業にもプラスの影響を与えます。なぜなら、ユーザーがこのようにプラットフォームを活用している場合、顧客が離脱することはほぼないからです。
また、明らかに取引を希望し、必要としており、それが簡単に行えるようになったことに満足しているエンドユーザーも満足しています。
