見積の承認フローをCRMで組む｜多段承認と価格マスターの設計

見積の承認フローをCRMで組むとは、「何を超えたら止めるか」「誰の判断で通すか」「その記録をどこに残すか」の3点をシステムの側に固定する作業です。 承認者を決める作業ではなく、条件を決める作業だと考えてください。 条件は金額と値引き率（受注生産なら見積粗利率）の掛け合わせで決め、承認者・承認日・承認時の値引き率を取引側の記録として必ず残します。

「あの見積、部長の承認取ったんだっけ」——受注してから確認する会社は少なくありません。

見積の承認は、多くの会社で口頭とメールとExcelに分散しています。営業が価格表から金額を拾い、Excelで見積書を作り、値引きが大きければ上長にメールで相談し、返信をもって承認とする。この運用は、承認者が席にいて、案件が少なく、値引きの判断基準が共有されている間は回ります。しかし規模が大きくなると、誰がいつ何を根拠に承認したのかが、どこにも残っていない状態になります。

承認の設計でよくある誤解は、承認者の役職さえ決めれば運用が回るというものです。実際に効くのは、どこに線を引いて止めるかという条件のほうです。条件が言語化されていないと、承認者を何人並べても判断は属人的なままになります。

この記事では、HubSpotを例に、見積の承認フローの設計を整理します。受注生産や個別見積が中心で、値引き交渉が日常的に発生する会社の管理者、営業部門と管理部門の間で見積の統制をどう取るか悩んでいる方に向けた内容です。次の4点がわかります。

• 承認が必要になる条件の決め方 ── 金額だけで線を引くと機能しない理由と、代わりの軸を示します
• 標準機能で組める範囲 ── HubSpotの見積もり承認機能でできること、できないことを整理します
• 取引ステージで組む承認 ── 承認機能を使わずにステージで統制する設計です
• 価格マスターと値引きの持ち方 ── 商品ライブラリをどう作り、値引きをどう記録するかを説明します

読み終える頃には、自社の承認基準をどうシステムに落とすかのたたき台が作れる状態になります。ぜひ最後までご確認ください。

これは特定の企業の運用ではなく、承認フローの組み立て方を一般化した設計例です。以降では、この流れを構成する要素を順に見ていきます。

承認フローが必要になるのはどんなときか

まず、そもそも承認を挟むべき見積とそうでない見積を区別します。ここを曖昧にしたまま仕組みを入れると、承認は形だけになります。区別の軸は金額ではなく、判断が要るかどうかです。

すべての見積に承認を挟むと形骸化する

承認フローの導入でよくある失敗は、全件を承認対象にしてしまうことです。1日に何十件も承認依頼が飛ぶようになると、承認者は中身を見ずに通します。これは統制が効いているように見えて、実際には何も見ていない状態です。

承認が本当に必要なのは、次のような見積です。

金額の大小と、承認の必要性は必ずしも一致しません。小額でも仕様が特殊なら承認が要りますし、大口でも標準品の定価販売なら承認は不要です。

条件は「掛け合わせ」で決める

そこで、承認要否の判定は複数の条件の掛け合わせで設計します。

これは特定の企業の基準ではなく、承認条件の組み立て方を一般化した例です。実際のしきい値は、自社の粗利構造と決裁規程に合わせて決めてください。

このマトリクスを先に作ってから、システムの設定に入ります。順番が逆になると、システムの制約に合わせて基準を曲げることになります。

HubSpotの見積もり承認機能でできること

HubSpotには、見積もりに対する承認機能が標準で用意されています。冒頭に示した多段承認の流れを、どこまで標準機能で組めるのかを確認します。

対象プランと設定できる範囲

見積もりの承認機能は Revenue Hub の Professional および Enterprise で利用できます。標準の承認では承認者を最大10人まで指定でき、「全員の承認が必要」か「1人以上の承認で足りる」かを選べます。承認が必要になる条件は、プロパティーベースのフィルターで設定でき、たとえば「特定の割引額を超える見積もり」や「電子署名の承認方法を使用する見積もり」といった条件を組み合わせられます（見積もりの承認を設定する）。

さらに事前承認という仕組みがあり、こちらは Enterprise のみで利用できます。事前承認では最大5つの承認シーケンスを作成でき、1つのシーケンスあたり10人までの承認者を優先度順に設定できます。見積もり金額・割引レベル・SKUなどを条件に、ワークフロールールで細かく分岐させることも可能です。

標準機能が向いているケース

標準の承認機能は、次のような運用に向いています。

• 見積書をHubSpotの見積もり機能で作成している
• 承認の判定材料が、見積レコード上のプロパティーで表現できる（金額・割引額など）
• 承認者が固定、または少数のパターンで決まる

逆に言うと、見積書を別のシステムやExcelで作っている場合、この機能は使えません。見積レコードが存在しないためです。

正直な限界

承認機能には、次のような制約があります。

• 承認の対象は見積レコードであり、受注そのものを止める仕組みではありません。承認を経ずに取引を受注ステージへ動かすことは技術的には可能です
• 承認者が不在のときの代理承認は、シーケンスの設計で吸収する必要があります
• 承認履歴は見積単位で残るため、「この案件で何回差し戻したか」を横断で集計するには別途プロパティーが要ります

