チャットからカレンダーへ: より良い予約フロー。
十分なコンテキストを収集し、実際の予約ルートを示し、確認を明確にします。
誰のための約束かを決めてください。
予約フローは、単にカレンダーに記入するだけでなく、人々が適切な会議を選択できるようにする必要があります。会議の目的、誰が出席すべきか、どの問い合わせが別の場所に属するかを定義します。既存のカスタマー サポートでは、販売相談ではなくサービス キューが必要になる場合があります。
予約を申し出る前に、簡単なルート案内の質問を 1 つしてください。 「新しいプロジェクトについて話し合いますか、それとも既存のプロジェクトについて支援を受けますか?」多くの場合、すべての訪問者を同じカレンダーに送信するよりも便利です。会議が不要な場合は、予約不要のルートを人々に提供します。
詳細を収集する前に会議について説明します。
訪問者に、予約の内容、実際の所要時間、準備が必要かどうかを伝えます。実際のビジネス用語を使用してください。空き状況をでっち上げたり、それが確認されていない場合は相談が無料であると示唆したりしないでください。
会議の手配と準備に必要な詳細のみを収集します。目標についての短い説明で十分かもしれません。予約を正しくルーティングするために回答が必要でない限り、長い質問内容を通話用に保存してください。
実際の可用性ソースを使用します。
適切な予約サービスに接続するか、検証済みの予約リンクを提供します。統合で実際の可用性を確認できない場合は、アクションをリクエストとして提示し、チームがそれを確認することを説明します。アシスタントは決してタイムスロットを捏造してはなりません。
タイムゾーンを表示し、選択した日付と時刻を確認で繰り返します。これは、顧客が別の場所から旅行したり閲覧したりする地元企業にとっても重要です。予約サービスが影響を受ける地域をサポートしている場合は、夏時間の変更に関する動作をテストします。
リクエストを確認済みの予約から分離します。
予約システムが成功の結果を返した後にのみ「確認しました」と言ってください。保存が失敗した場合、またはスロットが使用できなくなった場合は、問題を説明し、再試行または代替ルートを提案します。訪問者が 2 回タップした場合の重複予約を回避します。
実際のプロセスを通じて再スケジュールまたはキャンセルするために必要な情報を含めます。明確な確認により、顧客とチームの両方にとって不確実性が軽減されます。リマインダーには、顧客の権限とチャネルに適用されるルールが反映されている必要があります。
予約だけでなく、出席した会議を確認します。
リクエストされた予約、確認された予約、出席した会議を個別に追跡します。カレンダーのエントリを増やしても、不適切な訪問者を間違ったチームに送るフローは、価値ではなく仕事を生み出します。
予約の欠席や不適切な予約の理由を検討します。冒頭の質問、会議の説明、確認には改善が必要な場合があります。焦点を絞ったフローから始めて、キャンペーンを送信する前に、キャンセルや在庫確認の失敗を含むプロセス全体をテストします。