パートナーリレーションシップマネジメント（PRM）とは？

著者: Brian Tr · 更新日: 2026年10月5日

「PRM」という言葉は2つの異なるものを指して使われており、これにまつわる混乱の大半は、その2つを混同することから生じます。1つ目は、実践としてのPRMです。自社製品を販売、導入、紹介するパートナーを、会社がどのように獲得し、支援し、報い、測定するかというやり方を指します。2つ目は、ソフトウェアのカテゴリーとしてのPRMです。その実践を運営するためにベンダーが購入するポータルやワークフローツールを指します。

本記事では、その両方を定義し、PRMが管理するパートナーライフサイクルを順にたどって、PRMとCRMの違いを説明します。そのうえで、PRMソフトウェアの主要な機能を挙げ、4つの大手ベンダーのプログラムがそれらの機能をどう提供しているかを示し、自社開発か購入かという考え方と、PRMの取り組みがうまくいかなくなる典型的なパターンを取り上げます。

PRMとは：取り組みであり、ソフトウェアのカテゴリーでもある

取り組みとしてのパートナーリレーションシップマネジメントとは、ベンダーが間接チャネルを管理するために用いる一連のプロセスです。どのパートナーを獲得するか、何を販売してよいか、どのように製品を学ぶか、案件の貢献をどう評価するか、どう報酬を支払うかを、誰かが決めなければなりません。この仕事は、ソフトウェアが関わるかどうかにかかわらず存在します。リセラーが10社ほどの会社なら、スプレッドシートと共有の受信トレイで回すことができます。

ソフトウェアのカテゴリーとしてのPRMとは、同じ仕事を大規模に支えるツールです。その中心となるのは、パートナー向けのポータルで、社外の企業がログインして、コンテンツを入手し、案件を登録し、ファンドを申請し、自らの成果を確認する場所です。ポータルの裏側には、パートナーの承認、リードの振り分け、ディールレジストレーションのレビュー、成果のレポートといった、ベンダー側のワークフローがあります。

この2つの意味は、互いに依存しています。ソフトウェアでは、ルールが曖昧なプログラムを直すことはできませんし、優れたプログラムは、やがてスプレッドシートでは収まらなくなります。どのようなプログラムが必要か検討中の場合は、まずチャネルパートナープログラムと、より広い視点のパートナー主導の成長モデルから始め、そのあとでツールの話に戻ってください。

PRMが管理するパートナーライフサイクル

PRMの対象範囲の大半は、6つの段階に対応します。プログラムごとに呼び方は違いますが、順序は変わりません。

獲得。 ベンダーは、どのパートナーを求めるのかを決め、応募者を審査します。優れたPRMの実践では、これを配信リストではなく、基準のあるファネルとして扱います。OracleのPRM製品ページは、この段階を「新しいパートナーを獲得し、スコアリングし、評価し、オンボーディングする」機能として説明しており、ベンダーがこれをどう捉えているかが分かります。一度きりの署名ではなく、スコアリングを伴うパートナー候補のパイプラインという捉え方です。

オンボーディング。 契約が締結されたら、作業はアクセス、審査のフォローアップ、最初の計画へ移ります。各段階と実用的なチェックリストは、パートナーオンボーディングで扱っています。

イネーブルメント。 オンボーディングには終わりがありますが、イネーブルメントにはありません。トレーニング、営業コンテンツ、技術リソースが継続的に流れ続けます。PRMは通常、コンテンツライブラリをホストし、誰が何を修了したかを追跡します。パートナーイネーブルメントをご覧ください。

コセリングとディールレジストレーション。 PRMを他のツールと最も大きく分ける段階です。商談を持ち込むのはパートナーで、ベンダーはそれを知る必要があり、双方が、誰が何を見つけたのかの共通の記録を必要とします。ディールレジストレーションはその仕組みです。パートナーが商談を申請し、ベンダーがレビューし、承認によってその案件に対するパートナーの権利が守られます。仕組みはディールレジストレーションで説明しています。登録が直販担当のアカウントと重なると、チャネルコンフリクトが起こります。PRMは所有関係を見えるようにすることでこれを減らせますが、方針をめぐる問題までは解決してくれません。

