見積書はCRMと販売管理のどちらで作る？作成先の選び方と受注までの確認点

見積・商談・受注は、何を決める記録？

架空の工業部品卸で、顧客から「ボルト100本ほしい」と相談を受けた例を見てください。

営業は相談内容を記録し、見積で品目や数量などの条件を整理します。管理担当は注文書と見積の品目・数量・価格を照合します。この例では価格が未確認です。内容が違う、または分からないときは営業へ確認し、条件を確かめてから受け付けます。画像は架空例で、自動登録や注文完了の実績ではありません。

見積は提示する条件、商談は検討中の案件、受注は注文を受け付けた記録として分けます。CRMは顧客との関係や営業のやり取りを管理する仕組み、販売管理は受注・出荷・請求などの販売業務を管理する仕組みです。機能の範囲は製品で違うので、名前だけで作成先を決めません。

この架空会社では、問い合わせから品目や条件を聞き、見積を作り、条件変更があれば改訂し、顧客の回答を管理担当へ渡す仕事を想定します。見積書が保存された状態、相手へ提示した状態、相手の回答を受けた状態、注文として登録してよい状態を一つの「完了」にまとめないでください。

最近の見積一件について、依頼の元資料、入力した人、顧客へ渡した版、回答の記録、注文担当が受け取る資料を並べます。実際に注文にならなかった見積も混ぜて消さず、その後どこで仕事が止まるかを確認します。

次の行動：営業と管理担当で、「見積作成」「提示・改訂」「注文受付」の境目を、現行資料の名前で説明してください。見積の作成先を決めた後のデータ同期は、CRMと販売管理の記録・更新条件をそろえる方法へ分けます。

いまの見積で、どの入力を減らしたい？

ボルト100本の依頼を例に、どこで同じ情報を入力し直すかを見ます。

依頼から見積、注文への引き継ぎまで同じ項目を追い、重複入力と不足情報を分けて調べます。価格は要確認で、時間短縮の実績を示すものではありません。

減らしたいのが二重入力か、見積の前に行う案件入力か、改訂後の転記かを分けます。どれも「手間」ですが、変える場所と残る仕事が違います。入力の回数を減らしても、注文担当が品目や版を調べ直すなら、後工程へ仕事が移っただけかもしれません。

営業に「見積が欲しいという依頼を受けてから、最初の書類を作るまで」を説明してもらいます。会社・送付先、商品、数量、価格の根拠、条件、社内で確認する人など、実際に必要な情報を挙げます。これは入力項目の一般的な保証ではなく、自社の一件で不足を調べる観点です。

毎回同じ品目を使う場合と、都度条件を調整する場合では、残す入力も違います。単価表の値を使ったことだけで、その顧客へ提示してよい条件だと判断せず、適用する価格や例外を確認する担当へ戻します。

次の行動：一件の入力を順番に並べ、「この転記を減らしたい」「この確認は残す」と線を引きます。誰の仕事が増減するか答えられる粒度で、提供会社へ説明してください。

候補製品で見積を作る前に、何が必要？

ボルト100本の見積を作る前に、利用条件と必要な情報を確認します。

プラン・権限、顧客や案件、品目と価格をそれぞれ照合します。実際に作れるかは対象製品と契約の条件で確認してください。

対象の見積機能で、利用条件と作成に必要な記録を確かめます。製品名が同じでも、契約中の版、プラン、利用者の割当や権限、使っている旧機能と現行機能で前提が異なることがあります。契約が未確認なら、機能紹介だけで自社でも使えるとしません。

HubSpotの現行見積を例にすると：英語公式はRevenue Hub Professional／Enterprise、作成者の対象利用者枠（seat）と権限を前提にし、legacy quotesとは説明を分けています。商談以外の入口もありますが、見積一覧から開けることだけで、商談との関係や必要入力がなくなるとは判断しません。現行の見積作成の公式説明で利用中の条件を確認します。

提供元への質問は、「商談の入力を飛ばせますか」だけでなく、「この版・利用者では、会社・案件・明細のどれが必須ですか。標準で引き継ぐ値は何ですか。追加の自動化を組むなら誰が管理しますか」とします。自動で案件を作る案にも、誤った関連先、不要な案件、訂正・停止時の仕事があり得ます。

ある利用者本人は、Sage200で扱う見積・注文の事務を減らすためHubSpotの利用を考え、先に商談を作る手間を相談しています。これは困りごとの一例です。投稿の件数・割合を日本の需要量やこの架空会社の成果へ使わず、返信の自動化案を公式手順として採用しません。投稿者本人の相談

次の行動：製品管理者と契約・見積機能の種類・利用者・必要記録をそろえ、標準、設定、追加対応、人が行う仕事へ回答を分けてください。実アカウントの設定変更や見積送信を、記事を読むための作業にはしません。

販売管理へ残す案と、CRMで作る案を比べる

同じボルト100本の見積を、二つの作成先で比べます。

販売管理とCRMそれぞれの入力と利用条件を調べ、どちらでも提示する版と注文の受け渡し先を確認します。注文先は未確認です。

