AEとCSの境界線を曖昧にしない営業設計

この記事で整理すること

AEとCSの責任分担を、組織図や担当範囲の線引きではなく、顧客体験、受注品質、導入後の定着から整理します。受注前にAEが確認すべきこと、CSが早めに関与すべき条件、引き継ぎで残すべき情報、共同で見る指標を扱います。

役割の境界線は、組織図ではなく顧客体験で決める

AE と CS の境界線を考えるとき、最初に見直すべきなのは「誰がどこまで担当するか」という社内都合の線引きではありません。顧客から見て、商談、契約、導入、定着、拡張がどのような体験として連続しているかを先に描く必要があります。社内では受注を境に担当者が変わっていても、顧客にとっては同じ課題解決の流れです。ここが分断されると、商談中に約束された価値と導入後に提供される支援がずれ、初期オンボーディングで不信感が生まれます。

一方で、顧客体験を重視するあまり AE と CS の役割を曖昧にすると、今度は社内の責任がぼやけます。AE が導入後の課題まで抱え込み続けると新規商談の推進力が落ち、CS が受注前の提案調整に巻き込まれすぎると既存顧客の定着活動が後回しになります。理想は「顧客には連続した体験を提供しながら、社内では責任と判断基準を明確に分ける」ことです。

よくある失敗は「良い人同士の助け合い」で設計を代替すること

立ち上げ期の営業組織では、AE と CS の距離が近く、個別の相談で問題が解決することが多くあります。AE が「この顧客だけ少し見てほしい」と頼み、CS が「今後の更新に関わるから早めに入る」と協力する。この動き自体は悪くありません。むしろ顧客理解を深めるうえでは重要です。

しかし、その助け合いが設計として固定されないまま案件数だけが増えると、現場は急に苦しくなります。どの案件に CS が同席すべきか、どのタイミングで引き継ぐべきか、商談中の要望を誰が実現可否判断するのかが毎回変わるためです。結果として、優秀なメンバーほど例外対応を抱え込み、チーム全体では再現性が失われます。

境界線を明確にする目的は、協力を減らすことではありません。協力すべき場面をあらかじめ決め、属人的な善意に依存しない状態を作ることです。特に B2B SaaS や IT 商材では、受注前の期待値調整と受注後の利用定着が売上継続に直結します。だからこそ、AE と CS の連携は「都度相談」ではなく「業務設計」として扱うべきです。

AE が持つべき責任

AE の主な責任は、顧客課題を特定し、導入判断に必要な情報を整理し、契約に向けた意思決定を前に進めることです。ここで重要なのは、単に受注することではなく「導入後に価値が出る条件を満たした受注」を作ることです。顧客の課題が曖昧なまま契約すると、導入後に CS が目的設定からやり直すことになります。

AE は商談中に、少なくとも三つの情報を明確にする必要があります。第一に、顧客が何を改善したいのか。第二に、その改善を誰が社内で推進するのか。第三に、導入後どの指標で成果を判断するのかです。この三点が欠けた案件は、受注できても定着しにくくなります。

また、AE は実現できない期待値を作らない責任も持ちます。商談を前に進めたい場面では、顧客の要望に対して「できます」と言いたくなります。しかし、導入後の運用負荷、既存機能との整合、CS が支援できる範囲を超えた約束は、後工程で必ず問題になります。AE の仕事は要望を丸ごと受けることではなく、顧客の目的に対して現実的な進め方へ翻訳することです。

CS が持つべき責任

CS の主な責任は、契約後に顧客が期待した価値へ到達できるよう、利用開始、定着、改善を支援することです。CS は顧客の社内事情、利用状況、現場のつまずきを見ながら、継続利用に必要な状態を作ります。したがって CS は、契約内容を受け取るだけでなく、受注前に設定された目的や制約を理解しておく必要があります。

ただし、CS が商談段階から全案件に深く入る必要はありません。重要なのは、CS が入る条件を決めることです。たとえば高単価案件、複数部門導入、既存業務の変更を伴う案件、セキュリティや基幹システム連携が論点になる案件では、受注前から CS または導入支援担当が関与した方が安全です。一方、標準的な導入で完結する案件では、商談後の引き継ぎ資料を整えるだけで十分な場合もあります。

