大企業における部門横断のトスアップ戦略

大企業におけるトスアップの構造的課題を整理する

企業規模が大きくなるほど、営業やマーケティングの組織体制は複雑化し、情報共有や役割連携が難しくなっていきます。特に大企業の場合は、部門の細分化や拠点の分散、評価指標の違いといった要素が絡み合い、情報連携が阻害されがちです。

ここでは、大企業特有の構造的な課題を整理し、トスアップがうまく機能せず、成果につながりにくくなっている理由を紐解きます。

営業・マーケティングの組織が多層化し、情報が分断されやすい

大企業では、営業やマーケティング部門といっても役割ごとに部門が細分化されていることが一般的です。営業部門は、インサイドセールス、フィールドセールス、アカウントセールス、パートナー営業、また、マーケティング部門も、デジタルマーケティング、イベントマーケティングなど、複数の部門に分かれています。

また、本社、支社、グループ会社など、組織階層や地域拠点によっても管轄や業務プロセスが異なるため、情報連携が複雑であり分断されやすい構造です。

そのため、「誰が・どのリードを・どの基準で・いつ営業に渡すのか」というトスアップの判断や責任が不明確になりやすく、優先度の高いリードへの初動が遅れたり、各部門が独自の判断で対応してしまい、認識や対応方針のズレが発生するといった情報連携の問題が発生しやすくなります。

顧客接点が複数の部署に分かれ、全体像を把握しづらくなっている

営業やマーケティングの各種部門が、同じリードに接触することは、大企業や中堅企業では珍しくありません。例えば、展示会で名刺交換したリードに対して、マーケティング部門のイベント担当者がフォローメールを送り、その後にセールス部門のインサイドセールスが電話でヒアリングを行い接触したり、過去に担当していた営業担当者が別商材の提案をしていた…といったように、同じ企業内の複数部門の複数の関係者が、時期や目的をずらして接点を持つことはよくあることです。

しかし、こうした状況では「誰が、いつ、どのような対応をしたのか」といった接点情報が部門ごとに分断されやすく、顧客対応の全体像をつかみにくくなります。その結果、営業が誤った理解のまま提案してしまったり、過去の対応と重複した案内をしてしまうといった問題が発生しやすくなります。

情報が分断されたままでは、顧客に一貫性のある体験を提供することが難しくなり、結果として商談の機会損失や成約率の低下を招くリスクが高まります。

全体最適が見えづらく、トスアップが成果につながらない構造になっている

本来であれば、マーケティングが獲得したリードを、インサイドセールスが顧客の状態を細かくヒアリングし、その情報を基に営業が適切なタイミングで商談につなげていくといった一貫した体制が理想です。しかし現実には、トスアップの目的や判断基準が部門間で共有されないまま各部門が自部門で評価指標やKPIを抱え、目標達成に集中するあまり、部分最適な動きに陥っているケースが多く見られます。

その結果、リードの引き渡し後に対応がばらつき、成果につながりにくいという課題が生じやすくなります。ツールや仕組みが整備されていても、それが部門を横断するプロセスとして機能していない状況では、効果的な連携とは言えません。

CRM/SFAの運用を前提としたトスアップ戦略を再設計する

部門間の情報分断やプロセスの不統一、責任の曖昧さといった構造的な課題を解消し、トスアップを確実に成果につなげていくには、CRM/SFAを活用して、リード情報の一元管理、対応フローの標準化、担当部門の役割と責任を明確にする仕組みを整えることが重要です。

リード情報の一元管理

部門で分断されがちなリードに対する接点情報や対応履歴を、CRM/SFAツール上で一元的に管理します。誰が、いつ、どのような対応をしたのか、を関係者全員が把握できる状態を作ることで、対応の重複や抜け漏れといったリスクを減らし、スムーズな引き継ぎが可能になります。

対応フローの標準化