同じ見積の条件を使い、作成先を変えたときに誰の何が変わるかを比較します。現在の販売管理に商品や価格条件、改訂の運用が集まっているなら、見積作成はそこへ残し、営業へ必要な状況を返す案も候補です。CRMへ移す案では、営業の案件と見積を近くで扱える一方、必要な商品情報や注文への引継ぎをどこで管理するかが残ります。いずれも本例で対応可能と実証した結果ではありません。

実際の製品条件、現行側の役割、利用プラン、注文作成先、採用した版、入力時間、費用、試験結果は未確認です。未確認の項目を、0・不要・自動処理の成功として埋めません。二案は修正前後や優劣の実績を比べたものではありません。

販売管理へ残す案が合いそうなら、営業が見積の状態を知るのに必要な情報へ連携範囲を絞れるかを質問します。CRMで作る案が合いそうなら、作成前の入力と改訂・注文への受渡しが一件で成立するかを試験対象にします。必須条件が合わない、回答が不足する場合は、候補や範囲を見直します。

次の行動：両案の同じ行へ、確認した根拠と残る質問を記入します。「CRMに見積機能あり」という一項目だけで採用せず、費用・利用条件・管理担当の回答が出てから判断します。

どの見積から、いつ注文を作ってよい？

ボルト100本の見積を変更した場合に、どの版を注文の根拠にするかを見ます。

新しい版が自動的に採用済みになるわけではありません。顧客へ渡した版と注文の条件を照合し、違い・不明点は確認します。

最新の見積と、注文へ進めることを確認した見積は同じとは限りません。複数案、価格変更、数量変更、提示期限などで改訂する場合、顧客へ渡した内容と、社内が見ている内容が食い違うことがあります。作成日時が新しいだけで注文対象へ選ばず、どの版を相手へ示し、どの回答と結び付くかを確認します。

顧客への提示、社内の承認、顧客からの受付根拠、製品内の状態、実際の注文登録を分けます。システムに承諾という状態があっても、自社が必要とする確認や注文への引継ぎを全部満たすとは限りません。個別取引の契約成立を本記事で判断するものでもありません。

HubSpot公式には、同じ商談で複数の見積を公開した場合に、商談の金額・明細へ影響する説明があります。作業中の明細と顧客へ渡す版を同じものと思い込まず、改訂後に何が変わるかを確認します。また承諾後の請求等の自動処理にはbeta参加や設定の条件があるため、自社の販売管理で注文が自動作成される保証にはしません。

見積の構成や価格計算を扱うSalesforce CPQの公式教材では、注文生成に使う見積のPrimary指定と、設定によるApproved条件を説明しています。商談なしで注文を作る場合の設定も同パッケージ固有の説明です。この名称や手順をHubSpotや全CRMへ移さず、利用製品で「どの見積を対象に、何がそろったら注文へ進めるか」を質問する参考にします。Salesforce CPQの注文生成の前提

次の行動：複数案から一つを採る例を、対象製品で説明してもらいます。旧案を誤って注文へ進めないこと、数量変更後の明細、取消・訂正の戻し先まで試験候補にします。注文受付後の在庫・出荷・請求は、販売管理システムの要件整理で別に具体化します。

一件を試して、使う範囲と残る仕事を決める

架空のボルト100本を使い、試行前の期待と実際の結果を分けます。

入力から注文への引き継ぎで必要な情報を渡せるかを試す計画です。実際の結果は未実施で、結果を記録してから残る仕事を相談します。

同じ架空の見積を使い、必要入力から改訂・受渡しまで通して比べる計画を作ります。誰でも使える実アカウントや、実顧客への送信・実注文を前提にしません。管理担当と提供会社が認めた試験場所、利用者の役割、対象の版と設定、架空資料を先に合わせます。

図の確認は未実施の計画です。二案の結果や費用が埋まった、合格済みの図ではありません。

標準機能でできたという回答なら、その対象版・設定・利用者で再現できる根拠を確認します。追加対応が必要なら、作成・変更・例外のどこを誰が作り保守するかを見積条件へ入れます。人が確認する案なら、資料と判断条件を残し、代理担当でも同じ版へ戻れるかを確かめます。

次の行動：試す操作ごとに期待する結果と確認担当を決め、実施後だけ実際の結果を別欄に書きます。採用した範囲と保留する範囲を、営業と管理担当で読み合わせてください。

まとめ：見積の一件を持って、作る場所を決める

ボルト100本の一件を例に、見積の作成先を決めるための質問を整理します。

依頼と見積を持ち寄り、二案の入力と渡し方を比べます。提示する版と受け取る担当を確認し、分からない条件と質問先を残します。

見積の作成先は、入力の少なさと注文へ渡す条件を同じ一件で比べて選びます。販売管理へ残す案、CRMで作る案のどちらも、元資料、商品条件、改訂版、顧客へ渡した内容、注文を作る根拠が追えることを確認します。機能があることや接続できることだけで、仕事全体が減るとは決めません。

この説明例の二案は、実績や優劣の比較ではありません。注文作成先、改訂の運用、採用版、入力時間、全費用、試験結果は未確認です。製品の前提条件を確かめ、不足する回答を担当へ返した後、試験で得た結果から範囲を選びます。

今日の一歩：顧客情報を伏せた見積一件を、営業と管理担当で並べてください。「この転記を減らしたい」「この版を相手へ渡す」「この条件が足りないので注文は保留」と言える一箇所を選び、その同じ資料を提供会社への質問へ変えましょう。