CSから見た「売り方が悪い案件」の共通点

この記事で整理すること

受注時点では良い案件に見えても、導入後に利用が進まない、問い合わせが増える、解約リスクが高まる案件があります。CSから見ると、営業段階で期待値、利用部門、成功条件、導入体制が曖昧なまま契約しているケースが少なくありません。この記事では、売上だけでなく継続利用を見据えた売り方へ変えるために、AEとCSが受注前にそろえるべき観点を整理します。

背景

SaaSやITサービスの営業では、契約が終わった瞬間に価値提供が終わるわけではありません。むしろ顧客にとっては、契約後に設定し、現場へ展開し、利用を定着させる段階から本番が始まります。営業段階で成功条件が曖昧なまま受注すると、CSは導入後に顧客の期待値、運用体制、利用部門の巻き込みを一から確認することになります。これはCSだけの問題ではなく、営業プロセスの問題です。

よくある失敗

• 受注金額や決裁完了だけで良い案件と判断している。
• 顧客の導入体制や運用責任者を確認しないまま契約している。
• 営業資料でできることを広く見せすぎ、導入後の期待値がずれる。
• AEからCSへの引き継ぎが契約内容と議事録だけになっている。

実務での見直し方

見直すべきなのは、受注前の確認項目です。AEは、導入目的、成功条件、利用部門、運用責任者、初期設定の担当、社内展開の進め方を商談中に確認します。CSは、受注後に必要な情報をAEへ戻し、受注前チェックの観点として営業プロセスに組み込みます。特に重要なのは、顧客が何をもって成功と判断するかです。単に機能を使うことではなく、どの業務がどう変われば導入価値があるのかを言語化します。

見落としやすいのは、CSが知りたい情報とAEが受注前に確認している情報の粒度が違うことです。AEは契約に必要な合意を見ますが、CSは導入初日に誰が動くのか、現場へどう展開するのかを見ます。この粒度差を埋めないと、引き継ぎ資料はあっても導入支援には使いにくくなります。

現場で起きるサイン

このテーマで問題が起きている組織では、会議やSFA上に小さなサインが出ます。たとえば、受注金額や決裁完了だけで良い案件と判断している状態が続くと、担当者は前に進んでいる感覚を持っていても、顧客側の判断は進んでいないことがあります。顧客の導入体制や運用責任者を確認しないまま契約している場合も、案件の見た目は整っていても、次の関係者や次の判断に進む材料が不足します。

CSの現場で分かりやすいのは、初回オンボーディングで顧客が「営業から聞いていた話と違う」と感じる場面です。営業段階では部門全体で使う前提だったのに、契約後に管理者が一人しか決まっていない。あるいは、成功条件が入力率の向上だけで、どの会議や業務を変えるのかが決まっていない。この状態では、CSは導入支援よりも期待値の再調整から始めることになります。

もう一つのサインは、会話が担当者個人の感覚に寄りすぎることです。温度感が高い、反応が良い、前向きそう、といった表現だけでは、営業組織として支援できません。実務で扱うには、誰が、何を、いつまでに、何のために判断するのかを記録する必要があります。記録できない情報は、商談中に確認できていない可能性があります。

チームで分担すること

この見直しは、営業担当者だけに任せると続きません。担当者は顧客との会話から事実を集め、マネージャーは案件レビューで不足している論点を確認します。営業企画やRevOpsは、SFA項目、会議アジェンダ、確認テンプレートを整えます。CSやプリセールスが関わるテーマでは、導入後や技術確認で必要になる情報を受注前の確認項目へ戻します。

分担を決めるときは、誰が入力するかだけでなく、誰がレビューするかまで決めます。入力欄を増やしても、レビューされなければ形だけになります。逆に、レビュー観点が明確であれば、営業担当者は何を確認すべきかを商談前から意識できます。運用の目的は管理を細かくすることではなく、顧客の判断を前に進めるための情報を欠かさないことです。

明日から使えるチェックリスト

• 導入目的を顧客の言葉で説明できる。
• 利用部門、管理者、運用責任者が分かっている。
• 初回オンボーディングで確認すべき未合意事項が残っている。
• 商談中の約束事項と、まだ約束していない事項を分けている。
• CSへ渡す一枚の引き継ぎメモがある。