どの状態のリードを・どのタイミングで・誰が引き受けるのか、判断基準をあらかじめ共通化しておくことで、どのリードを優先的に営業へ渡すべきかをブレなく判断できるようになります。一定のスコアを超えたリードだけを営業に引き渡すといったスコアリングの仕組み、確認すべきヒアリング項目、そしてリードの状態を示すステータス管理の明文化などの基準を部門間で揃えることが重要です。判断の軸が揃えば、トスアップの質とスピードも自然と向上していきます。

担当部門の役割と責任の明確化

単に判断基準を設けるだけでなく、部門ごとの役割と責任を明確に定義し、全体最適の観点から連携を設計することが大事です。SLA（サービスレベルの合意）やKPIを明文化し、誰がどのフェーズを担当し、いつまでに何をすべきかが共有されていれば、組織全体で同じ方向を向いた連携が実現できます。

これらの仕組みを整えることで、部門間で足並みの揃ったトスアップ体制を構築することができます。次に、リードの一元管理、対応フローの標準化、役割と責任の明確化をどのような視点で設計すべきか、CRM/SFA設計のポイントについて学んでいきます。

CRM/SFAを部門横断の情報基盤として設計する

CRM/SFAを部門横断の情報基盤として設計するために、まずは、接点履歴や進捗状況、担当者の動きなどをCRM/SFA上に集約し、誰が見ても一目でリードの全体像が把握できる状態を作ります。

リード情報を一元管理できるデータ構造を設計する

まず必要なのは、CRM上でのデータ構造の整理です。以下の各データが、バラバラに存在するのではなく、正しく関連づけられた状態で管理されていることが前提となります。

• 取引先（企業情報）
• 連絡先（担当者）
• 見込み客（リード）
• 商談（案件）
• 活動履歴（接触・対応記録）

例えば、あるリードに対してイベント経由で名刺を取得し、その後インサイドセールスが初回ヒアリングを実施し、以下のように商談につながったという流れがあったとします。その場合は、名刺獲得時から商談までの間の以下の情報全てがCRM内で正しくつながっている状態が望ましいです。

• イベントで得た名刺情報（＝連絡先）と企業情報（＝取引先）
• MAツール上でのリードが行動した情報履歴（資料DLやメール開封履歴）
• インサイドセールスが入力したヒアリング内容（＝活動履歴）
• 商談案件（＝商談）

上記が関連づけられていなければ、営業担当者は有効な情報を元に判断・提案することができません。

また、マーケティング部門はExcelを使用、営業はSFAツールを使用、インサイドセールスはMAツールだけを使用している…といったように、部門ごとに情報が点在していると、リードの全体像は見えず、過去の接触内容がわからないまま重複対応が発生したり、重要な手がかりが見落とされたりするリスクも高まります。すべての部門が共通のプラットフォーム上で情報を扱い、誰が見てもリードの状況が正しく把握でき、一貫性のある対応が行える状態に整えましょう。

複数部門の接点履歴を可視化する仕組みをつくる

それぞれの部門が異なるタイミングで同リードに接点を持つため、誰が・いつ・どのような対応をしたか、をCRM/SFA上に接点履歴を記録し、関係者全員がリアルタイムで確認できる状態を整えます。

• インサイドセールスでは、ヒアリングした内容やトスアップを行った判断をツール内の「活動履歴」に入力し記録する
• マーケティングでリードナーチャリングを目的に行ったメルマガ送付履歴、また送付後の反応をCRM内に自動反映させて皆が見える形を作る
• 営業では、商談を行った際の記録、商談後の状況や進捗を営業担当者が正確に記録し、他部門もそれを参照できるようにする

このように、部門ごとの行動履歴を蓄積し、可視化することで、社内での対応状況がひと目でわかり、連携ミスや対応のバッティングを未然に防ぐことができます。

誰でも最新の情報にアクセスできるビュー・権限を整える

情報の記録だけでなく、誰でも必要なタイミングで最新情報にアクセスできる環境を整えます。情報が見えていない、または一部の担当者しかアクセスできない状態では、部門間での連携ミスや対応の重複・漏れが発生しやすくなるため、各部門の対応状況を確認できるビューの設計と、業務に応じた適切な閲覧権限の設定を行いましょう。

