見積と値引きの承認は、四つのルールで管理できます。全員がそこから価格を付ける、有効期間付きの一つの価格表。顧客がすでに見たバージョンを新しいバージョンが上書きすることのない、番号付きの見積。見積が送られる前に承認者が目にする利益率。そして、段階をオーナーが決め、記憶ではなくシステムが強制する値引き承認マトリクスです。顧客が特定のバージョンを承諾すると、それが受注または契約となり、その後のすべての納品、請求書、紛争がそこを参照します。

第一部の演習から見積へ

第一部では、掛け売りを七つのステーションとして整理し、一つの演習を提案しました。未払いの請求書のうち最も古い十件を、その見積、受注、納品の証拠までさかのぼってたどるというものです。最初に探した書類は、顧客が承諾した見積でした。三つのバージョンがあって、どれが承諾されたのか誰も確信がない見積や、誰が与えたのか誰も言えない値引きが見つかったなら、ここから始めます。見積の前にあるもの、つまり商談や見込み客のフォローはこのシリーズの対象外で、サウジ企業向けCRMガイドで取り上げました。

有効期間付きの一つの価格表

多くの会社では、誰もそう決めたわけではないのに、同じ品目に複数の価格があります。マネージャーが先月更新したスプレッドシートの価格、ある営業担当者が似た顧客に送った直近の見積の価格で同僚がそれをコピーしたもの、そしてしばらく更新されていない会計システムの価格です。各営業担当者は一番手近な情報源から価格を付けるので、似た二社の顧客が異なる二つの価格を受け取ることになり、誰もそれを意図していません。

解決策は、責任者のいる単一の価格の情報源です。価格表には各品目やサービスが価格と単位とともに載り、開始日と終了日があります。その形は業種ごとに異なります。

  • 工場または卸売業者。品目と販売単位ごとの価格で、卸売やプロジェクトなど顧客グループごとの価格表を持つこともあり、どの顧客がどのグループに属するかはオーナーが決めます。
  • 建設業者。繰り返し発生する工事項目の単価で、各見積の数量明細書の価格付けに使われ、プロジェクトごとに価格を付ける項目と並んで使われます。
  • 保守会社または不動産運営会社。定められた範囲に対する訪問一回、一時間、または月額契約の価格と、その価格に含まれるものと、交換部品や追加作業など別途請求されるもの。

価格が変わるとき、古い価格表を編集するのではなく、新しい開始日を付けた新しい価格表を発行します。変更前に発行されたすべての見積は発行時の価格に結び付いたままで、後から誰かが価格表を更新したために顧客が見た見積の数字が変わることはありません。価格表の編集はオーナーが指名した一つの役割の権限であり、営業担当者は価格を入力するのではなく価格表から選びます。

一顧客向けの特別価格は、終了日付きの合意です。大口顧客が特定の品目でより良い価格を得る、枠組み合意が一定期間の単価を定める、年間保守契約が訪問一回の価格を固定する、といった場合です。こうした価格は営業担当者の記憶や、顧客の購買担当者とのWhatsAppのやり取りの中にあることが多く、営業担当者が異動すると価格も一緒に消え、同僚が同じ顧客に見積を出すと違う価格が出てきます。特別価格は顧客レコード上の合意として記録するほうがうまくいきます。対象となる品目やカテゴリー、価格または値引き、開始日と終了日、付随する条件、承認者です。そうすればシステムがその顧客の見積と請求書に自動で適用し、期限が切れる前に警告するので、更新は誰も気づかないまま続く習慣ではなく、誰かが下す判断になります。

番号付きの見積：すべてのバージョンが顧客の見たまま残る

第一部では、WhatsAppで送られた修正版に現れ、受注とともに保存されることのなかった値引きについて説明しました。これは、見積が通常同じファイルの中で修正されるために起こります。営業担当者が見積を開き、価格や数量を変え、前のバージョンに上書き保存するのです。二週間後に顧客が見積を承諾しますが、どのバージョンでしょうか？営業担当者のノートパソコンにあるものが、顧客の手元にあるものと同じとは限りません。

ルールは単純です。すべての見積に番号があり、すべての修正はその番号の下の新しいバージョンとなり、送られたバージョンは決して編集されません。システムは各バージョンを、日付、送った人、送り先とともに送ったときのまま保存するので、顧客が見積の価格は違っていたと言ったときには、記憶で言い争う代わりに、その日に顧客が受け取ったバージョンを開けます。見積ファイルはレコードそのものから生成されるので、顧客が見たものはシステムにあるものとまったく同じです。そのうえで、WhatsAppでもメールでも、顧客が慣れている方法で送ります。ファイルがレコードから作られている限り、経路は問題ではありません。

