Salesforce導入の推進責任者に指名されたものの、ベンダーとの初回打ち合わせで何を聞かれるのかも見当がつかない——営業10〜20名を率いる営業マネージャーの方から、よく伺うお話です。Excelの営業管理表が限界なのは日々実感している。役員からは「営業のデジタル化」を指示された。それでも、何をいつ決めればよいのかというリストが手元にありません。
同じ判断を迫られている会社は、いま増えています。ITRの調査「ITR Market View: SFA/MA市場2026」によると、SFA(営業支援システム)市場の規模は2024年度に617億円、前年度比14.9%増となりました。2025年度は15.2%増が見込まれ、2024年度から2029年度までの年平均成長率(CAGR)は11.8%と予測されています(国内59ベンダーを対象とした調査)。
(出典:ITR Market View: SFA/MA市場2026)
新規の導入だけでなく、すでに使っている企業の拡張も市場を押し上げているとされています。営業をシステムで管理することは、もはや一部の大企業だけの選択ではありません。
ただし、市場が伸びていることと、自社の導入がうまくいくことは別の話です。導入がうまくいかない原因の多くは、製品の選定ミスではありません。導入を「システムの入れ替え」と捉えたまま進めてしまうことです。実際に入れ替わるのは、ソフトウェアではなく営業の運用そのものです。誰がいつ何を入力し、どの数字で会議をするのか。その設計を決めるのはベンダーではなく、営業を預かっている自分自身です。
この記事では、Salesforceの全体像から、Excel管理から移すと変わること・増えること、導入の5フェーズと各段階の成果物、自社が決めることとベンダーに任せることの線引き、費用の3層構造、そして役員への説明と稟議の通し方までを、営業マネージャーの立場で順に整理します。基本操作や用語の詳細、支援会社の選び方は扱いません。
読み終えたときに、自分の意思決定リストと、役員に示す費用と時間軸が手元に残る状態を目指します。まずは、Salesforceとは何かから確認しましょう。
Salesforce(セールスフォース)は、顧客情報と営業活動の記録を1か所に集めて管理するクラウド型のCRM/SFAプラットフォームです。商談の進捗、顧客とのやり取り、見込み客の情報などを、担当者個人のExcelやメールボックスではなく、組織の共有データとして蓄積します。営業管理のSales Cloud、顧客サポートのService Cloud、マーケティングのAccount Engagementなど、業務ごとに分かれた複数の製品で構成されているのが特徴です。そして導入の本質は、ソフトウェアの入れ替えではなく、営業の運用を作り直すことにあります。
見た目のうえでは、これまで分散していたものが1か所に集まります。各自のExcelの営業管理表、机の上の名刺、個人のメールボックスに残った顧客とのやり取り。これらが1つの画面から辿れるようになる、というのが導入後の姿です。
ただし、この「運用の作り直し」という捉え方が、この記事全体の前提です。Salesforceを入れても、商談の進み具合をどの基準で判断するか、誰がいつ何を入力するか、どの数字で会議をするかが決まっていなければ、画面が新しくなっただけで終わります。
自社の規模で使えるのか、という点も気になるところだと思います。結論から言えば、営業10〜20名の組織で機能が足りないという事態は、まず起きません。つまずくとすれば、道具の性能ではなく、次章以降で扱う「決めること」の側です。
なお、この記事は営業10〜20名規模の中堅企業を前提に書いています。数百名の営業組織を前提とした導入論とは、決めるべきことの粒度も、かけるべき費用も変わります。
ベンダーからの提案書や見積書には、複数の製品名が並びます。まずはその区別からつけていきます。
Salesforceは1つの製品ではなく、業務ごとに分かれた製品群です。見積書に複数の名前が並ぶのはこのためです。営業マネージャーがまず関係するのは、このうちSales Cloudです。
|
製品名 |
担当する業務 |
営業マネージャーとの関係 |
|
Sales Cloud |
営業管理(顧客・商談・活動履歴の記録と可視化、売上予測) |
中心。まずここから検討する |
|
Service Cloud |
顧客サポート(問い合わせ受付、対応履歴、サポート状況の管理) |
サポート部門を持つ場合に検討。営業管理だけなら必須ではない |
|
Account Engagement |
マーケティング(見込み客の獲得・育成、メール配信、Web行動の記録) |
Web問い合わせや展示会名刺を商談につなぐ段階で検討する |
3つを同時に入れる必要はありません。Excel管理からの脱却が目的であれば、まずSales Cloudです。マーケティングとの連携構想がある場合も、営業側の運用が固まってからAccount Engagementを検討するほうが、決めることが混ざらずに済みます。
Account Engagement(旧称Pardot)は、分類としてはMA(マーケティングオートメーション)ツールにあたります。SFAは営業活動の管理、CRMは顧客情報の管理、MAは見込み客の獲得と育成を担う道具で、対象とする顧客の段階が異なります。Salesforceはこの3つの領域にまたがる製品群を持っているため、「SFAツールなのかCRMツールなのか」という問いには、どちらでもあると答えるのが正確です。
製品の区別がつけば、提案書は読めるようになります。あとは、会話に出てくる用語です。
用語は6つ押さえれば、ベンダーとの会話は成立します。調べるたびに新しい言葉が出てきて手が止まる、という状態を避けるために、営業の言葉に訳した対応表を置いておきます。
|
Salesforceの用語 |
営業の言葉でいうと |
Excelでいうと |
|
オブジェクト |
情報の種類ごとの台帳(顧客用、商談用、など) |
シート |
|
レコード |
1件のデータ(A社、A社の◯◯案件、など) |
1行 |
|
項目 |
入力欄(会社名、金額、確度、など) |
列 |
|
リード |
見込み客(まだ商談化していない接点) |
名刺リストの1件 |
|
商談 |
進行中の案件(金額・確度・完了予定日を持つ) |
案件管理表の1行 |
|
活動 |
訪問・電話・メールなどの行動履歴 |
日報や商談メモ |
この6つがわかっていれば、要件定義の打ち合わせで話についていけなくなることはまず起きません。それ以上の用語や、実際の画面での使い方は、稼働が近づいてから覚えれば十分です。
道具の輪郭は見えました。次は、その道具に移すと営業の日常がどう変わるのかです。
Excelから移すと、情報が個人の資産から組織の資産に変わります。案件の状況が見えるようになり、予測の精度が上がり、報告のための作業が仕組みに置き換わります。ただし同時に、入力という新しい習慣と、運用ルールを維持する仕事が確実に増えます。この「増える分」を計画に織り込めるかどうかが、導入の成否を分けます。
|
誰にとって |
変わること |
増えること |
|
現場(営業メンバー) |
案件情報を探す時間が減る。上司への状況報告が減る |
商談後の入力という日々の作業 |
|
マネージャー |
案件の滞留が見える。予測の精度が上がる。報告資料の作成が減る |
入力ルールを作り、守られているかを見て、改定する仕事 |
|
組織 |
情報が担当者個人ではなく組織に蓄積される |
稼働後も続く改善の運用 |
導入のメリットを語る記事は、たいてい左側だけを扱います。しかし右側を知らないまま稼働を迎えると、現場から「聞いていた話と違う」という反応が出て、そこから入力が止まります。両方を先に見ておいてください。
いま起きている不便は、管理のやり方が悪いから起きているのではありません。Excelという道具の構造から来ています。
症状としては、ファイルが重くて開くのに時間がかかる、同時に編集できないので誰かが閉じるのを待つ、最新版がどれかわからなくなる、同じ情報を報告書と管理表に二度入力する、といったところだと思います。関数やマクロを組める方であれば、そのつど工夫で回避してきたはずです。
ただ、工夫では越えられない線が3つあります。ひとつは、データが資産にならないことです。ファイルが分かれ、書式が揃わないまま蓄積された過去の案件情報は、後から見返して傾向を読むことができません。ふたつめは属人化です。案件の背景や次の一手は担当者の頭の中にあり、Excelには結果だけが残ります。担当者が異動・退職すると、情報ごと消えます。みっつめは予測精度の頭打ちです。各自の感覚で書かれた「見込みA/B/C」を足し上げても、精度は上がりようがありません。
私たちが支援の現場で見てきた限り、この3つはExcelの使い方をどれだけ工夫しても解決しません。週次会議の前夜に各自のファイルを1つに手作業でマージしている、という状況が続いているのであれば、それは工夫の限界であって、能力の問題ではありません。
では、道具を変えると何が変わるのか。順に見ていきます。
いちばん大きく変わるのは、「報告のための作業」が減り、数字が常に最新である状態になることです。
案件の見える化から説明します。全員が同じ場所に商談を登録すると、どの案件がどの段階で、いくらで、いつ決まる見込みなのかが一覧で見えるようになります。重要なのは、進んでいる案件よりも止まっている案件が見えることです。3週間動いていない商談、提案までは行ったのに次の予定が入っていない商談。これまでは会議で本人に聞かなければわからなかったことが、画面を開けばわかります。声をかける相手を選べるようになる、という変化です。
予測の精度は、データが溜まるにつれて構造的に上がります。商談の段階ごとの通過率が実績として残るため、「この段階の案件はこれくらいの割合で受注に至る」という自社固有の目安ができます。感覚で置いていた確度が、過去の実績に裏づけられた数字に変わります。
報告業務については、集計と可視化の機能が標準で備わっているため、月次の数字を手作業で集計する必要がなくなります。
私たちが支援の現場で見てきた変化として、いちばん実感されやすいのは会議の性質が変わることです。それまで進捗の確認に使っていた時間が、状況の共有ではなく「どうするか」の相談に充てられるようになります。月曜朝の進捗確認会議が、画面を一緒に見ながらの短い確認に変わり、残りの時間が個別案件の打ち手の議論に移る。この変化は、営業10〜20名規模でもはっきり出ます。
ただし、これらはすべて「入力されていれば」の話です。裏返しを見ておきます。
Salesforceは、入力されて初めて機能する道具です。ここが、入れれば動く会計システムや勤怠システムとの決定的な違いです。したがって、確実に増える仕事があります。
現場に増えるのは、日々の入力です。商談が終わったら、その日のうちに結果と次のアクションを登録する。1件あたり5分だとしても、営業15名がそれぞれ毎日行えば、組織全体では相応の時間になります(この5分という数字は説明のための仮の値です)。これまで自分の手帳とExcelで完結していた記録を、組織のために書く作業に変えるわけですから、現場から見れば純粋に増える負担です。ここを「効率化のためだから」と押し切ると、稼働直後に必ず反発が出ます。
マネージャーに増えるのは、ルールを作り、守られているかを見て、必要なら改めるという仕事です。何を必須入力にするか、商談をいつ「受注」に動かすか、入力されていない案件をどう扱うか。こうしたルールは一度決めて終わりではなく、運用してみて実態と合わなければ直す必要があります。この仕事は、導入プロジェクトが終わっても続きます。
大切なのは、増える分を上回る回収を計画の中で設計しておくことです。「入力に時間を使ってもらう代わりに、報告と情報探しの時間を減らす」「1年目は入力の定着に集中し、予測精度の活用は2年目から」といった具合に、増える分と減る分をセットで見立てておく。これができていれば、現場にも役員にも説明ができます。
そのためには、導入の工程全体がどうなっているかを知っておく必要があります。
導入は、要件定義・環境構築・データ移行・トレーニング・稼働の5つのフェーズで進みます。マネージャーの仕事は作業を手伝うことではなく、各フェーズで何ができあがったかを確認することです。工程名だけを追っていると、何が終われば次に進んでよいのかがわからなくなります。
|
フェーズ |
やること |
できあがる成果物 |
マネージャーの関与 |
|
1. 要件定義 |
今の営業の運用を言語化し、管理する情報とルールを決める |
要件定義書(商談フェーズの定義・管理項目一覧・入力ルール) |
主役。決めるのは自社 |
|
2. 環境構築 |
要件に沿って画面・項目・権限を設定する |
設定済みの環境と設計書 |
確認役。要件どおりかを見る |
|
3. データ移行 |
Excelの既存データを移す |
移行後のデータと、移行対象の判断記録 |
何を持ち込み何を捨てるかを決める |
|
4. トレーニング |
現場が使える状態にする |
操作手順書・入力ルールの説明資料 |
キックオフの説明は自分が行う |
|
5. 稼働 |
実運用を開始する |
稼働判定の記録・運用体制 |
稼働判定の基準を事前に決める |
期間は、規模と要件によって大きく変わります。項目数を絞って標準機能の範囲に収めれば短く済み、既存システムとの連携や独自開発が入れば長くなります。「Salesforce導入は何か月」と一律に示せる公的な調査データは見当たらないため、この記事では確定的な数字を置きません。私たちが支援の現場で見てきた範囲では、全体で数か月を見ておくのが無理のない計画です。そのうえで、初回打ち合わせでベンダーに自社要件での見積もりを出してもらってください。このときフェーズごとの工数の内訳まで示してもらうと、複数社の見積もりを比べるときにも使えます。
以下、各フェーズで読者が具体的に何をするのかを見ていきます。
導入の成否の大半は、この最初のフェーズで決まります。ここだけは、ベンダーに丸投げできません。
要件定義でやるのは、いま自分たちがどう営業しているかを言葉にする作業です。具体的には、商談の段階をどう区切るか(初回接触・提案・見積提示・最終交渉、など)、それぞれの段階に入る条件と出る条件は何か、案件について何を記録しておきたいのかを決めます。「見込みA/B/C」という感覚で回してきた運用を、「この条件を満たしたらこの段階」という定義に置き換える作業だと考えてください。
この作業が重要なのは、後の工程がすべてここに従うからです。画面に並ぶ入力欄も、会議で見るレポートも、要件定義で決めた内容から自動的に決まります。ここが曖昧なまま構築に進むと、稼働してから「この項目は要らなかった」「この数字が取れない」という手戻りが発生します。
もうひとつ、この段階でやっておくべきことがあります。情シスとマーケティング担当を巻き込むことです。情シスは既存システムとの連携やセキュリティ要件で実質的な拒否権を持っています。マーケティング担当は、Webからの問い合わせや展示会の名刺をどう営業に渡すかの当事者です。どちらも、構築が始まってから呼ぶと要件のやり直しになります。キックオフの前に一度話をしておいてください。
定義が固まれば、いよいよ環境ができていきます。
環境構築はベンダーの領分です。ただし、データ移行で「何を持ち込み、何を捨てるか」は自社にしか決められません。
構築フェーズでは、要件定義で決めた内容に沿って、画面の項目、入力の必須設定、権限、レポートの雛形などが作られていきます。ここは技術的な作業なので、任せて問題ありません。マネージャーがやるのは、できあがった環境が要件どおりかを実際に触って確認することです。この確認を飛ばすと、稼働直前に「思っていた画面と違う」という事態になります。
判断が必要なのはデータ移行です。長年のExcelには、進行中の案件、決着済みの案件、連絡が途絶えた見込み客、退職した担当者の名刺情報などが混ざっています。これを全部持ち込むと、稼働直後の画面が古い情報で埋まります。検索しても目当ての顧客が出てこない、担当者名が現任者と違う、という状態は、現場が「使えないシステムだ」と判断するには十分な理由になります。
3年前の失注案件を持ち込むかどうか、といった判断は、営業の実務を知っている人にしかできません。基準としては、「今後1年のうちに営業活動の対象になりうるか」で線を引くとぶれにくくなります。過去の分析に使いたいデータがあれば、別途Excelで保管しておけば足ります。
環境と情報が整ったら、次は人の準備です。
トレーニングは操作説明から始めるのではなく、「なぜやるのか」の説明から始めてください。
新しい仕組みが入るとき、現場が最初に気にするのは操作方法ではありません。キックオフの場では、これは行動を監視するための仕組みではなく案件を前に進めるために全員で使う道具である、という位置づけを、最初に自分の言葉で伝えてください。
稼働の判定基準も、事前に決めておく必要があります。「全員が操作できる」だけでは不十分で、たとえば進行中の案件がすべて登録されている、必須項目が埋まっている、といった状態を基準として決めておきます。基準がないまま日程だけで稼働すると、Excelとの二重管理が続きます。
書籍やサイトによっては、導入の終わりを稼働と定義していることもありますが、使われる状態を作る仕事はここから始まります。
工程の全体像は見えました。ここからが、この記事の本題です。各フェーズで、何を自分が決めなければならないのか。
原則はひとつです。業務の意思決定は自社、技術の実装はベンダー。この線引きを最初に持っておくことが、「言われるまま設定して、あとで直せなくなる」を防ぐ最大の防御になります。
ベンダーは技術のプロですが、自社の営業がどう動いているかは知りません。逆に、営業を預かる側は営業のプロですが、Salesforceの設定方法は知りません。したがって、業務のルールに関わることは自社が決め、それをどう実現するかはベンダーが決める、という分担になります。この当たり前の分担が崩れるのは、自社側が「何を決めるべきか」を知らないまま打ち合わせに臨んだときです。
私たちが支援の現場で見てきた限り、導入がうまく進む会社とそうでない会社の差は、この線引きを最初から持っていたかどうかにほぼ集約されます。以下に、決めるべき項目を並べます。
自社にしか決められないのは、業務のルールに関わる7項目です。フェーズ番号は前章の工程表と対応しています。
|
フェーズ |
自社が決めること |
ベンダーに任せてよいこと |
|
1. 要件定義 |
商談フェーズの定義(段階の区切りと、入る条件・出る条件) |
定義を画面上でどう表現するか |
|
1. 要件定義 |
管理項目(何を記録するか。まずは絞る) |
項目の型・入力形式・自動計算の実装 |
|
1. 要件定義 |
入力ルール(誰が、いつまでに、どこまで入れるか) |
必須設定・入力チェックの実装 |
|
1. 要件定義 |
レポート要件(会議で何の数字を見るか) |
レポート・ダッシュボードの作成 |
|
3. データ移行 |
移行データの取捨(何を持ち込み、何を捨てるか) |
移行作業と、データの変換・重複整理 |
|
4. トレーニング |
運用責任者(稼働後にルールを見て直す担当) |
操作研修の実施と手順書の作成 |
|
5. 稼働 |
稼働判定の基準(何が満たされたら本稼働とするか) |
稼働に向けた環境の最終確認 |
7項目のうち4つが要件定義に集中していることに注目してください。プロジェクトの序盤に判断が集中するので、キックオフ前から考え始めておくと余裕を持って進められます。
補足を1点だけ加えます。管理項目は、最初は絞ってください。あれもこれも記録したいと考えて数十個の項目を並べると、現場は入力しきれず、結局どの項目も埋まらないという状態になります。まずは会議で実際に見る数字と、案件を前に進めるために必要な情報に限定し、足りなければ稼働後に足す。項目は後から増やせますが、一度「入力しない習慣」がつくと元に戻すのは大変です。
では、任せる側については何を気にすればよいのでしょうか。
技術の実装は任せて構いません。ただし、「なぜその設計にしたのか」を書き残してもらうことだけは、譲らないでください。
設定作業、既存システムとの連携、権限設計、データ移行の実作業といった技術領域は、専門家に任せるほうが速く、確実です。その中身を細かく理解する必要はありませんし、理解しようとして時間を使うのは得策でもありません。
唯一の条件が、設計の根拠を残してもらうことです。「この項目は、月次の予実管理で使うために設けた」「この自動処理は、二重入力を避けるために入れた」といった意図が文書として残っていれば、後から運用を変えたいときに、どこを触ればよいかが判断できます。導入時の設計をどう残したかが、その後何年にもわたって効いてきます。
逆に、根拠が残っていない環境は、担当者が代わった時点で誰も触れなくなります。「なぜこの項目があるのかわからないが、消すのが怖いのでそのまま」という状態は、実際によく見かけます。契約や打ち合わせの段階で、設計書と設定の意図を成果物として明記してもらってください。
反対に、決めるべきことを決めないまま進むと何が起きるのか。先に見ておきます。
失敗する会社の共通点は、製品選定を誤ったことではありません。決めるべきことを決めないまま構築が始まったことです。私たちが支援の現場で見てきた範囲では、次の4つのパターンに集約されます。
いずれも、構築が始まる前の意思決定で防げるものです。逆に言えば、稼働してから気づいても、修正には相応の手間がかかります。
決めるべきことの中には、金額も含まれます。次は費用です。
Salesforceの費用は、ライセンス・初期構築・運用の3層で積み上がります。月額のライセンス料金だけを見て稟議を書くと、後から必ず不足します。
「1ユーザーあたり月額◯円」という表示は、3層のうち1層目の金額です。実際には、導入時に一度だけかかる構築費用と、稼働後に継続してかかる運用費用が加わります。役員に説明する立場としては、この3つを分けて積み上げ、初年度と2年目以降で金額の形が変わることまで示せると、話が早く進みます。
以下、1層ずつ確認していきます。
ライセンス費用は、エディション×ユーザー数×利用期間で決まります。
Salesforceには機能の範囲に応じた複数のエディションがあり、上位のものほど1ユーザーあたりの単価が上がります。ここで押さえておくべきなのは、機能の細かい差ではなく、「エディションによって単価が変わる」という構造があることです。どのエディションが必要かは、要件定義で決めた管理項目やレポート要件から逆算して判断できるので、順番としては要件が先、エディション選定が後になります。
積算の考え方はシンプルです。営業メンバーの人数に、マネージャーと管理者を加えたユーザー数を出し、単価を掛け、12か月分にします。営業15名の組織であれば、マネージャーと管理担当を含めて16〜18ライセンスといったところが出発点です。全員に同じエディションを割り当てる必要はなく、閲覧が中心の役員には別の形を検討する余地もあります。
単価は改定されることがあるため、この記事では具体的な金額を記載しません。稟議に載せる数字は、必ず公式の価格ページで最新の表記を確認し、確認した日付を添えて使ってください。
ライセンスの外側に、もう1層あります。
初期構築費用は「作業料」ではなく、要件定義・設計・設定・データ移行・トレーニングという工程に対して払う費用です。
見積書に「構築費用」と一式で書かれていると、何に対する金額なのかが判断できません。前章の5フェーズの工程表と突き合わせて、どの工程にどれだけの工数が乗っているかを確認してください。要件定義の工数が極端に薄い見積もりであれば、実質的に「決めるのは自社側で」という前提になっている可能性があります。逆に、こちらで決めるべき項目まで含まれているなら、その分は自社でやると伝えて削れます。
なお、外部の支援会社に導入や活用の伴走を依頼する場合、その支援費用はライセンスや構築費用とは別に発生します。支援会社をどう選ぶかは、導入体制の設計という観点から別記事で整理しています。
中堅BtoB企業のSalesforce導入体制ガイドはこちら
そして、稼働してからも費用は続きます。
稼働後にかかり続けるのは、保守費用、改善のための費用、そして社内の管理者の工数です。
保守は、障害対応や問い合わせ窓口として契約するものです。改善費用は、運用してみて出てきた「この項目を足したい」「このレポートを変えたい」に対応するための予算枠を指します。この枠を持っていないと、稼働後に出てきた小さな不満が放置され、それが「使いにくいシステム」という評価に変わっていきます。
見落とされやすいのが社内工数です。項目の追加やユーザー管理、入力状況の確認といった作業を誰かが担当します。この工数は請求書に載らないため見えにくいのですが、実際には人件費です。役員に説明する際は、金額として計上しなくても「誰が何時間くらい持つのか」は明示しておくほうが、後の議論が楽になります。
これらを合わせて、3年総額(TCO)で見る習慣をつけてください。初年度は構築費用で膨らみ、2年目以降はライセンスと運用費が続く、という形になります。初年度の金額だけを提示すると「思ったより高い」という反応になりやすく、3年で均して見せると投資としての判断がしやすくなります。費用の面からも「導入して終わり」ではないことを共有できる、という効果もあります。
総額が見えたら、次は「いつ回収できるのか」への答えです。
効果は、報告の効率化 → 案件の見える化 → 予測精度 → マーケティング連携という順で、段階的に出ます。この時間軸を先に示すことが、「いつ効果が出るのか」という役員の問いへの最良の答えになります。
「導入すれば売上が上がります」と答えると、翌期の数字で判断されてしまいます。そうではなく、何がいつ良くなるのかを分けて説明し、最初の報告で見る指標まで合意しておく。そのほうが、途中で止まるリスクを下げられます。
効果には、すぐ出るものと、データが溜まって初めて出るものがあります。
短期に出るのは、報告工数の削減と案件の見える化です。全員が同じ場所に登録し始めれば、集計作業はその時点でなくなります。滞留している案件も、登録された翌週から見えます。ここは仕組みが動けば出る効果なので、稼働直後から実感できます。
中期に出るのが、売上予測の精度です。これは自社の実績データが蓄積されて初めて意味を持つため、時間がかかります。商談の段階ごとの通過率が実績として何件分か溜まるまでは、予測はまだ感覚の延長です。
長期の効果が、マーケティングとの連携です。Webからの問い合わせや展示会の名刺が、どれだけ商談になり、どれだけ受注に至ったか。この歩留まりが見えるようになると、マーケティング投資の判断が変わります。ただしここまで来るには、営業側の入力が安定していることが前提になります。
時期の目安は、私たちが支援の現場で見てきた範囲では、報告の効率化が稼働から数か月、予測精度が半年から1年、マーケ連携はその先です。ただしこれは自社の観察にもとづく見立てであって、公的な調査で裏づけられた数字ではありません。入力の定着具合と商談件数によって動くため、稟議に断定して書かないでください。役員に説明する際も、「◯か月で効果が出ます」ではなく「この順番で出るので、最初の報告は報告工数と登録率で行います」と伝えるほうが、後で説明に困りません。
この時間軸を、そのまま稟議に変換します。
稟議は、費用の3層×効果の時間軸×市場の裏づけの3点セットで組みます。この順に並べるだけで、決裁者が知りたいことはほぼ埋まります。
|
稟議の構成 |
書く内容 |
材料の出どころ |
|
1. 目的 |
Excel管理では解決しない課題(属人化・予測精度・報告工数)と、何を変えるのか |
この記事の前半 |
|
2. 費用 |
ライセンス・初期構築・運用の3層。初年度と3年総額の両方 |
費用の章 |
|
3. 効果 |
短期・中期・長期の順番と、最初の報告で見る指標 |
効果の時間軸 |
|
4. リスクと回避策 |
使われないリスクと、それに対して何を決めてあるか(意思決定リスト) |
意思決定リストと失敗パターン |
最後に、環境の裏づけを1行添えておくと通りやすくなります。日本情報システム・ユーザー協会(JUAS)の「企業IT動向調査2026」によると、2025年度にIT予算を増額する企業は52.6%と半数を超え、予算の増減を示すDI値は43.3ポイントと5年連続で上昇しました(東証上場企業およびそれに準じる企業4,500社を対象に2025年9月6日から10月22日にかけて実施、有効回答957社)。IT投資に前向きな企業が多数を占める環境にあるということです。冒頭で触れたSFA市場の成長も、「他社もやっている」という材料として添えられます。
ただし、環境が追い風であることは、説明責任が軽くなることを意味しません。むしろ投資枠があるからこそ、「何にいくら」の説明が求められます。数字を出し切ることが、いちばん確実な通し方です。
数字が揃ったら、あとは想定問答です。
想定問答を準備しておけば、稟議は「説得」の場ではなく「確認」の場になります。よく出る質問と、答えの方向性を並べます。
|
質問 |
答えの方向性 |
|
Excelのままではだめなのか |
不便の話ではなく、データが資産にならない・属人化する・予測精度が構造的に頭打ちになるという3点で答える。工夫では越えられない線であることを示す |
|
いつ元が取れるのか |
効果の順番で答える。短期は報告工数、中期は予測精度、長期はマーケ連携。最初の報告で何を見るかまで先に合意しておく |
|
使われなかったらどうするのか |
稼働後の定着をどう設計するかで決まる、と答える。あわせて、意思決定リストで何を決めてあるかを示す |
|
(情シスから)既存システムとの連携やセキュリティは |
要件定義の段階で情シスに同席してもらう前提で答える。連携範囲と権限設計は要件に含める |
3つ目の質問は、その場で答えを長くしないほうが賢明です。「稼働後の運用で決まるので、そこは別途計画を用意します」と伝え、稟議の論点を導入の可否に戻してください。
4つ目については、質問される前に情シスを巻き込んでおくのが最善の対策です。稟議の場で初めて情シスが内容を知る、という進め方は避けてください。
ここまでで、決めるべきことと、社内で説明すべきことは揃いました。
Salesforceは業務ごとに分かれた製品群で、営業管理の中心になるのはSales Cloudです。Excelから移すと、案件の見える化・予測精度・報告の自動化という変化が起きる一方で、入力の習慣と運用ルールを維持する仕事が増えます。導入は要件定義から稼働までの5フェーズで進み、各段階に確認すべき成果物があります。そのなかで自社にしか決められないのは、商談フェーズの定義から稼働判定の基準までの7項目です。費用はライセンス・初期構築・運用の3層で積み上がり、3年総額で見ます。効果は報告の効率化から順に段階的に出ます。
最初の一歩は、意思決定リストを自社の言葉で埋めることです。7項目を紙に書き出し、いま答えられるものと答えられないものを分けてください。答えられない項目が、ベンダーとの初回打ち合わせまでに決めるべきことです。この作業に、システムの知識は要りません。唯一の条件は営業の実務を知っていることで、それはすでにお持ちのはずです。
決めるべきことを決め切れば、導入は進みます。逆に、そこが空白のまま構築が始まると、どれだけ高機能な環境を作ってもうまくいきません。機能ではなく意思決定が成否を分ける、というのはそういう意味です。
KPIツリーとは?営業畑の役員を納得させるBtoB数値計画の立て方・作成手順はこちら
意思決定リストの7項目は、この記事のとおりです。ただし、自社の営業でフェーズをどう区切るか、管理項目をどこまで絞るか、移行データのどこで線を引くかは、いまの運用を見なければ決められません。そしてこの種の抜け漏れは、自分では気づきにくいものです。
ビズブーストでは、Salesforceの導入支援と、その後の活用・定着化の伴走支援を行っています。30分の無料オンライン相談では、この記事の意思決定リストをそのままお持ちいただき、貴社の営業体制と現在のExcel運用に照らして「どこが決まっていて、どこが決まっていないか」を一緒に点検します。発注のご相談ではなく、ベンダーとの打ち合わせに臨む前の判断の壁打ちとしてご利用ください。