見積中の案件を見失わない：見積番号と受注ステータスの設計

見積書と営業案件を別IDで管理し、再見積の二重計上を防ぐ方法。状態定義、採用版、次回対応、受注後の引き継ぎを記入例で示します。

見積書を発行できても、どの案件が返答待ちで、どれが受注したかは別に管理する必要があります。見積作成ソフトを変える前に、案件台帳へ見積番号、状態、次回対応を残す方法を試してください。

この記事では見積書の法的な要件や発行ソフトの選定ではなく、見積提出から受注までの進捗を整理します。表計算でもCRMでも、同じ考え方を使えます。

見積書の枚数と案件数を分ける

一つの案件で、数量や仕様を変えた見積書を何度か出すことがあります。見積書を一枚一案件として集計すると、同じ仕事を重複して数えてしまいます。

案件には固定の案件IDを付け、見積書には別の番号と版を付けます。たとえば「D001・秋のチラシ」という案件に、「Q001-1」「Q001-2」という見積を関連付けます。

顧客、案件、見積の三つを分けると、同じ顧客からの複数依頼と、同じ依頼の修正版を区別できます。まず現在のファイル名と番号の付け方を確認し、新しい仕組みを増やす前に対応関係をそろえましょう。

「ほぼ受注」は正式な受注とは分けます。確度を残す場合でも、確定した金額や納期と混ぜないようにします。状態を細かくしすぎるより、誰が見ても同じ判断になる定義を置くことが重要です。

CRMにも商談の段階を管理する機能がありますが、製品標準の名称をそのまま使う必要があるかは運用に合わせて確認します。Biginのパイプライン機能

これは架空の例です。金額が必要なら、通貨と税の扱いをそろえた列を追加します。見積ファイルは決まった場所へ保存し、台帳にはファイル名または参照先を残します。

最新版だけを台帳へ表示しても、以前の見積は適切な保存先に残します。旧版のファイルを上書きして消すと、顧客から「前の条件」と言われた際に比較できません。

再見積では「値下げ」だけでなく、数量減、仕様変更、納期変更など理由を残します。同じ金額に見えても、含まれる作業範囲が違うことがあります。

架空例なら「Q001-1は500部、Q001-2は300部。印刷部数変更により再計算」と記録します。単に価格だけを更新するより、次の担当者が条件を読み違えにくくなります。

顧客が複数案から選ぶ場合は、どの案が採用されたかを明記します。CRMや台帳の最新金額だけでは、採用された仕様まで伝わらない場合があるため、受注した版への参照を残します。

受注状態にしたら、制作や納品の担当へ必要な条件を引き継ぎます。引き継ぐ情報は、採用見積、納品物、納期、顧客が提供する素材、未確定事項です。

受注の連絡があっても、仕様が一部未確定ならそのまま書きます。営業担当の記憶だけに残る条件をなくすことが、台帳を共有する目的です。

案件が少なければ、表計算で状態ごとに絞るだけでも進捗を確認できます。Googleスプレッドシートなどのフィルタ機能を使い、見積提出済みで次回対応日がない案件を探します。フィルタの公式説明

週に一度、長く動いていない見積、金額だけが更新された案件、受注したのに引き継ぎ先がない案件を確認します。CRMへ移しても、この確認の責任者は必要です。

既存の見積発行を続けたまま、まず案件台帳で未回答と採用版を見えるようにしてください。入力が分散し始めたら、顧客管理ツールの判断表を使って共有方法を見直します。