この限界を理解したうえで、次に説明する取引ステージ側の統制と組み合わせるのが実務的です。

取引ステージで組む承認

見積書を別システムで作っている会社や、Professional未満のプランで運用している会社では、取引のパイプライン側で統制を掛けます。承認機能を使う場合でも、受注そのものを止めるにはこちらの設計が要ります。ステージと必須プロパティーだけで組めるため、追加の費用も発生しません。

承認ステージを挟む

パイプラインに「社内承認待ち」というステージを1つ挟み、その前後で必須プロパティーを設定します。HubSpotでは条件付きステージプロパティーの設定画面で、プロパティーを必須にするチェックボックスをオンにできます（パイプラインを設定・カスタマイズする）。

ステージ設計の例を挙げると、次のようになります。

このとき「値引き率」は計算プロパティーで自動算出します。営業に手入力させると、そこが最初に崩れます。計算プロパティーはProfessional以上で利用でき、カスタム式で算術演算や条件分岐を組めます（計算プロパティーを作成する）。

通知と記録を分けて考える

承認の設計では、通知（誰に知らせるか）と記録（何を残すか）を分けて考えると整理しやすくなります。

• 通知：ステージが「社内承認待ち」に入ったら、条件に応じた承認者へタスクを作成し、社内チャットへ通知を飛ばす
• 記録：承認者・承認日・承認時の値引き率を、取引のプロパティーとして固定する

通知だけを組んで記録を忘れると、半年後に「なぜこの価格なのか」を誰も説明できなくなります。承認フローの本当の価値は、止めることよりも、後から辿れることにあります。ワークフローの基本的な組み方はHubSpotワークフローの設定ガイドで扱っています。

逆行を禁止する

承認済みステージから見積作成ステージへ戻れる設計にしておくと、承認後に金額を書き換えて再提示する運用が生まれます。これを許すと承認の意味がなくなります。

金額を変えたい場合は、新しい見積レコードを作って再度承認を通す。この原則を運用ルールとして明文化してください。システムで完全に禁止するのは難しいため、ここは運用で担保する部分になります。

価格マスターと値引きの持ち方

承認の判定は、標準価格が定義されていて初めて成立します。「何%引いたか」を機械的に出せる状態が前提になるためです。ここが整っていないと、承認のしきい値を決めても判定そのものが人手になります。

商品ライブラリに標準品を登録する

まず、繰り返し出てくる標準品は商品ライブラリに登録します。型番・標準価格・標準原価を持たせておくと、見積作成時に選ぶだけで金額が入り、値引き率と粗利率が自動で計算できる状態になります。

登録の粒度は、「型番単位で価格が決まるもの」までにしてください。仕様の組み合わせで価格が変わる製品を全パターン登録しようとすると、マスターが数万件になって保守できなくなります。

特注品はどう扱うか

受注生産の会社では、そもそも標準価格が存在しない見積が大半、というケースもあります。この場合は「標準価格に対する値引き率」ではなく「見積粗利率」を承認の判定軸にします。

• 商品項目に原価を入力させる（見積時点の見込み原価で構わない）
• 見積金額と原価合計から、粗利率を計算プロパティーで算出する
• 粗利率が一定を下回ったら承認対象にする

この設計にすると、標準価格がなくても統制が効きます。ただし見込み原価の精度が承認の精度を決めるため、原価の入力ルールを先に固める必要があります。

原価の入力ルールを先に決める

見積粗利率を承認の判定軸にする場合、原価に何を含めるかを決めていないと、営業ごとに数字の意味が変わります。ある担当は材料費だけを入れ、別の担当は据付の外注費まで入れる、という状態では、同じ粗利率でも中身が別物になります。

決めておくべきは、次の3点です。

このうち社内工数を含めるかどうかは、どちらでも構いませんが必ず統一してください。含めない設計にすると粗利率が高めに出るため、承認のしきい値もその前提で設定する必要があります。

もう1つ重要なのが、見積時点の見込み原価と、受注後の実際原価を別のプロパティーで持つことです。同じ項目を上書きしていくと、見積の精度（見込みと実績の差）が測れなくなります。この差を測れるようにしておくと、値引きの判断が正しかったかを後から検証でき、しきい値の見直しにも使えます。

値引きは「機能」ではなく「明細」で表す

値引きの記録方法にも設計上の分岐があります。金額を割り引く形で記録すると、後から「なぜ値引きしたのか」が分かりません。

おすすめは、値引きの理由を明細行の名前として残す方法です。「年度末発注割引」「複数台導入割引」といった名前でマイナス金額の明細を1行入れると、値引きの内訳と理由が見積書にも社内データにも同時に残ります。値引き理由が集計できるようになると、どの理由の値引きが実際に受注に効いているのかを後から検証できます。

見積から請求までの一連の流れの設計はQuote-to-Cash（見積から入金まで）の設計、見積から請求書を自動生成する仕組みは見積書から請求書を自動生成する方法で扱っています。

