プラットフォーム戦略の進め方｜中堅企業が顧客とパートナーをつなぐ事業設計

自社の製品やサービスを起点に、顧客とパートナーが互いに価値を得られる取引を設計することが、プラットフォーム戦略の出発点です。

「自社だけでは顧客の要望に応えきれない」「パートナーを紹介しても、その後の結果が分からない」。こうした悩みがあるなら、参加者を集める場を作る前に、顧客と供給側の間で成立させたい取引を確かめる必要があります。

プラットフォーム戦略とは、複数の参加者をつなぐ場を設け、参加者同士の取引や交流から価値が生まれるように設計する事業戦略です。中堅企業では、自社が顧客の課題と供給側の事情を理解している領域を選ぶと、取引条件を具体的に検討できます。この記事では、事業の形を選び、手動で取引を試し、結果に応じて運用を見直す順序を示します。

この記事でわかること

自社事業にプラットフォーム戦略やエコシステム構築を取り入れたい中堅企業の経営者に向けた記事です。

• プラットフォームの基本構造 — 顧客と供給側がそれぞれ何を提供し、何を受け取るかを整理します。参加者が増えることと、取引しやすくなることの違いも確認します。
• 既存事業との違い — パイプライン型とプラットフォーム型を比較し、自社が提供し続ける仕事と、参加者同士の取引にできる仕事を分けます。
• 事業の形の選び方 — 業界特化型マッチング、パートナーエコシステム、データを活用する場について、着手できる条件と見直す条件を示します。
• 立ち上げと運用の順序 — 初期参加者の確保から候補の提示、取引後の確認、収益化の検討まで、各段階で何を記録するかを整理します。

読み進めながら、実際の顧客相談を一つ選んでください。顧客の要望、供給側に求める条件、紹介後に確認したい結果を書き出せば、自社が次に試すべき取引を具体化できます。

本記事は「経営戦略フレームワーク完全ガイド｜実務で使える10の戦略ツール」シリーズの一部です。

本記事はStartLinkの「経営管理DX完全ガイド」関連記事です。

プラットフォームビジネスの基本構造

プラットフォームでは、自社がすべての価値を作って顧客に届けるとは限りません。供給する参加者と利用する参加者が出会い、取引を進められるように、場の運営者が情報や手順を整えます。

一文にできたら、双方が取引へ進むために必要な情報を洗い出します。

サプライサイドとデマンドサイドを分ける

価値を提供する側をサプライサイド、受け取る側をデマンドサイドと呼びます。Airbnbを例にすると、両者と場の役割は次のとおりです。

自社の事業では、まず顧客が相手を選ぶために必要な条件を挙げます。対応範囲や依頼方法など、判断に必要な情報が供給側から得られないなら、募集を広げる前に聞き取り項目を揃えます。顧客の要望と選択条件が明確なのに候補が足りないなら、条件に合う供給側の確保へ進みます。

ネットワーク効果が生まれる条件を見る

ネットワーク効果とは、参加者が増えることによって、ほかの参加者にとっても場の価値が高まることです。同じ側の参加者が増えることで価値が上がる直接ネットワーク効果と、片方の側が増えることで反対側の価値が上がる間接ネットワーク効果があります。前者はLINEの利用者同士のつながり、後者はAmazonの出品者と買い手の関係を考えると区別しやすくなります。

自社で確かめる際は、登録者数だけで判断しません。供給側が増えた後、顧客は条件に合う候補を見つけやすくなったか。顧客からの相談が増えた後、供給側には対応できる依頼が届いたか。双方にとっての変化を取引の記録から確認します。片方に参加者が増えても相手側の選択や取引が改善していなければ、集客を広げる前に登録情報と候補の提示方法を見直します。

取引が成立するまでを一つの流れにする

検索できる一覧を用意しても、問い合わせ後に何が起きたか分からなければ、場の運営を改善できません。相談の受付、候補の提示、取引の可否、取引後の評価を一つの流れとして追います。

最初から複雑な仕組みを用意する必要はありません。顧客の要望、提示した候補とその理由、結果を同じ項目で記録します。候補を選べない相談が続くなら登録条件へ、提示後に進まない相談が続くなら提供条件や連絡方法へ戻ります。止まった段階が特定できたときに、直す条件を選べます。

パイプライン型とプラットフォーム型の違い

既存事業が製品やサービスを自社から顧客へ届けている場合、その価値の流れはパイプライン型として整理できます。プラットフォーム型では、参加者同士のやり取りも価値の源泉になります。既存事業全体を切り替える前に、顧客の目的を達成するために外部との取引が必要な部分を見つけます。

比較表を事業の問いとして読む

次の表は、両者の違いを項目ごとに比較したものです。「判定」の列は個別事業の成果を示すものではなく、検討時の着眼点として読んでください。実際の選択は、顧客と供給側の取引が成立する条件を確かめたうえで行います。

