コセリング（共同販売）とは？ベンダーとパートナーが1つの案件に共同で取り組む方法
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
ほとんどのパートナーモデルは、仕事をきれいに分担します。リセラーは仕入れて販売します。紹介パートナーは名前を渡し、一歩下がります。コセリングは違います。2つの営業チームが、同時に案件に関与し続けるからです。一方が製品を持ち、もう一方が関係、連携、またはサービスを持ち、双方が顧客と話します。
この重なりこそが、コセリングが魅力的であり、同時に難しい理由です。どちらも単独では成約できなかった案件を勝ち取れることがあります。一方で、2人の担当者が同じ買い手に電話をかけ、クレジットをめぐって争い、相手が何を約束したのか互いに把握していない、という事態も起こり得ます。本記事では、この用語を定義し、隣接するモデルと切り分け、3大クラウドベンダーがコセルのプログラムをどう文書化しているかを見たうえで、仕組み、クレジットの付与、落とし穴を取り上げます。
コセリングの意味
コセリングとは、ベンダーとパートナーが特定の顧客の商談に共同で取り組む協業型の営業活動で、双方が相手に欠けているものを提供します。ベンダーは製品の深い知識、経営層へのアクセス、調達経路をもたらすかもしれません。パートナーは、顧客との関係、導入のキャパシティ、補完的な製品をもたらすかもしれません。
Microsoft自身の定義は、意図的に広く取られています。同社のPartner Centerのドキュメントは、コセリングを、Microsoftとそのパートナーエコシステムとの間のあらゆる協業的な取り組みとし、需要の創出、セールスプランニング、セールスリードの共有、パートナー同士の権限委譲型の販売の加速、マーケットプレイス主導のコマースの提供を挙げています（Microsoft Learn）。この幅広さは、有用な注意喚起です。実際には「コセル」は、温かい紹介1件から、双方に担当者の名前が入った共同のアカウントプランまで、あらゆるものを含みます。
本物のコセリングを、緩やかなパートナーシップから分ける特徴は3つあります。
- 特定された案件。 取り組みの中心は特定の顧客と案件であり、漠然とした協業の意思ではありません。
- 2つのアクティブな営業チーム。 双方の会社が、その案件に人員を割り当てます。
- 共有された可視性。 双方が、通常は共有システムや登録レコードを通じて、案件の状況を見られます。
コセリングと再販、紹介、パートナー起点の案件の違い
パートナーは複数を同時に行うことが多いため、これらのモデルは混同されます。次の表は、誰が何をするかで整理したものです。
| モデル | 誰が販売するか | 顧客との関係を所有するのは誰か | パートナーの典型的な役割 |
|---|---|---|---|
| 再販 | パートナーが販売する。多くはベンダーから仕入れ、自社で価格を設定する | パートナー | 取引、請求、サポートを行う |
| 紹介 | ベンダーが販売する | ベンダー | リードを紹介し、一歩下がる |
| パートナー起点の案件 | どちらが成約させてもよい | 案件を生み出した側 | 商談を見つけ、持ち込む |
| コセル | 両方のチームが共同で販売する | 共有。案件ごとに定義 | ベンダーの営業担当と並んで、案件への取り組みに貢献する |
2点の補足が重要です。第1に、「パートナー起点」は案件がどこから来たかを表し、コセリングは案件がどう進められるかを表します。パートナー起点の案件がコセルされることも、ベンダー起点の案件がコセルされることもあります。起点と協業は別々の軸であり、だからこそパートナーアトリビューションでは、それぞれに別のフィールドが必要になります。
第2に、再販と紹介は、一方の当事者が主導するため、運営が単純です。この2つのより詳しい比較は、紹介・アフィリエイト・リセラーの違いをご覧ください。コセリングは責任が共有されるため、より要求の高いモデルであり、共有された責任には、書面のルールが必要です。これはチャネルセールスモデルの中の主要な施策の1つであり、パートナー主導の成長の中核となる仕組みです。
ハイパースケーラーのコセルプログラムの構造
大手クラウドベンダー3社は、最も正式なコセルのプログラムを運営しており、その仕組みを公開しています。これらは構造の例として読むべきであり、そのまま真似るテンプレートとして読むものではありません。プログラム、基準値、特典は変わるため、以下はすべて各ベンダーのページに記載されている内容です。
Microsoft：コセルのステータスと紹介
Microsoftは、パートナーがMicrosoft Marketplaceに掲載するソリューションを軸に、コセルを組み立てています。Azureソリューションについては、同社のドキュメントが、in-market、co-sell ready、Azure IP co-sell eligibleという3つのコセルのステータスを挙げています（Microsoft Learn）。上位のステータスほど、解放されるものが増えます。
- Co-sell readyになると、ソリューションがMicrosoftの営業チームに公開されます。要件のページには、Microsoft Marketplaceでのオファーの公開、ビジネスプロファイルの完成、コセルの対象となる地域ごとの営業窓口の提供、1枚資料とピッチデックを含む掲載資料の提出といったステップが挙げられています（Microsoft Learn）。
- Azure IP co-sell eligibleになると、パートナーはコセルの紹介を提出できます。概要ページによれば、これによりオファーの販売が、顧客のMicrosoft Azure Consumption Commitmentsに貢献できるようになります（Microsoft Learn）。要件ページでは、過去12か月でAzure Consumed RevenueまたはMarketplace Billed Salesが少なくともUSD 100,000あること、さらに技術検証と、取引可能なMarketplaceオファーが求められています（Microsoft Learn）。
概要ページはまた、コセルの作業を4つのカテゴリーに分けています。Microsoftの営業チームとのコセル、パートナー同士、プライベートディール（独自に進めている案件を共有し、Microsoftのレポートに反映させること）、ソリューションアセスメントです（Microsoft Learn）。プライベートディールは、それ自体が有用な考え方です。ベンダーが支援していない場合でも、自分が取り組んでいる案件を伝えておくことで、パイプラインのデータが正確に保たれます。
Referralsワークスペースでは、パートナーが案件を作成し、Microsoftを招待します。結果を確認するには、FAQによれば、Partner Centerで案件を開き、Microsoftのステータスのセクションを確認します。FAQには、辞退の理由も挙げられており、たとえばMicrosoftの営業担当が顧客を直接管理していない場合などがあります。また、Microsoftが回答する前に案件の期限が切れた場合や、案件金額がUSD 25,000未満の場合には、理由が表示されないとも記されています（Microsoft Learn）。
AWS：ACEとPipeline Manager
AWSは、ACEとして知られるAPN Customer Engagementsプログラムを通じてコセリングを運営しています。同社のドキュメントによれば、ACEのパートナーは、AWSとの協業のための案件を作成し、共有し、受け取ることができます（AWS Partner Central）。プログラムのページには、パートナーはACE Pipeline Managerを通じてAWSと販売案件を共有し、AWS Salesでの可視性を最大化するために、ライフサイクルを通じて案件を更新し続けることが推奨されると記されています（AWS）。
AWSのセールスガイドは、共有パイプラインのステージとして、Prospect、Qualified、Technical validation、Business validation、Committed、Launched、Closed lostを示しています（AWS Partner Central）。双方が同じステージの用語を使うことが、このシステム全体の目立たない土台です。
最も示唆に富むのは、関与がどう決まるかです。ガイドによれば、すべての案件にはコセルモーションが割り当てられ、誰が主導するかが決まります。AWS Field-engaged（案件がAWSの営業チームとマッチングされ、直接協業する）、Agent-engaged（AWS Partner Centralのエージェントが、パートナーとともに案件を選別し、情報を補強する）、Partner-led（パートナーがエージェントの支援を受けて推進する）のいずれかです。各案件には、0から100のOpportunity Qualityスコアも付与されます。AWSは、スコアが高いほどAWSの現場の営業担当が関与する可能性が高まるかもしれないが、保証はされないと述べています（AWS Partner Central）。
ここからの教訓は、案件を登録することは、営業担当が付くことと同じではないということです。案件がチームの時間をどれだけ得られるかはベンダーが決めており、完全で具体的なレコードほど、より多くの時間を得られます。
Google Cloud：パートナーパスとしてのコセリング
Google Cloudの公開資料は、仕組みの面では簡素です。同社のパートナーネットワークのページは、コセリングや技術革新といった実社会での取り組みに報いるプログラムを説明し、パートナーパスは、コセリング、サービス、テクノロジーのいずれに注力するかというビジネスモデルに合わせて設計されていると述べています（Google Cloud）。同プログラムのローンチ記事は、成功したコセルの販売活動、質の高いサービス提供、ISVとの共同イノベーションに報いるとしています（Google Cloud blog）。
案件登録の段階的なフローは、パートナーポータルの内側にあり、その詳細は公開ページにないため、ここでは引用していません。Googleのプログラムを評価される場合は、別のバージョンのプログラム向けに書かれた要約ではなく、ポータル内の最新のドキュメントをお読みください。
コセルの進め方の仕組み
ベンダー固有のフォームの下では、同じ6つのステップが繰り返し現れます。ベンダーを問わないプログラムでは、そのすべてが必要になります。
- アカウントマッピング。 双方がターゲットアカウントのリストを突き合わせて、重なりを見つけます。ベンダーが関係を持ち、パートナーにユースケースがあるアカウント、あるいはその逆です。コセルの失敗の大半は、このステップを飛ばし、一方がまったく接点を持たないアカウントを追うことから始まります。
- 案件の登録。 一方が案件を記録します。顧客、課題、見込み額、時期、関係者などです。Microsoftのフローでは、パートナーが案件を作成してMicrosoftを招待し、AWSのフローでは、パートナーがPipeline Managerを通じて案件を共有します。一般的なパターンはディールレジストレーションです。
- 承諾または辞退。 もう一方が確認します。承諾は、名前の挙がった担当者がアサインされることを意味します。MicrosoftのFAQは、理由を添えた辞退があることを示しており、AWSの関与モデルは、承諾が程度の問題であることを示しています。
- 役割とルール・オブ・エンゲージメント。 誰が顧客に連絡するのか。誰が提案書、価格、契約を所有するのか。誰が技術検証を進めるのか。これらには案件ごとに書面での答えが必要であり、できれば最初の打ち合わせで合意しておきます。
- 共有されたパイプラインの可視性。 案件が進むにつれて、双方が同じステージ名を使ってレコードを更新します。更新されないレコードは、信頼を最も損なうものです。
- クローズと振り返り。 受注か失注かにかかわらず、結果はシステムに戻され、パートナービジネスレビューで何がうまくいったかを検証します。
パートナー側では、受け取った依頼への対応が、次に得られるものに影響します。MicrosoftのFAQは、迅速に応答すること、承諾する案件を選別すること、見込み案件規模、クローズ日、最終ステータスを報告することを勧めており、その情報を質の高い紹介の提供に使うと述べています（Microsoft Learn）。
報酬とインセンティブ
コセリングが機能するのは、双方の個々の営業担当にメリットがある場合だけです。ベンダーの担当者が、パートナーの案件を手伝っても何も得られなければ、その担当者は静かに無視するでしょう。Microsoftの概要は、これを同社のステータスモデルに結び付けています。Business ApplicationsのコセルのインセンティブのステータスであるStandardとPremiumは、Microsoftの営業チームがパートナーのオファーを販売する動機づけとなるものと説明されています（Microsoft Learn）。コセルされた案件で営業担当のクォータクレジットが具体的にどう機能するかは、各プログラムで確認し、「クォータの消化」に関する主張は、そのプログラム自身の条件で確認できるまで慎重に扱ってください。自社のプログラムでは、この問いを明示的に決めておきます。パートナーがコセルされた案件を成約させたとき、ベンダーの担当者は全額のクレジットを得るのか。ベンダーが主導したとき、パートナーのチームはクレジットを得るのか。
コセルされた案件のクレジットの付与方法
クレジットの問題は2つの部分からなり、これらを混同すると、争いが始まります。
売上またはパイプラインのクレジットは誰が得るのか。 これはレポートの問題です。パートナープログラムは通常、起点（ソース）、貢献（インフルエンス）、コセルの寄与を別々に追跡し、安全なルールは、各案件を1つの主たる役割のもとで1回だけ数えることです。詳しくはパートナーアトリビューションをご覧ください。
誰が、いくら支払いを受けるのか。 これは報酬の問題です。パートナーのマージン、紹介料、リベート、ベンダー側の営業担当のコミッションやクォータクレジットが関わる場合があります。これらは、アトリビューションのレポートではなく、パートナー契約とルール・オブ・エンゲージメントから導かれます。
実践的なアドバイス：
- クレジットのルールは、最初の争いの後ではなく、最初の案件の前に書き出します。
- 共同の案件は、はい・いいえの一言では捉えきれないため、各社が果たした役割（起点、選別、技術リード、クローズ）を記録します。
- 日付入りの登録レコードを保管します。2人の担当者が同じ案件を主張したとき、タイムスタンプとメモが決着をつけます。
- 争いになった案件を四半期ごとに見直し、繰り返し破綻するところはルールを厳しくします。
落とし穴
重要なポイント：コセリング
- Microsoftは、コセリングを、Microsoftとそのパートナーエコシステムとの間のあらゆる協業的な取り組みとして定義し、需要の創出、セールスプランニング、セールスリードの共有を含めています（Microsoft Learn）。
- MicrosoftのAzure IP co-sell eligibleの要件では、過去12か月でAzure Consumed RevenueまたはMarketplace Billed Salesが少なくともUSD 100,000あることが求められます（Microsoft Learn）。
- AWSはすべての案件に、コセルモーション（AWS Field-engaged、Agent-engaged、Partner-led）と、0から100のOpportunity Qualityスコアを割り当てます。スコアはAWSの営業担当が関与する可能性を高めるかもしれませんが、保証するものではありません（AWS Partner Central）。
- AWSの共有パイプラインは、ProspectからLaunchedまでの6つのステージと、Closed lostで構成されています（AWS Partner Central）。
- MicrosoftのReferral FAQは、Microsoftが回答する前に案件の期限が切れた場合や、案件金額がUSD 25,000未満の場合は、辞退の理由が表示されないと述べています（Microsoft Learn）。
- Google Cloudは、同社のパートナープログラムがコセリングなどの実社会での取り組みに報い、コセリング、サービス、テクノロジーに合わせたパスがあるとしています（Google Cloud）。
チャネルコンフリクト
コセリングは、1人の顧客の前に2つの営業部隊を立たせるため、チャネルコンフリクトにとってまさに格好の構図です。よくある引き金は、ベンダーの直販チームがすでにそのアカウントを担当している場合、2社のパートナーが同じ案件を主張する場合、一方を切り崩す値引きがある場合です。アカウントの種類ごとに担当者を明記したルール・オブ・エンゲージメントがあれば、その大半は防げます。残りには、意思決定者と期限を備えたエスカレーションの経路が必要です。
薄いレコードと幽霊案件
説明が1行で、次のステップもない登録済みの案件は幽霊です。システムの中には存在しますが、他のどこにも存在しません。AWSの案件管理に関するガイダンスは、望ましい状態を具体的に示しており、タイトルに顧客、ワークロード、提供モデルを明記すること、顧客の実際のビジネス課題を記述すること、ステージを正確に保つこと、次のステップを担当者と日付とともに書くことなどが含まれます（AWS Partner Central）。このアドバイスは、どのプログラムにも応用できます。
データ共有の制限
パイプラインを共有することは、顧客情報を共有することです。そうする前に、顧客との契約とパートナー契約が何を許可しているかを確認し、各社が自分の役割を果たすために必要なフィールドだけを共有してください。社内の価格やマージンのデータは、通常、それぞれの側にとどめます。競合する者同士が交換できる内容に競争法上の制約がある市場で事業を行う場合は、特に2社のパートナーが互いに競合している場合には、共有レコードに何を載せるかについて法的助言を受けてください。正しい答えは法域と契約によって異なるため、ここでは特定のルールを引用していません。
インセンティブのずれ
ベンダーの担当者が直販案件でのみ報酬を受けるなら、コセルされた案件は好意にすぎません。パートナーの担当者が自社製品でのみ報酬を受けるなら、ベンダーの製品は後回しになります。共同の施策を始める前に、双方の報酬を確認してください。日常的なリズムを保つ方法は、パートナーリレーションシップマネジメントをご覧ください。
適合しないコセリング
コセリングが向いているのは、特定の状況です。複雑な案件、連携やサービスを必要とするソリューション、パートナーが関係を持っているアカウントです。単純な取引型の製品には向きません。独立系ソフトウェアベンダーのパートナーを通じて販売するベンダーは、ベンダーのクラウドマーケットプレイス上でコセルすることが多く、コンサルティング企業は導入のキャパシティを強みにコセルします。
関連記事
