▼ この記事の内容
大企業の営業支援ツールは、部門別の権限、既存システムとの連携、試行から展開へ進む条件をそろえて選びます。許可・禁止の操作や復旧手順を試し、費用と社内作業も同じ範囲で比較する進め方です。未確認事項は未対応と分け、確認担当と期限を決めて次に試す候補を絞ります。
部門ごとに必要な操作や扱える情報が違うと、営業支援ツールの機能一覧だけでは採否を決めにくくなります。大企業の選定の出発点は、営業部門、情報システム、購買が確認する条件を、実際の業務に対応させることです。中小企業の営業支援ツールの選び方も、あわせてご覧ください。
たとえば、兼務を解除した後に不要な案件が見えなくなるか、既存システムとの接続に失敗しても正しく復旧できるかは、試行で確かめる項目です。対象の契約プランについての回答と試験結果を分け、確認できていない条件も残します。
部門別の権限表、連携確認表、試行と展開の判断表を使って、候補を絞る手順を整理します。提案するのは、全社展開の費用と社内で必要な作業も確認し、次に試す候補と追加確認する内容を決める進め方です。
大企業向け営業支援ツールは部門ごとの必須条件で絞る
大企業の営業支援ツールは、部門別の権限、既存システムとの連携、段階的に導入する条件をそろえて候補を絞ります。ここで提案するのは、営業部門、情報システム、購買が同じ条件を確認できるよう、必要な業務と採否の根拠を表にまとめる方法です。
必須条件と希望条件を分ける
最初に、満たせなければ対象業務を進められない必須条件と、使い勝手を高める希望条件を分けます。大企業で候補比較の前に整理するのは、部門ごとの閲覧範囲、既存システムとの接続、試行から利用部門を広げる条件です。
営業業務で必要な操作と、情報管理上認める操作は、同じ業務場面に対応させて確認します。兼務担当者が別部門の案件を見る必要がある場合、対象の案件と利用目的を示すのは営業側です。そのうえで、情報管理の担当者と閲覧を認める範囲を決めます。
必須か希望かという優先度と、確認済みか未確認かという確認状況は、別の欄で管理します。以下は要件を整理するための説明用の記入例であり、実際の導入結果ではありません。条件の区分は自社の業務に合わせて決め、確認が終わるまでは証拠欄を取得済みとして埋めません。
| 業務 | 利用部門 | 必須／希望 | 条件 | 確認先 | 証拠 | 状態 |
|---|---|---|---|---|---|---|
| 兼務担当者が別部門の案件を確認します | 兼務元・兼務先の営業部門を記入します | 対象業務に必要なら必須とします | 業務に必要な案件だけを閲覧できることを確認します | 営業責任者と情報システムへ確認します | 合意した閲覧範囲と権限試験の記録を残します | 確認前は未確認と記入します |
| 既存システムの顧客情報を引き継ぎます | 営業部門と顧客情報の管理部門を記入します | 業務の継続に必要なら必須とします | 必要な項目が、決めた方向で更新されることを確認します | 既存システムの管理担当者と導入候補の提供元へ確認します | 対象項目への回答と接続試験の記録を残します | 確認前は未確認と記入します |
| 案件一覧の表示順を調整します | 一覧を使う営業部門を記入します | 変更できなくても業務が完了するなら希望とします | 必要な案件を確認できるか、実際の操作で確かめます | 利用担当者と導入候補の提供元へ確認します | 操作した結果と残る手間を記録します | 確認前は未確認と記入します |
| 試行後に利用部門を広げます | 試行部門と拡大先の部門を記入します | 展開に必要な受入条件を必須とします | 権限・連携・移行の確認と、教育・支援の準備を終えてから拡大を判断します | 各部門の責任者、情報システム、購買へ確認します | 試行結果と拡大に必要な作業・費用の回答を残します | 確認前は未確認と記入します |
必須条件を満たす根拠がある候補は、試行の対象に残します。必須条件に回答がない候補は追加確認の対象です。満たせないと確認した候補は、対象業務を変えない限り見送りとします。希望条件が多くそろっていても必須条件の不足を補ったとは扱いません。未確認だけを理由に非対応と決めることも避けます。
確認する部門と採否の根拠を整理する
営業マネージャーは、各部門の要望を業務単位でまとめ、何を確認すれば候補に残せるかを整理します。「顧客情報を共有したい」という要望で具体化するのは、誰が、どの顧客の、どの情報を、何のために使うかです。部門間で必要な範囲が違う場合は、違いを残したまま確認先へ渡します。
情報システムには、必要な操作と制限したい操作、接続する既存システム、更新する項目を対応させて確認します。製品資料に権限管理や連携の記載があっても、自社が使う範囲と対象の契約プランで実行できるかは、別に確認が必要です。回答だけで判断できない部分は、試行時に確かめる項目として残します。
購買には、試行と全社展開それぞれの対象人数・部門・期間を伝え、同じ範囲で費用条件を確認します。利用料に加え、初期設定、データ移行、教育、追加接続の作業が見積もりに含まれるかも見比べる対象です。社内で担う作業は提供元への支払いと分けて記録し、担当部門と必要な作業量を確認します。
顧客情報の共有と案件進捗の管理が要望に混在する場合は、CRMとSFAを管理する業務で分ける考え方を確認し、必要な情報と更新担当を整理します。
営業AI・営業DX CRMツールの選び方｜営業成果で比べる基準と失敗回避
市場シェアを候補選びの参考にする場合は、調査対象・地域・集計期間によるシェアの違いも確認します。順位だけを、自社の必須条件を満たす根拠にはしません。
営業AI・営業DX SFAシェアランキングの見方｜比較前に見る選定軸
採否の記録では、次の情報を要件ごとに対応させます。
- 判断の根拠、確認者、確認日、未回答事項を記録します。
- 対象プランについての回答と、試行で実際に確かめた結果を区別します。
- 未回答事項には確認担当と回答期限を定めます。
この記録を基に、候補に残す理由と追加確認が必要な条件を区別します。次は、閲覧・編集・出力の権限を具体的な操作に分けて確認します。
複数部門の閲覧・編集・出力権限を確認する
権限の確認では、誰がどの案件を見て、編集・出力できるかを部門ごとに整理します。許可する操作と許可しない操作を同じ条件で試し、例外の承認者と記録先を決めます。
操作範囲とデータ範囲を権限表にまとめる
権限の確認では、閲覧・編集・出力を分け、それぞれで扱えるデータの範囲を決めます。画面で案件を確認する業務と、案件一覧をファイルに出力する業務は、別々の記入対象です。それぞれで必要な操作と禁止する操作を対応させます。
対象データは、顧客情報・案件情報などの種類に加え、自分の担当案件、所属部門の案件、確認が必要な項目まで具体化します。人が操作する利用者のほかに、システム間の情報交換に使う「連携アカウント」も表に加えます。整理するのは、接続に必要なデータと操作だけです。
Salesforce Trailheadの権限管理教材では、データの種類ごとに作成・閲覧・編集・削除を制御し、権限の設定をまとめた権限セットなどで利用者へ付与する方法を説明しています。[1]HubSpotのユーザー権限ガイドでは、CRM（顧客管理システム）の対象データについて、全件・自分のチーム・自分が担当する情報などから閲覧・編集範囲を選ぶ方法を示しています。[2]
以下は、権限を整理するための説明用の記入例であり、実際の導入結果ではありません。営業部門と情報システムで必要な範囲を決め、許可・禁止の期待値、つまり試験で確かめる動作を先に記入します。
| 役割 | 連携アカウント | 対象データ | 閲覧 | 編集 | 出力 | 異動時 | 兼務解除時 | 退職時 | 許可・禁止の期待値 | 試験結果 |
|---|---|---|---|---|---|---|---|---|---|---|
| 営業担当者として確認します | 人の利用者として扱い、連携用とは分けます | 担当する顧客・案件と必要な項目を記入します | 担当範囲を許可する例とします | 担当案件の必要項目を許可する例とします | 業務上必要な対象だけを許可する例とします | 異動後に残す権限と解除する権限を記入します | 兼務がある場合は解除対象を記入します | 本人の利用を停止する条件を記入します | 担当案件の編集を許可し、対象外案件の編集・出力を禁止する例とします | 未確認です。実施後に操作ごとの結果を記録します |
| 複数部門の兼務担当者として確認します | 人の利用者として扱い、連携用とは分けます | 兼務元・兼務先で必要な案件と項目を記入します | 両部門の必要範囲を許可する例とします | 各部門で担当する業務に必要な範囲を記入します | 閲覧範囲とは別に許可範囲を決めます | 異動後も継続する業務の権限を記入します | 解除した部門の不要な権限を外す条件を記入します | 両部門での本人の利用を停止する条件を記入します | 継続する担当業務を許可し、兼務解除後の対象外データの閲覧を禁止する例とします | 未確認です。変更前後の結果を記録します |
| 既存システムとの情報交換を担います | 接続に使うアカウントと管理担当を記入します | 接続対象の顧客・案件・項目を記入します | 接続元から取得する範囲を記入します | 接続先で更新する範囲を記入します | 外部へ取り出す対象と許可範囲を記入します | 管理担当が異動する場合の引継ぎを記入します | 管理担当の兼務解除で変える管理権限を記入します | 退職者の管理権限と継続する連携の扱いを分けて記入します | 対象項目の更新を許可し、対象外データの取得・更新を禁止する例とします | 未確認です。接続経由の実行結果を記録します |
候補製品ごとにこの表へ記入して見比べると、資料だけでは判断できない条件が具体的になります。対象の契約プランについて提供元へ確認するのは、出力を個別に制限できるか、案件・項目単位で必要な範囲を指定できるかです。公式説明に選択肢があっても自社の設定で同じ動作になるとは決めず、担当者が未割当のデータなども含めて試験項目に残します。
参考：Control Access to Objects｜Salesforce Trailhead
参考：HubSpot user permissions guide｜HubSpot
異動・兼務・退職時の権限の動きを試す
権限試験では、許可した操作ができることと、禁止した操作が拒否されることを両方確かめます。提案する進め方は、試験用の利用者とデータを用意し、権限表に沿って閲覧・編集・出力を実行する方法です。通常の営業業務だけでなく、所属や担当が変わる場面も対象にします。
異動の試験では、変更前に見える案件と操作できる項目を記録し、所属・担当・権限を変更した後に同じ操作を試します。別々に確認するのは、異動先で必要な操作ができるかと、異動元で不要になった操作が拒否されるかです。引継ぎのために一部の権限を残す場合は、対象データと解除する時期も先に決めます。
兼務解除では、解除した部門の権限を外した後も、継続する部門の業務が行えるかを確認します。退職の試験で確かめるのは、本人の利用を停止した後に閲覧・編集・出力ができないかです。必要な業務まで止まった場合も、禁止した操作が残った場合と同様に、期待した動作との差として記録します。
連携アカウントは、人の画面操作とは別に、接続経由で許可した取得・更新ができるか、対象外の操作が拒否されるかを試します。接続元を確認する認証方式と、認証情報の管理・更新・無効化を担う担当も、情報システムと提供元で確認します。管理担当者が異動・退職する場合に分けて扱うのは、本人が連携を管理する権限と、業務として継続する接続です。連携の停止や引継ぎが必要かを決めてから、変更後の動作を確かめます。
試験結果には、操作した利用者または連携アカウント、対象データ、変更前後の設定、期待した動作、実際の結果を対応させて残します。実施していない操作は未確認です。禁止した操作が通った場合や必要な操作ができなかった場合は、設定や提供条件を確認して再試験します。権限の対象範囲を整理した後の確認対象は、既存システムとやり取りする項目と更新方向です。
既存システムとの連携を項目・方向・復旧条件で確かめる
既存システムとの連携では、接続先の名前だけでなく、どの項目がどちらへ更新されるかを確認します。認証と権限、停止したときの再開手順を並べ、確認する担当者と結果を残します。
項目ごとに更新方向と正本を対応させる
既存システムとの連携は、業務に必要な項目を選び、接続元と接続先のデータをどう対応づけるかから確認します。顧客や案件を区別する番号などの「識別子」を決めます。試すのは、同じ顧客の情報が正しい接続先へ反映されるかです。既存のCRM（顧客管理システム）を残す場合も、新しいツールへ渡す項目と、既存側で管理を続ける項目を整理します。
次に、項目ごとに正しい値を管理する元データを「正本」として定めます。会社名や請求先は基幹システム、商談の進捗は営業支援ツールで管理する分担を検討するなら、各項目を誰が修正するかも整理する対象です。両方で同じ項目を変更する場合は、値が食い違ったときに優先する側と、確認を担う部門を先に決めます。
更新方向は、接続元から接続先へ送る片方向か、双方の変更を反映する双方向かを項目ごとに確認します。更新頻度を決める基準は、営業業務で必要な反映時期です。必要な更新頻度と処理量を、対象プランの連携件数や処理量の制限と見比べます。通常時に加え、まとめて更新する場面で想定する量も示します。その条件を満たせるかは、提供元への確認事項です。
同じ顧客の複数の登録をまとめる「名寄せ」や削除も、更新とは別に扱いを決めます。確認するのは、接続元で顧客を統合・削除したときに、接続先の顧客情報と関連する案件をどう扱うかです。試験用データでは識別子を見比べ、同名の別顧客を取り違えていないか、重複を解消した後も案件との対応が保たれるかを確認します。
以下は連携条件を整理するための説明用の記入例であり、実際の導入結果ではありません。基幹システムの顧客名を営業支援ツールへ反映する場面を例に、確認する内容を示します。試行では更新前後の値と識別子、処理件数・時間を記録し、必要な処理が対象プランの制限内で完了するかを判断します。
| 接続元 | 接続先 | 項目 | 元データ | 識別子 | 更新責任 | 更新方向 | 頻度 | 制限 | 失敗時 | 通知 | 再実行 | 復旧担当 | 追加開発 | 保守 | 結果 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 基幹システムを接続元とする例です | 営業支援ツールを接続先とする例です | 顧客名を反映する例です。実際の対象項目を記入します | 基幹システムの顧客名を正本とする例です | 顧客番号など、両側の登録を対応づける値を確認します | 正本の修正担当と、値が食い違う場合の確認担当を決めます | 基幹システムからの片方向を例とし、逆方向の更新が起きないかも確認します | 業務で必要な反映時期と、実行できる頻度を記入します | 対象プランの件数・処理量の上限と、想定量を見比べます | 失敗した対象と、反映済みの対象を確認する方法を記入します | 通知方法、受け取る担当、確認する時間帯を決めます | 再実行する対象と条件、自動・手動の別を確認します | 社内と提供元の担当範囲、連絡先を記入します | 標準の接続で足りない作業と、その担当・費用を確認します | 接続設定の変更や障害対応の担当・費用を確認します | 未確認です。試行後に期待した値と実際の結果を記録します |
必要な項目・更新方向・処理量の条件を満たすと確認できた候補は、復旧試験へ進めます。未確認の条件は追加確認へ回し、必須条件を満たせないと確認した候補は、対象業務や接続方法を変えない限り見送りとします。
接続失敗後に復旧できるかも試行で確かめる
連携の試行で提案するのは、正常に更新できることに加え、接続に失敗した後の復旧まで確かめる進め方です。Microsoft LearnのDynamics 365導入ガイドでは、本番移行前にシステム連携試験、利用部門による受入試験、性能試験を完了し、承認する手順を示しています。[3]これは同製品の導入手順の説明であり、検討中の製品の復旧機能や性能を保証するものではありません。
まず正常時の試験で、送ったデータ、接続先に反映された値、処理が完了した時刻を記録します。その後に確認するのは、接続停止や更新の途中失敗です。試験には、情報システムと提供元が合意した環境を使います。業務で使用中の接続を止めずに試せる方法を定め、どこまで処理されたかを追える記録が残るかも確かめます。
失敗時に決めるのは、誰がどの方法で通知を受け、何を確認してから再実行するかです。自動で再実行する機能の有無と条件、手動操作が必要な範囲を分け、実際に通知が届くかまで試します。通知を受け取る担当と復旧作業をする担当が異なる場合は、失敗した対象と処理記録を引き継ぐ方法も確認します。
再実行後は、処理の完了表示だけで判断しません。接続元と接続先で見比べるのは、顧客・案件の識別子と主要項目です。反映済みのデータが重複して登録されていないか、失敗した分が欠けていないかを別々に確認します。停止中に変更した値がある場合は、再実行によって古い値へ戻っていないかも試験に含めます。
復旧担当が分けて記録するのは、社内で設定を直す範囲と、提供元へ対応を依頼する範囲です。再試験の合格条件には、必要な更新が完了すること、重複・欠損・値の不一致が残らないこと、業務上必要な時間内に復旧することを自社の条件として定めます。未実施の項目は未確認として残し、連携の確認結果を、実際の営業業務を使った試行へ引き継ぎます。
参考：Prepare to go live｜Microsoft Learn
試行から部門拡大へ進む条件を決める
営業支援ツールの利用部門を広げる前に決めるのは、実際の業務で確かめる項目と、拡大を認める条件です。権限・連携の動作に加え、移行した情報の正確さ、業務の完了可否、教育・支援の準備まで確認する進め方を提案します。
代表業務と例外業務の両方を試す
試行する部門を選ぶ範囲は、日常の営業業務と、兼務や接続失敗などの例外を確認できる範囲です。Microsoft LearnのDynamics 365導入ガイドでは、事業部門や地域などに分けて段階的に導入する方法を示しています。[4]同製品の導入計画の説明であり、すべての営業支援ツールに共通する試行人数や期間を定めたものではありません。
試行前には、移行対象のデータ、利用者への操作説明、問い合わせ先を用意し、業務に使えるかを確認する「受入担当」を決めます。見比べるのは、移行前後の件数、主要項目、顧客・案件の識別子、顧客と案件の関連づけです。件数が一致していても別の顧客へ案件がひもづいていないかまで確認します。元の運用へ戻す手順と、試行中に追加・更新した情報を戻し先へ反映する方法も、試行開始前の確認事項です。
試行では、顧客情報の確認から案件更新までの代表業務を担当者が実行し、兼務解除後の権限や接続失敗からの復旧も試します。想定するデータ量と同時利用人数で記録するのは、画面の応答時間、連携処理の時間、業務を最後まで完了できたかです。受入担当は、移行データの差異と各試験の結果を事前に決めた条件と見比べ、未実施の項目を合格に含めず残します。
参考：Plan your deployment and release｜Microsoft Learn
拡大・再試験・見送りの条件を記録する
部門拡大の判断の基準は、事前に決めた必須条件と、それに対応する確認記録です。条件を満たした項目、試して不一致が分かった項目、まだ確認していない項目を分け、修正後に再試験する範囲を記録します。以下は試行と展開を判断するための説明用の記入例であり、実際の導入結果ではありません。
| 業務 | 受入条件 | 確認方法 | 担当 | 移行前後の件数・主要項目・識別子・関連づけ | 性能・実務確認 | 結果 | 未解決 | 再試験 | 中断・復帰条件 | 判断担当 | 復帰手順 | 試行中の更新データの扱い | 展開判断 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 移行した顧客情報を使い、案件を確認・更新する業務を例とします | 必要な情報が正しく対応し、許可された操作で対象業務を完了できることを条件として定めます | 移行前後のデータを見比べ、役割別の操作と接続失敗後の復旧を試して、実行記録を残します | 営業側の受入担当、情報システム、提供元の担当範囲を決めます | 件数の差、主要項目の値、識別子の一致、顧客と案件の対応を記録します | 想定データ量・同時利用人数で応答時間と連携処理時間を測り、代表業務の完了可否を確認します | 確認前は空欄とし、実施後に期待した動作と実際の結果を記入します | 確認済みの不一致と未確認事項を分け、対応担当と確認期限を決めます | 修正箇所と影響する業務を指定し、同じ受入条件で再確認します | 重要なデータ不一致、禁止操作の実行、業務継続に必要な性能条件の未達などを候補として、事前に定めます | 展開の中断、元の運用への復帰、再開を判断する責任者を決めます | 利用・連携を止める順序、戻す対象、復帰後にデータを見比べる方法を事前に確認します | 追加・変更した情報を識別し、戻し先への反映方法と重複・欠損の確認方法を決めます | 確認記録を基に、拡大・再試験・見送りを判断します。試行中は中断・復帰の要否も判断します |
重要な移行データの不一致や禁止操作の実行などが判明し、事前に定めた中断条件に当てはまる場合は、展開を中断して元の運用へ戻す判断を行います。判断担当は復帰手順に沿って対応し、試行中の更新情報が失われたり重複したりしていないかも確認します。修正可能な問題は再試験へ回し、必要な条件を満たせないと確認した候補は見送りとしますが、回答待ちや試験未実施だけを理由に非対応とは扱いません。
拡大先では、試行部門との業務の違い、入力にかかる手間、教育担当と問い合わせ対応の余力も確認します。現場で使い続けられるかを検討する際は、入力負担と管理職による記録の活用を併せて確認する方法も参考になります。入力率だけでは導入成功としません。システムが業務に使えるという受入判定と、商談や受注の成果が変わったかという評価は別です。確認条件と支援体制がそろった部門から拡大する案を基に、次は追加設定や教育を含む費用・契約条件を比較します。
営業AI・営業DX 営業支援ツールは簡単さで選ぶ｜現場が定着する5つの条件と比較表
全社展開にかかる費用と契約条件をそろえて採否を判断する
費用比較では、対象人数・部門・期間と、提供元に依頼する作業範囲をそろえます。提案するのは、試行で確認した権限・連携・移行の条件を見積もりに対応させ、支払額と社内で必要な作業を分けて判断する進め方です。
初期・継続・追加・終了時の費用と社内負担を整理する
見積もりを依頼する前に、試行時と全社展開時それぞれの利用人数、対象部門、利用期間を決めます。接続するシステム、移行するデータ、教育する利用者の範囲も同じ条件で示します。比較するのは、候補ごとの見積もりに含まれる作業です。まだ決まっていない展開範囲は、確定した範囲と分けて追加時の条件を確認します。
費用は、初期設定・移行・教育、継続利用・保守、部門や接続の追加、契約終了時の対応に分けて確認します。旧システムと並行して使う期間がある場合は、双方の利用料・保守料と、一時的な接続に必要な作業も見積もりに含めます。顧客・商談情報については、共有先、外部で処理する範囲、保存先・保存期間、削除の条件を提供元と契約書で確認します。契約終了時のデータ出力・移行・削除についても、依頼できる作業と費用の有無を見積もりに対応させ、不明額を0円として合計しません。以下は費用条件を整理する説明用の記入例であり、実際の見積もりや導入結果ではありません。
| 対象範囲 | 期間 | 初期 | 継続 | 追加 | 終了時 | 含有範囲 | 社内の担当 | 社内の作業 | 必要工数 | 未確認 | 回答期限 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 試行部門と拡大先の部門、人数、接続先、移行対象を記入します | 試行期間、展開予定、見積対象期間、契約期間を記入します | 設定・移行・教育の費用と対象作業を確認します | 利用料・保守料と、対象人数や処理量などの算定条件を確認します | 部門追加時の設定・教育、利用増加、追加接続の費用条件を確認します | データ出力・移行・削除の対応範囲、費用、申出期限を確認します | 各作業が基本料金に含まれるか、別見積もりかを記入します | 設定・移行・教育・保守・終了対応ごとに担当部門を決めます | 権限設定、移行前後のデータを見比べる作業、操作説明、障害対応、終了時のデータ確認などを記入します | 作業ごとに必要な時間または人日を確認し、未算定は未確認とします | 費用と作業範囲の未回答事項を分けて記録します | 社内の確認担当と提供元で合意した回答日を記入します |
社内の設定・移行・教育・保守・終了対応は、提供元への支払額とは別に、担当と必要な作業時間を確認します。提供元に任せる案と自社で行う案を比べる場合も、同じ作業がどちらに含まれるかを対応させます。これは、社内負担の見落としを防ぐための比較材料です。試行に無料利用を含める場合は、無料プランと期限付きの試用で確認する条件の違いも確認し、試行後の利用範囲と費用を別に整理します。
営業AI・営業DX 営業支援ツール無料｜比較軸と選び方
確認事項が残る候補は条件を付けて判断する
未確認は回答や試験結果がそろっていない状態で、未対応は必要な条件を満たせないと確認した状態です。回答待ちの候補には、確認する条件、社内の担当、提供元の回答期限、判断に使う資料や試験結果を対応させます。以下は追加確認を管理する説明用の記入例であり、実際の回答や採否を示したものではありません。
| 確認事項 | 確認担当 | 回答期限 | 判断に使う根拠 | 回答までの扱い | 再検討する条件 |
|---|---|---|---|---|---|
| 拡大先の部門でも必要な権限を設定できるか確認します | 営業側と情報システム側の確認担当を記入します | 提供元と合意した回答日を記入します | 対象プランの回答と、役割別の試験結果を残します | 必須権限の確認が終わるまで、対象部門への展開を保留します | 対象部門・役割・契約プランが変わったら再確認します |
| 追加接続と終了時の対応が見積もりに含まれるか確認します | 情報システム側と購買側の確認担当を記入します | 見積回答と条件確認の期限を記入します | 作業範囲を明記した見積書と契約条件を残します | 未確認額を0円とせず、総額の比較を保留します | 接続先・データ量・対応範囲が変わったら再見積もりします |
採用する候補には満たした必須条件と費用・作業の根拠を、保留する候補には未確認事項と判断を再開する条件を残します。見送りの判断に使うのは、必要な権限を設定できない、接続条件を満たせない、必要な作業を予算や社内体制で担えないなど、確認できた理由です。対象人数、部門、接続先、契約期間、作業分担が変わった場合は、以前の試行結果や見積もりが適用できる範囲を確かめ直します。
FAZOMを併せて検討する場合も、既存システムとの接続可否や対象データは提供元へ確認します。FAZOMの機能と導入前の確認事項を確認資料に含め、提供元に質問した項目と回答を記録します。既存のCRM（顧客管理システム）・SFA（営業支援システム）、会議ツール、電話システムとの接続が必要なら、利用環境と対象データを伝え、対応範囲と費用について回答を得ます。確認済みの条件と回答待ちの項目を整理してから、自社で次に試す候補を決めます。
まとめ｜条件をそろえて次に試す候補を決める
大企業の営業支援ツールを選ぶ際に候補を絞る基準は、部門ごとにそろえた必須条件と、権限・連携・段階導入の確認結果です。許可した操作ができるかと禁止した操作が拒否されるかを確かめ、接続失敗後の復旧、移行データの正確さ、実際の業務を完了できるかまで試すことを提案します。
全社展開へ進む前には、教育・支援の体制と、中断して元の運用へ戻す条件も確認します。費用を比べる際に合わせるのは、対象人数・部門・期間・作業範囲です。社内で担う作業は支払額と分けて整理します。
まずは各候補の必須条件について、確認済みの結果と未確認事項を表にまとめます。未確認だけを理由に未対応と決めることは避け、営業側の取りまとめ担当が情報システムや購買と確認先・回答期限を決めます。これは、試行へ進める候補と追加確認が必要な候補を整理するための手順です。
営業AIの活用も検討する場合は、導入前に整理する課題を以下の資料で確認できます。
営業AIを入れても売上につながらない理由を、8項目のチェックリストで解説！
＞＞無料で『営業AIを成果につなげる導入前チェックガイド』をダウンロードする