表を使うときは、まず顧客の目的を書き、その達成に必要な仕事を並べます。自社の提供物だけで目的を満たせるなら、既存事業の品質や提供方法を改善します。外部の供給側が必要なら、どの仕事を依頼し、顧客への説明や問題発生時の対応を誰が担うかを決めます。その役割を説明できてから、参加者同士をつなぐ形を検討します。

既存事業の一部から試す

自社の製品やサービスを使う顧客が、周辺の支援も求めているかを確認します。求めているなら、対象となる相談とパートナーの提供範囲を区切り、紹介や共同提供を試します。求めていないなら、取引の場を新設する理由を問い直します。

試す段階では、顧客の要望とパートナーの対応条件を同じ書式で残します。紹介後に取引へ進んだか、進まなかった理由は何かを確認してください。自社が担う説明とパートナーが担う提供を分けて記録すると、引き継ぎで止まったのか、提供条件が合わなかったのかを見分けられます。その流れを手動で説明でき、繰り返し発生する作業が見えたら、記録や候補提示の仕組み化を検討できます。

成長性と運営負荷を分けて評価する

参加者が増えると選択肢が広がる一方、登録内容の確認、問い合わせ対応、品質上の問題への対処も必要になります。

• 候補が増え、顧客が選んだ理由も説明できる ── 対象領域を広げる検討に進みます
• 候補は増えても取引に結び付かない ── 対象を絞って登録条件と提示方法を修正します
• 対応が追いつかない ── 参加者の募集より先に審査や問い合わせ対応の役割を整えます

広げる判断には、顧客が選べることと、運営が問題に対応できることの両方が必要です。

中堅企業が選べる事業の形

中堅企業が検討しやすい形として、業界特化型マッチング、パートナーエコシステム、データプラットフォームがあります。選ぶ基準は、自社が持つ資産の種類だけではありません。顧客が何に困り、供給側と結び付くことで何を解決できるかを先に確認します。

業界特化型マッチング

発注者が適切な受注者を見つけにくく、受注者にも対応できる仕事を見つけにくい事情があるなら、マッチングを検討できます。例えば、製造業の部品加工を扱うキャディは、発注企業と加工工場をつなぐ形の事業です。

自社で考える際は、発注条件と供給側の対応条件を並べます。

• 担当者の会話の中にしか条件がない ── 双方から同じ項目を聞き取れるようにします
• 条件を揃えても紹介が成立しない ── 選ばれなかった理由を確認し、対象業務や顧客層を絞ります
• 条件に合う候補を提示でき、その理由を顧客に説明できる ── 取引後の結果を追う段階へ進みます

パートナーエコシステム

顧客が自社の製品やサービスを使う過程で周辺の支援を必要とするなら、パートナーとの連携を検討できます。HubSpotを例にすると、CRMの利用に関わる連携アプリ、導入支援パートナー、HubSpot Academyなど、役割の異なる要素があります。自社のエコシステムを考える際も、連携先の数より、顧客に必要な支援と各パートナーの役割を明確にすることが先です。

顧客が求める支援を特定し、パートナーが対応できる範囲を確認します。次に、紹介前の説明、紹介後の窓口、問題が起きたときの対応を誰が担うか決めます。

• 顧客への説明が途切れる ── 連携を広げる前に役割分担を直します
• 顧客に価値があっても、パートナー側に参加する理由が見えない ── 紹介条件や協力の進め方を見直します

データを活用する場

例えば、トレジャーデータのCDPは、データの統合・分析・活用の場として位置付けられます。自社でもデータを活用する場を考えるなら、「誰が、どの判断に、どの情報を使うか」を先に決めます。データを集められることだけでは、参加者へ提供する理由になりません。

情報については、次の項目を確認します。

• 情報の出どころ
• 利用目的
• 提供範囲

説明できない情報は共有の対象に含めず、扱える範囲で利用者の判断に役立つかを確かめます。匿名化や集約を検討する場合も、先に用途と提供範囲を揃えます。利用者が必要とする判断と提供できる情報が結び付かないなら、集約する項目や対象者を見直します。

初期参加者を集める順序

プラットフォームには、供給側がいなければ顧客が来ず、顧客がいなければ供給側も参加しにくい「鶏と卵」の問題があります。最初から双方を広く集めるのではなく、自社にある顧客の要望、提供できるもの、既存の関係を確認し、どちらから取引を成立させられるかを決めます。

先に確保する側を決める

• 顧客から具体的な要望が集まっているのに候補が足りない ── 供給側の確保を優先します
• 提供できるパートナーがいても相談が来ない ── 顧客がその支援を必要とする場面を聞き直します

