▼ この記事の内容
SFAとCRMのどちらを導入するか、併用するかは、定義ではなく自社で管理したい業務と営業会議の判断が出発点です。案件と顧客に分けて書き出した必須要件を比較表の項目にし、候補製品を同じ基準で確かめてから、情報システム担当や予算決定者と合意します。
SFAツールとCRMを比べ始めると、どちらを導入するか、両方を併用・連携するか、一体型の製品にするかで迷い、候補製品の比較に進めないことがあります。定義や機能一覧を読んでも、自社の営業組織にどれが合うかまでは決まりません。
判断の出発点は、ツールの定義ではなく、自社で管理したい業務と営業会議で判断していることです。案件の進捗を追いたいのか、顧客との接点の履歴を共有したいのかを書き出し、その必須要件を比較表の項目にしてから製品を比べます。
ここで扱うのは、管理業務と会議の判断の書き出し方、導入目的別の選び分け表、併用・連携の前に確かめる4つのポイント、製品比較表に入れる9つの項目、顧客データを預ける前に情報システム担当と確認すること、社内で合意するまでの6つの手順です。
SFAとCRMのどちらにするかは「管理したい業務」から決める
定義より先に管理業務と会議の判断を書き出す
SFAとCRMのどちらを導入するか、併用するかは、ツールの定義からではなく、自社で管理したい業務と営業会議で判断していることを書き出して決めます。書き出した内容を比較表の項目にしてから、候補製品を比べます。
「管理したい業務」を分ける基準は、何を追いかけたいかです。商談化から受注までの案件の進み具合を追いたいのか、見込み客や既存顧客とのやり取りの履歴を残したいのかを区別します。前者に近ければSFAの役割が、後者に近ければCRMの役割が中心です。両方が同じくらい必要な場合は、一体型の製品や連携も比較の対象に残します。
「会議の判断」とは、誰が、どの会議で、何を決めているかです。週次の営業会議で営業マネージャーが受注見込みの案件を確認する、月次の会議で営業責任者が予実の差を見て打ち手を決める、といった場面を具体的に並べます。判断に使う数字や情報が分かると、ツールに求める集計や入力項目も決まってきます。
書き出す細かさを決めるのは、商材、営業人数、部門の構成です。単一の商材を少人数で扱う組織なら、案件と顧客について数行ずつ書けば比較の材料になります。インサイドセールス、フィールドセールス、カスタマーサクセスが分かれている組織では、部門ごとに書き出してから内容を突き合わせます。
構成を決めただけで、入力の定着や受注率が変わるわけではありません。書き出しは、候補製品を同じ基準で比べるための材料であり、社内で選んだ理由を説明するときの根拠です。
SFAは案件の進捗、CRMは顧客との接点の履歴を扱う
SFAは商談化から受注までの案件の進捗と営業活動を、CRMは見込み客から既存顧客までの顧客情報と接点の履歴を主に扱います。両方の機能を1つにまとめた製品もあります。
用語の定義や主な機能、MAを含めた役割分担を詳しく確認したい場合は、SFAツールが持つ機能と、CRM・MAとの役割の違いを整理した解説が参考になります。
営業AI・営業DX SFAツールとは？機能とCRM/MAの違いをやさしく解説
「一体型か両方か」を先に決めると比較がぶれる
検討の最初に「一体型にするか、SFAとCRMを両方入れるか」を決めてしまうと、候補製品を比べる基準が途中で変わりがちです。構成は、管理業務と会議の判断を書き出した結果として決めます。
構成から入ると、デモを見るたびに評価の観点が入れ替わりがちです。一体型の製品のデモでは顧客管理の画面に目が向き、SFAのデモでは案件の一覧や予実の集計に目が向きます。比べる項目が製品側の見せ方で決まるため、候補を並べた段階で、どの製品が自社の業務に合うのかを説明しにくくなります。
「一体型なら二重入力がない」「両方入れれば漏れがない」といった一律の結論も、自社の条件に当てはまるとは限りません。すでにCRMを顧客台帳として使っている組織では、案件管理を追加して連携するほうが、現場の入力方法を大きく変えずに済む場合があります。反対に、案件と顧客の記録をこれから整える組織では、連携の設定と運用を誰が担うかが決まらず、検討そのものが止まる場合もあります。
先に書き出しておけば、構成の判断は「どの管理業務を、どの会議の判断のために、どの製品で扱うか」を確かめる作業です。一体型か併用かは、その答えが出てから比べれば間に合います。次は、今の管理業務と営業会議の判断を書き出す手順です。記入例とあわせて紹介します。
自社の管理業務と営業会議から選定要件を引き出す
今の管理業務を「案件」と「顧客」に分けて書き出す
書き出しは、今の管理業務を「案件」に関わるものと「顧客」に関わるものに分けるところから始めます。どちらにも当てはまらない業務は別枠に残し、無理に振り分けません。
案件に関わる業務は、商談化から受注までの進み具合を記録し、追いかけるものです。商談段階の更新、受注見込み時期と金額の入力、次回訪問や提案書提出といった次の行動の記録がこれに当たります。顧客に関わる業務は、相手の会社や担当者との関係を残すものです。問い合わせの受付履歴、過去の購買内容、先方担当者の異動や連絡先の変更、契約更新の時期などを書き出します。
業務名だけでなく、「今どこに記録しているか」と「誰が更新しているか」も並べておきます。記入例は次のとおりです。
| 区分 | 管理業務 | 今の記録場所 | 更新する人 |
|---|---|---|---|
| 案件 | 商談段階と受注見込み時期の更新 | 営業管理表（エクセル） | 各営業担当者 |
| 案件 | 次回の訪問・提案の予定 | 各自の手帳・カレンダー | 各営業担当者 |
| 顧客 | 問い合わせの受付内容と対応履歴 | 問い合わせ用の共有メールボックス | 営業事務・サポート担当 |
| 顧客 | 購買履歴と契約更新の時期 | 基幹システム・請求データ | 営業事務・経理担当 |
記録場所が複数に分かれている業務や、更新する人が決まっていない業務は、ツールを入れたあとに誰が入力するかを決め直す必要があります。比較の段階で印を付けておくと、デモで入力画面を見るときの確認点が明確です。
今の運用をエクセルで管理している場合は、案件一覧・活動記録・集計のどこに何を入れているかを見直すと、書き出しの材料がそろいます。手元の管理表と見比べるときは、エクセルで営業管理表を作るときのシートの分け方と入力項目を整理した記事が、項目の漏れを見つける手がかりです。
営業AI・営業DX 営業管理ツールを無料のエクセルで作るには？｜シートの分け方と入力項目・共有ルール
営業会議で誰が何を判断しているかを並べる
管理業務を書き出したら、次は会議ごとに「誰が」「何を判断し」「そのために何の情報を見ているか」を並べます。ツールに求める集計や画面の基準は、この判断に使う情報です。
会議は週次・月次など、開く頻度ごとに分けます。定例の営業会議だけでなく、案件ごとの個別レビューや、営業部門とカスタマーサクセスが顧客の状況をすり合わせる場も含めます。
| 会議 | 判断する人 | 判断すること | 見ている情報 |
|---|---|---|---|
| 週次の営業会議 | 営業マネージャー | 今月受注を見込む案件に手を打つか | 商談段階・受注見込み時期・次の行動 |
| 月次の営業会議 | 営業責任者 | 予実の差を埋める打ち手と担当の割り振り | 予算と見込みの差、商談段階ごとの件数 |
| 案件レビュー | 営業マネージャーと担当者 | 提案内容や条件の提示を進めるか | 顧客とのやり取りの経緯、競合の状況 |
| 部門間の顧客共有 | 営業責任者とカスタマーサクセス責任者 | 契約更新や追加提案の優先順位 | 購買履歴・問い合わせ履歴・更新時期 |
「見ている情報」は、会議の判断に案件寄りの情報と顧客寄りの情報のどちらが多く使われているかを確認する列です。週次・月次の会議で商談段階や予実を見ている組織と、部門間で顧客の履歴を見ている組織では、中心に置く構成が異なるのです。前述した管理業務の書き出しと突き合わせ、会議で使われていない記録と、会議で必要なのにどこにも記録されていない情報にそれぞれ印を付けます。
「見ている情報」には、件数や金額だけでなく、顧客とのやり取りの経緯や問い合わせ内容も含めます。数字で表せない情報も、何を判断するために参照するかが明確なら選定要件になります。件数や金額を集計して判断する会議では、指標の定義と集計単位を先に決めます。指標の選び方を確認したいときは、営業KPIの決め方と、会議での使い方を扱った記事も参考になります。
営業AI・営業DX 営業kpiとは？意味と実務での使い方
書き出した業務を必須と任意に分けて要件にする
書き出した管理業務と会議の判断は、「業務や判断に欠かせない必須要件」と「代替手段があり、あると助かる任意要件」に分けてから、製品比較表の項目にします。デモで新しい機能を見たときも、先に決めた要件に照らして必要性を確認します。新たな制約が分かった場合は、その理由を残して優先順位を見直します。
分けるときは、「この業務をツールで扱えなかった場合、どの会議の判断や日々の業務に支障が出るか」を問います。会議で直接使わない機能でも、顧客対応や入力作業に欠かせず、今の方法では代替できなければ必須要件です。閲覧・編集の権限など、情報システム担当が求める利用条件も別途確認して必須要件に加えます。週次会議で受注見込みを確認するなら、商談段階と受注見込み時期の記録・集計を候補にします。名刺情報の取り込みは、現在の入力方法で必要な情報を無理なく登録できるなら任意とし、担当者の作業量に照らして判断します。
必須要件に使うのは、製品の機能名ではなく業務の言葉です。「予実管理機能」と書く代わりに、「月次の営業会議で、営業責任者が予算と受注見込みの差を担当者別に確認する」と書きます。こうしておくと、製品ごとに機能の呼び名が違っても同じ基準で比べられます。
業務の言葉で書いた要件は、選定の途中で情報システム担当や予算決定者に選んだ理由を説明するときの根拠にもなるのです。この後の手順では、必須要件を満たさない候補を先に外し、残った候補を同じ比較表で確かめます。要件が整っていても導入後に入力が続くとは限らないため、デモや試用では、実際に入力する担当者にも要件と照らして使い勝手を見てもらいます。
会議で判断することは書き出せても、その判断に使う数字は未定という組織もあるものです。見る数字が決まらないまま製品を比べると、比較表の「営業会議で使う集計」の行で、集計機能が必要かどうかを決められません。会議で追う数字を先に固めておきたい場合は、次の資料も手がかりになります。
商談数を13件→28件に変えた、売上目標を因数分解し「見るべき数字」を特定する手順を穴埋め式ワークシートで解説！
＞＞無料で『売上を最短で動かすための営業KPI設計ガイド』をダウンロードする
導入目的別にSFA中心・CRM中心・一体型を選び分ける
導入目的別の選び分け表
導入目的から構成を選ぶ目安は3つです。案件の進捗や予実を会議で確認したいならSFA中心、既存顧客との接点を部門間で共有したいならCRM中心、両方を同じ顧客単位で見たいなら一体型の製品か連携を検討します。
前のセクションで必須に分けた要件を、次の表の「導入目的」の列に当てはめて読みます。「比較前に確認すること」の列には、候補製品を絞り込む前に社内で答えを出しておく問いを並べました。
| 導入目的 | 主に見る情報 | 中心に検討する構成 | 比較前に確認すること |
|---|---|---|---|
| 案件の進捗・予実を営業会議で確認する | 商談段階ごとの件数、受注見込み金額、受注予定月、次の行動の予定日 | SFA中心 | 顧客の基本情報を今どこで管理しているか。既存の顧客台帳を残すか |
| 既存顧客との接点・問い合わせ・購買履歴を部門間で共有する | 先方担当者とのやり取り、問い合わせと対応の内容、購買履歴、契約の更新時期 | CRM中心 | 案件の進捗を誰がどの会議で見ているか。今の案件管理の方法を続けるか |
| 案件と顧客の両方を同じ顧客単位で見る | 顧客ごとの進行中の案件と、過去の接点・購買の履歴 | 一体型の製品、またはSFAとCRMの連携 | すでに使っているシステムがあるか。連携を運用する部門と責任者を決められるか |
どの行を選ぶかの判断基準は、必須の要件が案件の側と顧客の側のどちらに多く並んでいるかです。1つの行に決めきれない場合は、必須の要件ごとに当てはまる行を書き添え、行が分かれるかどうかを見ます。表は構成を選ぶ出発点であり、既存のシステムや部門の分担によっては、別の行を選ぶほうが自社の運用に合う場合もあります。
案件の進捗や予実を会議で確認するならSFA中心
週次・月次の営業会議で、案件がどの商談段階にあり、予算に対していくら受注を見込めるかを確認したい場合は、SFAが検討の中心です。必須の要件が「商談段階ごとの件数」「受注予定月ごとの見込み金額」「予定日を過ぎた案件の一覧」のように案件の単位で書かれているなら、この行に当てはまります。
当てはまりやすいのは、CRMを顧客台帳として使っているものの、商談の進捗やメンバー別の行動が会議で見えないという場面です。顧客の基本情報は整っていても、案件ごとの段階や次の予定が営業担当者の手元の表に残っていると、会議の前に誰かが集計し直すことになります。この場合に足りないのは顧客の記録ではなく案件の記録なので、SFAの役割を中心に比べます。
既存のCRMを残す場合は、SFAの単独導入やCRMとの連携も候補です。顧客の基本情報をSFA側でも入力し直す運用になるなら、二重入力が起きないかを併用の確認項目で確かめます。製品を比べる際は、予実の集計を会議で使う単位（担当者別、チーム別、月別など）で出せるかを、デモの画面で確認します。
既存顧客との接点を部門で共有するならCRM中心
営業、カスタマーサクセス、サポートなど複数の部門が同じ顧客とやり取りしていて、その履歴を共有したい場合は、CRMが検討の中心です。必須の要件が「商談前に直近の問い合わせと対応内容を確認する」「契約の更新時期を部門をまたいで把握する」のように顧客の単位で書かれているなら、この行に当てはまります。
既存顧客への追加提案や契約更新を重視する組織では、案件の進み具合と並んで、顧客とのこれまでのやり取りが会議の判断材料になります。前のセクションの記入例のように、購買履歴は基幹システム、問い合わせの対応履歴は共有メールボックスと記録場所が分かれている場合は、それらの履歴を1か所で参照できるかが比較の中心です。
案件管理をすでに別の仕組みで行っている場合は、その仕組みを残すかどうかを先に決めます。残すなら、CRMに案件の情報をどこまで持たせるかと、どちらの記録を正とするかも確認事項です。営業担当者が初回の問い合わせから商談中のやり取りまで記録・確認したいのか、契約後の既存顧客への対応履歴だけを管理したいのかによっても、比べる製品の範囲が変わります。
同じ顧客単位で両方を見るなら一体型か連携を検討
案件の進捗と顧客との接点の両方を、同じ顧客ごとにまとめて見たい場合は、一体型の製品か、SFAとCRMの連携が検討対象です。「この顧客の進行中の案件と直近の問い合わせを同じ画面で確認し、次の提案を決める」といった要件が必須に入っているなら、この行に当てはまります。
一体型と連携のどちらが合うかを左右するのは、今使っているシステムと運用体制です。SFAかCRMのどちらかがすでに現場で使われているなら、それを残して足りない側を連携させるほうが、入力の方法を大きく変えずに済むことがあります。どちらもこれから整える組織では、連携の設定や運用を担う人を社内に置けるかどうかが判断の分かれ目です。
どちらを選ぶ場合も、同じ顧客や案件の情報を2か所に入力する運用が生まれないか、どちらの記録を正とするかは確かめておきます。自社の既存システムの事情で表のどの行にもきれいに当てはまらない場合も含め、最後の行に近いと判断したら、次のセクションで扱う併用・連携の確認項目に沿って構成を具体的に決めます。
SFAとCRMを併用・連携するかを判断する確認項目
並行運用・連携の前に確かめる4つのポイント
SFAとCRMの併用・連携を決める前に確かめたいのは、次の4点です。同じ情報を二重に入力することにならないか、どちらの情報を正とするか、連携するデータの項目・方向・頻度、それぞれを運用する部門と責任者です。
- 同じ顧客・案件の情報を、SFAとCRMの両方に入力することにならないか
- 顧客名、担当者の連絡先、案件の金額などの情報について、どちらのシステムの記録を正とするか
- 連携するデータの項目、方向（どちらからどちらへ送るか）、頻度
- SFAとCRMをそれぞれ運用する部門と、連携を管理する責任者
4点のうち答えが出ていない項目は、併用開始前の確認事項として残します。たとえば、顧客の電話番号がSFAとCRMで違っていた場合、基準にする記録が未定だと、担当者によって修正先が分かれるおそれがあります。正とする記録と責任者に加え、食い違いを見つけた人が誰へ連絡し、誰が修正するかも決めておきます。
4点は製品の機能ではなく、自社の運用として先に答えを出しておく問いです。連携できるかどうか、その方式や費用は製品と契約によって異なるため、各社の公式資料やデモで確かめる必要があります。4点の答えがそろっていれば、各社の公式資料やデモで製品ごとに確かめる連携の条件を絞り込めます。
同じ情報を二重に入力しない分担と「正」を決める
併用するときに最初に決めるのは、どの情報をどちらのシステムに入力するかの分担です。会社名、所在地、担当者の連絡先といった顧客の基本情報と、商談段階、見込み金額、受注予定月といった案件の情報を並べ、情報ごとに入力する場所を1つに決めます。
分担とあわせて、同じ情報が両方のシステムにある場合にどちらを「正」とするかも決めます。ここでいう「正」とは、内容が食い違ったときに基準にする記録のことです。顧客の基本情報はCRMを正としてSFAには連携で写し、商談段階と見込み金額はSFAを正とする、というように情報ごとに決めて書き分けます。正が決まっていれば、もう一方で誤りを見つけたときも正の側を直す、という修正のルールにできます。
分担を決めるときは、実際に入力する営業担当者の作業も確認対象です。商談のあとにSFAへ活動を記録し、同じ内容をCRMの接点履歴にも書いているなら、同じ情報を二重に入力しています。担当者と一緒に入力する画面と項目を洗い出し、1回の入力で両方に反映できるか、どちらかへの入力をやめられるかを確かめます。
連携するデータの項目・方向・頻度を書き出す
分担と正が決まったら、システムの間で受け渡すデータを項目・方向・頻度の3つで書き出します。項目は、顧客の基本情報、商談段階、受注金額など、連携の対象にする情報です。方向はSFAからCRMへ送るのか、CRMからSFAへ送るのか、両方向でそろえるのかを指し、頻度は入力のたびに反映するのか、1日1回などまとめて反映するのかを指します。
書き出すときは、「項目／送る側／受け取る側／頻度／使う会議や部門」を項目ごとに1行ずつ並べると、抜けや食い違いを見つけやすくなります。受注した案件の金額をCRMの購買履歴に反映したい場合、送る側はSFA、受け取る側はCRMで、頻度は月次の会議に間に合う程度が必要です。両方向で更新する項目は同じ情報を両側から書き換えられるため、前の手順で決めた正と矛盾していないかを確かめます。
商談の会話データも連携対象に含める場合は、送る側・受け取る側・頻度を、書き出した一覧を持ってデモで確認します。どの製品を組み合わせる場合も、連携できる項目・方向・頻度は製品と契約によって異なるため、各社の公式資料やデモでの確認が必要です。
運用部門と責任者が決まらないなら一体型も比べる
4つ目の確認項目である運用部門と責任者が決まらない場合は、併用・連携だけでなく一体型の製品も比較の候補に加えます。連携を続けるには、項目名の変更や連携エラーへの対応、正とする記録の見直しなど、導入後も作業が発生し続けます。担当する人がいないまま併用を始めると食い違いが放置され、会議で使う数字への信頼を損なうおそれがあるためです。
責任者を決めるときは、SFAを使う営業部門、CRMを使うカスタマーサクセスやサポートの部門、システムの設定を担う情報システム担当のうち、誰がどの作業を受け持つかを書き出します。連携の設定変更は情報システム担当、項目の定義と正の見直しは営業企画、というように作業ごとに分ければ、1人に負担が集中しない分担を考えやすくなります。書き出した結果、担当者のいない作業が残るなら、その作業が少なくて済む構成を探す理由です。
一体型を選んでも連携の管理がすべて不要になるとは限らず、既存システムとの接続や部門ごとの権限設定は残ります。併用と一体型の優劣は一律には決まらず、判断の基準は運用に必要な作業と担当者です。どちらを候補に残す場合も、次のセクションで扱う製品比較表に同じ項目で並べて確認します。
製品比較表に入れる項目と確認方法
製品比較表に入れる9つの項目
製品比較表には9つの項目を行として入れます。管理したい業務との対応、入力項目の設定、担当者が入力する手間、営業会議で使う集計、閲覧・編集の権限設定、他システムとの連携方式、データの書き出し、費用の決まり方、導入時の支援範囲です。
| 項目 | 確認すること | 候補A | 候補B | 確認方法 | 確認日 |
|---|---|---|---|---|---|
| 管理したい業務との対応 | 書き出した管理業務と会議での判断に、どの機能で対応するか | 公式資料・デモ | |||
| 入力項目の設定 | 商談段階の選択肢や自社独自の項目を、誰がどこまで追加・変更できるか | 公式資料・デモ | |||
| 担当者が入力する手間 | 商談後の記録に開く画面の数、入力する項目、外出先から入力できるか | デモ・試用 | |||
| 営業会議で使う集計 | 会議で見る件数・金額・予実を、追加の加工なしで表示できるか | デモ | |||
| 閲覧・編集の権限設定 | 担当・部門・役職ごとに、見られる情報と編集できる情報を分けられるか | 公式資料・デモ | |||
| 他システムとの連携方式 | 連携するデータの項目・方向・頻度に対応できるか。標準の機能か個別の設定か | 公式資料・デモ・見積 | |||
| データの書き出し | 案件や顧客の情報をどの形式で書き出せるか。契約終了時に何を持ち出せるか | 公式資料・見積 | |||
| 費用の決まり方 | 利用人数・機能・契約期間のどれで金額が変わるか。初期費用や追加費用の条件 | 見積 | |||
| 導入時の支援範囲 | 初期設定・データ移行・操作説明のうち、提供事業者が受け持つ作業と自社に残る作業 | 見積 |
候補Aと候補Bの欄には、○や×ではなく、確認できた内容をそのまま短く書きます。「商談段階の選択肢を管理者が追加できる」「案件一覧をCSVで書き出せる」のように書いておけば、自社の必須要件を満たすかどうかを後から読み返して判断できます。確認できていない欄は、空欄ではなく「未確認」と記載する対象です。どの方法で埋めるかを確認方法の列に書きます。
9項目の重みは組織ごとに異なるため、前の手順で必須とした要件に関わる行から確認します。SFAの候補を比べる観点を詳しく知りたい場合はSFAを比較するときの選び方を、CRMの候補であればCRMを比較するときに使う判断基準をまとめた記事で、製品の種類に合わせた見方を確かめてください。そのうえで確認した内容をこの表へ書き戻すと、SFAとCRMの候補を同じ行で並べて比べられます。
営業AI・営業DX SFA比較で失敗しない選び方｜営業現場に定着する5つの軸
営業AI・営業DX CRM比較で失敗しない選び方｜営業現場に定着する5つの軸
公式資料・デモ・見積で確認し、確認日を残す
表の各行を確認する方法は、内容に応じて公式資料・デモ・見積です。入力項目の設定、営業会議で使う集計、権限設定など機能に関わる行は、公式資料で当たりをつけてからデモで実際の画面を見ます。費用の決まり方と導入時の支援範囲は、自社の利用人数や必要な設定を伝えたうえで、見積と一緒に回答をもらいます。
確認した内容の横に残すのは、確認日、確認に使った資料、回答者です。製品の仕様や料金は改定されることがあり、数か月前に確認した内容が合意の時点では変わっている可能性があるためです。確認日を残しておけば、社内で合意する前にどの行を確かめ直すかをすぐに判断できます。
公式資料とデモの説明が食い違う場合や、回答が「設定次第」にとどまる場合は、両方の内容を書いたうえで、提供事業者へ追加で確認する行として印を付けます。未確認の欄を推測で埋めると、確認済みの候補と未確認の候補が同じ扱いで並ぶため、比較に偏りが生じるのです。確認できた範囲と未確認の範囲を分けて書いておけば、社内へ説明するときにも、決まっていることと残っている確認を区別して示せます。
入力の手間は実際に入力する担当者が確かめる
9項目のうち「担当者が入力する手間」の行は、管理職がデモを見るだけでは判断しにくい項目です。日々の商談のあとに記録を入れるのは営業担当者であり、画面の数や項目の多さを負担と感じるかどうかは、実際に操作した人でなければ分かりにくいためです。デモの場に入力する担当者を同席させ、試用できる製品であれば担当者に操作してもらいます。試用の有無や条件は製品ごとに異なるため、候補ごとに確認しておきます。
確かめる際の条件は、候補ごとに同じ作業を同じ手順で試すことです。直近の商談を1件選び、活動の記録、商談段階の更新、次の行動の予定日の入力までを行って、開いた画面の数、入力した項目、外出先の端末から入力できるかを書き留めます。同じ商談を使えば、候補による違いを担当者の感想だけでなく、作業の中身として比較表に書けます。
担当者から出た意見の記入先は「担当者が入力する手間」の行です。必須要件に関わる意見は候補を絞る判断にも使います。入力が続くかどうかを左右するのは、製品の操作に加え、入力項目の多さや会議での情報の使われ方です。SFAへの入力が現場に定着しない原因と改善の手順を扱った記事もあわせて確認すると、比較表だけでは見えない運用上の課題を洗い出せます。次のセクションでは、顧客データを預ける前に情報システム担当と確認することを整理します。
営業AI・営業DX SFA入力が定着しない原因とは？改善の優先順位と会議でのデータ活用を解説
顧客データを預ける前に確認すべきセキュリティ項目
閲覧・編集できる人を担当と範囲で限定できるか
顧客データをクラウドのSFAやCRMに預ける前に、最初に確かめるのは、誰がどの範囲のデータを閲覧・編集できるかを限定できるかどうかです。個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン（通則編）」は、個人データを取り扱う情報システムについて、担当者と取り扱う個人情報データベース等の範囲を限定するアクセス制御を、技術的安全管理措置の一つとして挙げています。[1]
【公的資料の要点】
通則編10-6（1）は、担当者と取り扱う範囲を限定するアクセス制御を挙げています（要約）。
これをSFAやCRMに当てはめると、役割ごとに閲覧・編集の範囲を決めることになります。営業担当者は自分が担当する案件と顧客を編集する、営業マネージャーはチーム全体の案件を閲覧する、カスタマーサクセスは既存顧客の問い合わせ履歴を編集する、といった分け方です。前のセクションで作った比較表の「閲覧・編集の権限設定」の行にこの役割と範囲を書き込み、候補製品でそのとおりに設定できるかをデモで確かめます。
権限をどこまで細かく分けるかの判断材料は、部門の構成や扱う顧客情報の種類です。営業部門だけで決めず、情報システム担当と一緒に役割ごとの範囲を書き出してから、比較表に反映します。
参考：個人情報の保護に関する法律についてのガイドライン（通則編）｜個人情報保護委員会
利用する人を識別し、認証できるか
次に確かめるのは、SFAやCRMにログインしている人が正当な権限を持つ本人かどうかを確かめる仕組みです。個人情報保護委員会のガイドライン（通則編）は、技術的安全管理措置として、アクセス制御と並んでアクセス者の識別と認証を挙げています。[1]
【公的資料の要点】
通則編10-6（2）は、アクセス者の識別と認証を挙げています（要約）。
1つのアカウントを複数の営業担当者で使い回す運用では、誰がどの顧客情報を閲覧し、変更したかをたどれないのが問題です。比較表の権限設定の行には、利用者ごとにアカウントを発行するか、社内で使っている認証の方式に合わせるか、退職や異動のときに誰がいつアカウントを止めるかを加え、情報システム担当に確認してもらいます。
ガイドラインが示す識別と認証の手法の例は、事業者の規模によって異なります。自社にどの手法が必要かを、社内の情報セキュリティの規程と照らし合わせて判断するのは、情報システム担当です。営業部門は、候補製品で使える認証の方式を公式資料やデモで集め、その判断の材料として渡します。
参考：個人情報の保護に関する法律についてのガイドライン（通則編）｜個人情報保護委員会
提供事業者が顧客データを取り扱う契約になっているか
「クラウドに顧客データを預けると、提供事業者へ個人データを渡したことになるのか」という疑問は、選定の終盤に情報システム担当や法務担当から出やすい論点です。個人情報保護委員会の「『個人情報の保護に関する法律についてのガイドライン』に関するQ&A」は、クラウドサービスの利用が個人データの提供や委託に当たるかは、サービス提供事業者がその個人データを取り扱うこととなっているかどうかで判断するとしています。[2]
【公的資料の要点】
取り扱わないこととなっている例として、契約条項で取り扱わない旨が定められ、適切にアクセス制御を行っている場合を挙げています（A7-53の要約）。
同じQ&AのA7-54は、提供や委託に当たらない場合でも、クラウドサービスを利用する事業者は自ら適切な安全管理措置を講じる必要があると示しています。[2]クラウドの製品を選んだからといって、社内での対応がいらなくなるわけではありません。前の2つの確認項目で決めた権限の範囲や認証の運用は、利用する側の責任で整えます。
候補製品ごとに確かめるのは、利用規約や契約書が顧客データの扱いをどう定めているか、提供事業者側からのアクセスをどう制限しているかです。これらを比較表の行に加え、個人データの提供に当たるか、当たる場合に委託として扱われるかと、自社に必要な対応を情報システム担当と法務担当に確認してもらいます。その確認結果も、次のセクションで扱う社内合意の説明資料の一部です。
参考：「個人情報の保護に関する法律についてのガイドライン」に関するQ&A｜個人情報保護委員会
候補を絞ってから社内で合意するまでの選定手順
選定は6つの手順で進める
SFAやCRMの選定は、管理業務の棚卸し、要件の優先順位づけ、候補の絞り込み、同じ比較表での確認、入力する担当者によるデモ・試用、情報システム担当と予算決定者との合意、の6つの手順で進めます。
- 管理業務と営業会議で判断することを棚卸しする
- 書き出した業務を必須要件と任意要件に分け、優先順位をつける
- 必須要件を満たさない候補を外し、候補を絞り込む
- 残った候補を同じ比較表で確認する
- 実際に入力する担当者がデモや試用で確かめる
- 情報システム担当・予算決定者と合意する
この順番にするのは、比較の基準を先に固めておくためです。棚卸しと優先順位づけを先に済ませておけば、デモで目を引く機能を見ても、必須要件に戻って候補を比べ直せます。反対に候補を先に集めると、製品ごとの説明に合わせて要件が書き換わり、比較の途中で基準がぶれがちです。
手順1と2では前のセクションで書き出した管理業務と必須・任意の要件を、手順4では製品比較表を、手順6の準備では情報システム担当と確認した権限や契約の内容をそのまま使います。デモや試用の有無と条件は製品ごとに異なるため、手順5で選ぶのは候補ごとに行える方法です。6つの手順は選定の進め方を整えるものであり、導入後に入力が続くかどうかは、運用を始めてからも担当者の声を聞いて確かめます。
必須要件を満たさない候補を先に外す
候補の絞り込みでは、よい製品を探すより先に、必須要件を1つでも満たさない候補を外します。候補が多いままデモを受けると確認に時間がかかるうえ、製品ごとに説明の順番が違うため、比べる条件がそろいません。何社まで絞るかに決まった数はなく、同じ比較表で確認しきれる数を目安にします。
外すかどうかを判断する出発点は、公式資料で確かめられる必須要件です。月次の営業会議で予算と受注見込みの差を担当者別に確認することが必須なら、その集計を表示できない候補を外します。既存顧客の問い合わせ履歴を営業とカスタマーサクセスで共有することが必須なら、部門ごとに閲覧・編集の範囲を分けられない候補を外します。公式資料だけでは判断できない要件は、「未確認」と記載してデモで確かめる対象です。
外した候補は比較表から消さず、どの必須要件を満たさなかったかと確認日を1行で残しておきます。社内の合意の場で「あの製品は検討したのか」と聞かれたときに、外した理由を業務の言葉で答えるためです。任意要件の差は候補を外す理由にせず、残った候補の間で比べるときの判断材料にとどめます。
情報システム担当と予算決定者に同じ比較表で説明する
社内で合意するときは、営業部門が候補の確認に使った比較表をそのまま使い、情報システム担当と予算決定者に同じ表で説明します。相手ごとに別の資料を作ると、確認した内容と説明の内容がずれ、その候補を選んだ理由が伝わりにくくなるためです。表の中で、それぞれが判断する行を示しながら説明を進めます。
情報システム担当には、閲覧・編集の権限設定、他システムとの連携方式、データの書き出しの行と、前のセクションで確認した認証の方式や契約上の顧客データの扱いを示します。予算決定者に示すのは、費用の決まり方と導入時の支援範囲の行です。利用人数・機能・契約期間のどれで金額が変わるのか、自社に残る作業は何かを説明します。どちらにも必須要件と外した候補の理由、各行の確認日を添えておけば、確かめ直す行を相手が自分で見つけられます。
商談の会話データの活用もあわせて検討している場合は、その費用の決まり方も同じ比較表に加える項目です。FAZOMを候補に含めるなら、FAZOMの導入ガイドにある料金の決まり方で、見積の前に整理しておく条件を確かめてから予算決定者への説明に臨みます。
まとめ
SFAとCRMのどちらを導入するか、併用・連携するか、一体型にするかは、ツールの定義から選ぶのではなく、自社で管理したい業務と営業会議で判断していることを書き出して決めます。案件の進捗や予実を会議で確認したいならSFA中心、既存顧客との接点を部門間で共有したいならCRM中心、両方を同じ顧客単位で見たいなら一体型か連携が検討の出発点です。
併用・連携を選ぶ場合は、二重入力が起きないか、どちらの情報を正とするか、連携するデータの項目・方向・頻度、運用する部門と責任者を先に確かめます。候補製品は、管理業務との対応や入力の手間、権限設定、費用の決まり方などを同じ比較表で確認し、確認した方法と確認日を残します。顧客データを預ける前に情報システム担当と確認するのは、閲覧・編集の範囲、利用者の識別と認証、提供事業者が顧客データを取り扱う契約かどうかです。
選定は、棚卸し、優先順位づけ、候補の絞り込み、比較表での確認、入力する担当者によるデモや試用、社内の合意の順に進めます。候補製品の機能や料金を具体的に比べる段階では、SFAやCRMの比較記事で判断基準を確かめながら、自社の比較表を埋めていきます。
比較表の「営業会議で使う集計」の行は、会議で追う数字が決まっていないと埋められません。情報システム担当や予算決定者へ説明する前に、見る数字の定義をそろえておくと話が進めやすくなります。以下のガイドをご活用ください。
商談数を13件→28件に変えた、売上目標を因数分解し「見るべき数字」を特定する手順を穴埋め式ワークシートで解説！
＞＞無料で『売上を最短で動かすための営業KPI設計ガイド』をダウンロードする
