▼ この記事の内容
見積もりは、価格を出す順番を固定するのではなく、顧客が何のために必要としているかと、条件がどこまで確定しているかで選びます。概算・正式・更新・再見積もりごとに、仮定、未決事項、承認者、次の確認を分けて示すと、価格だけを先走らせずに説明できます。
見積もり提示では、すべての情報がそろうまで待つべき場合も、早い段階で費用感を示した方がよい場合もあります。まず、相手が予算検討をしたいのか、社内承認へ進みたいのか、条件変更を相談したいのかを確かめます。
この記事の判断表と記入例は、営業実務を整理するための提案です。架空案件の例は実績や製品の出力ではなく、取引条件や法的な必須項目は個別の契約・社内ルールを確認してください。
営業で見積もりを提示するタイミングは依頼目的と条件確定度で決める
価格を出す順番を固定すると、予算検討と正式承認で必要な情報の違いを見落とします。依頼目的と条件の確定度から、いま示せる内容を選びます。
価格を聞かれたら提示目的を確認し概算か正式かを伝える
見積もりを提示する時点は、商談の何番目かではなく、相手が予算の目安、正式な承認、更新条件、変更後の差分のどれを必要としているかで選びます。まず依頼目的を言葉にし、現時点で出せる情報の範囲を伝えます。
弥生株式会社の概算見積書に関する実務解説は、取引初期の費用感確認と、仕様・条件が固まった後の正式見積を分けて説明しています。これは同社の解説に基づく限定的な整理であり、すべての取引の法的判断や精度を示すものではありません。
参考：概算見積書とは？必要性や正式見積書との違い、書き方を解説｜弥生株式会社
概算・正式・更新・再見積もりの判断表
見積もりの名称だけで判断せず、未確定の条件と変更の有無を見ます。提示する情報と、次に確認する事項を同じ表で整理します。
概算見積は仮定と変動項目を明記して費用感を示す
概算見積は、対象作業や数量が未確定な段階で、予算検討に必要な費用感を共有するための選択肢です。金額だけを渡さず、前提にした範囲、変動しうる項目、正式化のために確認する事項を同じ資料に残します。
たとえば対象部門が未確定なら、その点を仮定として明記し、対象部門が決まった時にどこを確認するかを添えます。金額や契約条件は、正式な見積もりと契約書で確定させます。
正式・更新・再見積もりは旧版との差と承認条件を分けて示す
正式見積では、確定した範囲、除外、金額、納期、支払条件、有効期限などを案件の条件に沿って確認します。定型更新では期間や数量の差を、仕様変更では旧版からの変更点と追加の確認事項を、混ぜずに示します。
次の表は説明用の判断表です。架空の業務システム支援案件を想定し、どの見積もりにも同じ形式を強制するものではありません。
状況 提示する情報の例 残す確認 予算検討 概算の範囲と仮定 対象作業と変動項目 条件が確定 正式見積 範囲、除外、納期、承認 定型更新 更新条件 旧契約との差と期間 仕様変更 再見積もり 変更点と差し替え承認
見積もり提示を進める5つの手順
見積作成から提示後の確認まで、情報の状態を変えながら進めます。確定した内容、仮定、未決事項を分けると、説明と承認の順番を整えやすくなります。
依頼目的と前提を聞き確定・仮定・未決を分ける
見積もり作成は、依頼目的の確認、前提の整理、社内承認、提示と説明、質問・変更・次の確認という順で進めると整理しやすくなります。概算を求められた場合は、正式化まで待たせず、仮定と未決事項を添えて提示する分岐を作ります。
以下は架空案件の記入例です。対象部門が未確定の段階では概算の前提を残し、対象作業が決まった段階で正式見積に切り替え、追加作業の依頼では再見積にします。
記入欄 架空の業務システム初期設定支援の例 担当と次の確認 確定した情報 顧客は社内の予算検討に使う概算を希望。初期設定と操作説明を検討している 営業担当が依頼目的を記録する 概算の前提 初期設定と操作説明を対象にする。既存データの移行作業は金額に含めない 提供側の作業担当が見積範囲を確認する 未決事項 利用部門、操作説明の対象者、開始希望時期。データ移行を追加するかも未決定 顧客窓口が関係部門へ確認し、営業担当と回答予定日を相談する 金額が変わる条件 データ移行の追加や操作説明の対象拡大。変更時は作業量を確認して再見積もりする 営業担当は追加料金を即答せず、作業担当と承認者へ確認する 正式化に向けた確認 対象範囲と除外、数量、開始時期、支払条件、有効期限を合意可能な状態に整理する 各未決事項の確認結果を記録し、見積版を更新する
範囲・除外・条件を整理し社内承認を確認する
提示前には、品目や数量だけでなく、金額、納期、支払条件、有効期限、発行者など、取引条件に応じて確認する項目を整理します。社内の承認が必要な条件は、顧客へ送る前に誰が確認するかを決めておきます。
マネーフォワード クラウド請求書のテンプレート解説には、見積書で扱う項目の例があります。ただし、これは同社の解説であり、業種や契約ごとの必須要件を網羅するものではないため、実際の条件は案件ごとに確認します。
参考：見積書テンプレート｜マネーフォワード クラウド請求書
見積を説明し質問・変更・次の確認を記録する
見積書を送るだけでなく、どの前提で金額や範囲を示したかを説明し、相手の質問、変更の有無、次に確認する担当と時期を記録します。返信がないことから理由を推測せず、確認が必要な事項と希望する連絡方法を分けて扱います。
送付時の件名、添付、前提、確認事項、連絡希望の文面を整えたい場合は、見積もり提示メールの文例を、判断が終わった後の表現確認に使えます。
商談・営業スキル 営業で見積もりを送るメールのテンプレート｜初回・条件変更・フォローの文例と確認事項
価格相談と比較検討で前提を確認する
価格相談や比較では、金額以外の条件が判断を左右します。範囲、納期、承認、変更時の扱いを分けて確認します。
値引きは採算・承認権限・条件変更を分けて検討する
値引きの相談では、価格だけを先に変えるのではなく、採算、承認権限、対象範囲、開始時期、支払条件のうち何を変えられるかを分けて確認します。価格調整が常に範囲削減を意味するわけではないため、提案できる選択肢と制約を整理します。
相手の予算が変わった場合も、必要な作業を推測して削るのではなく、優先する範囲と残す条件を確認します。社内判断が未了なら、その状態を明示して次に確認する人と期限を残します。
比較の場では範囲・納期・保守・条件の差を確認する
相見積もりでは、顧客が共有できる範囲で、比較している対象範囲、納期、保守、支払条件、変更時の扱いが同じかを確認します。前提が異なる資料を金額だけで比べると、判断に必要な情報が抜けます。
比較の結果を急いで結論へ変えず、どの条件が未確認かを質問として残します。見積もりの形式や説明順を変えることが受注を保証するものではありません。
提示後の確認とチームレビューで次の対応を決める
提示後は、相手の状態を推測せず、確認できた事項と次の連絡予定を残します。チームでは案件条件と改訂理由を分けて振り返ります。
返信の有無にかかわらず確認事項と連絡予定をそろえる
提示後は、相手が検討中か、条件の確認が必要か、連絡時期を希望しているかを、確認できた範囲で記録します。無返信を失注理由に置き換えず、こちらから確認する事項と、相手が確認する事項を分けて次回の連絡を決めます。
見積もり送付後の確認メールを作る場面では、提示後のフォロー文例も、伝える前提を整理する材料になります。
レビュー表では状態・改訂理由・回答所要日数を案件条件と分けて見る
チームで振り返る時は、提示目的、条件の確定度、残る確認、版、承認状況、提示日、相手の反応、次の対応を同じ表で確認します。回答までの所要日数や改訂理由を見る場合も、対象期間と案件条件を決め、案件差を手順の効果と混同しません。
この表はチームで確認項目をそろえるための例です。件数や割合を根拠なく加えず、次回に変える確認項目を選ぶために使います。
たとえば当月に初回見積もりを提示した案件を対象とし、月末時点で返信済み・回答待ち・見送りを分けます。返信までの日数は返信済み案件だけで集計し、回答待ちの件数を別に示します。改訂理由は顧客の範囲変更、提供側の記載訂正、期限の更新などに分け、同じ案件の複数の改訂を案件数と混同しません。これにより、待っている案件が集計から消えたり、改訂が多いだけで品質が悪いと判断されたりすることを避けられます。
確認欄 見る理由 提示目的と確定度 概算か正式かの判断を確認する 改訂理由と版 変更した条件を追う 連絡予定と次の対応 推測で止めず確認を続ける
まとめ
営業で見積もりを提示する時は、価格を出す順番を固定せず、依頼目的と条件確定度から概算・正式・更新・再見積もりを選びます。仮定と未決事項、承認、提示後の確認を記録し、比較や価格相談では前提の差を分けて確認しましょう。
