前章で、業務領域ごとに SoR事実の唯一の記録元 の構造は違うこと、そしてパートナーセールスの SoR は業界として未確立であることを確認しました。 では、パートナーセールスの SoR は具体的に どのデータモデル で作るべきでしょうか。
この章では、CRM顧客管理システム の3要素（Contact / Company / Deal商談・案件）では絶対に足りない理由と、それを補う5軸コンテキストの構造を提示します。
5軸 ── パートナーセールスの SoR が満たすべき構造
パートナーセールスにおいて「今このパートナーに何をすべきか」を判断するために、SoR が保持しなければならない軸は5つあります。
- パートナー（会社）軸 契約形態、Tier階層・重要度ランク、業種マッチ率、本業シナジー、地域カバレッジ。会社単位の構造データ
- コンタクト軸 パートナー内担当者の基本属性（氏名・所属・役職・連絡先）。CRM が持っているのはここまで
- 熟達度Lv その担当者が自社プロダクトを「売れる人」になっているかの段階。仕込み期 → 実装期 → 自走期
- 活動Lv 直近の稼働状況。提案数、質問数、ポータルアクセス、メール開封率、チャット応答時間の時系列
- チームパワー × 役割バッジ 組織内の影響力・巻き込み力／意思決定者・提案者・実行者・チャンピオンといった機能ラベル
既存 CRM が持っているのは、このうち最初の2軸（パートナー＋コンタクト）だけです。残り3軸 ── 熟達度Lv、活動Lv、チームパワー × 役割バッジ ── は、パートナーセールスに固有のもので、汎用ツールのデータモデルには存在しません。
なぜ5軸すべてが必要なのか ── 判断ポイントごとに効く軸が違う
「5軸も必要か？ 多すぎないか？」という疑問が出るかもしれません。答えは、判断ポイントごとに 効いてくる軸が違うから、です。
- オンボーディング初期 90日 役割バッジ（誰が鍵人物か）と熟達度Lv（誰が育つか）が主役。会社軸だけ見ても、誰に研修すべきかは決まらない
- 稼働低下の予兆検知 活動Lv の時系列が主役。「先月は提案3件、今月0件」── ここで動かないと、Stage進化段階 2、Stage 3 へと冷却が進行する
- Tier 判定・支援配分 パートナー軸（営業人数・業種マッチ）とチームパワー（決裁者接点）が主役。コンタクト1人を見ても判断できない
- 離反防止・再活性化 役割バッジと活動Lv の組み合わせ。「鍵人物が動いていないのか、それとも組織全体が冷えているのか」で打ち手が変わる
どの判断にも答えられる SoR は、5軸すべてを持っていなければなりません。1軸でも欠けると、その判断ポイントで AI Agent も担当者も 黙り込みます。「データはあるのに、結論が出せない」という現象は、たいていこのどれかの軸が欠けているせいで起きています。
11種の type 別アクティビティログ ── 活動Lv の解像度
5軸のうち、活動Lv は単に「何回会ったか」では足りません。何の活動を、どの粒度で記録するかで、SoR の有用性が大きく変わります。
汎用 CRM の標準的な活動ログは、おおむね4種類（電話／メール／会議／メモ）です。これでは、パートナーセールスの活動の質的な違いを記録できません。type ごとに、記録すべき固有フィールドが違うからです。
- 訪問 場所、参加者リスト、経営層接触の有無、駐在ミッションの達成度
- セミナー・勉強会 参加人数、質問者数、事前資料の熟読度、アンケート回答率
- ジョイントマーケ 配信リスト数、反応率、共催ウェビナーの登録／参加比率、成約寄与
- チャット応答 反応時間、絵文字、温度感、相談 vs 業務連絡の比率
- 提案・案件創出 業種、案件規模、提案フェーズ、ボトルネック箇所
汎用の Property を手で増やしていくアプローチでは、ここまでの粒度を一貫して維持するのは事実上不可能です。なぜなら、どの type にどのフィールドを紐づけるかという type ごとのスキーマ を、CRM 側が持っていないからです。
パートナーセールス専用の SoR が必要なのは、この「type 別の固有スキーマ」を最初から備えているかどうかが、活動Lv の解像度を決めるからです。
最も観測が難しい2軸 ── チームパワーと活動Lv の質
5軸のうち、観測の難しさには明確な序列があります。
パートナー軸とコンタクト軸は、契約書や名刺で得られます。熟達度Lv は研修参加・提案数・成約数の関数として観測できます。活動Lv の 量 も、ログを取れば数えられます。
では、最も難しいのは何か。チームパワー（誰が組織内で誰を動かせるか）と、活動Lv の質（その会話は前向きだったか、温度感はどうか）です。これらは商談記録や提案ログには残りません。日常の Slack や Chatwork、Messenger のやり取りに流れています。
既存の PRMパートナー関係管理 が取り切れていないのは、まさにこの領域です。SoR を完成させるには、チャットを構造化して取り込む仕組み が必要になります。これがなぜ必然なのか、どう実装すべきかは、後続の D 章で詳述します。今ここでは「最も難しい2軸の観測手段は、日常のチャットの中にある」という事実だけを抑えておけば十分です。
活動Lv は 11種の type 別固有スキーマ で記録されることで、初めて意思決定の素材になります。そして最も難しいチームパワーと活動Lv の質は、日常のチャットを取り込まなければ観測できません。
── ただし、ここまでで完成するのは SoR ＝ 土台 までです。軸を持っただけでは、判断は変わりません。次章では、SoR を入力に取って「次の一手」を組み立てる層、SoA次の一手を提案する層（System of Action）を導入します。
- SoRエス・オー・アール
- System of Record。業務における "事実の唯一の記録元" を担うシステム。顧客情報なら CRM、商談なら SFA。パートナーセールス領域ではこれまで SoR 自体が存在していなかった、というのが synergeee の出発点。
- SoAエス・オー・エー
- System of Action。SoR を素材として "次の一手" を提案・実行する層。AI エージェントが提案カードを出すレイヤー。
- PRMピー・アール・エム
- Partner Relationship Management。パートナー企業との関係管理を支援するシステム領域。従来は商談管理に偏り、関係性の管理が手薄だった。
- CRMシー・アール・エム
- Customer Relationship Management。顧客との関係を一元管理するシステム。Salesforce や HubSpot が代表。コンタクト・案件・商談を扱うが、パートナー構造は持たない。
- Tierティア
- パートナーを重要度別に分類する区分（Tier 1 / 2 / 3 など）。重点パートナー設計の基本概念。
- Dealディール
- 営業上の取引機会・案件。CRM・SFA で管理される基本単位。
- Stageステージ
- SoA の判断進化を表す3段階（純 Judgment → Gray → Intelligence 化）、または商談の進捗段階を指す。