架空の注文E101で、顧客が「16日希望」、営業が「17日なら調整を確認します」と述べています。AIが日付だけを拾うと、16日と17日のどちらを受付へ入れるか分かりません。

営業担当は、顧客の希望16日、営業の候補17日、返答前という状態を元発言と一緒に記します。「調整を確認します」は約束した納期という意味に読み替えません。

W3Cの来歴の考え方は、誰の発言からどの記録を作ったかを残す参考になります。希望・提案・合意の分類は会社の受付用の編集例で、法的な契約成立の判定を置き換えるものではありません。

この章の根拠：出典1出典2

受付表に納品日という1列しかないと、顧客の希望を社内の予定へ移しやすくなります。責任者は希望、提案候補、確認済みの回答日を分けるか、状態欄を必ず添える方法を決めます。

E101で返答がない間は、17日を確定欄へ入れません。営業の候補が実際に可能か、現場の確認も必要なら、その状態も残します。顧客の希望と自社の可能日が同じ数字でも、確認が済んだ根拠は別です。

既存の受付システムが日付1列しか扱えない場合は、未確定の案件を別の一覧へ置くなどを検討します。列の制約に合わせて意味を消さず、現場へ渡してよい状態を責任者が決めます。

この章の根拠：出典1出典3

後から顧客が「17日でお願いします」と返答した場合、営業はその発言をE101へ保存します。現場が17日に対応できると確認しているかも照合し、会社が定めた回答の記録へ反映します。

単なる既読、返信なし、別件への返答を合意の根拠へ変えません。日付や数量の対象が同じ注文かを確認します。曖昧な返答なら営業責任者が追加確認の方針を決めます。

この教材では、運用上、返答と社内確認がそろった状態を確認済みと呼びます。実際の契約や約束の成立条件は個別の規程と担当の判断です。AIの分類だけで確定したとは記しません。

この章の根拠：出典2出典3

「17日は難しい」には17日という数字がありますが、了承ではありません。「17日なら担当に確認後」という返答も、条件付きで未確定です。営業担当は数字と一緒に否定・条件を残します。

AIが日付だけを抽出する設定なら、原文の状態も出す指示や欄を追加して確認します。確認後という条件を削って了承に変えた回答は、営業責任者が採用しません。

電話で確認した場合も、会社の記録手順に沿って発言内容、日時、担当を残します。メールにない合意をAIに補わせず、別の確認記録として追加します。

比較表は横に動かして全ての列を確認できます。

この章の根拠：出典1出典3

E101が返答前に17日確定として現場へ渡った場合は、営業責任者が対象注文を確認し、現場へ未確定であることを伝える担当を決めます。抽出設定を直すだけでは、既に立てた予定は変わりません。

運用担当は希望、提案、否定、条件付き、確認済みの例で状態欄を確認します。原文に戻れることも点検し、良い回答だけを選んで記録しないようにします。

責任者は、未確認の状態がある案件をどこまで現場へ渡すかを改めて決めます。状態の分類と業務の実行許可は別の判断として残します。

この章の根拠：出典1出典2

E101では、16日希望と17日候補を返答前の確定納期にしませんでした。日付を拾うだけでなく、誰のどんな意思かを受付欄へ残します。

返答が来たら同じ注文への発言と社内確認を照合します。否定や条件付きの返答も分け、AIの分類だけで合意や実行許可を決めません。

抽出表の記入メモへ、未確定と確認先を残してください。誤って確定状態で渡した記録は現場の予定への影響も確認し、元発言へ戻れる受付にします。

この章の根拠：出典1出典2出典3