どちらの場合も、参加を依頼する前に、扱う取引と参加者に期待する対応を伝えられるようにします。

供給側に無料や優遇条件を提示する方法もあります。ただし、参加のための条件だけを先に決めず、顧客に示す内容、供給側に求める対応、条件を見直す場面を揃えて説明します。参加者の関心があっても、取引条件に合意できなければ、その条件を修正してから募集を広げます。

自社が片方の役割を担う

自社に提供できる製品やサービスがあるなら、初期には自社がサプライサイドを担う方法があります。顧客の要望を受け、自社で応えられる範囲と外部の力が必要な範囲を確認します。

顧客の要望が自社の対応範囲を超えたら、外部パートナーへ渡す条件を記録します。次の内容を毎回同じ形で残します。

• 依頼内容
• 顧客が重視する条件
• 引き継ぎ後の窓口

その情報でパートナーが対応可否を判断できるようになったら、外部へ役割を開く範囲を検討します。

既存の顧客接点から確かめる

既存の顧客接点がある場合は、顧客が現在どのように相手を探し、どの段階で困っているかを聞きます。その不便が自社と参加者の連携で解消できそうなら、対象を区切って取引の流れを試します。

顧客がすでに十分な方法で相手を見つけられているなら、別の場を用意する理由を問い直します。反応は賛否だけで記録せず、要望、提示した候補、選ばれなかった理由に分けます。解決したい不便が確認できた相談から、供給側に必要な条件を具体化します。

コアトランザクションを設計する

コアトランザクションは、場で成立させたい中核的な取引です。次の順に並べ、各段階で誰が何を受け渡すかを決めます。

1. 価値の作成
2. マッチング
3. 取引
4. 評価

登録とマッチングの条件を揃える

供給側が製品、サービス、情報を登録するときは、顧客が比較に使う条件を示せるようにします。条件が足りず候補を選べないなら、登録時に聞く項目を見直します。使われない項目が多いなら、顧客の選択に関わるものへ絞ります。

顧客の要望と供給側の条件を照らし合わせたら、候補を提示した理由も残します。候補を選んだ理由を説明できない場合は、推薦の仕組みを複雑にする前に判断基準を言葉にします。理由を顧客に説明でき、供給側も対応可否を判断できたら、取引へ進めます。

候補の抽出にAIを使う場合も、入力する条件と提示理由を人が確認できる形にします。条件の整理や比較を補助させる範囲と、顧客への推薦や例外対応を担当者が判断する範囲を決めておきます。理由を確認できない候補が出たら、自動化を広げる前に、登録情報と判断基準へ戻ります。

取引と評価を次の改善につなげる

候補の提示後には、取引に進んだかを確認します。進まなかった場合は、条件の不一致、連絡の行き違い、役割の曖昧さなど、分かった理由を記録します。取引後の評価も、点数を集めることより、次の顧客が選ぶ際に役立つ情報を見つけるために使います。

• 提供条件の違いが原因 ── 登録内容へ戻ります
• 対応の進め方が原因 ── 役割分担へ戻ります
• 理由が分からない ── 結果だけを集計する前に、顧客と供給側への確認方法を決めます

理由に応じて戻る段階を変えることで、修正する範囲を絞れます。

CRMに記録する範囲を決める

HubSpotを使う場合も、先に取引の流れを定義します。顧客との接点をコンタクトや会社、商談の進行を取引で追うなら、誰の要望がどの取引につながったかを確認する設計が考えられます。HubSpotでは取引をコンタクトや会社のレコードに関連付けられます（出典：Create deals）。

まず、相談を受けた人、候補を提示した人、結果を確認する人を決め、それぞれが残す情報を揃えます。紹介までを扱うなら、紹介結果を確認できる範囲から始めます。取引成立後の顧客対応や請求まで追う必要があるなら、引き継ぐ情報と担当部門を追加で決めます。どの段階で記録が途切れたか分かる状態になれば、入力項目を増やす前に担当と確認方法を見直せます。

以下の画面は、HubSpotでクローズ日ごとの商談金額を表にしたレポート例です。プラットフォーム事業でも、取引結果を振り返る際に「どの結果を一覧で確認したいか」を考える参考になります。画面に表示された金額は、この事業の成果を示すものではありません。

運用ルールと収益化を見直す

取引が動き始めたら、参加者が利用するときの条件と、運営を続けるための収益条件を検討します。品質管理、価格設定、紛争への対応に加え、一覧だけで取引が進まない状態や、参加者が複数の場を使う状況も確認します。実際の取引で生じた問題から、必要なルールを具体化します。

品質とトラブル対応の責任を決める

参加者の審査基準、取引後の評価、不正への対応は、提供するものに合わせて設計します。