また、リードに関わる全部門が、自分たちが対応した内容やアプローチした時期、アプローチした結果、をきちんと記録するルールを整備することも重要です。情報の入力・更新が正しく行われることで、関係者全員が同じ情報を基に判断・行動できるようになり、組織全体での一貫性ある対応につながります。

トスアップ判断基準とプロセスを標準化する

リード情報や接点履歴を整理した後、どのリードを、誰が、どのタイミングで引き渡すかを明確にするため、トスアップの判断基準とプロセスを標準化を進めます。判断やアクションのルールを明文化し、再現性ある形で運用できる状態をつくることで、チーム全体で一貫した対応が可能になります。

ここでは、トスアップのプロセスと設計の方法、標準化するポイントなどを踏まえ確認していきます。

MQL・SQLの定義を明確にする

トスアップ基準となるのが、MQL（Marketing Qualified Lead）とSQL（Sales Qualified Lead）と呼ばれる以下、2つの定義です。

MQL：マーケティングが営業に渡してよいと判断したリード
SQL：営業が実際にアプローチ（商談・提案）すべきと判断されたリード

両者の定義が曖昧なまま運用されていると、渡すべきでないリードが営業に送られたり、トスアップされたリードが放置される、といった問題が起こりやすくなるのです。

■ MQLの定義例

MQLとして扱うためには、以下のような行動・属性・反応・接点の条件を組み合わせてスコア化・判断するのが一般的です。

上記を基に、例えば、

「スコア合計70点以上かつ問い合わせフォーム送信済」の場合にMQLと認定

「セミナー参加済かつISのヒアリングで課題あり」と判定されたリードをMQLとする

といったように、明確な条件を設けておくことで、感覚的に良さそうだから渡すなどの属人的判断を排除し、営業が納得感をもって受け取れる状態をつくることができます。

■ SQLの定義例

SQLは、営業に進めるべき優先度の高いリードです。インサイドセールスが初期ヒアリングを行い、以下のBANT条件が満たされた場合に、SQLに昇格させます。

上のBANT情報から、

「インサイドセールスが課題と導入時期を確認済み」であればSQLにステータス変更し、営業にトスアップする

などの基準を定めます。MQLとSQLの基準を定め、誰が見ても判断がずれることなくトスアップされる仕組みを整えることが重要です。

トスアップ判断のフェーズとアクションを設計する

MQLやSQLの基準を定めた後、それを実際の業務プロセスの中でどのように判断し、どのタイミングで誰に引き渡すのか、判断ポイント・承認プロセス・通知の流れを含めて以下のようなフローを設計します。

1. インサイドセールスが初回接触とヒアリングを実施する
2. ニーズや検討時期など、SQL基準に該当するかを確認する
3. 該当する場合、リードのステータスを「SQL」に変更する
4. CRM上で営業担当に自動通知が送られ、タスクが割り当てられる

誰が、いつ、何を判断して、次に誰が引き継ぐのか、の一連の流れを1〜4を例に明確に設計することでリードの対応漏れや、対応が被るといった初歩的なミスを防ぐことができいます。

また、このプロセスは単に目視や手動で行うのではなく、CRM/SFAのワークフロー機能や自動通知機能を活用することで、属人化を防ぎつつ運用負荷を下げることもできます。引き渡しの判断基準だけでなく、それを実行に移すプロセスそのものが組織全体で共有されていれば、トスアップの精度とスピードの両面で効果が上がるでしょう。

タスク・通知・引き渡し履歴をCRM/SFA上で管理する

次に、トスアップされたリードに対し営業担当者がすぐに対応できるよう仕組み化するためにも、トスアップ後のタスク割り当てや通知、履歴管理までを含めた運用設計を行います。

マーケが渡したが営業が見ていなかった…、インサイドセールスがトスアップしたが対応されないまま放置されていた…といった問題は起きやすいものです。

これらの問題を防ぐためにもまず、対応が漏れることなく確実に営業がアクションを行えるよう、トスアップが発生した瞬間に、以下3つが自動で行われる仕組みをCRM/SFA上に実装します。

