代理店やパートナー企業からの報告を、Excelやメールで受け取っている会社は少なくありません。月末になると各社からファイルが届き、それを1つに集計し直す作業が発生します。フォーマットは代理店ごとに微妙に違い、記入漏れも珍しくなく、集計が終わる頃には数字が1週間前のものになっています。
この状況を見た情報システム部門や営業企画部門が最初に思いつく解決策は、たいてい同じです。「代理店の担当者にも自社のCRMを直接使ってもらえばいいのではないか」。二重入力がなくなり、報告を待つ必要もなくなり、リアルタイムで案件の状況が見える。理屈のうえでは筋が通っています。
この発想は、多くの場合「代理店経由もDXしろ」という経営層からの号令とセットでやってきます。直販部門はすでにCRMで案件を管理しているのに、売上の大きな割合を占める代理店経由の商流だけがExcelとFAXで運用されている。この非対称を経営会議で指摘されたパートナーセールス担当者が、まず検討するのが「代理店にもCRMのアカウントを配る」という案です。しかし、いざ社内で検討を始めると、情報システム部門やCRMベンダーの担当者から「それはこういう問題が出ます」と、想定していなかった論点を次々に指摘されることになります。
ところが、この発想を実行に移そうとすると、SalesforceであってもkintoneであってもHubSpotであっても、ほぼ同じところでつまずきます。つまずき方が製品によらず共通しているということは、それが特定のCRMの機能不足ではなく、CRMという道具そのものの前提に起因する構造的な問題だということです。本稿では、なぜ代理店を自社CRMに入れたくなるのかを整理したうえで、どのCRMを使っていても共通して立ちはだかる論点、そして主要3製品がその論点にどう向き合っているかを、公式ドキュメントに基づいて中立に確認します。最後に、その先にある設計の考え方をまとめます。
なぜ社外の代理店をCRMに入れたくなるのか
代理店経由の販売比率が高い会社ほど、この誘惑は強くなります。理由は主に2つです。
1つ目は二重管理の解消です。代理店側は自社の営業活動を自社の方法で管理し、メーカー側への報告のためにもう一度同じ情報を別の形式で作り直しています。これは代理店にとっても負担であり、報告を後回しにする動機にもなります。メーカー側から見れば、代理店にCRMを直接使ってもらえれば、この二度手間がなくなるように見えます。
2つ目は報告の鮮度と粒度です。月次のExcel報告では、案件がどの段階にあるかという情報が丸められてしまい、経営会議での予測が外れる原因になります。CRMの中でリアルタイムに案件のステータスが動けば、この問題は解消するはずだと考えるのは自然な発想です。この、Excelでの代理店管理がどこまで持ちこたえ、どこで壊れるのかという境界線については、姉妹記事の「代理店管理、Excelで対応できる範囲とその先」で詳しく扱っています。
この2つの動機自体は正当です。問題は、その解決策として「自社のCRMに代理店を招き入れる」という手段を選んだ瞬間に、CRMという道具の設計思想と正面からぶつかる論点が3つ発生することです。次章で、その3つを順に見ていきます。
どのCRMを使っていても共通して立ちはだかる論点
Salesforce、kintone、HubSpotは、社内向けのCRM・SFAとしての設計思想も、価格帯も、想定する企業規模もまったく異なる製品です。それにもかかわらず、社外の代理店やパートナーを迎え入れようとすると、驚くほど同じ形の壁に当たります。それは、これらの製品が本来「自社の社員が、自社の情報を扱うための道具」として設計されているためです。社外の第三者を招き入れることは、後から付け足した拡張機能であって、製品の中心的な設計思想ではありません。
その結果として現れる論点は、整理すると次の3つに集約されます。
論点1｜データの所有権は、実はメーカー側にあるとは限らない
代理店の担当者を自社CRMのユーザーとして招待するとき、メーカー側の視点では「自社のCRMに、代理店にも入ってもらう」という認識になりがちです。しかし、代理店側の視点に立つと、これはまったく別の意味を持ちます。代理店が持っている顧客リストや商談の情報を、取引先であるメーカーのシステムに直接入力する、つまり自社の顧客資産を取引先のデータベースへ差し出す構造になるのです。
代理店にとって顧客との関係は、その代理店自身の営業資産です。それを競合のメーカーも同じように扱っている取引先のCRMに、自社の担当者名や連絡先まで含めて入力することに慎重になるのは、当然の防衛本能です。運用が順調に回っている間はこの緊張関係が表面化しませんが、代理店契約の条件が変わったとき、あるいは代理店が複数のメーカーの製品を扱っているときに、この「データがどちら側にあるのか」という所有権の問題が顕在化します。
メーカー側が良かれと思って用意した「代理店専用の使いやすい画面」であっても、その裏側のデータが物理的にメーカーのCRMのインスタンスに格納されている限り、代理店から見た構造は変わりません。この非対称性に気づかないまま設計を進めると、代理店側の協力が思ったほど得られない、という壁に当たります。
この論点が最も分かりやすく表面化するのは、代理店契約が終了する場面です。代理店の担当者が数年かけてメーカーのCRMに入力してきた顧客情報や商談履歴は、契約終了と同時にどちらのものになるのでしょうか。メーカー側は「自社のCRMに入っているのだから自社のデータだ」と考えがちですが、代理店側からすれば、自分たちが開拓し育ててきた顧客リストを、契約終了後もメーカーに握られたままにする形になります。この問題を運用ルールや契約書だけで手当てしようとする会社は多いのですが、そもそもデータが物理的にどちらの基盤にあるのかという設計上の選択が、契約終了時の力関係を先に決めてしまっているのです。
この緊張を和らげようとして、一部の会社は「代理店には顧客名や連絡先を伏せ、案件の進捗だけを入力してもらう」という運用でしのごうとします。しかしこれでは、そもそも代理店側の入力の手間を減らすという当初の目的が薄れてしまいます。案件の実態を正確に伝えようとすればするほど顧客情報の記載が必要になり、記載を避ければ情報の精度が落ちる。この綱引きは、権限やルールの工夫では根本的に解消しません。データを渡す範囲そのものの設計に立ち戻る必要があります。
論点2｜社内向けの権限モデルでは「中間的な応答」が作れない
CRMの権限モデルは基本的に、あるレコードを「見せる」か「見せない」かの二択で設計されています。ロール、チーム、共有ルールといった仕組みは、いずれもこの二値の判定を、誰に対して・どの範囲で適用するかを細かく調整するためのものです。
ところが、代理店との関係で本当に必要になるのは、しばしばこの二択のどちらでもない、中間的な応答です。典型例が、代理店が新しい見込み客を見つけたときの重複確認です。代理店は「この会社にアプローチしてよいか」を知りたいだけであり、それが自社の直販部門や別の代理店とすでに接触しているかどうかという一点さえ分かればよいのです。社内の案件一覧を丸ごと見せる必要はなく、むしろ見せてはいけません。
しかし、社内向けの権限モデルの延長でこれを作ろうとすると、うまくいきません。レコードへのアクセス権を持たせれば見えすぎてしまい、権限を持たせなければ何も返ってきません。「重複しているかどうかという一言の判定だけを返す」という、社内の権限設計には存在しない第三の応答は、既存の共有ルールや権限セットを組み合わせても素直には作れないのです。Salesforceの共有の仕組みも、レコード単位でのアクセス許可を土台にしており、判定結果だけを返す仕組みではなく「アクセスできる／できない」を制御するものです。バッティング（商談の競合）の判定は、この土台の外側に別のロジックとして用意する必要があります。
具体的な場面を想像すると分かりやすくなります。ある代理店の担当者が、展示会で名刺交換した見込み客を自社に登録しようとしています。この担当者が本当に知りたいのは「この会社に、すでに自社の直販担当や別の代理店が接触していないか」の1点だけです。接触している場合はその案件を諦めるか、事前にメーカー側と調整すればよく、接触していなければそのまま案件登録を進めればよい。つまり必要なのはYesかNoかの1つの判定だけであり、誰が・いつ・どんな条件で接触しているかという中身までは、代理店に開示する必要も権限もありません。ところが標準的な権限モデルは「見せる相手の範囲」を決める仕組みであって、「特定の問い合わせに対して1つの判定だけを返す」仕組みではないため、この単純な要求ですら標準機能の外側に作り込みが必要になります。
現場でよく見られる次善策が、営業企画の担当者が代理店からの問い合わせをいったんメールや電話で受け、社内のCRMを自分の目で確認してから代理店に折り返すという運用です。これは仕組みとしては機能しますが、担当者1人がすべての問い合わせを人力でさばく体制になり、代理店の数が増えるほど、あるいは展示会シーズンのように問い合わせが集中する時期ほど、この担当者がボトルネックになります。権限モデルで自動化できない部分を人の判断で埋め合わせている状態であり、代理店の数が数十社を超えたあたりから運用が破綻し始めます。
論点3｜月1ログインの代理店営業にシート課金は成立しない
3つ目は費用の構造です。SalesforceもHubSpotも、ユーザー数に応じた有償シートの課金モデルを採用しています。代理店の担当者全員にログインアカウントを配ろうとすると、シートの数は代理店の人数に比例して増えていきます。
ここで見落とされがちなのが、代理店側のCRM利用頻度です。代理店の営業担当者は自社のメーカー1社だけを担当しているわけではなく、複数のメーカーを扱っているのが一般的です。その担当者にとって、貴社のCRMは数ある取引先のシステムの1つに過ぎず、実際にログインするのは新製品の説明会があったときや、案件を登録するときなど、月に1回あるかないかというケースが珍しくありません。
その利用頻度に対して、社内の営業担当者と同じ有償シートを払い続けることは、費用対効果として成立しにくくなります。かといってシートを絞れば、その代理店担当者はそもそもCRMにアクセスできず、当初の目的だった「代理店にも直接使ってもらう」ことができません。人数分のシートを持ち続けるか、アクセスを諦めるかの二択に追い込まれるのが、この論点の厄介なところです。
この問題は、代理店の数が増えるほど深刻になります。1社や2社の代理店であれば、多少の無駄なシート費用は許容範囲かもしれません。しかし代理店網が数十社、担当者の頭数で数百人という規模になると、実際にログインしているのはそのうちの一部だけという状況で、大半のシートが「配ってはいるが使われていない」という状態のまま費用だけが積み上がります。ここで多くの会社が取る次善策が、閲覧のみに絞ったビューオンリー系のシートを使うという方法です。これは通常の有償シートより単価を抑えられ、製品によっては無償で提供されている場合もあります。ただし閲覧のみのアカウントでは、代理店に案件を入力してもらうという当初の目的は満たせません。低頻度の利用者にどこまでの操作を許すかという論点は、形を変えて残り続けます。
費用を抑えるための別の次善策として、代理店1社につき共有の汎用アカウントを1つだけ発行するという運用も見られます。担当者ごとの個別アカウントを作らずに済むため、シート数は増えません。しかし、この方法は「誰が入力したか」「誰が閲覧したか」という記録が失われるという副作用を伴います。代理店側で担当者が異動しても引き継ぎのたびにパスワードを共有し続けることになり、セキュリティ上の管理も緩くなります。シート課金という制約を回避しようとするほど、別の問題を抱え込む構図です。
以上の3つが、どのCRMを選んでも共通して現れる構造的な論点です。ここからは、Salesforce、kintone、HubSpotという主要3製品が、それぞれこの論点にどう向き合っているのかを、製品の優劣ではなく仕組みの違いとして確認していきます。
Salesforceの場合｜Experience CloudとPRMという厚い仕組み
Salesforceは、社外のパートナーや顧客を自社の基盤に迎え入れるための仕組みを、Experience Cloudという別建ての製品として持っています。パートナー企業とのやり取りに特化した機能群は、Partner Relationship Management（PRM、パートナー関係管理）と呼ばれ、リードの配分や案件登録、資材の共有といった機能がテンプレートとして用意されています。この製品カテゴリの全体像については、姉妹記事の「PRMとは何か」で整理しています。
Salesforceにおける代理店担当者の作り方は、公式ヘルプで手順が明確に定められています。まず代理店の会社にあたる取引先（アカウント）を「パートナーとして有効化」し、その取引先に紐づく担当者（コンタクト）に対して「パートナーユーザーを有効化」という操作を行います。ユーザーにはPartner Community（パートナーコミュニティ）などの外部ユーザー向けライセンスを割り当て、プロファイルとロールを設定します。この一連の操作を行うには「外部ユーザーの管理（Manage External Users）」という権限が必要と定められています。サイトの有効化時に送信を選択すれば、Experience Cloudサイトからのウェルカムメールでログイン情報が届きます（参照：Salesforce「Create Experience Cloud Site Users」(2026年8月時点)）。
この作りが示しているのは、Salesforceにおけるパートナーユーザーは、あくまで自社のSalesforce組織の中に作られた「取引先に紐づく特別なユーザー」だということです。パートナー企業の視点で見れば、自社の担当者がメーカー側のSalesforce組織にアカウントを持ち、そこに情報を入力するという構造そのものは変わりません。Experience CloudにはPartner Central（パートナー向けサイトのテンプレート）や、リード配分・案件登録の機能があらかじめ組み込まれており、社内向けのCRM機能とは別のライセンス体系・別の製品として提供されています（参照：Salesforce「Learn More About Experience Cloud Licenses」(2026年8月時点)）。裏を返せば、Salesforceでこの3つの論点に向き合うには、標準のSales Cloudの延長ではなく、Experience Cloudという別建ての基盤とライセンスを新たに用意する必要がある、ということでもあります。相応の投資と設計の工数を前提にした仕組みであり、代理店が数社から十数社程度の規模で「まず小さく始めたい」というニーズには、必ずしも合わない場合があります。
kintoneの場合｜ゲストスペースという区切られた部屋
kintoneは、社外の関係者を招き入れるための機能として「ゲストスペース」を用意しています。これは、通常のポータルとは切り離された専用の空間を作り、そこに顧客・取引先・協力会社などを「ゲストユーザー」として招待する仕組みです。招待された外部の取引先や協力会社、あるいはグループ会社は、そのゲストスペースの中に置かれたアプリ（案件情報や資料を格納するデータベース）にアクセスし、スレッド形式のやり取りやタスクの共有を行えます（参照：サイボウズ「ゲストスペース・ゲストユーザー」(2026年8月時点)）。
kintoneの設計で特徴的なのは、区切りの単位が「スペース」であるという点です。ゲストユーザーは招待されたゲストスペースの中身にはアクセスできますが、その企業が持つほかのスペースや全体のポータルには入れません。裏を返せば、1つのゲストスペースの中に置いたアプリは、そのスペースに招待された代理店であれば基本的に見える設計であり、代理店Aと代理店Bを同じスペースに同居させることは想定されていません。代理店ごとにゲストスペースを分けて運用するのが基本の設計になります。ゲストユーザーには、ゲストスペースの基本設定の変更・削除、参加メンバーの追加・削除、アプリの新規作成・設定変更・削除といった、管理者側の操作は許可されません（参照：kintoneヘルプ「ゲストユーザーが利用できない機能」(2026年8月時点)）。
料金の面では、ゲストユーザーはkintone本体の契約に対する追加サービスという位置づけで、契約コースに応じた1ユーザーあたり定額の月額課金が発生します（ライトコース700円・スタンダード/ワイドコース1,440円）（参照：サイボウズ「ゲストスペース・ゲストユーザー」(2026年8月時点)）。代理店の担当者が1人であっても10人であっても、招待した人数分の費用が積み上がっていく点は、Salesforceの有償シートと同じ構造です。一方で、招待する代理店側が別途kintoneを契約している場合はアカウントを統合でき、追加費用なしで連携できる仕組みも用意されています。これは代理店側にとって導入のハードルが下がる一方、代理店側もkintoneを利用していることが前提になるという条件でもあります。
HubSpotの場合｜パートナーシートは代理店管理のための機能ではない
HubSpotには「パートナーシート」という無償のユーザー枠が存在します。この名称だけを見ると、自社の販売代理店を無料でCRMに招待できる機能のように見えるかもしれません。しかし、これは誤解です。
HubSpotの公式ヘルプでは、パートナーシートの対象者を「対象条件を満たすHubSpot Solutions PartnerおよびProviderの従業員」と明確に定義しています。付与されるには、Solutions Partner企業に所属していること、その企業のメールドメインとパートナーアカウントのドメインが一致していること、既存のHubSpot Solutions Partnerアカウントのユーザーであることという条件を満たす必要があります。つまりパートナーシートは、HubSpotの認定パートナー企業（実装支援会社や代理店契約を結んだHubSpot自身のエコシステム上のパートナー）が、クライアントのHubSpotアカウントに無償で入るための仕組みであり、メーカーが自社の販売代理店やディーラーを招待するための一般的な機能ではありません（参照：HubSpot「パートナーおよびプロバイダーの従業員にパートナーシートを割り当てる」(2026年8月時点)）。
したがって、製造業や国産SaaSの会社が自社の販売代理店をHubSpotに招き入れたい場合、選択肢は通常の有償シート（Core、Sales Hubなど）を代理店の担当者に付与するか、権限を絞ったビューオンリーの形で共有するか、あるいはログインを前提としないフォームやワークフローで情報を受け取るかのいずれかになります。標準機能を使った具体的な設計手順は、姉妹記事の「HubSpotで代理店管理を設計する」で扱っています。HubSpotには、Salesforceのようなパートナー専用の別製品（Experience Cloud相当のもの）は存在せず、代理店を迎え入れる場合は社内向けの標準機能をどこまで転用できるかという設計問題になります。この点は、Salesforceが別建ての基盤を用意しているのとは対照的な設計思想です。
各社の対応を、冒頭の論点に当てはめると
ここまで見てきたSalesforce・kintone・HubSpotの仕組みを、あらためて冒頭に挙げた3つの論点（データの所有権・権限モデルの限界・経済性）に当てはめて整理します。優劣をつけるためではなく、どの製品を選んでも、この3つのどれかは自社で設計しなければならない余地が残るということを確認するためです。
Salesforceは、Experience CloudとPRMという厚い基盤を用意することで、権限モデルの限界にはリード配分や案件登録の機能で一定の答えを持っています。しかし、パートナーユーザーがメーカー側のSalesforce組織に紐づくという構造自体は変わらないため、データの所有権の緊張は残ります。加えて、この基盤を使うこと自体が別ライセンス・別実装コストを伴うため、経済性の論点は「シート単価」ではなく「基盤導入コスト」という別の形で現れます。
kintoneは、ゲストスペースという軽量な仕組みで経済性と導入の速さに強みがありますが、区切りの単位がスペース単位であるため、論点2で挙げたような「1つの問い合わせに対して1つの判定だけを返す」という細かい制御は標準機能の範囲を超えます。データの所有権についても、ゲストスペース内のデータはメーカー側のkintone契約の中に存在するため、Salesforceと同様の構造が残ります。
HubSpotは、パートナーシートという無償の枠を持つものの、これは自社の代理店管理には使えないことをすでに確認しました。したがって代理店を迎え入れる場合は、有償シートの経済性の論点に真っ先に向き合うことになり、権限モデルの中間的な応答やデータの所有権の設計は、標準機能の外側で個別に組み立てる前提になります。
3社に共通する構造｜CRMは社内の正のデータベースとして設計されている
Salesforce、kintone、HubSpotの仕組みを並べてみると、表面的な機能の違いを超えて、1つの共通点が見えてきます。それは、これら3製品がいずれも「自社の情報を、自社の社員が正確に管理するためのデータベース」を土台として設計されているという点です。
Salesforceは、その土台の外側にExperience Cloudという別製品を用意することで、社外との接点を厚く作り込んでいます。kintoneは、ゲストスペースという区切られた部屋を用意することで、社外との情報共有を軽量に実現しています。HubSpotは、社外向けの専用製品を持たず、社内向けの機能を工夫して転用する前提で設計されています。アプローチは三者三様ですが、いずれも「社内の正確な情報を、どこまで社外に開放するか」という発想から出発しており、「社外のパートナーが、自分たちのペースで、必要な情報だけをやり取りする」という発想を主軸には置いていません。
これは製品の欠陥ではありません。CRMという道具の本来の役割が、自社の顧客情報・商談情報を1か所に集約し、社内の意思決定を支えることにあるためです。その役割を担う道具に対して、所有権も利用習慣も異なる社外の第三者を、社内の従業員と同じ器に迎え入れようとすること自体に、無理が生じているのです。論点1のデータ所有権も、論点2の権限モデルの限界も、論点3の経済性も、すべてこの1つの構造からの帰結だと捉えると、見通しがよくなります。
社内のCRMと社外のパートナーのあいだに、別の層が要る
ここまでの整理から導かれる結論は、シンプルです。社内向けのCRMの権限設計をどれだけ丁寧に組んでも、この3つの論点は解消しません。必要なのは、権限をさらに細かく切ることではなく、社内のCRMと社外の代理店・パートナーのあいだに、性質の異なる別の層を1枚挟むという発想の転換です。
この層の役割は3つです。1つ目は、社内のCRMを「正のデータベース」として保ったまま、外部に見せる情報だけを絞り込んで中継すること。案件の全体は社内のCRMに残したまま、代理店には登録した案件の進捗や、バッティングの有無といった、必要最小限の応答だけを返せる設計にします。2つ目は、代理店側の入力を、代理店の顧客リストそのものを差し出す形ではなく、案件登録という限定された情報の受け渡しに留めること。これにより、論点1のデータ所有権の緊張を和らげられます。3つ目は、ログイン頻度の低い代理店担当者を、CRMの有償シートという単位ではなく、別の課金体系・別の利用体験で受け止めること。月1回のログインでも成立する設計にすることで、論点3の経済性の問題を回避できます。
このような、社内CRMと社外パートナーの中間に立つ仕組みを指して、一般にパートナーポータルやPRM（パートナー関係管理）ツールと呼びます。何を基準にこうしたツールを選ぶべきかは「PRMツール選びで失敗しないために」に、パートナーポータルという概念そのものの整理は「パートナーポータルとは何か」にまとめています。また、代理店の案件登録という運用そのものの設計、特にバッティングが起きたときの処理ルールについては「案件登録制度の作り方」で、報告の見える化という観点からの課題整理は「代理店経由の売上が見えない」で、それぞれ詳しく扱っています。
重要なのは、この「別の層」を導入することが、社内のCRMを軽視することを意味しない点です。むしろ逆で、社内のCRMには社内の正確な情報だけを保ち、その信頼性を守ったまま、社外との接点は別の設計思想を持つ層に任せる。この役割分担ができて初めて、代理店にとっても自社にとっても無理のない情報共有が実現します。「代理店を管理する」というより、「代理店と連携し、必要な情報をお互いに見える化する」という語感のほうが、この設計思想には近いと言えます。
先ほどの案件登録の場面に当てはめると、この層があることで何が変わるかが具体的に見えてきます。代理店の担当者はCRMにログインせず、案件登録用の入力画面だけにアクセスします。入力された見込み客の情報は、いったんこの層で受け止められ、社内のCRMにある既存の案件と自動的に照合されます。代理店側に返ってくるのは「登録を受け付けました」または「その会社はすでに他の担当と接触があるため確認が必要です」という、判定結果に基づく短い応答だけです。社内のCRMの中身がそのまま代理店に見えることはなく、代理店の入力内容も、案件登録という限定された範囲を超えて社内のCRMに流れ込むことはありません。ログインの手間もシートの費用も発生しないため、月に1回しかアクセスしない代理店担当者にとっても導入のハードルが低くなります。これが、権限を継ぎ足すのではなく層を1枚挟むという発想の具体的な姿です。
代理店が数社でも、これらの論点は起きるのか
ここまでの話を読んで、「うちは代理店が数社しかないから、そこまで大げさな話ではないのでは」と感じた方もいるかもしれません。実際、代理店が2〜3社程度で、担当者も片手で数えられる規模であれば、汎用アカウントの共有やメールでの折り返しといった手作業の次善策でも、当面は運用が回ってしまいます。3つの論点は、規模が小さいうちは表面化しにくいという性質を持っています。
問題は、代理店の数や取引の規模が育ってきたときに、この次善策がそのまま限界を迎えることです。代理店が10社を超え、担当者の異動や交代が起き始め、経営会議で代理店経由の数字の精度を厳しく問われるようになったタイミングで、データの所有権・権限モデル・経済性という3つの論点が一斉に顕在化します。多くの場合、この転換点は代理店網が育ってから初めて認識されるため、対応が後手に回りがちです。自社の代理店網が今どの段階にあり、この3つの論点にどれだけ近づいているかを早めに見立てておくことが、後からの手戻りを避ける鍵になります。
まとめ
- 代理店をCRMに直接招き入れたくなる動機は、二重管理の解消と報告の鮮度向上という2点にあり、それ自体は正当な課題認識です。
- しかしSalesforce・kintone・HubSpotのどれを使っても、データの所有権（代理店から見れば自社の顧客リストを取引先のCRMへ差し出す構造になる）、権限モデルの限界（バッティング判定だけを返す中間的な応答が作れない）、経済性（月1ログインの代理店営業にシート課金は成立しにくい）という3つの共通した論点にぶつかります。
- Salesforceは別建てのExperience Cloud/PRMという厚い仕組みで、kintoneはゲストスペースという区切られた部屋で、HubSpotは社内向け機能の転用でこの論点に向き合っています。HubSpotのパートナーシートは無償ですが、対象はHubSpot認定パートナー企業の従業員に限られ、一般の販売代理店の管理には使えません。
- 3社に共通するのは、CRMが「社内の正確な情報を社員が扱うためのデータベース」として設計されている点です。この土台に社外の第三者を迎え入れようとすること自体に、構造的な無理があります。
- 解決の方向性は、権限をさらに細かく切ることではなく、社内CRMと社外パートナーのあいだに別の層を置くことです。社内CRMは正のデータベースとして保ち、代理店との接点はパートナーポータルやPRMツールといった別の仕組みで受け止める設計が、3つの論点をまとめて解消します。
自社のCRMと代理店・パートナーとの関係を、どこまで社内の仕組みで対応し、どこから別の層に切り出すべきか。この線引きの判断には、自社の商流や代理店網の規模、現状のCRM運用を踏まえた個別の検討が欠かせません。代理店協業の状況をHubSpotの外に持ち出さず見える化する新しいツール「PartnerLens（パートナーレンズ）」を、現在β版として先行案内しています。ご関心のある方はPartnerLensのβ版ウェイトリストからご登録ください。個別のご相談は、無料相談からお気軽にどうぞ。