インセンティブとファンド。 パートナーは、プログラムが何に報いるかに反応します。これには、マージンやリベートの構造（パートナーインセンティブ）と、共同出資のマーケティング（マーケット開発資金で解説）が含まれます。ソフトウェアの観点では、承認と実績の証明の手順を伴う、ファンドの申請と請求のワークフローを意味します。

測定。 レポートが、サイクルを完結させます。パイプラインを生んでいるパートナー、取引を処理しているだけのパートナー、休眠しているパートナーを見分けます。これがなければ、ティアやインセンティブの判断は勘で下されます。指標そのものについては、パートナーKPIをご覧ください。

PRMとCRMの違い

CRMは、ベンダー自身の顧客と見込み客を中心に作られており、ユーザーはベンダーの従業員です。PRMは、それぞれ自分の顧客を持つ外部の組織を中心に作られており、ユーザーには、ベンダーでまったく働いていない人も含まれます。この1つの違いが、他の違いのほとんどを生み出しています。

この2つは競合関係にはありません。実務では、PRMはほぼ必ずCRMと連携します。登録された案件は、最終的にベンダーの営業チームが予測する商談になるからです。リスクは、二重入力とレコードの食い違いです。パートナーが別のシステムでレコードを作るようになると、CRMを唯一の信頼できる情報源にすることが、いっそう重要になるのはそのためです。

PRMを、CRMの上に載せるレイヤーとして提供するベンダーもあれば、CRMと同期する独立したPRM製品を販売するベンダーもあります。どちらのモデルも存在し、その選択はデータの所有権に影響します。これについては、自社開発か購入かの節で改めて触れます。

PRMの主要な機能

ベンダーが違っても、大半のPRM製品は、機能を同じ十数の領域にまとめています。これを要件のチェックリストとして使ってください。

• パートナーポータル。 パートナーが必要なものすべてを見つけられる、ブランド化された認証付きのスペースです。通常、シングルサインオンと、ロールに基づく表示をサポートします。
• パートナーの獲得とオンボーディングのワークフロー。 申請フォーム、スコアリングまたは承認のステップ、タスクリスト、契約の取り扱い。
• パートナーのアカウントとユーザーの管理。 企業プロフィール、階層、コンタクト、そして自社の同僚を追加できるパートナー側の管理者。
• コンテンツとトレーニングのライブラリ。 営業資料、製品ドキュメント、コース、認定の追跡。
• リードの振り分け。 マーケティング起点のリードを適切なパートナーに渡すルールと、パートナーがそれを受け入れ、却下し、更新する手段。
• ディールレジストレーション。 申請フォーム、承認のワークフロー、有効期限のルール、保護のロジック。
• 見積もりと商談の支援。 価格設定ツール、見積書の作成、商談の状況の共有ビュー。
• インセンティブとファンドの管理。 MDFの申請、請求、承認、支払いの追跡。対応している場合は、リベートやSPIFFの管理も含みます。
• コマーケティングのツール。 共同ブランドの素材、キャンペーンのテンプレート、共有のメールやソーシャルのコンテンツ。
• 分析とスコアカード。 パートナースコアカードやティアのレビューに反映される、パートナー単位およびプログラム単位のダッシュボード。
• 連携。 CRM、マーケティングオートメーション、請求、学習システムとの接続。
• ガバナンス。 監査証跡、権限、文書や契約の保管。

すべてのプログラムがこれらすべてを必要とするわけではありません。紹介のみのチャネルなら、リードフォーム、支払いの記録、ダッシュボードがあれば足りるかもしれません。見積もりとテリトリーのルールがあるリセラーのチャネルでは、はるかに多くが必要です。

主要ベンダーのプログラムは、PRMの機能をどう提供しているか

大手のプラットフォームベンダーは、自社のパートナープログラムを運営し、PRMツールを販売しているため、そのドキュメントを見れば、機能がどのようにパッケージ化されているかが分かります。以下の説明は各ベンダー自身のページに基づいており、価格ではなく機能を説明しています。製品名やパッケージは変わるため、細部に頼る前に、最新のドキュメントをご確認ください。

Salesforce