見積には、価格だけでなく、後工程の全員が必要とするものも載せます。

  • 有効期間。有効期限のない見積は開いたままになり、顧客が数か月後に戻ってきて、コストが動いた価格を承諾します。期限が切れたら、新しいバージョンで価格を付け直します。
  • 支払条件。オーナーがこの顧客のために定めたとおりで、これは次の部のテーマです。
  • 範囲と除外事項。建設や保守では、誰も書かなかった一行から数か月後に紛争が始まることがあります。がれきの撤去と清掃は価格に含まれているのか？交換部品は月額契約の対象なのか？
  • 顧客側の参照番号。依頼番号やプロジェクト名です。顧客の経理チームが後であなたの請求書をそれと照合するからです。

顧客が特定のバージョンを承諾すると、そのバージョンが受注または契約となり、顧客が発注書番号を送ってきた場合はそれも一緒に保存されます。その時点から、すべての納品、請求書、紛争がこの受注を参照するので、どの請求書からでも顧客が承諾した価格と、その値引きを承認した人にたどり着けます。これこそ、第一部の演習で探していたものです。

見積が送られる前に承認者の前にある利益率

営業担当者が値引きの承認を求めるとき、承認者は値引き後の価格という一つの数字しか見ていないことが多く、本当に必要な数字なしに経験で判断します。本当の問いは、この値引きの後に自社にいくら残るのか、です。それには価格の横にコストが必要で、コストの出どころは業種によって異なります。

  • 工場と卸売業者。品目カードの品目コストです。仕入コスト、自社で製造する場合は製造コストです。その数字の正確さは、その裏にある在庫と原価計算の正確さ次第です。
  • 建設業者。数量明細書の各項目の材料、労務、機材、下請の見積コストで、利益率は項目ごと、そして見積全体で計算されます。
  • 保守会社。範囲そのもののコストです。訪問回数、技術者の作業時間、価格に含まれる材料と交換部品です。

こうして承認者は一つの画面で、定価、要求された価格、コスト、値引き前後の利益率、そして営業担当者が書いた理由を目にします。競合の価格、大量の数量、あるいは会社が参入したい業種の新規顧客などです。同じ値引きでも、ある見積では受け入れられ、別の見積では受け入れられないことがあります。それぞれの背後にある利益率が違うからです。

誰がコストと利益率を見るかは、販売の判断である前に権限の判断です。オーナーは、営業担当者が自分の限度を知って交渉できるよう利益率を見せると決めることも、承認者だけが見られると決めることもできます。システムがその選択を強制する限り、どちらも正当です。この原則は権限：データがファイルを離れたら誰が何を見るのかで説明しました。ファイルとして回覧されるコスト表は、誰も意図していなかった人の手に渡ります。

値引き承認マトリクス：どの値引きを誰が承認するのか？

値引き承認マトリクスは、一つの問いに答える表です。営業担当者は尋ねることなくどこまで値引きでき、それを超えるものは誰が承認するのか。これは購買側で購買依頼と承認限度として取り上げたのと同じ論理を、反対側から見たものです。あちらでは出ていくお金を管理し、こちらではお金が届く前に手放すものを管理します。

段階そのもの、つまり営業担当者が承認できるもの、営業マネージャーに回るもの、財務マネージャーやオーナーまで上がるものは、オーナーが決めます。それは会社自身の利益率と市場を反映するからです。どこでも正しい上限というものはなく、他社から借りた上限は、厳しすぎて販売を止めることも、緩すぎて何も管理できないこともあります。オーナーは段階を値引き率に基づいて決めることも、値引き後に残る利益率に基づいて決めることもできます。後者なら、すでに利益率の薄い品目で、小さく見える値引きを止められます。

数字より大切なのは、何が値引きに当たるのかを知ることです。価格上の譲歩は、必ずしも「値引き」という名前の行で現れるとは限らないからです。

  • 明示的な値引きで、見積の明細行や見積合計に対するもの。
  • 無償の追加数量、または通常は有料の配送や設置が無料になるもの。
  • この顧客の通常の条件より長い支払条件。それは自社の現金から提供する資金融通だからです。
  • 保守契約での追加訪問、通常より長い保証、または範囲外の小さな作業を無償で行うこと。

