「見積から注文へ」とは、合意した見積を打ち直すことなく、実際に出荷できる注文に変える工程です。 依頼、価格付け、交渉、承認、承諾、変換という流れです。BtoBの販売のうち「これが当社の価格です」と「注文が入りました」の間の区間であり、合意した数字が最も失われやすい場所です。
これをめぐる混乱の半分は語彙の問題なので、この記事はそこから始め、それから各段階、工程が実際に壊れる場所、Shopifyでの形、そして自社の工程が機能しているかの測り方をたどります。
見積から注文、見積から入金、注文から入金、CPQ
四つの言葉が大きく重なり合い、会話でもソフトウェアの宣伝でも日常的に入れ替えられます。それぞれ異なる範囲を扱います。
| 用語 | 開始点 | 終了点 | 通常の担当 |
|---|---|---|---|
| CPQ(構成・価格・見積) | バイヤーの要件 | 見積の送付 | 営業 |
| 見積から注文 | 見積の依頼 | 確定した注文 | 営業と業務 |
| 注文から入金 | 注文 | 入金の完了 | 業務と経理 |
| 見積から入金 | 見積の依頼 | 入金の完了 | 商業活動の連鎖全体 |
ここから二つのことが導かれます。CPQは「見積から注文」が面白くなる場所で止まります。 正しい見積を作ることを扱い、その後で合意に何が起きるかは扱いません。そして**「見積から入金」は「見積から注文」と「注文から入金」の合計です。** だからこそ「見積から入金」として売られるソフトウェアは、通常、請求機能を後付けした見積ツールか、見積機能を後付けしたERPのどちらかです。
道具を検討しているなら、有用な問いはどの呼び名を使っているかではありません。その範囲がどこで始まりどこで終わるか、そして各境界での引き継ぎが自動なのか、人が何かを打ち直しているのかです。
各段階と、それぞれを生き延びなければならないもの
「見積から注文」の工程には六つの段階があります。各段階で重要なのは何が起きるかだけでなく、何が無傷で先へ運ばれなければならないかです。
| 段階 | 何が起きるか | 何が生き延びなければならないか |
|---|---|---|
| 依頼 | バイヤーが特定の品目と数量について価格を尋ねる | 要件:商品、数量、仕様、納品先、必要期日 |
| 価格付け | 価格を入れた提案を作る | 明細価格、値引き、送料、有効期限。メッセージではなく記録として |
| 交渉 | 双方が条件の合意まで再見積を重ねる | すべてのラウンドと変更点。「何に合意したか」が争点にならないように |
| 承認 | 商談がそれに値するときの社内の決裁 | 誰がいつ、何を根拠に承認したか |
| 承諾 | バイヤーが確約する | 承諾された正確な版と、承諾した人 |
| 変換 | 合意が注文になる | 合意した価格、条件、そしてPOの参照番号 |
右の列を上から下へ読むと、一貫していることが明らかです。どの段階も、合意した数字を失う機会です。 機能している工程とは、注文上の価格が双方の合意した価格であると証明でき、そこに至った経緯を示せる工程です。
「見積から注文」が実際に壊れる場所
実務では、失敗の形は事業を越えて一貫しています。
- 二つ目のシステムへの打ち直し。 最も多く、最も高くつくものです。誰かが承認された見積を読み、注文に打ち込みます。桁の入れ違いが、月末まで誰も気づかない利益の問題になります。
- 合意と注文の間で価格がずれること。 見積はこう言ったのに、注文は今日のカタログから作られました。打ち直しの静かないとこであり、より厄介です。正しく見えるからです。
- 承認がメールに存在すること。 管理者がやり取りの中で「私はいいと思います」と返信します。半年後、22%の値引きを誰が承認したのか誰にも答えられません。
- 条件は合意されたのに適用されないこと。 交渉でNet 30に合意したのに、注文が購入手続きでの支払いを求めて出ていきます。あるいはもっと悪く、バイヤーの経理チームが自分たちの手続きでは支払えないものを受け取ります。
- 一部承認が新しい商談として扱われること。 バイヤーが11行のうち8行を求めています。工程が8行を変換して3行を開いたままにできないなら、3行を失うか8行を遅らせるかのどちらかです。
- 監査証跡がないこと。 版、承認者、承諾、変換がそれぞれ別の場所に存在します。価格がどう決まったのかを尋ねられると、組み立て直すのに午後いっぱいかかります。
これらのどれも価格の問題ではないことに注目してください。引き継ぎの問題、つまりある段階で分かっている事実が次の段階に届かない問題です。
Shopifyでの「見積から注文」
Shopifyには見積というオブジェクトが標準では存在しません。そのモデルはカートまたは注文から始まるため、依頼・価格付け・交渉・承認・承諾の段階はプラットフォームの中に居場所がなく、最後の段階には明白な居場所があります。Shopifyの下書き注文です。
そのため、ShopifyにおけるBtoBの「見積から注文」の工程の形はかなり明確です。見積の一生は見積アプリで扱い、それから承認された見積をネイティブの下書き注文に変換します。そうすればできあがった注文が、事業の残りがすでに存在する場所に収まります。レポート、税、出荷、アプリ、会計から見て、それは通常のShopifyの注文です。実際そうだからです。
もう一つの選択肢、つまり注文を自分のシステムに保持する見積ツールは、この工程が取り除くために存在する引き継ぎの問題を、そのまま再導入します。
その変換の仕組みと、下書き注文にできることとできないことはShopifyのBtoB下書き注文で扱っています。この記事の残りは工程に留まります。
何が引き継がれ、何が再計算されるか
「見積から注文」についての文章の多くが飛ばす部分であり、注文上の数字が合意した数字と一致するかどうかを決める部分です。
交渉した明細価格は引き継がれます。 カタログから読み直されるのではなく、変換時に記録されます。それが要点です。三週間前に合意した価格が、先週の火曜のカタログの変更を生き延びます。
税と送料は再計算されます。 Shopifyは下書き注文の作成時に、現在の規則と現在の配送先住所に対して両方を計算し直します。そうしなければなりません。税は商品がどこへ行くかに依存する法的な計算であり、住所は見積の時点から変わっているかもしれないからです。
つまりこの二つは食い違い得ます。 それを無視する工程は、誰かを驚かせる工程です。健全な扱い方は、見積の数字と再計算された数字を比べ、差が大きければ止めることです。QuotWayでは、あらゆる差分が見積の履歴に記録されます。税のずれが設定したしきい値(既定では2%)を超えると、注文が出る前に明示的な確認が必要になり、自動化された変換は人のために停止します。送料のずれは、止めることなく確認できるよう提示されます。
想定外の差の最もよくある原因は規則の変更ではありません。提案と変換の間で配送先住所が変わることであり、しきい値を調整するのではなく住所を確認することで直せます。
素朴な工程を壊す事例
「バイヤーがすべてを承認し、一つの注文が出る」だけを扱う「見積から注文」の工程は、四半期のうちにこれらすべてに出会います。
一部承認。 バイヤーが決められる明細を確約し、残りの交渉を続けます。承認された明細をすぐ変換すれば、残りに人質に取られることなく、今日決められる商談を成約させられます。(見積の一部承認。)Professionalプラン以上です。
一つの見積、複数の注文。 異なる納品先、段階的な出荷、別々の倉庫です。承認された見積を複数の下書き注文に分割すれば、各注文が実際の出荷の形に合います。各グループがそれぞれの送料を調整するため、バイヤーが一つの輸送費を期待しているならまとめて変換してください。
商品ではない明細。 組立費、輸送費、受注生産の品目です。個別の明細はバリエーションの裏づけなしに名称と価格を持ち、個別明細として注文に引き継がれます。(個別・手動の明細。)
前払いのお金。 購入手続きで受け取る手付金と、条件に基づく残額です。「半額前払い、残額はNet 30」という形です。ShopifyではこれはPlus専用の機能で、当社側ではProfessionalプランからです。
支払条件。 BtoBに対応したストアの組織バイヤーについては、見積の変換時にバイヤーのShopifyの支払条件を適用できるため、交渉を伴う商談が決済ではなく請求されます。(ShopifyのBtoBの支払条件。)その変換時の挙動はEnterpriseプランにあります。
設計に織り込む価値のあるプラットフォームの制限が一つあります。Shopifyの下書き注文が保持できる明細は最大200件です(注文では500件)。バイヤーが日常的に数百の異なる商品を一度に発注するなら、分割を計画してください。
承認は変換の後ではなく前に属する
繰り返し起きる設計上の誤りは、決裁を最後に置くこと、つまり注文ができてから承認することです。これは二重の意味で遅すぎます。バイヤーはすでに承認していない価格を見てしまっていますし、注文を取り消すことは提案を送らないことよりはるかに悪いのです。
承認は、事業の外の誰かに対して確約が行われる二つの地点に属します。提案が送られるときと、バイヤーが承諾するときです。一つ目を関門にすれば、担当者が承認されていない価格をそもそもバイヤーの前に置けません。二つ目を関門にすれば、バイヤー自身の組織が確約の前に調達の決裁を回せます。
これが慣習ではなく統制であるためには、確認が画面上に表示されるのではなくサーバー側で強制されなければなりませんし(承認の強制の仕組みをご覧ください)、しきい値は設定される前に書き留められていなければなりません。それが承認マトリクスの役割です。
「見積から注文」を測る
二つの数字と、一つの注意です。
見積から注文への成約率 - 注文になった見積の割合です。何かと比べる前に、母数を決めてください。受け取った依頼、送った提案、判断に至った見積のどれかです。同じ事業が同じ月に、どれを選ぶかによっておよそ30%から60%超までの数字を正直に報告できてしまいます。
サイクルタイム - 依頼から注文までの期間です。最初の応答、提案の応答、合計に分ける価値があります。1時間で受領を伝え3日で見積を出す事業は、そのどちらもしない事業とはまったく異なる問題を抱えているからです。
注意点。 そのどちらについても、信頼できる公開のベンチマークはありません。出回っている数字は、標本も方法も開示していないベンダーのページから来ていますし、この分野の厳密な研究は見積への応答ではなくリードへの応答を測っています。公開されたBtoBの見積のベンチマークが実際に述べていることがそれぞれを追跡しています。見つけた数字とではなく、固定した定義に基づく自社の傾向と比べてください。
具体例
ある販売店が、年間契約価格である部品2,400個の依頼を受け取ります。
- 依頼。 バイヤーがストアフロントから、数量、納品先、6週間先の必要期日を添えて提出します。カタログ価格は$12.40なので、依頼の概算は$29,760です。
- 価格付け。 担当者が単価$11.20、つまり9.7%の値引きで提案を作り、パレット輸送費$986と14日間の有効期限を付けます。合計$27,866です。
- 承認。 値引きが10%未満なので承認の段階は作動せず、提案はすぐに送られます。12%の値引きなら、先に営業マネージャーへ回っていたはずです。
- 交渉。 バイヤーが$10.75で再見積を出します。担当者が$11.00で返し、これは下限価格より上です。両方のラウンドが版として記録され、バイヤーは三回目を承諾します。
- 承諾。 バイヤーが自分の顧客アカウントで承諾します。承諾には時刻とメールアドレスが刻まれます。
- 変換。 承認された見積が単価$11.00の下書き注文になります。$12.40ではありません。Shopifyが税と送料を再計算し、輸送費が見積より$14高く戻ってきますが、これは提示されつつしきい値の範囲内です。バイヤーのNet 30の条件が適用され、注文は決済ではなく請求されます。
所要は4日です。請求書上の数字は三回目のラウンドで合意した数字であり、その間のすべての段階が記録に残っています。
よくある失敗
- 注文を保持するツールで見積を出すこと。 引き継ぎの問題を移動させただけで、解決していません。
- 見積を記録ではなく文書として扱うこと。 PDFは出力です。争いを決着させるのは版管理された履歴です。
- 最後に承認すること。 注文ではなく、提案と承諾を関門にしてください。
- 再計算を無視すること。 税と送料は動きます。起きる前に許容範囲を決めてください。
- 有効期限がないこと。 期限のない見積は、無期限に確約した価格であり、決して片づかないパイプラインです。
- 母数を固定せずに成約を測ること。 定義が動くなら、その数字は無意味です。
- 順調な道筋だけを想定して設計すること。 BtoBにおいて一部承認と分割出荷は例外ではなく、日常です。
よくある質問
「見積から注文へ」とは何ですか?
「見積から注文へ」とは、合意した見積を打ち直すことなく、実際に出荷できる注文に変える工程です。依頼、価格を入れた提案、交渉のラウンド、社内の承認、バイヤーの承諾、そして注文への変換を含みます。その目的は、注文上の価格が双方の合意した価格であると証明でき、そこに至った経緯の記録が残ることです。
「見積から注文」と「見積から入金」の違いは何ですか?
「見積から注文」は見積の依頼から確定した注文までを扱います。「見積から入金」は同じ連鎖を出荷と請求を経て入金の完了まで延長するため、「見積から入金」は「見積から注文」と「注文から入金」の合計です。CPQはさらに狭く、見積が出た時点で終わり、その後に合意に何が起きるかは扱いません。
「見積から注文」のワークフローとは何ですか?
「見積から注文」のワークフローとは、見積が注文になるまでにたどる順序です。依頼、価格付け、交渉、承認、承諾、変換です。ただしワークフローは段階だけではありません。それに付随する規則、つまりどの値引きに決裁が必要か、見積がどれだけ有効か、バイヤーが一部だけを承認したときに何が起きるかも含みます。
Shopifyは「見積から注文」に標準で対応していますか?
完全にはしていません。Shopifyには見積というオブジェクトが標準では存在しないため、依頼、交渉、承認の段階はプラットフォームの中に居場所がありません。最後の段階には居場所があります。承認された見積はShopifyネイティブの下書き注文になれます。実務上それは、見積アプリが一生を扱い、その結果を別のシステムに保持するのではなく、実際の注文としてShopifyへ渡すことを意味します。
見積と注文の間で価格には何が起きますか?
交渉した明細価格は、カタログから読み直されるのではなく変換時に記録されるべきで、そうすれば合意した価格が後のカタログの変更を生き延びます。税と送料は異なります。注文の時点で現在の規則と現在の配送先住所に対して再計算されるため、見積の数字と異なり得ます。健全な工程はその二つを比べ、差が大きければ一時停止します。
見積の一部を注文にできますか?
はい、工程が一部承認に対応していればできます。バイヤーが決められる明細を確約し、それらがすぐ注文に変換され、残りの明細はさらなる交渉のために開いたまま残ります。持っておく価値があります。そうでなければ、今日成約できる商談を、まだ議論中の明細に人質に取られることになるからです。
「見積から注文」にはどれくらいの時間をかけるべきですか?
信頼できる公開のベンチマークはありません。出回っている数字は標本を開示していないベンダーのページから来ていますし、厳密な研究は価格の入った見積までの時間ではなくリードへの最初の応答を測っています。自社のサイクルタイムを測り、最初の応答と提案の応答に分け、他人の数字とではなく固定した定義に基づく傾向を追ってください。
QuotWayの位置づけ
QuotWayはEFOLIが開発した、Shopify向けのBtoB見積・交渉アプリです。Shopifyが扱わない段階をカバーします。ストアフロントやカートからの見積依頼、明細ごとの価格と有効期限を持つ版管理された提案、双方向の再見積、提案が送られる前にサーバー側で強制される承認ポリシー、そして顧客アカウントまたはホスト型ポータルでのバイヤーの承諾です。それからその結果を、交渉した価格を運ぶネイティブの下書き注文としてShopifyへ渡します。税と送料は再計算され、ずれがあれば記録されます。加えて、Professionalでは一部承認と分割変換、BtoBに対応したストアのEnterpriseでは変換時の支払条件、Shopify PlusのストアではProfessionalから手付金が利用できます。無料のLiteプランで流れ全体を回せます。見積を注文に変換する、QuotWayにできることとそのプラン、プランと料金、またはShopifyにQuotWayを追加するをご覧ください。
出典
- Shopifyヘルプセンター:下書き注文
- Shopifyヘルプセンター:BtoBを利用するための要件と考慮事項 - 注文と下書き注文の明細数の上限。
- Shopifyヘルプセンター:ShopifyのBtoB
関連記事
QuotWayがこれをあなたのストアでどう扱うかをご覧ください。