SalesforceのLightning Partner Managementガイドは、チャネルマネージャーとパートナー向けのパッケージ済みソリューションを説明し、次の機能を挙げています。パートナーアカウント管理、パートナーの獲得、オンボーディングとサポート、リードの振り分け、ディールレジストレーション、コンテンツライブラリ、パートナー分析、マーケット開発資金の管理です。同ガイドは、ディールレジストレーションでは、パートナーが申請した登録案件が自動的にチャネルマネージャーに送られて承認を受けること、そして承認のワークフローをカスタマイズできることも説明しています。その過程で作成されたリードは、企業が定義した割り当てルールに従います。これは、CRMの上に載せたレイヤーとして提供されるPRMの分かりやすい例です。パートナーのレコードは、ベンダー自身のパイプラインと同じプラットフォームにあります。出典：Salesforce Lightning Partner Managementガイド。

Oracle

OracleのPRMのページは、ライフサイクル全体にわたる機能を説明しています。最初の段階では、新しいパートナーを獲得し、スコアリングし、評価し、オンボーディングする機能に触れています。コセリングについては、ディールレジストレーションと承認、そしてパートナーがリードを請求し、見極め、転換する手段を挙げています。ファンドについては、マーケット開発資金を承認、支払い、そのリターンを追跡する機能を説明し、成績上位のパートナーを特定するためのパフォーマンスダッシュボードも備えています。PRMを単一のポータルではなく、エンドツーエンドのライフサイクルとして示しているベンダーの好例です。出典：Oracle Partner Relationship Management。

Microsoft Partner Center

MicrosoftのPartner Centerは、非常に大規模なプログラムのパートナー側から見て、PRMの機能がどのように見えるかを示しています。Referralsワークスペースは、コセリングの商談とディールレジストレーションを扱います。Referralsのよくある質問は、ディールレジストレーションの対象となるのはIPインセンティブのみであること、案件が最終状態になると編集できなくなること、そしてパートナーは、迅速に応答し、案件の規模、クローズ日、最終ステータスを報告することで、コセリングでの可視性が高まることを述べています。Microsoftの一括操作のページは、ガバナンスの側面を示しています。Referrals adminやReferrals userといったロール、定義された登録ステータス（ReviewPending、ActionRequired、Approved、Passed、Failed、Closed）、そして申請後に読み取り専用になる項目です。これらの詳細は、PRMの2つの設計原則を示しています。パートナーの担当者に対するロールベースのアクセスと、登録された案件ごとの明示的なステータスモデルです。

HubSpot

HubSpotのSolutions Partner Programは、エージェンシーやサービスパートナーに適用されたPRMの考え方を示しています。そのプログラムポリシーでは、Partner Directoryにプロフィールを掲載するには、パートナーが最低1つのHubSpot認定に合格する必要があり、ティア付きのSolutions Partnerになるには、Partner Certificationに合格してそれを維持する必要があると述べています。つまり、認定が可視性とステータスに結びついているのです。どのPRMでも注目すべきパターンです。イネーブルメントの成果（認定）が、プログラムのルール（ディレクトリへの掲載、ティア設定）に直結しています。認定をプログラムの手段としてどう使うかは、パートナー認定をご覧ください。

重要なポイント：パートナーリレーションシップマネジメント

• SalesforceのLightning Partner Managementガイドは、パートナーアカウント管理、獲得とオンボーディング、リードの振り分け、ディールレジストレーション、コンテンツライブラリ、パートナー分析、MDF管理を標準の機能として挙げています（Salesforce）。
• Microsoftは、Partner Centerでディールレジストレーションの対象となるのは、IPインセンティブ（Azure IP co-sell、Biz apps premium、Biz apps standard）のみだと述べています（Microsoft Learn）。
• Microsoftの一括ディールレジストレーションのステータスは、ReviewPending、ActionRequired、Approved、Passed、Failed、Closedです（Microsoft Learn）。
• HubSpotは、Partner Directoryにプロフィールを掲載するには最低1つの認定、ティア付きのSolutions Partnerになるには維持されたPartner Certificationを求めています（HubSpot）。
• Oracleは、自社のPRMが、獲得、オンボーディング、ディールレジストレーション、リード管理、MDFの承認と追跡、パフォーマンスダッシュボードを対象としていると説明しています（Oracle）。

自社開発か購入か：概念上のトレードオフ

