見積もり後の仕様変更を整理する｜金額・納期・承認を同時に確認する

元の合意から変更点を切り出す

顧客の変更依頼は、元の見積もりのどこを変えるのかに分けて整理します。数量、仕様、対象範囲、納品場所、希望日を照合し、変更されない項目も確認します。「前より少し大きく」など曖昧な言葉は寸法や対象数へ戻します。依頼を受けた時点では承認済みではなく、対応可否を調べる段階として扱います。

変更依頼を一行で上書きしない

案件ID、変更ID、元の版、依頼日時、変更前、変更後、理由、確認担当、影響、顧客の回答を記録します。案件SC-102で20個から30個へ変える依頼と、納期を早める依頼は別項目にします。関連する依頼は同じ変更IDで束ねてもよいですが、どちらか一方だけ対応できる場合に判断を分けられる構成にします。

金額以外の影響を確認する

追加の材料、制作時間、外注手配、送料、既に進んだ作業を確認します。総額が変わらなくても、納期や保守の対象が変わる場合があります。変更しなかった場合と変更した場合の差を短く示し、誰の確認が必要かを明確にします。見積もりの計算欄と、顧客へ提示する条件を混ぜず、採用する値を担当者が確認します。

再提示した条件への回答を確認する

変更後の見積もりには、対象の変更IDと版番号を付けます。顧客が金額だけ了承し、納期には触れていないなら、全条件を承諾したと決めつけません。対象範囲、金額、日程、既存作業の扱いを揃えて確認し、承諾の参照先を残します。確認前に制作や発送を切り替えないよう、保留中の変更が分かる一覧を作ります。

先に作業してしまった場合を戻す

承認前に作業が進んだ場合は、どの時点で何を変えたかを残して一度止めます。元の条件へ戻せるか、追加費用が発生したか、顧客との再確認が必要かを担当者が判断します。変更履歴を削って元から決まっていたように見せず、誤実行として記録します。自動通知が原因なら、承認状態の条件を確認してから再開します。

部分承諾と取り下げを確認する

確認用には数量だけ承諾、納期だけ保留、依頼の取り下げ、元の見積もりが期限切れの例を用意します。取り下げた変更が受注条件へ残らないか、部分承諾を全承諾にしないかを確認します。案件の採用条件を表示したとき、元の版と変更後の版が混ざらず、制作担当が一つの条件セットを読めることを完了条件にします。

SC-102：数量だけ承諾された場合

確認用のSC-102で、数量20個から30個への変更と納期前倒しを一緒に提案したとします。顧客が「30個でお願いします」と返信しても、前倒しが可能と確認できたとは限りません。社内では数量の増加が承諾済み、日程が確認待ちと分け、全条件を確定する前に制作へ新しい締切を渡さないようにします。追加の材料を先に手配する必要がある場合は、その判断と範囲を明記します。顧客が後から数量変更を取り下げたときにも、すでに手配した内容を説明できる状態にします。履歴を分けることで、合意したことと先行した社内作業を混同せずに済みます。

社内で先に確認できる項目と、顧客の回答が必要な項目を分けると待ち時間を短くできます。材料の調達可否は社内で調べ、変更後の日程を採用するかは顧客へ確認するなど、判断の順番を整理します。複数の変更が同時に届いた場合は、前の依頼を取り下げたのか追加なのかを確認します。変更依頼の日付だけで優先して最新の値を採用すると、先に承諾した別の条件まで消えることがあります。対応した変更を一覧にし、実行担当へ渡す前に一つの条件セットへまとめます。担当者が条件を読み上げて説明できることを確認します。

道具と費用を増やす前に確認する

変更が少なければ見積台帳と確認用の文書で始められます。複数担当が同時に扱う場合は、Airtableなどで変更の状態と採用版を共有します。追加する道具の費用だけでなく、見積もり直し、既存作業のやり直し、顧客への説明時間も見積もります。計算を自動化する前に、誰が条件を承認するかを固定します。

• Tallyで見積もり依頼フォームを作る｜仕様・希望日・確認事項の集め方
• AIで見積もり計算フォームを作る｜単価・数量・端数処理をそろえる
• 社内承認フローを選ぶ｜確認・実行・差し戻しを分ける