• 営業担当に自動で通知が届く
• 初回対応などのフォロータスクが自動で割り当てられる
• 対応期限や優先度が明確に設定される

また、営業が対応したかどうか、履歴を記録し、可視化できるようにしておくことも大事です。後から状況を正しく振り返ることができ、万が一の対応漏れやトラブル時にも責任の所在が明確になります。

KPI・SLA・役割分担を整備し、再現性のある連携体制を築く

ここまで、基準やフローなど運用を定義することとについて学びました。最後には、成果につながるようKPI（評価指標）やSLA（対応基準）を部門間で共有し、再現性の高い連携体制の整備を行います。部門横断で取り組むべき評価指標や対応基準、改善体制について整理します。

部門横断で連携プロセスに紐づくKPIを定義する

部門間でスムーズな連携を実現するには、各部門が“自部門だけ”に閉じたKPIではなく、プロセス全体を意識したKPIを持つことが重要です。例えば、マーケティング部門がMQL数のみを追っている場合、数を満たすことだけが目的化され、営業が対応しづらいリードまでトスアップされてしまう可能性が出てきます。

そのため、プロセスのつながりを意識した指標設計に見直し、各部門が一貫したゴールに向けて協働できる状態をつくります。以下のように、各指標が「連携の質」や「スピード」に紐づいた指標を設計してみましょう。

■指標のNG例

上記で定義したKPIは、CRM/SFAなどを活用して継続的に可視化・モニタリングできるようにします。

トスアップに関するSLA（対応期限・品質基準）を整備する

KPIによる可視化とあわせて、SLAの整備も行います。どのような状態でトスアップすべきか、営業はいつまでに対応すべきか、の"渡すべき状態"と"対応期限"の2点は最低限、事前に定めておきましょう。これらを定めておくと、部門間の認識ズレや責任の曖昧さが起きづらくなります。

トスアップの品質基準（渡すべき状態）の設定

以下のようになインサイドセールスやマーケティングがトスアップ時に満たすべき最低条件を決めておきます。

• BANT情報のうち、2項目以上が確認されている
• 直近の接触日と対応履歴がCRM上に記録されている
• 商談化の可能性・理由がコメント欄に明記されている

部門間で共通認識を持つことで、営業側がスムーズに対応できるようになります。

対応期限（SLA時間）の設定

営業が対応すべき期限（SLA時間）も以下のように明確に定めます。

• トスアップから24時間以内に電話やメールなどで初回接触を行う
• 48時間以内にステータスを更新する
• 初回対応完了までにCRMでの対応記録入力を必須で行う

活用されないといった事態を防ぐためにも、上記定義を明確化し周知するだけでなく、CRM/SFAにSLA達成状況をトラッキングするといった仕組みの工夫も行いましょう。

定期的なレビューと改善を行う

指標は定めて終わりではなく、定期的に観測し、継続的に改善していくことが望ましいです。KPI・SLAは、初期段階では理想をもとに設計されがちですが、進めていくうちに現場の運用実態と乖離することもよくあります。

月次や四半期などの単位でレビューの場を設け、以下のような視点で設定したKPIが実態と見合っているか確認を行います。

• トスアップ数と商談化率の推移
  →トスアップが目的化していないか？トスアップ数ばかり増えていないか？
• トスアップ後の初動までの平均時間
  →営業の動き出しが遅れていないか？SLAが守られているか？
• MQL→SQL→受注までのリードタイム
  →どこかのプロセスで停滞していないか？ボトルネックはどこか？
• 各担当者ごとの対応状況・ボトルネック
  →一部メンバーに業務が偏っていないか？引き渡し後の放置がないか？

レビューの際には運用の定量データだけでなく、現場の声などの定性データも含め、実際にトスアップを受けた営業の所感や、ISが感じた違和感なども収集し共有するようにします。

CRMやダッシュボード機能を活用し、状況を可視化しながらマーケ・IS・営業の3部門でレビューを行うことで、現場に即したKPIやSLAの見直し・アップデートができるようになります。このようにレビューと改善を「定例の運用プロセス」に組み込み、再現性の高いトスアップと連携を実現させましょう。