このチェックリストは、すべてを一度に完璧に埋めるためのものではありません。最初は、次の商談や次の会議で確認する項目を二つだけ選びます。たとえば、導入目的を顧客の言葉で説明できるかどうかを確認し、次に利用部門、管理者、運用責任者が分かっているかどうかを見ます。未確認の項目があれば、次回商談の質問、フォローメール、社内レビューのいずれかに戻します。

重要なのは、空欄を責めるのではなく、空欄を次の確認事項として扱うことです。商談は常に情報が揃った状態で進むわけではありません。だからこそ、何が分かっていて、何がまだ分かっていないのかを分ける必要があります。この分離ができると、案件レビューは報告ではなく支援の場になります。

運用に落とす方法

AEとCSの定例で、導入後に失速した案件を月に一度だけ振り返ります。責める場にせず、受注前に確認できたこと、確認できなかったこと、資料表現で期待値を広げすぎたことを分けます。その結果を受注前チェックリストへ戻します。SFAには、導入目的、成功条件、利用部門、運用責任者、未合意事項を入力する欄を持たせます。入力欄を増やすだけではなく、案件レビューで空欄の理由を確認することが運用です。

月次のAE/CSレビューでは、失速した案件だけでなく、スムーズに立ち上がった案件も一件ずつ見ます。良い案件に共通する受注前の確認事項を抜き出すと、チェックリストは現場に合ったものになります。

運用に落とすときは、既存の会議とSFAに接続します。新しいチェックシートを作っても、普段の案件レビューや1on1で見なければ定着しません。週次会議では、対象案件をすべて確認するのではなく、停滞している案件、次の判断者が不明な案件、未確認事項が多い案件に絞ります。限られた会議時間を、読み上げではなく次の打ち手に使います。

SFAでは、自由記述だけに頼らない方がよいです。自由記述は文脈を残すには便利ですが、集計や比較には向きません。最低限、確認済み、未確認、次回確認、対象外のように状態を分けられる項目を用意します。細かい項目を増やしすぎると入力されなくなるため、最初は営業が本当に判断に使う項目だけに絞ります。

見るべき指標またはレビュー観点

見るべき指標は、受注件数だけではありません。初回オンボーディング実施率、管理者設定までの日数、主要機能の利用開始率、受注後30日以内の未合意事項数、CSからAEへの差し戻し件数を見ます。これらが悪化している場合、売り方のどこかで期待値や導入体制の確認が不足しています。

指標を見るときは、単月の結果だけで判断しません。営業活動には案件のタイミング、顧客側の稟議時期、担当者の経験差が影響します。まずは30日単位で、入力品質、次回アクション、停滞理由、関係者確認、失注理由の具体性が改善しているかを見ます。数字が悪い場合も、すぐに担当者の能力問題にせず、プロセス、資料、会議、マネージャー支援のどこに詰まりがあるかを分けます。

最後に、改善した内容を標準化します。うまくいった質問、顧客が社内共有しやすかった資料、案件レビューで有効だった確認項目は、個人の工夫で終わらせず、テンプレートや会議アジェンダに戻します。営業組織の実務改善は、一度の施策ではなく、現場で見つけた良い型を繰り返し更新することで定着します。

公開前に確認すること

この記事のテーマを自社で扱うときは、最後に三つの観点で確認します。第一に、現場が明日から使える粒度になっているか。第二に、マネージャーやRevOpsがレビューできる記録として残るか。第三に、顧客の判断を助ける内容になっているかです。社内向けの管理項目だけを増やしても、顧客の検討が進まなければ営業実務としては不十分です。

最初にチームで確認する問いは、「CSが初回オンボーディングで聞き直していることは何か」です。聞き直しが多い項目ほど、受注前の確認項目に戻す価値があります。

また、記事の内容をそのまま全案件へ一律に適用しないことも重要です。新規商談、既存顧客、エンタープライズ、パートナー経由では、確認すべき相手やタイミングが変わります。まずは対象案件を絞り、運用してみて、会議で振り返る。そこで得た学びをチェックリストやSFA項目へ戻す。この小さな改善サイクルを前提にすると、営業組織に無理なく定着します。

編集・監修について

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