リードは、誰かがフォローアップする場合にのみ役立ちます。
チームがコンテキスト、担当責任、明確なタスクを受け取るように、チャットボットから CRM へのハンドオフを設計します。
ハンドオフをビジネスプロセスとして扱う。
名前と電子メールを収集しただけでは、見込み顧客の発掘は終わりではありません。問い合わせを誰が受け取るのか、どのような情報が必要なのか、どのような行動をとるべきかを決定します。統合を構成する前に、営業チームとこの契約書を作成してください。
有用なハンドオフには、顧客の要求、関連する資格回答、元のチャネル、および選択された次のステップが含まれる場合があります。要約のない長いトランスクリプトや、基礎となる会話へのリンクのない要約を送信することは避けてください。
接続をオンにする前にフィールドをマップします。
会話の回答と CRM フィールドの間に小さなマッピングを作成します。連絡先の身元と問い合わせ自体を区別します。 1 人が時間の経過とともに複数の問い合わせを行う可能性があります。メッセージごとに新しい連絡先を作成すると、データベースの信頼が難しくなる可能性があります。
どのシステムが各フィールドを所有するかを決定する。レポート プロセスで必要な場合は元のソース情報を保存し、ボットの会話が再開されたために慎重に維持されたライフサイクル ステージを上書きしないでください。値を推測するのではなく、不確実な回答を不確実として保存します。
すべての問い合わせに所有者とフォールバックを与えます。
サービスの種類や地域など、チームが理解しているルールに従ってルーティングします。一致するルールがない場合、または割り当てられた同僚が対応できない場合に何が起こるかを定義します。未割り当てのキューにも所有者が必要です。
CRM 接続が失敗した場合は、運用プロセスに目に見える例外を作成し、ハンドオフが成功したと主張しないようにします。実装では、重複レコードのない安全な再試行をサポートする必要があります。起動前に、失敗した接続と繰り返しの送信をテストします。
顧客のコンテキストと選択を保持します。
必要性、確認済みの詳細、および未解決の質問を要約します。顧客の希望する連絡方法と関連するフォローアップ権限を含めます。キャプチャされたすべての連絡先を無関係なキャンペーンに登録しないでください。
概要としては、「オフィスの設置に興味がある。場所は確認済み。時期は未定。次のステップについてメールで問い合わせる」というものがあります。これにより、チームメイトは顧客にすべてを繰り返すのではなく、実際の質問から始めることができます。
結果を伴うループを閉じます。
チームに、問い合わせが受け入れられたか、不適切な情報か、重複した情報か、まだ不足している情報かをマークするよう依頼します。それらの結果を利用して、認定フローを改善します。多くのレコードを送信するが、使用できる問い合わせがほとんどないボットには、より熱心な挨拶ではなく、プロセスの変更が必要です。
未割り当てのキューと失敗したキューを定期的に確認してください。シンプルな統合と明確な責任から始めて、実際のハンドオフの問題が軽減される場合にのみ自動化を追加します。目標は、顧客が会話の続きであると認識できる、情報に基づいたタイムリーな応答です。