• 顧客が供給側の品質を比較できない ── 登録時に示す情報と確認方法を整えます
• 問題が起きた場合に備える ── 連絡を受ける窓口、当事者への確認方法、返金を含む対応の判断者も決めます

価格や手数料については、顧客に表示する価格と供給側への支払い条件を分けて整理します。参加時点で説明できない条件があるなら、取引を広げる前に文書化します。実際に問い合わせが生じたら、決めた手順で対応できたかを確認し、判断が分かれた箇所を見直します。

カタログサイト化とマルチホーミングを見分ける

登録情報が並んでいても、参加者が適した相手を見つけられず、問い合わせ後の取引も進まないなら、一覧だけの「カタログサイト」になっている可能性があります。顧客が候補を選べないのか、選んだ後に連絡が途切れるのかを分けて確認し、それぞれ検索条件と問い合わせ後の手順を見直します。

参加者が複数の場を併用することを、マルチホーミングと呼びます。例えば、飲食店が食べログ、ぐるなび、ホットペッパーを併用するケースです。自社の場が選ばれる理由を確かめるには、顧客と供給側の双方に、どの情報や支援が取引に役立ったかを聞きます。理由を示せないなら、機能を増やす前に、対象とする取引と運営が担う仕事を見直します。

手数料は取引の価値と合わせて考える

手数料を決める前に、場の運営が何を提供しているかを明確にします。集客、候補の選定、取引の支援、取引後の対応を分けて書き出し、誰がそれぞれの価値を受け取るかを確認します。

参加者が運営の役割と料金条件を理解し、その条件で取引を続けたいと判断できるなら、手数料や継続課金を検討します。取引が成立していない、あるいは運営の価値を説明できないなら、先にコアトランザクションへ戻ります。条件を変える際は、対象となる取引と適用する場面を参加者へ説明できるようにします。

よくある質問

プラットフォーム戦略には大規模な投資が必要ですか？

投資の範囲は、最初に扱う取引によって変わります。既存のWebフォームと手動のマッチングから始める方法もあります。まず顧客と供給側の条件を揃え、候補の提示から結果の確認まで追えるかを確かめてください。繰り返す作業が明らかになったら、その作業からシステム化を検討できます。条件が揃わず取引が止まるなら、仕組みへの投資を決める前に聞き取り項目を見直します。

「鶏と卵」の問題にはどう着手しますか？

すでに顧客の具体的な要望があるなら、対応できる供給側を探します。自社に提供できるものがあるなら、初期には自社が供給側を担う選択もあります。どちらの場合も、取引が進まない理由を記録します。条件が合わないまま反対側の参加者を増やすのではなく、提示内容や対象とする取引を見直してください。

手数料率はどのように決めますか？

顧客と供給側がそれぞれ得る価値、運営が担う仕事、取引後の対応範囲を整理します。その内容と料金条件を参加者へ説明でき、取引も成立しているなら、誰にどの形で負担してもらうかを検討します。価値や役割を説明できない場合は、率を決める前に取引の設計へ戻ります。

既存事業をプラットフォーム型へ転換する必要がありますか？

企業様によって最適な形は異なります。顧客が自社の提供物だけで目的を達成できるなら、既存事業の改善を優先できます。周辺サービスや外部の供給側を必要としているなら、その接点を既存事業に加えて試します。顧客の要望と取引結果を追い、連携が継続して役立つと確認できた範囲から広げてください。

まとめ

プラットフォーム戦略は、顧客と供給側の間に成立させたい取引を定義するところから始まります。必要な情報、運営の役割、結果の確認方法を揃えれば、参加者を増やすべきか、取引の条件を直すべきかを判断できます。既存事業で扱う顧客相談から選ぶと、実際の取引に沿って検討できます。

まずは、外部の提供者との連携が役立ちそうな顧客相談を一つ選んでください。

1. 顧客の要望と、供給側に求める条件を書き出します。
2. 候補を選んだ理由から取引結果まで記録し、どの段階で止まるかを確かめます。
3. 止まった理由に応じて、対象領域、登録条件、役割分担のいずれを直すか決めます。

この流れを説明できたら、同じ条件で扱える相談の範囲を検討します。取引が進まない場合は参加者を増やす前に、止まった段階の条件へ戻ってください。

CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• 事業多角化の判断基準｜シナジーがある多角化とない多角化の見分け方 -- プラットフォーム構築を新規事業として位置づける際の、シナジー評価と撤退基準の設定方法を解説しています。
• サブスクリプションモデルへの転換方法 -- プラットフォームの収益モデルとして主流のサブスクリプション型ビジネスへの移行ステップを紹介しています。
• 競争戦略の基本｜ポーターの3つの基本戦略を中堅企業に適用する方法 -- プラットフォーム戦略の前提となる、業界構造の分析と競争ポジションの選択について解説しています。