これらはすべて同じマトリクスを通します。そうしなければ、書かれた値引きは管理しても、書かれていない譲歩は管理されないまま残ります。購買側のルールはここでも当てはまります。誰も自分自身の値引きを承認しない、権限は個人ではなく役割に属する、すべての承認者には不在時のための指名された代理人がいる、そして承認は承認者の名前と時刻とともに見積バージョンそのものに記録されるので、承認後にバージョンが変われば承認者に戻ります。依頼は承認者のスマートフォンにリンクとして届き、ノートパソコンを開かずに承認できます。承認が遅いことこそ、営業担当者を電話での約束に追い込むからです。

なぜ請求書の後ではなく前なのか？見積で承認された値引きは価格の一部であり、最初から請求書に載ります。販売後に約束された値引きは、付加価値税法施行規則のもとで別の道をたどります。第40条第1項は、供給の価額を変える事由として、あらかじめ合意された価額が何らかの理由で変更される場合を挙げており、そこには販売完了後に提供される追加値引きも含まれます。それが税務請求書の発行後に起こり、請求書上の付加価値税が納付すべき付加価値税を上回る場合、第54条は、元の請求書を明確に参照するクレジットノートを、その事象が起きた月の翌月15日までに発行することを求めています。つまり、請求書の後に電話で与えた値引きは営業担当者と顧客の間にとどまらず、期限付きの税務書類になり、財務部門はそれを発行しなければならないことを知らないかもしれません。個別のケースについて相談すべき先は、税務アドバイザーです。

Origamiの視点

ある会社のために見積のワークフローを構築するとき、私たちはその会社が今実際にどう価格を付けているかから始めます。営業担当者がどこから価格を取っているのか、見積は通常いくつのバージョンを経るのか、誰が値引きを承認するのか、主要顧客向けの特別価格はどこにあるのか。電話で与えられた値引きは、どこで管理を強める必要があるかを教えてくれる前に、現在の承認がどこで遅すぎるかを教えてくれます。

そのうえで、それをシステムが強制するワークフローに変えます。有効期間付きの価格表、ファイルがレコードから作られる番号付きバージョンの見積、各役割の権限に応じて表示される利益率、オーナーがプログラマーなしで段階を調整できる値引きマトリクス、スマートフォンに届く承認、そして会計システムと電子インボイスにつながる受注となる承諾済みの見積です。これは、私たちのサービスの一環として構築するカスタムシステムの一部です。

今週の演習：顧客が承諾した直近二十件の見積を見直す

どんなシステムよりも先に、価格表と顧客の間で実際に何が起きているのかを把握する必要があります。営業マネージャーと財務マネージャーが、一回か二回の打ち合わせで実施できます。

  • 顧客が承諾した直近二十件の見積を取り出し、第一部の演習で見つかったなら、十件の請求書の裏にある見積も加えます。
  • 各見積について、価格がどこから来たのかを問います。現行の価格表か、以前の見積か、手入力か。
  • 各見積のバージョン数を数え、顧客が承諾したバージョンを特定し、それを顧客が見たとおりの形で見つけられるかを確認します。
  • 見積の中のすべての譲歩を書き出します。値引き、無償の数量、無料配送、より長い支払条件、追加訪問で、それぞれの横に誰が承認したのか、その承認がどこに記録されているのかを書きます。
  • 利益率が把握されていたかを記録します。見積を承認した人が、承認したその時点で把握していたかどうかです。

誰が承認したのか誰も言えない譲歩の数が、この部のベースラインです。次に、望む値引きマトリクスを一枚の紙に書きます。自社で何が値引きに当たるのか、自社に合う段階、各段階を承認する役割、承認者が不在のときに誰が代わるのか。その一枚と二十件の見積で見つけたものとの差が、システムが埋めるべきものです。

次の部では

価格には一つの情報源があり、見積にはバージョンが保存され、すべての値引きには誰もが知る承認者がいます。次の部では、最初の出荷の前のステーション、与信限度と保証に進みます。顧客を追加するときに一度だけ、二つの無料の公的情報源と照合する顧客レコードから始め、次にオーナーが定め、システムがすべての受注とすべての納品で確認する与信限度と支払条件、そして掛け売りの前にオーナーが選べる保証を扱います。

出典