見積・提案の版管理｜差し替え地獄を防ぐ「Revision」設計と承認フロー

見積や提案は、顧客とのやり取りで条件が変わり続けます。
このとき版管理が無いと、「最新版がどれか分からない」「承認済みがいつの間にか変わっている」「営業と現場で条件が違う」などの事故が起きます。
この記事では、見積・提案の“差し替え地獄”を防ぐための版（Revision）管理を、実務で回る形に整理します。

1. まず状態を3つに分ける：下書き／確定／失効

版管理は、番号を振る前に「状態」を決めると破綻しにくいです。
最低限、次の3状態があると運用が安定します。

• 下書き：編集途中（内部で条件を詰める）
• 確定：顧客提示・社内承認済み（原則は編集不可）
• 失効：過去版（参照のみ、最新版ではない）

この状態設計は、ステータス遷移（遷移図）として明文化しておくと、実装・説明・運用が揃います。

2. Revisionの付け方：人が理解できて、機械がブレない形

Revisionは「R1 / R2」などでも良いですが、
重要なのは“最新版が一意に決まる”ことと、“何が変わったか追える”ことです。

• 版番号：R1, R2, R3…（顧客に見せるなら分かりやすい）
• 内部ID：編集用の一意ID（機械的に扱う）
• 変更理由：「条件変更（数量）」「納期変更」「割引調整」などを必須化

3. “確定版は編集させない”：編集したいなら新しい版を作る

確定版を編集できる仕様にすると、承認の意味が壊れます。
現実的には「確定版はロック」「変更したければ複製して新しい下書きを作る」が強いです。

• 確定版を複製 → 下書きR(n+1)を生成
• 変更点を入力（変更理由必須）
• 承認して確定 → 旧確定版は失効へ

承認の考え方は 承認フロー と同じで、「誰が確定できるか」を明確にすると事故が減ります。

4. 顧客提示用PDF：作り方を統一して“送り間違い”を減らす

見積の提示は、PDFが混ざるケースが多いです。ここが統一されていないと送り間違いが起きます。
おすすめは次の方針です。

• PDF生成：確定時に自動生成（または「確定PDF」ボタン）
• ファイル名：案件ID＋Revision＋日付（例：Q-20251220-R3.pdf）
• 保存：権限チェックできる領域に保存（直リンクしない）

添付の安全設計は ファイル添付 の考え方がそのまま使えます。
また、顧客へのメール文面や返信設計は 確認メールの必須情報 と揃えるとブレません。

5. 条件表・例外条件：口頭合意を残すための欄を用意する

実務では「今回は例外」「今回はサービス」が必ず混ざります。
この条件がPDFに残らないと、後から揉めます。
そのため、見積には次の欄を最初から用意すると安定します。

• 有効期限（例：発行日から◯日）
• 前提条件（納期、支払、搬入条件など）
• 対象外・免責（何を含まないか）
• 例外条件（今回だけの特記事項）

“例外処理”を事前に設計しておく発想は、料金計算ロジック（例外処理）と同じで、後で綻びが出にくいです。

業種別の典型

物流（運賃・附帯作業・燃料サーチャージ）

見積条件が多く、改定も頻繁です。
業務像は 物流向け を前提に、
見積設計（運賃と附帯作業）は版管理とセットにしないと運用が破綻しやすい領域です。

自動車販売・整備・タイヤショップ（作業メニュー・部品・追加整備）

入庫後に追加整備が発生しやすく、見積が差し替わりがちです。
業務像は 自動車販売・整備・タイヤショップ向け を前提に、
入庫〜作業指示（ピット割当）と見積の確定タイミングを揃えると、現場と営業の齟齬が減ります。

インテンスでも、見積・提案ほど“後から揉める”領域は、確定版のロックと履歴を最優先で設計します。

まとめ

見積・提案の版管理は、「番号」より「状態」と「確定のルール」が肝です。
下書き／確定／失効を分け、確定版は編集不可、変更したければ新しい版を作る。
承認・履歴・PDF生成まで揃えると、“最新版が分からない”事故を現実的に潰せます。