営業情報を、分断させない。
営業・マーケティング・導入支援・サポートに散らばる情報を、正本・共通ID・権限・連携・移行の観点から整理します。メール・電話・会議の履歴を無理なくつなぎ、複数部門で同じ顧客情報を使うための実務手順です。
この記事でわかること
対象：複数の営業部門や関係部署で顧客・案件情報を共有したい営業企画、情報システム、DX推進、管理者
- 正本・共通ID・同期方向を決め、無理な一元化と二重管理を避ける
- メール・携帯電話・固定電話・Web会議の接点を、確認可能な履歴としてつなぐ
- 移行、権限、組織変更、データ出力まで含めて運用ルールを設計する
目次
営業情報の分断は、データが存在しないことより、同じ顧客や案件を別の名前・粒度・更新ルールで管理していることから起きます。営業、マーケティング、カスタマーサクセス、情報システムがそれぞれ正しい情報を持っていても、つなげられなければ判断は遅れます。
営業情報が分断しているサイン
- ・会議のたびに担当者が表計算へ転記している
- ・顧客名の表記揺れで検索結果が分かれる
- ・営業から引き継いだ顧客情報を別部門が再入力している
- ・同じ案件のステータスが部署ごとに違う
- ・退職や異動のたびに履歴の所在が分からなくなる
最初に決めるべき「正本」
| 情報 | 正本の候補 | 重複させないもの |
|---|---|---|
| 会社・拠点 | 取引先マスタ | 部署ごとの名称・住所 |
| 担当者 | 取引先担当者 | 個人の連絡先を含む複数台帳 |
| 案件 | 案件管理 | 営業会議用の別ステータス |
| 活動 | 商談・電話・メール履歴 | 日報や議事録への手入力 |
| 契約後の対応 | 顧客支援の管理 | 引き継ぎ資料の手作業転記 |
正本は「一番高機能なシステム」ではなく、更新責任者と利用場面が明確で、必要な部署から参照できる場所です。すべてを1つに集約できない場合は、共通IDと同期方向を決め、二重管理の範囲を限定します。
顧客・案件・活動を共通IDでつなぐ
| 設計対象 | 最低限そろえる項目 | 設計上の注意 |
|---|---|---|
| 顧客 | 会社ID・拠点・正式名称・担当範囲 | 統合や分割のルールを決める |
| 担当者 | 担当者ID・所属・役割・連絡先 | 異動と退職時の扱いを決める |
| 案件 | 案件ID・顧客ID・段階・責任者 | 受注後の引き継ぎ先を決める |
| 活動 | 活動ID・案件ID・日時・接点種別 | 元の記録に戻れるようにする |
メール・電話・会議記録をつなぐ方法
| 接点 | 自動化しやすい部分 | 人が確認する部分 |
|---|---|---|
| メール | 宛先・差出人・件名・日時の取得 | 顧客と案件の紐付け |
| 携帯電話 | 発着信・通話記録の取得 | 対象顧客と公開範囲 |
| 固定電話 | 環境に応じた連携と記録 | 連携対象・保存期間・例外 |
| Web会議 | 録音・議事録の登録 | 要約の修正と次回行動 |
連携は「すべてを自動で登録する」ことが目的ではありません。誤った顧客への紐付けや不要な記録を減らし、担当者が確認しやすい例外処理を用意することが重要です。
既存データを移行するときの順番
- 1. 顧客・担当者・案件の重複と欠損を調べる
- 2. 共通IDと正式名称を決める
- 3. 過去データをすべて移す範囲と、参照用に残す範囲を分ける
- 4. 権限と保存期間を確認する
- 5. 小さな対象で同期・検索・更新を試す
- 6. 例外と戻し方を決めてから段階展開する
関係部署が多い組織の運用ルール
| ルール | 決める内容 |
|---|---|
| 登録 | 誰がどの条件で顧客・案件を作成できるか |
| 更新 | ステータス・担当者・次回行動の更新期限 |
| 閲覧 | 部門・役職・担当範囲ごとの参照権限 |
| 変更 | 組織再編・商材追加・名称変更の申請先 |
| 出力 | 契約終了時や監査時に取り出す項目と形式 |
品質を見える化する指標
- ・顧客と案件の紐付け率
- ・必須項目の欠損率
- ・同一顧客の重複登録件数
- ・更新期限を超えた案件の割合
- ・連携エラーと手動修正の件数
- ・会議資料を作るための転記時間
正本を決めるための会議を先に行う
システムを選ぶ前に、顧客・案件・活動のどの情報を、どの部門が正本として管理するかを決めます。営業が更新した案件の状態を導入支援が参照するのか、サポートが更新した契約情報を営業が参照するのかで、同期方向と修正権限は変わります。会議では「誰が入力するか」だけでなく、「誤っていたときに誰が直すか」「変更をどこまで通知するか」まで確認します。
| 情報 | 正本の候補 | 運用で決めること |
|---|---|---|
| 顧客基本情報 | 顧客管理の台帳 | 重複統合と変更申請の担当 |
| 案件状態 | 営業の案件管理 | ステージ変更の条件と更新期限 |
| 活動履歴 | 商談・電話・メールの記録 | 顧客や案件への紐付けルール |
| 契約・利用状況 | 契約管理やサポートの記録 | 営業が参照する項目と公開範囲 |
連携は小さく始めて、例外を残す
- ・最初は顧客IDと案件IDなど、照合に必要な共通キーをそろえる
- ・同期する項目を絞り、片方向で試してから双方向へ広げる
- ・紐付けできないデータは未確定箱へ送り、勝手に登録しない
- ・連携エラーの通知先、再処理、手動修正の担当を決める
- ・組織変更や担当者変更時にキーと権限を更新する
情報を一元化することより、情報の意味と責任を一貫させることが優先です。複数のサービスを残す場合でも、利用者がどこを見ればよいか、更新がどこへ戻るか、いつまで保持するかが分かれば、分断による確認作業を減らせます。
製品選定より先に、移行後の運用を描く
営業情報の分断を解消する計画では、導入直後の画面だけでなく、半年後の組織変更と担当者交代まで描きます。新しい部署が増えたときに顧客IDをどう引き継ぐか、案件の責任者が変わったときに履歴をどこまで見せるか、契約終了時にデータをどう出力するかを確認します。移行期間は旧システムと新システムが並行するため、二重入力をいつ終えるか、差分を誰が確認するかも決めておく必要があります。
- ・移行対象を現行・参照・保存の3区分に分ける
- ・移行前後で件数と紐付け率を照合する
- ・並行運用の終了日と例外申請を決める
- ・組織変更時の管理者と権限更新を決める
- ・契約終了時のデータ出力と削除依頼の窓口を決める
分断を解消する担当者会議の進め方
設計を決めた後も、現場では例外が発生します。月次の短い会議で、検索できなかった顧客、同期に失敗した案件、更新先が分からなかった活動を持ち寄り、定義・権限・連携・教育のどこを直すかを一件ずつ決めます。会議の議事録には結論だけでなく、変更する項目、影響を受ける部門、適用日、戻し方を残します。これにより、担当者ごとの判断で新しい台帳が増えることを防げます。
- ・事象を「見つからない・つながらない・更新できない・見せられない」に分類する
- ・原因をデータ、運用、権限、連携のいずれかに仮置きする
- ・影響範囲と優先度を確認して、変更を1つに絞る
- ・変更後に確認する指標と担当者を決める
- ・次回会議で結果と未解決の例外を確認する
運用責任を引き継げる形にする
担当者が変わっても分断を戻さないために、データ定義と連携設定を個人の経験に閉じ込めないようにします。変更申請の窓口、影響範囲の確認、テスト環境での確認、利用者への告知を手順として残し、管理者が交代しても同じ判断ができる状態を作ります。運用の担当者名だけでなく、役割と承認の流れを記録することが大切です。
よくある質問
複数のシステムを1つにまとめるべきですか？
必ずしも1つにする必要はありません。正本、共通ID、同期方向、例外処理が定義されていれば、役割の異なるシステムを連携して運用できます。
過去データはすべて移行したほうがよいですか？
利用目的と保存要件で判断します。日常的に検索する履歴、契約や監査で必要な記録、参照頻度の低い過去データを分けると、移行コストと検索性のバランスを取りやすくなります。
連携後の誤登録はどう防ぎますか？
候補表示、信頼度に応じた確認、未確定箱、修正履歴を用意します。自動化率だけでなく、誤登録の影響範囲と復旧手順を評価してください。
営業情報の分断を解消する要点は、製品名をそろえることではありません。顧客・案件・活動の意味と責任をそろえ、業務の変化に合わせて更新できる構造を作ることです。
複数部門で使える営業情報の設計を相談したい方へ
要件整理・デモを相談する →
執筆：小花 達也
新卒でソフトバンク株式会社に入社し、デジタルマーケティングを担当。その後、ベンチャー企業数社でBtoBマーケティング、データ基盤構築、営業などを担当した後、ELW株式会社に入社。DRIVE SFAでは導入支援とマーケティングを担当。
本記事は、DRIVE SFAの導入支援・営業運用に関する知見をもとに編集しています。