ベンダーは、いずれ、自社のCRMの上にパートナー向けのツールを構築するか、専用のPRMを導入するかを問われます。万能の答えはありませんが、トレードオフには一貫したパターンがあります。

CRMの上に構築すると、データを一か所にまとめられ、ワークフローを自社のチームで制御できます。プログラムがシンプルで、CRMがすでに外部ユーザーに対応していて、ポータルを設定、保守できる管理者がいる場合に向いています。コストは継続的に発生します。すべての承認ワークフロー、権限ルール、レポートに担当者が必要で、プログラムを変えるたびにプロジェクトになります。

専用のPRMを購入すると、登録、ファンド、オンボーディングのための構築済みのワークフローと、他社が最新の状態に保ってくれるパートナー体験が手に入ります。パートナーの数が多く、パートナータイプが複数あり、インセンティブのルールが複雑なプログラムに向いています。コストは、連携すべきシステムがもう1つ増えること、CRMと突き合わせるべきデータモデルがもう1つ増えること、そしてベンダーのロードマップに依存することです。

判断を左右しやすい問いは、次のとおりです。

1. いくつのパートナータイプを運営するか。 紹介、リセラー、インテグレーター、ISVの各パートナーには異なるワークフローが必要で、自社開発では、そのそれぞれに対応しなければなりません。
2. データは誰が所有するか。 パートナーと案件のレコードをどこに置くか、そして食い違ったときにどちらのシステムを優先するかを決めてください。
3. インセンティブはどれほど複雑か。 単純なマージンのティアは簡単ですが、ファンドの請求、実施の証明、リベートの計算が加わると、実質的なワークフローが増えます。
4. パートナー体験に何が必要か。 パートナーは、自社のポータルを他のすべてのベンダーのポータルと比べます。分かりにくければ、利用が減ります。
5. 誰が管理するか。 どちらの道を選んでも、担当者のいないツールは劣化します。
6. 規模が大きくなったらどうなるか。 20社のパートナーでうまくいく自社開発が、200社では負荷に耐えられなくなることがあります。

段階的なアプローチもよくあります。軽量な構成（共有フォーム、コンテンツフォルダー、登録用のシート）で始めてプログラムが機能することを確かめ、手作業がボトルネックになったらPRMツールに移ります。逆の失敗、つまりプログラムにルールが整う前に重厚なプラットフォームを購入することのほうが、コストは高くつきます。

PRMでよくある失敗のパターン

PRMの問題の大半は、ソフトウェアに表れたプログラムの問題です。

• プログラムの前にツール。 ポータルでは、曖昧な条件、定義されていないティア、パートナーの成功に責任を持つ人がいない状況を補えません。
• 幽霊ポータル。 ポータルにパートナーが必要とするものが何もないため、一度登録したきり戻ってこなくなります。パートナーを呼び戻すのは、コンテンツ、案件のツール、支払いの可視性です。
• 承認の遅さ。 ディールレジストレーションやファンドの請求が数週間待たされると、パートナーはシステムを迂回します。レビューのサービスレベルを設定し、測定してください。
• 重複したレコード。 パートナーとベンダーの営業担当が同じアカウントを作成し、誰もデータを信頼しなくなります。照合のルールと所有関係を、早めに定義してください。
• 権限の与えすぎ。 パートナーのユーザーにベンダーのデータへの広い閲覧権限を与えると、セキュリティと対立の問題が生じます。与えなさすぎると、ポータルが役に立たなくなります。ロールベースのアクセスは、意図的に設計してください。
• 測定がない。 誰もレビューしないダッシュボードは、行動を変えません。パートナービジネスレビューで扱っているように、定期的なレビューと結びつけてください。
• アトリビューションをめぐる紛争。 起点と影響の売上を双方が別々に数えると、信頼が損なわれます。パートナーアトリビューションをご覧ください。
• 連携のずれ。 項目の変更やプロセスの更新の後に、PRMとCRMの同期が崩れます。ポータルだけでなく、連携にも担当者を割り当ててください。

関連記事

• パートナーオンボーディング
• パートナーイネーブルメント
• ディールレジストレーション
• マーケット開発資金
• チャネルコンフリクト
• パートナーKPI
• CRMを唯一の信頼できる情報源にする
• チャネルパートナープログラム