%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
Knowledge SuiteからHubSpotへの移行は、機能をそのまま置き換える作業ではありません。顧客・営業データの流れを整理し、CRMを業務の基盤として組み直す機会です。
Knowledge SuiteからHubSpotへの移行は、機能をそのまま置き換える作業ではありません。顧客・営業データの流れを整理し、CRMを業務の基盤として組み直す機会です。
「SFAの案件情報は移せても、日報や稟議の運用はどうなるのか」
「GRIDY名刺CRMのデータを取り込んだ後、会社や担当者とどう結び付けるのか」
「グループウェアが分かれたら、営業が複数の画面を行き来することにならないか」——
Knowledge Suiteとは、グループウェア、SFA、CRM、名刺管理などを一つのプラットフォームで扱うサービスです。HubSpotへの移行では、CRM・SFAのデータを顧客から取引まで一元化し、日程管理や社内申請などは用途に合うツールへ分けて設計します。
この記事でわかること
Knowledge Suiteの機能を棚卸しし、HubSpotで管理する業務と別ツールに分ける業務を判断する方法を説明します。データを移す順序だけでなく、移行後に営業活動が滞らない設計の考え方も扱います。
- 機能ごとの移行先 — CRM・SFA・名刺管理と、スケジュール・稟議などの再構成方針を整理します。
- 取引データの移行設計 — 既存ステージをHubSpotの取引パイプラインへ対応付け、担当者や会社との関連付けを考えます。
- 名刺・活動履歴の扱い — CSVで移す項目や、過去の活動を移行するか判断する基準を紹介します。
- 移行後の運用準備 — データの差分やツール間の役割を確認し、段階的に定着させる方法を説明します。
Knowledge Suiteの機能を棚卸しして移行先を分ける
Knowledge Suiteでは複数の業務機能が一つのサービスにまとまっています。移行の最初に、各機能の利用実態と業務上の役割を整理すると、HubSpotへ無理に集約する範囲を避けられます。CRMを顧客・取引情報の基盤に置き、社内連絡や申請は専用ツールに分ける考え方が出発点です。
現在の機能と利用目的を対応付ける
まず、各モジュールについて「誰が、何のために、どの情報を更新しているか」を確認します。機能名だけを見て移行先を決めると、実際に使われていない画面まで再現しようとしたり、必要な情報の流れを見落としたりすることがあります。
| Knowledge Suiteの機能 | 移行時に整理する業務 | 再構成の考え方 |
|---|---|---|
| GRIDY SFA | 案件、ステージ、金額、活動記録 | HubSpotの取引と取引パイプラインに整理します |
| GRIDY CRM | 顧客、顧客データベース、セグメント | HubSpotのコンタクトと会社を中心に管理します |
| GRIDY 名刺CRM | 名刺データ、会社や部署の把握 | 必要な連絡先データを整理し、コンタクトと会社に関連付けます |
| GRIDY グループウェア | 予定、掲示板、申請、ファイル共有、メール | スケジュールや社内申請など、用途ごとに移行先を選びます |
| GRIDY レポート | 営業日報、週報、活動状況の共有 | 活動記録を基にレポートするか、提出型の日報を残すか決めます |
HubSpotに集約する範囲を決める
顧客・会社・取引・活動を関連付けると、営業の状況を個別の表や担当者の報告だけに頼らず確認できます。HubSpotをデータの置き場として扱うのではなく、どの段階で誰が情報を更新し、次の担当へ何を渡すかを決めることが大切です。
たとえば、問い合わせをコンタクトとして登録し、会社情報と関連付け、営業対象となった時点で取引を作ります。受注後の顧客対応に引き継ぐ情報をあらかじめ決めておけば、営業記録から顧客対応までを同じ情報の流れで確認できます。
グループウェア機能は用途別に分ける
スケジュール管理、稟議、掲示板、ファイル共有は、HubSpotへ移す必要があるとは限りません。予定はGoogle WorkspaceやMicrosoft 365、社内コミュニケーションはSlackやMicrosoft Teamsなど、既存の運用や要件に合う選択肢を比較します。
分離によってログイン先や通知先が増える場合は、各ツールの役割と入口を利用者に示します。どの情報をHubSpotに記録し、どの情報はグループウェア側で完結させるかを明文化すると、二重入力を避けやすくなります。
機能を再現しない選択肢も持つ
現行画面にある機能をすべて再現することが、移行の完了条件ではありません。使われていない日報項目や重複する顧客リストは、継続する理由と参照する担当者を確認したうえで、移行対象から外す判断もできます。
| 判断対象 | 残す場合 | 統合・廃止を検討する場合 |
|---|---|---|
| 日報・週報 | 個別報告が業務上必要で、確認者と用途が明確 | CRMの活動データで必要な状況を把握できる |
| 顧客リスト | 固有の用途や更新責任がある | HubSpotの会社・コンタクトと重複している |
| ファイル共有 | 承認や共有履歴などの要件がある | 既存のストレージで利用者が足りている |
| 稟議 | 申請・承認の手順が現行業務に必要 | 別の申請基盤に集約できる |
SFAの移行は取引データと営業プロセスを一緒に設計する
案件情報をインポートしても、営業担当者が同じ基準でステージを更新できなければ、取引一覧は管理に使いにくくなります。移行前に、案件の進行段階、受注確度、ステージの定義、必須入力項目を整理します。ステージ名の置き換えだけでなく、情報が次の判断にどう使われるかを合わせて決めます。
既存ステージの名前ではなく意味を確認する
Knowledge Suiteで使っているステージごとに、どの出来事が起きたら案件を進めるのかを書き出します。「提案」「見積」といった名称が同じでも、担当者ごとに移動の判断が異なる場合があります。移行先のステージは、社内で観察できる行動や顧客側の状態で定義します。
| 現行の段階例 | 移行先の検討例 | 移行前に確認すること |
|---|---|---|
| アプローチ | アポイント獲得 | 顧客との面談が設定された状態か |
| ヒアリング | 適格性の確認 | 課題や検討条件を確認できた状態か |
| 提案 | 提案済み | 提案内容を顧客へ提示した状態か |
| 見積 | 見積もり送付済み | 金額と提示日を記録するか |
| 交渉 | 意思決定者の承認待ち | 顧客側の意思決定状況を確認できるか |
| 受注 | 受注 | 契約や受注の完了条件は何か |
| 失注 | 失注 | 理由を記録し、将来の掘り起こし対象を識別するか |
表の移行先は対応付けを始めるための例です。実際のステージは、自社の商談プロセスに合わせて定義します。
パイプラインを四つの要素で組み立てる
取引パイプラインでは、取引ステージに加え、受注確度、ステージの定義、必須入力プロパティを整理します。受注確度はステージの進捗と見込みを結び付けるための値です。ステージ移行時の必須項目は、報告の依頼に頼らず、必要情報を残す仕組みになります。
| 設計要素 | 決める内容 | 運用で確かめること |
|---|---|---|
| 取引ステージ | 受注率や顧客の進行状態が変わる節目 | その段階を示す具体的な出来事があるか |
| 受注確度 | 各ステージの見込みをどう扱うか | 過去の受注状況と見込みの差を振り返れるか |
| ステージ定義 | 移動の条件と完了状態 | 担当者によって解釈が変わらないか |
| 必須入力プロパティ | ステージ移行時に残す情報 | 次の担当やマネージャーの判断に使えるか |
項目は業務で使うものから始めます。入力項目を増やしすぎると、営業担当者が重要な情報を見分けにくくなり、入力も続きにくくなります。
HubSpotでの設定場所は、設定（歯車アイコン）＞ データ管理 ＞ オブジェクト ＞ 取引 ＞「パイプライン」タブです。「パイプラインを作成」からステージを追加し、ステージごとに成約確率を入れます。成約確率は、ステージの合計金額に掛けて加重金額を出すために使われます。取引では、受注（Won）と失注（Lost）の両方のステージを確率に含めないと、売上レポートや分析が正しく処理されません（出典：Set up and manage object pipelines）。
ステージごとの必須入力は、同じ画面の「条件付きロジックルール」列で「ルールを追加」し、依存プロパティに対象のプロパティを追加して「必須」にチェックを入れて設定します。必須にしたプロパティは、値が入るまでレコードの作成や更新ができません。読み取り専用のプロパティは使えません。次の表は、Knowledge Suiteの段階を移す際の設計例です。プロパティ名は一例で、自社の運用に合わせて決めます。
| ステージ（例） | 成約確率の置き方（例） | そのステージで必須にするプロパティ（例） |
|---|---|---|
| アポイント獲得 | 低めの値から始める | 担当者（コンタクトの関連付け）、面談予定日 |
| 見積もり送付済み | 過去の受注状況を見て調整する | 金額、クローズ予定日、見積提示日（カスタムプロパティ） |
| 意思決定者の承認待ち | 見積段階より高めに置く | 意思決定者名、決裁予定時期（カスタムプロパティ） |
| 受注 | 100% | 契約締結日、請求先情報の確認状況 |
| 失注 | 0% | 失注理由（選択式のカスタムプロパティ）、再接触の目安時期 |
よくある失敗は、移行元のステージ名をそのまま並べて必須項目を決めないことです。移行元の「交渉」にあたる取引が、移行後は誰の判断でも進められる状態になり、予測金額が実態からずれます。インポート前にステージの定義書を作り、成約確率は移行後の数か月で受注実績と照らして見直します。
データを整えてコンタクト・会社と関連付ける
取引データには、案件名、顧客名、担当者、金額、ステージ、予定日、メモなどが含まれることがあります。実際に取り出せる項目はエクスポートデータで確認し、HubSpot側で対応するプロパティを一覧にします。
取引と顧客の関連付けには、表記の揺れを整えるだけでなく、会社やコンタクトを識別する値を使います。同じ会社名が複数のレコードにある場合は、どのコンタクトや会社を結び付けるかをデータ上で判別できる状態にしてからインポートします。
失注後の情報を次の営業活動につなげる
失注は履歴を閉じるだけではなく、今後の営業活動に使える情報として残します。失注理由を選択式で記録できるようにし、顧客が再検討する可能性がある案件は、再接触の条件や担当を決めて管理します。
この記録を集計すると、価格、競合、機能、時期、社内決裁など、どの理由が商談の結果に影響しているかを営業とマーケティングで確認できます。失注後に再接触する流れを作る場合も、対象の判断と連絡時期は担当者が確認し、機械的な一斉連絡にしない設計が必要です。
GRIDY名刺CRMの移行は連絡先の整理から始める
名刺情報は名前とメールアドレスを移すだけでは、営業活動で使える状態になるとは限りません。会社、部署、役職、連絡先をどのレコードに保存するかを決め、重複や古い情報を見直します。名刺画像や組織ツリーが必要な場合は、テキストデータの移行とは別に保管方法を考えます。
移行する項目を決めてデータを整える
エクスポートした名刺データを確認し、業務で使う項目を選びます。氏名、会社名、部署、役職、メールアドレス、電話番号、住所、登録日などを候補にし、HubSpotの標準項目または用途に合うプロパティへ対応付けます。
氏名の分割方法や電話番号の形式が混在している場合は、取り込み前に統一します。会社名の表記揺れは会社レコードの重複につながることがあるため、正式名称を採用するのか、現行表記も保持するのかを決めてから変換します。
重複・古い情報を確認する
名刺の情報は登録時点のものであり、現在も有効とは限りません。退職や異動を推測だけで決めつけず、メールの有効性や既存の顧客情報と照合できる範囲を確認します。
| 確認項目 | 対応の考え方 |
|---|---|
| メールアドレス | 同一人物の候補をまとめ、連絡先として使えるか確認します |
| 同一人物の複数名刺 | 現在の会社・役職と過去の所属をどう残すか決めます |
| 会社名 | 会社レコードの識別に使う表記をそろえます |
| 電話番号・住所 | 用途に応じて項目を分け、形式をそろえます |
| 登録日 | 現在の更新日と混同しないよう、元データの日付として扱います |
コンタクトと会社を関連付けて取り込む
名刺の人物情報はコンタクト、所属先は会社として扱い、必要に応じて両者を関連付けます。CSVの列をHubSpotのプロパティに割り当てるときは、既存レコードとの照合に使う識別値も確認します。メールアドレスだけで重複を判断できないレコードは、別の識別方法を用意してから取り込みます。
インポート前に、元データの列とHubSpot側の項目を照合し、レコード間の対応を確認します。
以下の画面は、HubSpotのインポートで対象オブジェクトを選ぶ画面です。
名刺CSVを取り込む手順は次の順です。メニュー名は公式ヘルプの表記に沿っています（出典：複数オブジェクトのレコードをインポートする）。
- エクスポートしたファイルを .csv または .xlsx にし、シートは1つ、1行目をヘッダー行にします。列数は1,000未満で、日本語を含むため UTF-8 で保存します。
- HubSpotで「データ管理」＞「データ連携」を開き、「Import a file」の「Import data」をクリックします。
- 「Advanced imports (all objects)」を選び、コンタクトと会社を対象オブジェクトに選びます。
- 1ファイルにまとめるか、コンタクト用と会社用の2ファイルに分けるかを選びます。2ファイルの場合は、両方に共通する列（例：会社名）を指定し、どちらのオブジェクトの一意キーにするかを選びます。
- 各列をHubSpotのプロパティにマッピングし、各オブジェクトの処理を「作成と更新」「新規作成のみ」「既存レコードの更新のみ」から選びます。
- まず数十行のテストファイルで取り込み、レコード数と関連付けを確認してから全件を取り込みます。
重複を防ぐ鍵は一意の識別子です。関連付けで識別子を省くと、紐付けではなく重複レコードが作られます（出典：インポートファイルを準備する）。
| 対象 | 使える識別子 | 注意点 |
|---|---|---|
| コンタクト | メールアドレス、レコードID、一意値を必須にしたカスタムプロパティ | レコードIDの列があると他の識別子より優先されます |
| 会社 | 会社のドメイン名、レコードID、一意値を必須にしたカスタムプロパティ | カスタムプロパティだけで判定すると、同じドメインの会社がそのまま取り込まれます |
| 空欄のセル | — | 空欄は無視されるため、既存の値を消す用途には使えません |
メールアドレスが無い名刺は、名刺ID（元データの一意の番号）を一意値を必須にしたカスタムプロパティとして作成し、識別子に使う設計が考えられます。設定（歯車アイコン）＞ データ管理 ＞ プロパティで作成します。
取り込み後に重複を確認する
取り込み後は、HubSpotの重複管理ツールで重複の候補を確認します。コンタクトまたは会社の一覧で「Actions」＞「Manage duplicates」を開きます。標準の照合条件は、コンタクトが名・姓・メールアドレス・IP国・電話番号・郵便番号・会社名、会社が会社ドメイン名・会社名・国／地域・電話番号・業種です。重複管理ツールはMarketing・Sales・Service・Data Hub・Smart CRMのいずれかのProfessional以上で使え、独自の照合ルールの作成にはData HubのProfessional以上が必要です（出典：重複レコードの確認と管理）。
レコードの統合は元に戻せません（出典：レコードを統合する）。統合の前に、どのレコードを残すか（主レコード）を決め、名刺データの整理方針と合わせて確認します。Data Hubの詳しい使い方はData Hub支援のページにまとめています。CRM移行全般のデータ設計はCRM移行のデータ設計完全ガイドも参考になります。
名刺画像と組織ツリーは別の要件として扱う
GRIDY名刺CRMの名刺画像は、テキスト項目と同じ方法で移行できるとは限りません。画像を参照する必要がある場合は、ファイルの保管場所を決め、該当コンタクトから参照できる運用を検討します。
組織ツリーについても、会社レコードの部署やコンタクトの役職を記録することと、図としての組織構造を維持することは別の要件です。標準機能で足りるか、外部アプリや追加のデータ構造が必要かを、営業がどの判断に使うのかから決めます。
活動履歴と日報は移す目的を決めてから扱う
過去の活動をすべて移すと、現在の商談に不要な記録まで新しい環境に持ち込む場合があります。一方、重要な提案経緯が参照できないと、引き継ぎや顧客対応に影響します。履歴を移す目的と参照担当を先に整理し、データ量や形式に応じて方法を選びます。
活動履歴を移すか参照用に残すかを決める
訪問、電話、メール、商談メモなどの履歴について、移行対象を種類別に整理します。期間だけで機械的に区切るのではなく、進行中の取引に関わる記録、次の担当が必要とする経緯、監査や社内確認のために参照する記録を識別します。
| 履歴の種類 | 移行を検討する条件 | 参照用に残す条件 |
|---|---|---|
| 進行中の取引の活動 | 次回対応や提案経緯の把握に必要 | 元システムで内容を確認できる |
| 完了した取引のメモ | 再提案や顧客対応に使う | 現行業務で参照頻度が低い |
| 日常の電話・訪問記録 | 顧客との関係や対応履歴を引き継ぐ | 個別レコードへの紐付けが難しい |
| 添付ファイルや画像 | 取引判断に必要な資料である | 別の保管場所で識別・検索できる |
移行する活動の種類と目的を確かめ、作成と既存データの更新を分けて計画します（出典：複数オブジェクトのレコードをインポートする）。
小規模な転記と一括移行を使い分ける
対象が限られ、履歴を少数のコンタクトや取引に紐付ける場合は、内容を確認しながら手作業で記録する方法があります。件数が多い、関連付けが複雑、属性を保ったまま登録する必要がある場合は、HubSpotのインポート機能やAPIを含めて移行方式を設計します。
方式を決める前に、元データの形式、HubSpotで扱う活動種別、レコードとの関連付け、エラー時の再処理方法を確認します。単純に活動テキストをノートへ貼り付けるだけでは、日付や担当者などの情報が失われる場合があります。
日報を提出型からデータ確認型へ見直す
GRIDYレポートで日報を作成している場合、報告の目的を分けて考えます。活動件数や取引ステージなど、CRMに記録された情報から確認できる内容は、レポートやダッシュボードで把握する設計が考えられます。判断や相談が必要な内容は、日報に残すのか、取引や活動のメモに記録するのかを明確にします。
担当者が数字を別途書き写す運用を続けると、CRMの記録と報告内容に差が生まれることがあります。日報をなくすこと自体ではなく、同じ情報を何度も入力させないことを基準に、必要な報告の形を決めます。
受注後に必要な情報まで流れをつなぐ
顧客情報がコンタクトや会社にあり、営業案件が取引に記録されたら、受注後に引き継ぐ項目を決めます。顧客対応や請求に使う情報を営業段階で確定できるようにし、担当者が個別に転記する範囲を減らします。
データの流れを「コンタクト・会社から取引、受注後の顧客対応、請求情報の連携」まで見渡すことで、営業だけに閉じないCRMの役割が明確になります。請求処理そのものは専用の業務システムで行う場合も、取引に必要な状態を戻せるかを連携要件として整理します。
会計にfreeeを使う場合は、StartLinkが開発したHubSpotアプリSync for freeeで、取引先の同期、取引からの見積書・請求書の作成、成約した取引のfreee会計への登録を扱えます。freeeで入金が消し込まれると、HubSpotの「freee取引」の決済状況が「決済完了」に更新されます。月次の継続請求はProfessionalプラン以上、合算請求と原価の支出登録はEnterpriseプランが条件です（プランの内容は製品ページの記載に従います）。会計・バックオフィス連携の全体像は会計・バックオフィス連携のハブ記事にまとめています。
グループウェアの分離後も業務がつながる構成にする
ツールを分けると、予定、申請、連絡、顧客情報が別々の場所に置かれます。単に移行先を選ぶだけでなく、通知やリンク、情報の正本を決めて業務が途切れないようにします。CRMに集約する情報と、各ツールで完結させる情報を区別します。
予定と顧客活動をつなぐ
カレンダーは既存のGoogle CalendarやMicrosoft Outlookを利用し、HubSpotとの連携範囲を確認します。顧客とのミーティングを設定したとき、予定だけでなくコンタクトや取引の活動として記録する運用にすると、後から顧客対応の履歴をたどりやすくなります。
HubSpotのミーティングリンクを使う場合も、予約後にどのレコードへ活動が記録されるかを試します。社内予定や顧客情報を含まない予定までCRMへ記録する必要はありません。利用者が迷わないよう、顧客予定と社内予定の扱いを決めます。
稟議や申請をCRMの外に置く
稟議・申請はHubSpotのCRM機能だけで再現しようとせず、申請・承認に適したツールを選びます。ジョブカンワークフロー、kintone、Google Workspaceなどを候補にする場合は、申請者、承認者、記録の保管先、CRMから参照したい情報を照合します。
案件の承認と社内稟議が混ざっている場合は、どちらが業務の正本かを分けます。営業案件のステージや金額は取引に記録し、正式な申請・承認の履歴は申請システムで管理する、といった境界を決めると二重管理を抑えられます。
通知先と情報の正本を決める
SlackやMicrosoft TeamsへCRMの通知を流す場合、通知を受けた人が何をするのかまで定義します。ステージ変更や活動登録をすべて通知すると、重要な連絡が埋もれることがあります。担当者やマネージャーが次の対応を判断できる条件に絞ります。
| 情報 | 正本にする場所 | 他ツールへ渡す情報 |
|---|---|---|
| 顧客・会社情報 | HubSpot | 必要な識別情報やリンク |
| 商談ステージ・金額 | HubSpotの取引 | チーム通知に必要な変更内容 |
| 社内申請の承認状況 | 申請ツール | 取引判断に必要な状態 |
| ファイル本体 | 合意したファイル保管先 | HubSpotに参照リンクを記録 |
| 会議予定 | カレンダー | 顧客対応に必要な活動情報 |
ログインや画面切り替えを運用で補う
オールインワンの環境から複数ツールに分かれると、利用者が画面を探す時間が増えることがあります。利用ツールの入口を社内ポータルやブラウザのブックマークにまとめ、顧客情報を更新する場所と社内連絡の場所を明記します。
シングルサインオンを使う場合は、各サービスの対応プランや社内の認証要件を確認してから構成します。利用者の利便性だけで決めず、アカウント管理や退職時の停止手順も運用担当と合わせて設計します。
移行は小さく試し、差分を管理して定着させる
移行では、データ設計と業務変更を一度に進めようとすると、問題が見つかった際に原因を切り分けにくくなります。対象を段階に分け、少量のデータで項目対応と関連付けを確認してから範囲を広げます。各段階の完了条件を決めておくことが、手戻りの抑制につながります。
StartLinkはHubSpotゴールドパートナーとして、150社以上のHubSpot支援に携わってきました。移行支援は、次の工程で進めます（Salesforce→HubSpot移行支援のページに載せている流れと同じ考え方で、移行元がKnowledge Suiteの場合も使えます）。
- 現状の整理・要件定義：利用中の機能と更新者を洗い出し、移行する対象と別ツールへ分ける対象を決めます。
- 設計・構築：項目のマッピング、取引パイプライン、カスタムプロパティ、権限を設計し、HubSpotに作ります。
- データ移行：テスト移行で確認してから本番移行を行い、移行後に件数と関連付けを照合します。
- テスト・検証：主要な取引と名刺のサンプルを営業担当者と一緒に確認します。
- 定着・運用改善：操作研修、ワークフローやレポートの追加、必須項目の見直しを、スモールスタートで広げます。
準委任で伴走する進め方なので、最初に対象を絞って始め、結果を見ながら範囲を広げることができます。移行の失敗パターンはSalesforce移行で失敗する7つの原因と対策、移行全体の手順はSalesforceからHubSpotへの移行完全ガイド、表計算からの移行はExcel・スプレッドシートからHubSpotへ移行する方法が参考になります。企業様によって最適な形は異なります。
現行業務・データ・移行先を一覧にする
最初にKnowledge Suiteで利用している機能と、担当者、更新頻度、後続業務を整理します。顧客、会社、取引、活動、名刺、申請などのデータを分類し、移行先、保持方法、責任者を決めます。
この段階では、HubSpotへ移す項目を最小限から設計します。入力担当者が使う情報と、レポートや引き継ぎに必要な情報を分け、使い道が説明できない項目は理由を確認します。
テストデータで項目と関連付けを確かめる
少量の代表データを用いて、コンタクト、会社、取引の作成と関連付けを確認します。項目の値が正しく入るだけでなく、会社名の揺れ、担当者の割り当て、ステージ変換、重複判定が想定どおりかを見ます。
インポート前後でレコード数と識別項目を照合し、欠落や重複があればマッピングか元データを修正します。期待する関連付けが確認できたら、本番対象のデータへ進みます。
本番移行日の差分を取り込む
最初のエクスポート以降も営業活動で新しい情報が生まれます。移行日までの更新を別途記録し、最終エクスポートで取り込むのか、差分リストから追加するのかを決めます。
| 時点 | 対応 | 次へ進む条件 |
|---|---|---|
| 移行準備 | 項目対応と移行対象を確定する | 対象データと除外理由を説明できる |
| テスト | 少量データで登録と関連付けを試す | 主要項目・重複・所有者が確認できる |
| 本番前 | 差分を記録し最終データを準備する | 追加・更新の対象を識別できる |
| 本番後 | 件数とサンプルを照合する | 重要レコードの値と関連付けを確認できる |
| 定着後 | 利用者の入力とレポートを見直す | 不要項目や手作業の残りを特定できる |
並行運用の範囲と終了条件を決める
旧環境と新環境を併用する期間を設ける場合、どちらを正本とするかをデータごとに指定します。両方で同じ取引を更新すると、後からどちらの値を採用すべきか判断できなくなります。
並行運用を終える条件は、データ移行の照合、利用者のアクセス、残作業の移管、旧環境を参照する担当者を踏まえて決めます。旧環境を参照専用にする場合も、参照権限と保管期間を社内で確認してから切り替えます。
運用しながら項目と自動化を広げる
移行直後から全てのワークフローやレポートを作る必要はありません。まず取引ステージ、担当者、次回対応など、営業の進捗判断に必要な情報を揃えます。その後、入力漏れが繰り返される箇所に必須項目や通知を設定し、活動や取引のデータが安定した段階でレポートを広げます。
この順序なら、個人の記憶や日報提出に依存していた作業を、記録とルールで引き継ぎやすくできます。自動化は、条件に合うときに誰へ何を知らせるかを明確にしてから追加します。
よくある質問
Knowledge SuiteからHubSpotへの移行では、グループウェアも移す必要がありますか？
すべてのグループウェア機能をHubSpotへ移す必要はありません。顧客・取引の管理はHubSpot、予定や申請、ファイル共有は用途に合うツールというように、業務の正本と利用者を基準に分けます。
GRIDY名刺CRMのデータはHubSpotへ取り込めますか？
名刺から得た氏名、会社名、役職、連絡先などのテキストデータは、項目を対応付けてコンタクトや会社として取り込めます。名刺画像や組織ツリーは別の要件として扱い、必要性に応じて保管方法や追加の仕組みを検討します。
SFAの取引ステージは現在の名称をそのまま使えますか？
名称をそのまま使うことはできますが、各ステージへ進める条件を担当者間で揃えることが先です。ステージ、受注確度、定義、必須入力項目を合わせて設計し、移行後の案件状況を同じ基準で判断できるか確認します。
過去の活動履歴はすべて移行した方がよいですか？
一律にすべて移すのではなく、進行中の取引や顧客対応の引き継ぎに必要な履歴を優先します。移行しない情報を旧環境で参照できるなら、参照担当と方法を決めておくと、必要な記録を失わずに運用できます。
複数ツールに分かれると二重入力が増えませんか？
情報の正本と更新する場所を決め、CRMへ記録する情報を絞ることで二重入力を抑えられます。通知や連携は、担当者が次に行う作業に必要な項目だけを対象にし、動作を少量のデータで確かめてから広げます。
まとめ
Knowledge SuiteからHubSpotへ移るときは、CRM・SFAを顧客と営業プロセスの基盤として再設計し、予定・申請・社内連絡などは役割に応じて別のツールへ分けます。取引パイプラインはステージ、受注確度、定義、必須項目を揃え、名刺や活動履歴は移行後の用途に合わせて範囲を決めます。
まずは、現在の顧客・案件・名刺のデータがどこにあり、誰が更新しているかを一覧にするところから始めてください。次の順序で進めます。
- Knowledge Suiteの機能とデータを棚卸しし、移行先と正本を決めます。
- 取引ステージ、項目、会社・コンタクトとの関連付けを設計します。
- 少量データでインポートと照合を行い、確認できた範囲から本番移行します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
