▼ この記事の内容
IT営業は、顧客の仕事で起きている問題を捉え、ITで対応できる範囲と条件を整理し、導入の判断から利用開始までをつなぐ仕事です。扱う商材が月額制のサービスか、個別に開発するシステムか、機器やネットワークかによって、確認事項と担当範囲が変わります。この記事では、IT営業の具体的な仕事内容と、商談を次に進めてよいかを判断する基準を整理します。営業マネージャー・営業企画が、自社の役割分担や育成方法を見直すための手順も紹介します。
IT営業は何する仕事？顧客の業務と技術をつなぎ、導入判断を支える
IT営業の中心的な仕事は、顧客の業務上の困りごとを、実現可能な提案に変えることです。製品を説明して見積書を出すだけではありません。誰がどの仕事で困っているのか、何を変えたいのか、導入するためにどのような条件を満たす必要があるのかを整理します。そのうえで、顧客と自社の技術担当が同じ前提で判断できるように調整します。
例えば、顧客から営業情報を一元管理したいと相談された場合、管理機能の紹介から始めると、必要な提案を見誤ることがあります。商談の記録が残らないのか、記録はあるが会議で使えないのか、担当者が変わると経緯が分からなくなるのか。表面的には同じ相談でも、解決したい問題によって、必要な機能や運用方法が異なるためです。
営業が整理するのは、課題・実現条件・判断の進め方
IT営業が商談で明らかにする内容は、大きく三つに分けられます。一つ目は顧客の現状と変えたい状態、二つ目は技術面・運用面の条件、三つ目は社内で導入を判断するための進め方です。どれかが抜けると、製品の評価は良くても契約や利用開始まで進まないことがあります。
| 整理する内容 | 具体的に確かめること | 整理できていないと起きること |
|---|---|---|
| 顧客の現状と変えたい状態 | 誰の、どの作業で、何が起きているか。導入後にどう変えたいか | 便利そうという評価にとどまり、導入する理由が定まらない |
| 実現するための条件 | 必要な機能、既存システムとの関係、データ、権限、利用体制 | 提案後に制約が見つかり、費用や計画の見直しが必要になる |
| 導入判断の進め方 | 利用部門、管理部門、判断する人、確認事項、判断の時期 | 担当者は賛成していても、社内の確認が進まない |
営業マネージャーが確認したいのは、担当者が多くの情報を集めているかだけではありません。その情報によって、顧客が次に何を判断できる状態になったかです。面談回数が増えていても、導入目的や確認事項が曖昧なままなら、商談が進んでいるとは判断しにくくなります。
営業が全部を担当するとは限らない
顧客の開拓、初回商談、提案、契約、導入支援、継続利用の支援を一人で担当する会社もあれば、分業する会社もあります。インサイドセールスは電話やオンラインで接点をつくり商談化する担当、カスタマーサクセスは導入後の活用や成果を支援する担当です。ただし、呼び方が同じでも、具体的な責任範囲は会社によって異なります。
そのため、IT営業の仕事を決めるときは、職種名だけで区切らないことが大切です。例えば、契約後の初期設定を別部門が担当するとしても、営業には、商談で合意した利用目的や導入条件を引き継ぐ役割があります。顧客との約束がどの担当につながるのかまで決めると、対応の抜けを見つけやすくなります。
職種としての全体像や、顧客業務と技術をつなぐための知識を整理したい場合は、IT営業とは？商材や仕事内容を解説｜顧客業務と技術をつなぐ知識、提案の準備順も参照できます。
商材によって、IT営業が確認することと提案の進め方は変わる
IT営業の仕事内容を一律に決めると、自社の商材に必要な確認が抜けることがあります。既存のサービスを提供するのか、顧客に合わせて開発するのか、機器や運用を含めて提供するのかで、営業が早い段階で把握すべき条件が変わるためです。まずは自社が何を、どの範囲まで提供しているかを整理します。
SaaSなどの既存サービスは、機能と業務の適合を確かめる
SaaSは、インターネットを通じて利用するソフトウェアサービスです。既存の機能を顧客の業務にどう当てはめるかが、提案の重要な部分になります。営業は、必要な機能の有無に加えて、利用人数、権限、既存データの取り込み、他のサービスとの連携、契約条件などを確認します。
ここでは、顧客の今のやり方をすべて再現できるかだけで判断しないことが大切です。顧客が運用を変えられる部分と、業務上変えられない部分を分けます。例えば、社内の入力項目は整理できても、取引先への提出様式は変えられない場合があります。その違いを確認しないと、標準機能で対応できるという説明が、現場の仕事と合わなくなります。
無料体験や試用を行う場合も、触ってもらうだけでは判断材料がそろいません。どの業務を試し、誰が使い、何が確認できたら導入を検討できるのかを先に決めます。試用後には、操作できたかと、実際の仕事に使えるかを分けて確かめます。
個別開発は、作る範囲と決め方を整理する
顧客ごとにシステムを開発する場合、営業は要望を開発担当へ渡すだけでは足りません。対象となる業務、利用者、必要な機能、他のシステムとの関係、納期の理由を確認し、どこまでを今回の対象にするかを整理します。要望が途中で変わった場合に、費用や日程をどう見直すかも関係します。
初回商談の段階では、開発費用や完成時期を確定できないことがあります。その場合は、現時点の見通しと、詳しい確認後に決める事項を分けて伝えます。技術担当による調査や要件整理が必要なら、その作業の内容、費用の扱い、顧客に協力してもらう範囲を明らかにしてから進めます。
機器・ネットワーク・運用サービスは、利用環境と責任範囲を確かめる
機器やネットワーク、システムの運用を扱う営業では、導入先の環境が提案を左右します。拠点、設置場所、利用人数、既存機器、保守契約、作業可能な時間帯などの確認が必要です。機器そのものの性能が適していても、設置や切り替えの条件が合わなければ、そのまま導入できないためです。
運用サービスでは、障害が起きた際の連絡先、対応時間、作業範囲、顧客側に残る管理業務なども確認します。営業が曖昧なまま対応できると伝えると、契約後の期待と提供範囲にずれが生じます。商品説明とあわせて、何を誰が担当する契約なのかを理解することが重要です。
自社の提案方針を比べるための判断表
次の表は、営業が提案の方向を選ぶための比較です。実際には、既存サービスと個別開発を組み合わせることもあります。最初から商材に当てはめるのではなく、顧客が変えたい業務と、変えられない条件を基準に比べてください。
| 提案の選択肢 | 向いている場合 | 向かない場合 | 確かめる点 |
|---|---|---|---|
| 既存サービスを使う | 必要な業務を既存機能で扱え、運用も合わせられる | 変更できない業務条件を既存機能で満たせない | 必要機能、権限、連携、データ移行、契約条件 |
| 個別にシステムを開発する | 固有の業務要件があり、仕様を決める体制を用意できる | 対象業務や要望が定まらず、判断する担当も決まっていない | 開発範囲、要件の決定者、変更時の扱い、保守体制 |
| 機器やネットワークを更新する | 利用環境や設備の制約が、業務上の問題に関係している | 問題の中心が業務ルールにあり、設備更新では改善しにくい | 現行構成、設置条件、切り替え方法、停止の影響 |
| 運用を外部に委ねる | 依頼したい作業を定義でき、社内の管理負担を見直したい | 作業範囲や責任分担を整理できず、委託先に判断を任せきりになる | 対応範囲、受付時間、連絡方法、顧客側に残る責任 |
| 先に業務運用を見直す | 問題の原因が入力ルールや担当分担にあり、現在の仕組みでも対応できる余地がある | 現行の仕組みでは満たせない機能や容量が必要 | 今の仕組みで可能な対応、残る制約、再検討する条件 |
提案を見送る判断も、営業の仕事に含まれます。現時点で自社の商材が合わない場合は、不足する条件や対応できない範囲を具体的に伝えます。どの条件が変われば再検討できるかまで整理しておくと、顧客も社内で判断しやすくなります。
新規開拓から導入後まで、IT営業が行う具体的な仕事
IT営業の活動は、顧客との接点をつくるところから始まり、課題の確認、提案、契約、導入へとつながります。ただし、すべての案件が同じ順番で進むわけではありません。既に導入条件が決まっている相談もあれば、何を変えるべきかから一緒に整理する相談もあります。相手がどこまで決めているかを確かめ、必要な確認から進めます。
新規開拓：話を聞く理由がある企業と接点をつくる
新規開拓では、自社の商材が役立つ可能性のある企業や部門を選びます。業種や従業員規模だけでなく、対象業務の有無、拠点の構成、既存の仕組み、事業上の変化など、提案との関係がある情報を確認します。公開情報から分かることと、実際に話を聞かなければ分からないことを分けておくと、初回の会話を組み立てやすくなります。
接点づくりでは、自社製品の特徴を並べるより、どの業務について話したいかを伝えます。ただし、公開情報だけで相手の課題を断定してはいけません。複数拠点の情報共有について、現在どのように運用しているかを確認したい、といった形で、仮説を質問に変えることが必要です。
対象企業の選び方から整理する場合は、IT営業の新規開拓を進める方法｜対象企業の選び方から初回商談と改善の手順も参照できます。
初回商談：相談の背景を、具体的な業務まで掘り下げる
初回商談では、問い合わせのきっかけだけでなく、実際に起きていることを確かめます。業務を効率化したいという話なら、誰が、いつ、どの情報を使い、何の作業をしているのかまで聞きます。処理に時間がかかるのか、確認の往復が多いのか、入力内容が不正確なのかによって、必要な対応が変わります。
現状を聞いた後は、顧客がどうなれば改善したと判断するかを確認します。数値が分かる場合はその根拠も確かめますが、把握していない数字をその場で無理に出してもらう必要はありません。まずは、会議前の転記が不要になる、担当交代時に履歴を確認できるなど、業務の変化として言葉にします。
- 今の仕事の流れと、問題が起きる場面を確認する
- その問題で困る人と、他の業務への影響を確かめる
- これまで試した対応と、解消できなかった理由を聞く
- 変更できない業務条件と、見直せる運用を分ける
- 導入を判断するために、次に確かめたいことを合意する
提案・実演：顧客の業務に沿って、できることを示す
提案書では、製品の説明に加えて、対象とする問題、提案する対応、期待する業務の変化、実施条件をつなげます。例えば、報告内容の転記が問題であれば、入力した情報をどの画面で確認でき、誰の作業がどう変わるかを示します。利用者に新たな入力が必要なら、その負担も含めて説明します。
実演では、確認したい業務の流れを先に共有します。画面を順番に見せるだけでは、顧客が自分の仕事に当てはめにくいためです。必要な操作を示した後に、実際の運用と合うか、例外的な処理があるかを確かめます。実演できなかった機能や未確認の連携は、その場で対応可能と扱わず、確認事項として残します。
見積もり・契約：費用と提供範囲の前提をそろえる
見積もりでは、金額だけでなく、何が含まれ、何が別途対応になるかを示します。初期設定、データ移行、利用者への説明、追加開発、保守などの扱いが曖昧だと、顧客は総額や社内負担を判断しにくくなります。利用人数や対象拠点など、金額の前提が変わる条件も確認します。
契約に向けては、利用部門の評価と、情報システム部門・購買部門などの確認を分けて把握します。担当者が使いたいと言っていても、必要な審査や手続きが残っていることがあります。営業は、誰に何を確認してもらう必要があるかを顧客と整理し、自社側で回答する担当につなぎます。
導入・継続利用：商談で合意した内容を、実際の運用へつなぐ
契約後は、導入担当に顧客名と契約内容を渡すだけで終わらせません。導入目的、対象業務、関係者、確認済みの制約、未解決事項、営業が伝えた内容を引き継ぎます。顧客が契約を決めた理由を共有できていないと、設定作業は完了しても、期待していた使い方につながらないことがあります。
営業が導入後も担当する場合は、利用状況と困りごとを確認し、必要に応じて支援担当や技術担当へつなぎます。追加提案は、新たな業務上の必要が確認できてから検討します。使い方が定まらない状態で機能や利用範囲だけを増やすと、顧客の負担が大きくなる可能性があります。
自社のIT営業に当てはめて、次に進むかを判断する手順
仕事内容を理解した後は、自社の商談で何を確認できれば次に進めるのかを決めます。営業活動を、面談をした、資料を送ったという実施記録だけで管理すると、顧客が判断できる状態になったかが見えません。自社の提供範囲と顧客側の確認状況を照らし合わせて進めます。
手順1：自社が提供する範囲を言葉にする
まず、自社が提供するものを、契約上の範囲と実際の作業に分けて確認します。サービスの利用権だけなのか、初期設定も含むのか、顧客ごとの開発や運用まで担うのかを整理します。営業、技術、導入支援の説明が食い違う部分があれば、顧客に提案する前にそろえます。
次に進めるのは、標準で提供すること、条件付きで対応すること、対応しないことを社内で説明できる状態です。個別判断が必要な項目は、営業が独断で決めず、誰に何を確認すれば回答できるかを決めておきます。
手順2：顧客の相談を、仕事の流れに置き換える
進行中の案件を一つ選び、顧客の相談を具体的な作業に書き換えます。情報共有を改善したいという記録だけなら、誰から誰へ、どの情報を、いつ渡しているかを確認します。聞き取れていない部分は、営業の推測で埋めず、次回の確認事項にします。
次に進める目安は、顧客と営業が、対象の業務と変えたい状態について同じ説明ができることです。相手の発言を整理して伝え、認識が合っているかを確かめます。顧客自身も問題を整理しきれていない場合は、提案を急ぐより、業務の現状を確認する場を設けます。
手順3：利用・技術・導入判断の条件を分けて確認する
次に、実際に使うための条件、技術面の条件、社内で導入を決めるための条件を分けます。利用者に評価してもらえば済む項目と、情報システム部門の確認が必要な項目では、相談する相手が異なります。一人の担当者にすべての回答を求めると、商談が止まる原因になります。
| 確認の段階 | 何を確かめるか | どうなら次に進むか | 足りない場合の対応 |
|---|---|---|---|
| 対象業務の確認 | 利用者、作業の流れ、現在の問題 | 対象業務と変えたい状態について認識が合っている | 実際の利用者に話を聞き、業務の流れを整理する |
| 利用条件の確認 | 必要機能、入力の負担、例外的な作業 | 業務に適用できる見込みがあり、残る確認事項が明確 | 対象業務に絞った実演や試用を行う |
| 技術条件の確認 | 連携、データ、権限、利用環境 | 対応可否を確認できた、または確認方法と担当が決まった | 技術担当と顧客側の関係者で確認する |
| 導入判断の確認 | 判断する人、予算の扱い、社内手続き | 判断に必要な情報と確認の順番が分かっている | 担当者と社内の検討手順を整理する |
| 導入準備の確認 | 開始条件、担当分担、移行や設定の作業 | 双方が実施する作業と、開始に必要な条件を共有できている | 導入担当を交え、未決事項と確認期限を整理する |
手順4：次回の予定ではなく、次回に確かめることを合意する
商談の最後には、次に何を確認し、その結果で何を判断するかを合意します。次回は詳しい説明をする、では目的が広すぎます。既存データを取り込めるかを確認する、現場の入力手順に合うかを利用者と確かめる、といった形にすると、必要な参加者と準備物が決まります。
進める条件がそろわない場合は、すぐに失注と判断する必要はありません。情報が不足しているのか、現在は優先度が低いのか、自社の提供範囲が合わないのかを分けます。保留にする場合も、何が変われば再検討するのかを記録すると、目的のない連絡の繰り返しを避けやすくなります。
商材ごとの商談の進め方を詳しく整理する場合は、IT業界の営業で商談を進めるには？｜SaaSと個別開発の確認事項も参照できます。
営業マネージャーが整えたい役割分担と、よくある失敗
IT営業に必要な知識は、製品知識、顧客業務の理解、技術の基礎、導入判断を支える力に分けて考えられます。すべてを同じ深さで学ぶより、自社の商談で何を説明し、何を専門担当に確認する必要があるかを基準に育成すると、仕事とのつながりが明確になります。
技術知識は、質問と確認のために身につける
営業に求められる技術知識の深さは商材によって異なりますが、少なくとも自社製品の仕組み、利用条件、制約は説明できるようにします。例えば、データを他のシステムへ渡せるかと聞かれたとき、単に連携可能と答えるのではなく、対象システム、渡す情報、頻度、必要な作業を確認する必要があります。
分からない質問を受けた際に、何を持ち帰れば技術担当が判断できるかも重要な知識です。顧客の質問をそのまま転送するだけでは、背景が不足することがあります。顧客が何を実現したいのか、現状はどうしているのか、いつまでに判断が必要なのかを添えると、回答の準備を進めやすくなります。
失敗1：機能説明が長く、導入する理由が残らない
製品に詳しくなるほど、多くの機能を説明したくなることがあります。しかし、顧客の問題と結び付いていない説明は、比較の材料になりにくいものです。商談の記録が紹介した機能の一覧だけになっている場合は、顧客がどの場面に関心を示し、何を判断できたかを確認します。
改善するには、実演前に対象業務と確認事項を絞ります。そのうえで、機能を見せるたびに、顧客の現在のやり方と比べて何が変わるかを確かめます。説明を短くすること自体が目的ではなく、顧客が必要な判断をできる説明にすることが目的です。
失敗2：技術担当に任せた結果、顧客の目的が伝わらない
難しい質問が出た際に専門担当へつなぐことは必要です。ただし、営業が商談の背景を整理しないまま引き継ぐと、技術面の回答は得られても、顧客が導入を判断できない場合があります。例えば、接続できるかという質問の背景に、毎日の手入力をなくしたいという目的があるなら、接続方式だけでなく運用まで確認する必要があります。
営業は、顧客の目的と商談全体の確認事項を持ち続けます。技術担当は実現方法や制約を判断し、営業はその回答が顧客の業務と導入判断にどう関係するかを整理する。この分担を明確にすると、専門担当が同席する商談の目的も定まりやすくなります。
失敗3：担当者の好反応を、導入決定に近い状態と捉える
便利そう、使ってみたいという反応は大切ですが、それだけで契約の見通しは決まりません。実際に使う人の評価、費用を判断する人の確認、社内手続きなどが残っている可能性があります。営業会議では、顧客の感想と、確認できた事実を分けて扱います。
マネージャーは、感触はどうかと聞くだけでなく、相手は何を評価したのか、次に誰が何を確認するのかを尋ねます。分からない項目は、担当者の説明を強めて埋めるのではなく、未確認として次の行動に落とします。これにより、案件の見通しと必要な支援を分けて考えやすくなります。
失敗4：契約後の説明が、商談中の説明と食い違う
初期設定まで対応してもらえると思っていた、データ移行は顧客側の作業だった、といった認識のずれは、提供範囲の説明や引き継ぎが不足していると起こり得ます。営業資料に書いてあることだけでなく、口頭で伝えた条件も記録し、契約前に顧客と確認することが大切です。
引き継ぎでは、合意済みの内容と未確定の内容を混ぜないようにします。顧客の要望、自社の回答、追加確認が必要な事項を分け、担当者と確認時期を明らかにします。導入担当が商談を一から聞き直さなくても、必要な作業を判断できる状態を目指します。
育成では、商談で使う行動を一つずつ練習する
営業研修では、製品の説明を覚えることに加えて、顧客の曖昧な相談を具体的な業務にする質問、未確認事項を持ち帰る伝え方、次に確かめることを合意する会話を練習します。一度に商談全体を直そうとするより、実際に不足していた行動を選ぶと、振り返りの基準が明確になります。
例えば、効率化したいという相談に対して、すぐ機能紹介へ進む傾向があるなら、現在の作業と問題が起きる場面を聞く練習をします。振り返りでは、質問したかだけでなく、回答を受けて対象業務を具体的に整理できたかを見ます。次の商談でも同じ点を確認し、実際の会話で使えたかを確かめます。
FAZOMは、営業のロープレや商談の振り返りをAIで継続する方法の一つです。自社の商談で不足している質問や説明を練習テーマにすると、日々の営業活動と結び付けて取り組みやすくなります。
まとめ
IT営業は、顧客の業務上の問題を整理し、ITで対応できる範囲と条件を確かめ、導入の判断から利用開始までをつなぐ仕事です。製品の機能を伝えるだけでなく、顧客が何を変えたいのか、どの条件なら実現できるのか、誰が何を確認して導入を決めるのかを明らかにします。
既存サービス、個別開発、機器・ネットワーク、運用サービスでは、必要な確認が異なります。自社の商材に合わせて、営業が回答する範囲、専門担当に確認する範囲、契約後に引き継ぐ内容を決めることが大切です。
自社で見直す際は、進行中の案件を一つ選び、対象業務、変えたい状態、実現条件、導入判断の進め方が確認できているかを見てください。不足している項目が分かれば、次に誰と何を確かめるかを決められます。活動の数だけでなく、顧客が判断できる状態に近づいたかを見ることが、IT営業の仕事を具体的に管理し、育てるための出発点になります。