承認フローを回した後に見る数字

仕組みを入れたら、次は効果を測ります。承認フローは入れて終わりではなく、しきい値が現場と合っているかを数字で点検し続ける対象です。見るべき指標は、次の5つに絞れます。

特に見てほしいのは、値引き率の分布でしきい値の直下に山ができていないかです。しきい値が20%のとき、19%台の見積が異常に多ければ、承認を避けるための調整が起きているサインです。この場合はしきい値を下げるのではなく、なぜ19%まで引く必要があるのかを個別に確認するほうが実態に近づきます。

レポートの作り方はHubSpotのレポート・ダッシュボード設計ガイドを参考にしてください。

よくある質問

見積の承認フローについて、ご相談の場でよくいただく質問をまとめました。

Q1. 承認者が出張や休暇で不在のとき、どうすればよいですか。

事前承認のシーケンス設計で、承認者を複数人指定して「1人以上の承認で足りる」設定にする方法が基本です（見積もりの承認を設定する）。あわせて、承認待ちが一定日数を超えたら次の承認者へ自動でタスクを作るワークフローを組んでおくと、止まったまま気づかれない状態を防げます。承認の設計では、通す経路より止まったときの経路を先に決めるのが実務的です。

Q2. 見積書はExcelで作っています。CRMで承認だけ管理できますか。

できます。取引のパイプラインに「社内承認待ち」ステージを挟み、必須プロパティーで承認理由と金額を入力させる設計です。Excelの見積書ファイルは取引レコードに添付します。ただし値引き率の自動計算ができないため、標準価格合計を手入力してもらう必要があります。入力の負荷が上がる分、定着させるには入力しないと次のステージへ進めない制約が必要です。

Q3. 承認のしきい値は、金額と値引き率のどちらで決めるべきですか。

両方を使うのが現実的です。金額だけだと小額の高値引き案件を素通りさせ、値引き率だけだと大口の標準価格案件まで止めてしまいます。「見積金額が一定額を超える」または「値引き率が一定を超える」のいずれかに該当したら承認、という設計が扱いやすくなります。標準価格が存在しない受注生産では、値引き率の代わりに見積粗利率を使ってください。

Q4. 承認機能を使うために、見積書のフォーマットを変える必要がありますか。

HubSpotの見積もり機能で見積書を作成する場合は、テンプレートの選択とカスタマイズが必要になります。既存の見積書フォーマットに社印や特定の様式が求められる場合、そこが移行の障壁になることがあります。フォーマットの再現可否は、承認フローの設計より先に確認してください。ここを後回しにすると、承認の仕組みを組んだ後で「この見積書では出せない」となります。

Q5. 承認履歴は監査で使えますか。

見積単位の承認履歴はシステム上に残りますが、監査対応として何が求められるかは会社ごとに異なります。実務では、承認者・承認日・承認時の金額・値引き率を取引のプロパティーとしても固定しておくことをおすすめします。見積レコードは差し替えられる可能性がありますが、取引側に転記した値は履歴として残るためです。何をどこまで残すかは、自社の規程に照らして先に決めてください。

関連記事

• 製造業のCRMデータ設計 ── 商社・代理店・エンドユーザーの3層をどう持つかを扱っています
• 製造業のHubSpot活用法 ── 製造業でのHubSpot活用の全体像をまとめています
• 建設業の案件パイプライン設計 ── 出来高に応じた分割請求の設計です
• 卸売業のCRM活用ガイド ── 卸売業の見積・受注の考え方を扱っています
• Quote-to-Cash（見積から入金まで）の設計 ── 見積から請求・入金までを一連で設計する方法です
• HubSpotのレポート・ダッシュボード設計ガイド ── 承認フローの効果を測るレポートの作り方です

まとめ

見積の承認フローは、承認者を決める作業ではなく、条件を決める作業です。要点を整理します。

• 全件を承認対象にしない。承認が飛び交うと中身を見ずに通す運用になります
• 条件は金額と値引き率（または粗利率）の掛け合わせで決める。片方だけでは漏れと過剰が同時に起きます
• HubSpotの見積もり承認は Revenue Hub の Professional 以上、事前承認は Enterprise。見積書を別システムで作っている場合は使えません
• 標準機能が使えないなら取引ステージで組む。承認待ちステージと必須プロパティーで統制します
• 通知と記録を分けて設計する。承認フローの価値は、止めることより後から辿れることにあります
• 値引きは理由を明細行の名前で残す。理由が集計できると、どの値引きが受注に効いたかを検証できます

最初の一歩としておすすめしたいのは、「直近1年で社内が議論になった見積を10件集め、そのときの値引き率と理由を並べる」ことです。この10件を見れば、自社のしきい値がどこにあるべきかが具体的な数字で見えてきます。基準を先に紙で決めてから、システムの設定に入ってください。

そのうえで、値引き率の計算プロパティーを1つ作り、既存の見積に当ててみる。ここから始めるのが現実的です。

自社の決裁規程に合わせた承認フローの設計を具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現在の承認の流れをうかがったうえで、設計の方向性をご提案します。