失注した商談から、何を改善すればよい？

「あの機能がなかったので失注しました」。商談の振り返りでそう報告されても、すぐに開発を決める前に確かめたいことがあります。相手が必要としていた仕事、価格や導入時期、社内の判断過程を見なければ、次の商談で何を変えるべきか分からないからです。

この記事では、失注した商談の記録を読み直し、製品・説明・提案の進め方に関する改善候補を選ぶ方法を紹介します。営業担当者の評価や、必ず受注できる方法ではなく、失注から何を学ぶかに絞ります。

失注理由の前に、商談の結末をそろえる

まず、何が決まった商談なのかを確認します。競合を契約した、従来の手作業を続けた、予算がなく計画を止めた、返事がなく結果を確認できていない。いずれも営業管理上は失注にする場合がありますが、改善を考える材料は異なります。

連絡が取れない案件を「価格で負けた」と決めつけると、理由が分からないまま値下げや機能追加を検討することになります。記録上の状態と、顧客に確認できた結末を分けて残してください。

GitLabの公開営業ハンドブックでは、失注時に該当する理由をすべて選び、今後に向けたメモや次の行動を更新する運用が示されています。一社の運用例ですが、理由を一語だけで閉じず、後で検討できる記録にする参考になります。

本記事では、対象期間を決めて商談を振り返り、結末が確認できた案件から具体的な経緯を読む方法を提案します。結果不明の案件も一覧から消さず、分かっている範囲を示します。

顧客の言葉と、担当者の解釈を分ける

「機能不足で失注」という要約だけでは、誰が何を言ったのかが分かりません。商談メモやメールを確認し、元の発言、その背景、担当者の解釈を区別します。

次の例は、架空の備品管理サービスを想定した説明用です。実際の商談や顧客の発言ではありません。

• 顧客の発言：「拠点別に一覧を出して、棚卸し担当者へ配りたいです」
• 提案中に確認したこと：一覧の絞り込みはできるが、拠点ごとの一括出力はできない。
• 担当者の解釈：一括出力が不足していることが失注の主因かもしれない。
• 未確認のこと：一括出力が必須条件だったか、ほかに決め手があったか。

「できない機能を聞かれた」ことと、「それが理由で選ばれなかった」ことは分けて確かめます。顧客が複数の条件を比較していたなら、機能が一つ増えても、ほかの条件が残るかもしれません。

発言を正確に記録していない場合は、引用符で囲まず要約と明記します。誰から、いつ聞いた情報かも残すと、後で確認し直せます。機密性のある見積もりや顧客情報は、振り返りに必要な範囲の関係者へ共有します。

機能・価格・進め方を順に確かめる

振り返りでは、足りない機能だけを一覧にせず、顧客が判断した条件を見ます。次の表は、改善先を考えるための確認例です。

この表は、失注を必ずどれか一つに分類するためのものではありません。複数の事情が関係しているなら、その組み合わせを残します。価格が論点だった場合も、競合の提示額など確認できない情報は推測で埋めません。

不足する機能は、機能名だけでなく「誰が、どの作業を終えられないか」まで戻して確認します。GOV.UKのユーザーニーズのガイドも、解決策より利用者の問題に注目し、根拠に基づいてニーズを確かめる考え方を示しています。

架空の商談から、次の確認を決める

先ほどの備品管理サービスの例を続けます。ここからも説明用の架空例です。

営業担当者の記録には「拠点別の一括出力がなく失注」とありました。一方、顧客からの見送りメールには「今期の棚卸しまでに設定と移行を終えることが難しい」と書かれていました。

振り返りでは、どちらかを正しい理由として採用せず、二つの論点を残します。一括出力の使い道は確認できていますが、導入期限に間に合わない事情も述べられているためです。

相手が追加確認に応じられるなら、次のように尋ねます。

1. 棚卸しで、どの準備や作業を特に心配していたか。
2. 最終的にどの方法で棚卸しを行うと決めたか。
3. 見送る判断で、機能と導入準備をそれぞれどう考えたか。

「一括出力があれば契約しましたか」という質問だけで受注可能性を確定しないようにします。仮定への回答と、すでに起きた判断は別の情報です。返信がない場合は追及せず、記録で確認できたことから検討します。

この時点では、次の商談で導入期限と移行作業を早めに確認する改善を試せます。一括出力については、似た業務を持つ顧客でも同じ作業負担があるかを調べ、製品側の検討へ渡します。営業の進め方と機能の検討を、並行して扱う例です。

複数の商談を比べ、改善候補を一つ選ぶ

一件の振り返りができたら、似た用途や規模の商談で、同じ問題が起きていないか確認します。大きな案件の印象だけで決めず、各案件の根拠へ戻れる状態にします。

受注した商談も比較に使えます。同じ機能がなくても受注できた案件があるなら、必要な業務、代替手順、導入支援などの違いを調べる手掛かりになります。ただし、違いが見つかっただけで勝敗の原因が確定するわけではありません。

件数や金額をまとめるときは、対象期間と案件の範囲を示します。一つの案件を複数の要望にひもづけた場合、案件金額を単純に足して「この開発で得られる売上」と扱わないでください。過去の失注額は、そのまま回収できる金額ではありません。

改善候補には、次の五つを添えると、検討する相手へ渡しやすくなります。

• 対象：どの顧客の、どの仕事で問題が起きたか。
• 根拠：発言や商談記録で何を確認できたか。
• 未確認点：機能以外にどの条件が残っているか。
• 次の確認：試作品、説明の変更、追加調査など何を試すか。
• 担当と確認日：誰が結果を持ち寄るか。

製品側へ渡す記録の形式は、営業・CSの顧客要望を開発へ渡す方法を使えます。この記事で確かめた失注の経緯を添え、開発の約束に置き換えないことが大切です。

改善した後は、次の商談で確かめる

改善の結果は、受注したかどうかだけでなく、狙った問題が解消したかも見ます。導入条件の確認を早めるなら、期限までに必要な作業と担当者を把握できたか。説明を変えるなら、顧客が自分の仕事に置き換えて判断できたかを確認します。

機能を試作する場合は、対象業務を完了できるかを確認し、実装の可否を別に判断します。「検討する」「試す」「提供を決める」は異なる状態です。顧客への説明でも、未確定の提供時期や受注後の対応を約束しないようにします。

よくある質問

まとめ

複数の改善候補から着手するものを選ぶ際は、開発する機能の優先順位を決める方法を参照できます。

失注した商談では、結末、顧客の言葉、判断した条件をつなげて読みます。機能・価格・説明・導入の進め方を見比べ、次に確かめる改善を一つ選んでください。

少数の商談は、元の記録と振り返りメモで整理できます。商談や要望が増え、似た困りごとを探す作業が重くなったら、検討材料をまとめる方法も見直せます。

アーコレ！は、集まった要望を整理し、改善の検討につなげるためのサービスです。失注の原因や受注見込みを自動で判定するものではなく、製品への要望をチームで考えるための情報整理に使えます。

アーコレでどう整理できるかを見る