CS が商談に入る際は、営業の補助役ではなく導入後の責任者として参加することが大切です。顧客の発言を聞き、導入時に障害になりそうな点を確認し、必要なら AE に期待値調整を促します。ここで遠慮してしまうと、契約後に「聞いていなかった」という問題が起きます。

引き継ぎで最低限そろえる情報

AE から CS への引き継ぎは、単なる議事録共有では不十分です。必要なのは、導入後の行動に使える情報です。最低限そろえるべき項目は、導入目的、意思決定者、現場利用者、現在の業務フロー、成功指標、懸念事項、商談中に約束したこと、約束していないことです。

特に「約束していないこと」を明文化することは重要です。顧客は商談中の会話を自社に都合よく解釈することがあります。AE 側も、口頭で補足しただけの内容を正式な合意のように扱ってしまうことがあります。導入開始時に CS がこの境界を確認できれば、後から期待値のずれを修正する負担が減ります。

引き継ぎ資料は長ければよいわけではありません。CS が最初の顧客ミーティングで使える形になっていることが重要です。理想は、資料を読めば「初回オンボーディングで何を確認し、どの順番で支援すべきか」が分かる状態です。

KPI を分けないと責任も分かれない

AE と CS の境界が曖昧な組織では、KPI も曖昧になりがちです。AE は新規受注額、CS は継続率や活用率を見る、という大枠はあっても、両者の接続点が設計されていないことがあります。すると AE は受注だけを追い、CS は受注後の問題を引き受ける構造になります。

接続点として有効なのは、受注品質を測る指標です。たとえば、初回オンボーディング実施率、導入目的の明文化率、初期設定完了率、契約後30日以内の主要機能利用率などです。これらは AE だけ、CS だけでは達成できません。商談中の期待値設定と導入後の支援がつながって初めて改善します。

ただし、共同 KPI を増やしすぎると責任が逆に曖昧になります。共同で見る指標は少数に絞り、最終責任はどちらが持つかを明確にするべきです。たとえば受注前の目的明文化は AE、契約後の初期活用は CS、ただし両者で月次レビューする、といった形です。

境界線は一度決めて終わりではない

営業組織のフェーズが変わると、AE と CS の境界線も変わります。顧客数が少ない時期は柔軟な対応が強みになりますが、顧客数が増えると標準化が必要になります。エンタープライズ比率が上がれば、受注前から導入設計に踏み込む必要が増えます。プロダクトが成熟すれば、CS が担っていた個別支援の一部をヘルプコンテンツやプロダクト内導線に移せます。

そのため、境界線は半年に一度は見直すべきです。見るべき観点は、失注理由、オンボーディング遅延、導入後の問い合わせ内容、更新時の懸念、アップセルの発生条件です。これらを確認すると、AE 側で直すべき期待値設定なのか、CS 側で直すべき支援設計なのか、プロダクトやドキュメントで解決すべき問題なのかが見えてきます。

明日から見直すチェックリスト

まず、直近で受注した案件を三件選び、AE と CS で振り返ります。商談中に設定した導入目的は明確だったか。CS は初回支援に必要な情報を受け取っていたか。顧客が期待していた成果と実際の導入計画にずれはなかったか。この確認だけでも、境界線の弱い部分が見えてきます。

次に、CS が商談に入る条件を決めます。金額、導入部門数、連携要件、業務変更の大きさなど、判断軸は組織に合わせて構いません。重要なのは、毎回の気分や担当者の人間関係で決めないことです。

最後に、引き継ぎテンプレートを一枚にまとめます。目的、関係者、成功指標、懸念、約束事項、未合意事項。これだけでも、受注後の混乱は大きく減ります。AE と CS の境界線は、冷たい分業のためではなく、顧客に一貫した価値を届けるための設計です。

編集・監修について

この記事は営業実務ラボ編集部が企画、執筆、編集しています。制作過程で生成AIを構成案作成、草案整理、表現確認に利用する場合がありますが、公開前に編集部が事実関係、出典、表現を確認しています。外部専門家による個別監修が入る場合は、記事内で監修者名または監修有無を明記します。