予約は、顧客とのやり取りでもある
予定の名前だけでなく、その人が誰で、すでに関係があるかを知りたい場面があります。Tsumiraは氏名、連絡先、担当者への関連をサービスや時間とともに持ちます。予約を毎回独立したものとして組み立て直さず、顧客の記録から関係を続けられます。関連は確認の助けであり、あらゆる人物識別の保証ではありません。
この予約に必要な情報を受け取る
予約には顧客名と読み、提供されたメールや電話、関連するメモがあります。その約束が誰のためかを示す予約の文脈です。サービスの準備と連絡に必要な事実を整えます。予約のメモは特定の訪問を説明し、事業が知るすべての私的情報を複写する必要はありません。目的に合う情報にすると、担当者が次の準備を理解できます。
- 顧客名と読み
- メール・電話の情報
- その予約に関係するメモ
万能の保証でなく、定義された照合を使う
予約の作成は、読み込んだCRM担当者の集合に共通の顧客照合を使います。見つからなければ顧客担当者を作成でき、予約に関連を保存します。正確な識別情報が役立つ一方、名前の変更や共有番号が必ず正しく解決する保証ではありません。過去の顧客情報を頼りにする前に、不明な関連は本人やチームへ確認してください。
- 共通の顧客照合ルール
- 必要に応じた担当者作成
- 予約と担当者の関連を保存
許可された顧客業務へ続ける
関連した担当者から、閲覧可能な顧客の文脈へ進めます。予約には独自の状態と会話があり、CRMには活動と権限があります。中止した予約も過去に約束があった記録です。取消が、CRMから顧客を消す操作になるわけではありません。サービスの日時変更と、関係全体に対する判断を分けて、適切な記録で確認できます。
- 予約からの顧客参照
- 予約とCRMそれぞれの文脈
- 取消は顧客の削除ではない
具体的な業務の流れ
予約情報を受け取る
実際の名前と、信頼できる連絡先を使います。
予約の流れで作る
対応する処理が担当者を認識または作成し、確定予約へ関連付けます。
関係を確かめる
見える顧客文脈を開き、過去の情報を使う前に曖昧さを解消します。
対応を続ける
予約変更と顧客連絡を、それぞれ適切なレコードで行います。
実務を想定した例
利用例：再び相談を予約する顧客
顧客がいつもの連絡先で、次の相談を予約するとします。対応する処理は既存の担当者を認識し、その関連を予約に持てます。担当者は準備のために閲覧可能な顧客情報を読みます。情報変更や不明な関連があれば、予約だけを本人証明とせずに確認します。
この機能についての質問
予約は顧客参照を持ちますか。
予約モデルにはCRM担当者との関連があり、独自の顧客情報とサービスも持ちます。
初回の人も担当者になりますか。
対応する作成経路は、共通照合で既存担当者が見つからない場合に顧客担当者を作成できます。
重複が絶対に起こらない保証ですか。
違います。情報の変更、限られた入力、共有の識別子は確認が必要な場合があります。曖昧な関連を本人の証拠としないでください。
取消はCRM顧客も削除しますか。
いいえ。予約の状態変更であり、CRMの関係や履歴を消す命令ではありません。
この業務に合う連携を検討する。
想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。
