判断できる依頼を受ける
何を求めているかを理解してから商業上の回答を決めます。質問構成、選択内容の当時の情報、連絡先を依頼に保持します。受付は発行済み見積版や財務文書、入金とは別で、それぞれに必要な確認があります。
依頼の根拠を残す
公開ウィザードの版、内容の参照、回答、選択内容、対応する同意を記録します。価格は対応カタログをサーバーで解決し、ブラウザーの合計を信頼しません。重複提出対策もあり、再送と別の依頼を区別します。必要な説明が十分かどうかは担当者が判断します。
- 当時の質問と提供内容
- サーバーでの価格解決
- 重複提出への対策
状態の意味を明確にする
新規、確認中、見積済み、完了を区別します。見積済みには実際の見積版の発行が必要で、単なるラベルではありません。現在の状態遷移では完了を再開しません。次の作業を理解できるよう、実際の進行に合う状態を使います。
- 新規と確認中
- 実際の見積発行に基づく状態
- 完了は勝手に再開しない
現在の版に対して操作
操作は期待する状態と依頼の版を確認します。古い画面から同僚の新しい判断を黙って上書きしません。変更があれば現在の依頼を読み直します。誰が不足情報を確認し、誰が回答を発行するかを決め、権限と状態確認で支えます。
- 現在状態の確認
- 同時変更を検知
- 責任ある次の行動
具体的な業務の流れ
依頼を開く
回答、提供内容、連絡先を読みます。
内容を判断
不足する範囲と価格確認を把握します。
対応する操作
確認、実際の見積発行、完了を選びます。
結果を確認
現在状態と後続見積との関係を確認します。
実務を想定した例
例：二人が同じ依頼を確認
一人が確認を始め、別の人が見積を発行します。期待状態の確認により、古い画面から後の判断を上書きしません。更新すると実際の見積版と見積済み状態が分かります。不足情報があるなら確認中で調整してから発行します。
この機能についての質問
受付時点で見積ですか。
いいえ。顧客の提出内容と、意図的に発行する見積版は別です。
未発行でも見積済みにできますか。
見積済みへの遷移は実際の版の発行に結び付きます。
完了を再開できますか。
現在の対応する状態遷移では完了を再開しません。
同僚が先に変更したらどうなりますか。
期待状態と版を確認します。現在の記録を読み直して判断します。
この業務に合う連携を検討する。
想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。
