CRM・SFA

顧客情報を部署間で共有するなら、会社の画面に4行置く

用語

CRM（顧客管理システム）
SFA（営業支援システム）

公開 2026年10月27日

「この会社、いまどういう状況でしたっけ？」

CRM（顧客管理システム）を入れている会社でも、この質問は社内チャットで普通に飛び交っています。営業は商談のことを知っている。サポートは先週の問い合わせを知っている。マーケは誰がセミナーに来たかを知っている。全員、記録もちゃんと残しています。

それでも、1社の状況を知るには3人に聞く必要がある。情報が足りないわけではありません。部署ごとに、自分の記録の中で完結しているんです。

部署の食い違いは、顧客にそのまま届く

社内の手間だけなら、まだいい。困るのは、この食い違いが顧客に届くことです。

サポートが障害の対応をしている最中に、マーケから新機能の案内が届く。更新の相談をしている顧客に、営業が別の担当者経由で同じ提案を二度持っていく。どの部署も自分の手順どおりに動いていて、誰も間違えていません。

McKinseyが2026年7月に公表した記事「The future of B2B sales: How growth champions rewire their playbooks with AI」は、同社の「2026 B2B Pulse Survey」（13か国、買い手と売り手あわせて約4,000人）をもとに、チームごとに情報が食い違うことが、B2Bの買い手がサプライヤーを乗り換える理由の1位になったと書いています。割合は示されておらず、調査国の内訳も記事には載っていません。日本の買い手に限った数字ではないので、そこは割り引いて読んでください。

日本の調査では、マツリカ（調査実施はIDEATECH、2024年11月、SFA/CRMを使う営業部門の管理職・主任101人）で、SFA（営業支援システム）/CRMの利用上の課題として「必要な情報が共有されない」を挙げた人が39.6%いました。回答者は営業部門だけで、他部署との共有を直接聞いた設問ではありません。SFAベンダーの自社調査で母数も小さいので、目安くらいに見てください。

連携を始める前に、連絡の前に聞いていることを数える

この話になると、すぐに「データを統合しよう」という方向に進みがちです。

同じMcKinseyの記事には、ある素材メーカーが20以上のデータソースをつないで、営業が次に見るべき顧客と論点を示す仕組みを作った事例が出てきます。この会社では営業が顧客と過ごす時間が全体の20%で、うまくいっている営業組織の3分の1から2分の1を下回っていた。仕組みの狙いは商談準備の手間を減らすことで、対象の営業の時間を10%以上生み出せる見込み、とされています。

大きな会社の、大きな投資の話です。中堅の会社がここから真似をすると、連携の要件定義だけで半年が過ぎます。

先にやるのは、もっと地味なことです。顧客に連絡する前に、他の部署へ何を聞いたかを2週間分集めます。

全員に日記を頼む必要はありません。

まず、社内チャットを主要な顧客の社名で検索して、過去2週間の「どうなってる？」を拾う
口頭で聞いた分は、営業・サポート・マーケから1〜2人ずつに、聞いたときだけ1行（いつ、どの会社、誰に、何を）書いてもらう
集めて分類するのは1人。CRMの管理者か営業企画が向いています

部署をまたいだ依頼なので、指示は各部署の長が揃って出すか、部門横断の権限を持つ人が出します。

2週間たつと、質問の種類はそれほど多くないことが分かります。多くの会社で上位に来るのは、次のようなものです。

いま商談は動いているか、誰が担当しているか
契約はいつまでで、更新の話はどこまで進んでいるか
未解決の問い合わせや障害はあるか
最後に誰が、いつ、何で連絡したか

この4つは、私が支援の現場でよく見る形で、調査の結果ではありません。自社で数えた結果がこれと違えば、自社の結果を優先してください。

4行は人に打たせず、出し方を行ごとに決める

数えた質問の答えを、会社（取引先）の画面の一番上に置きます。上の4つなら、こうなります。

進行中の商談：件数と、いちばん進んでいる商談の段階と担当者
契約と次の更新日：契約の終了日と、更新の商談があればその段階
未解決の問い合わせ：件数と、最も古いものの起票日
直近の接点：最後の連絡の日付と、その手段と相手

大事なのは、この4行を人に打たせないことです。「顧客の現況」という自由記述の欄を作って営業に更新を頼むと、2か月で止まります。書く人にとって、自分の仕事が何も楽にならないからです。

ただ、全部を集計の項目で出せるわけではありません。値の種類で、出し方が3つに分かれます。

件数と日付は、集計で出す。 商談の件数、未解決の問い合わせの件数、最古の起票日、最後の連絡日など。HubSpotでは会社の標準のプロパティ（関連する取引の数、最終アクティビティー日など）や集計のプロパティを使います。独自の集計プロパティを作れるかはプランによるので、手元の契約で確認してください。Salesforceでは取引先と商談の間で積み上げ集計項目が使えます。標準のケースは取引先と主従関係ではないため、積み上げ集計項目の対象になりません（自社の組織で要確認）。件数はフローなどで作ります。
段階・担当者・手段・相手は、関連リストで見せる。 集計の項目は件数や最大・最小を返すもので、「いちばん進んでいる商談の担当者」のような値は返しません。会社の画面に関連する商談や活動の一覧を置き、並び順と絞り込み（進行中だけ、新しい順）を決めておけば、一番上の行が答えになります。
どうしても1つの項目に入れたい値は、ワークフローやフローでコピーする。 たとえば更新の商談の段階。ただ、コピーの仕組みは保守の対象が増えるので、関連リストで足りるならそちらを選びます。

更新の商談を見分けるには、商談に「新規／更新」の区別がすでに入っている必要があります。無ければ、ここで初めて項目を足すことになります。着手前に確認してください。

集計も一覧も作れない値が1つだけ残ったら、それだけは担当を1人決めて、更新のタイミングを決めます。最終更新日を横に出しておくと、古い情報を信じる事故が減ります。

サポートがCRMの外にあるなら、2項目だけ戻す

ここまでの話は、問い合わせの記録がCRMの中にあることが前提です。サポートが別の問い合わせ管理ツールを使っている会社は少なくありません。

その場合も、全部を寄せる必要はありません。会社ごとの「未解決の件数」と「最古の起票日」の2項目だけを、CRMの会社に戻す最小の連携を考えます。照合のキー（会社をどの番号やドメインで突き合わせるか）を先に決めておかないと、この小さな連携でも重複が出ます。決め方は「CRM連携が止まる原因は、機能ではなく照合キーの設計でした」に書きました。連携を作るまでは、3行目を担当と更新日のある手作業の行にしておきます。

4行を、連絡するかどうかの判断に使う

4行を置いても、人が見なければ顧客に届く食い違いは減りません。マーケの自動配信は、誰も会社の画面を開かずに送られます。

なので、4行を手順に組み込みます。

未解決の問い合わせがある会社を、マーケ配信の除外条件に入れる。 障害の対応中に新機能の案内が届く事故は、これで止まります
営業とサポートは、顧客に連絡する前に4行を見る。 更新の時期や対応中の問い合わせを知らずに連絡しない