適切なフォールバックとハンドオフを設計する
会話型ユーザー エクスペリエンス (CUX) でユーザーの意図を判断または満たすことができない状況では、一連のフォールバック応答を開発する必要があります。 ここでの「シリーズ」は意図的なものです。 「すみません」と一言言っただけで済むとは思わないでください。 行き止まりにつながるような体験を作り出すことで、ユーザーの信頼を損ない、場合によってはブランドへの忠誠心を損なうことは避けたいものです。 適切なフォールバックとハンドオフは、ユーザーが達成しようとしていた タスク を、できるだけストレスなく完了するのに役立ちます。
事前に明確な期待を設定する
会話型のエクスペリエンスは、人間の方がうまく処理できるタスクの処理には適していません。 設計プロセス中に、CUXが行うことと行わないことを特定しました。 フォールバックの必要性を減らす1つの方法は、フォールバックが何であるかを最初から明確にすることです。
たとえば、銀行の エージェント を設計している場合は、挨拶文の中で、残高を確認したり口座間で送金したりできることを顧客に伝えます。 旅行の エージェント を設計している場合は、往復航空券の予約、ホテルの部屋の予約、旅程の変更ができることを顧客に伝えます。
ユーザーが エージェント に実行できない操作を要求した トピック に到達した場合、フォールバック トピック は、この明確さを提供するもう1つの場所です。 「申し訳ありませんが、わかりませんでした」のようなフォールバック。 [X] または [Y] をお手伝いできます。 これらのうちの1つを試してみませんか?」というメッセージは、エージェント が 実行できる 機能にユーザーを誘導するのに役立ちます。
機能に応じてフォールバックを考える
CUXがユーザーの要望を理解できない、または実現できないかどうかに関係なく、理解の追求、曖昧さの解消、ドメインの専門知識の確立という機能に応じてフォールバックについて考えると役立ちます。
理解を求める: CUXがユーザーの意図を理解できない場合は、ユーザーにリクエストを言い換えるか明確にするよう求めます。 例:
- 「それは分かりませんでした。 別の言い方をしてもらえますか？」
- 「よく分かりません。 言い換えてみていただけますか？」
- 「どう助けたらいいのか、ちょっと分からないんです。 いくつかのキーワードだけを使ってもう一度質問してみてください。」
曖昧さを解消する他の方法を見つけてください。 場合によっては、フォールバックは、ユーザーが何を望んでいるかを判断するのに役立つ、より明確な情報を求めるのに適した場所です。 ユーザーの意図に最も一致する提案を1つまたは2つ提供します。 例:
- 「[提案]のことですか？」
- 「[提案]したいようですね。 そうですか？
- 「[提案1] または [提案2] を見つけました。 それはそれらのうちの1つですか？
CUXが意図を理解していてもそれを実現できない場合は、ユーザーに対して透明性を保ちます。 CUXで何ができるかを案内したり、役立つ可能性のある他のリソースを提供したりします。 例:
- 「申し訳ありませんが、それについてはお手伝いできません。 [提案1]と[提案2]のどちらを試してみますか？
- 「申し訳ありませんが、それについてはお手伝いできないと思います。 何ができるかを知るには、「メイン メニュー」と言ってください。
- 「それについては情報がありませんが、役に立つかもしれない 完了 を見つけました: [完了]。」
エクスペリエンスにその機能を組み込む具体的な計画がない限り、「まだできません」や「まだやり方を学習中です」など、CUXがユーザーの意図に対応する方法を学習することを示唆するフレーズの使用には注意してください。
フォールバックバリエーションを作成する
誰かと会話していて、相手が立て続けに間違いを犯した場合、同じ謝罪を何度も繰り返すのは奇妙でしょう。 CUXについても同様です。 フォールバックを作成するときは、あらゆる状況に合わせていくつかのバリエーションを作成することをお勧めします。 そうすれば、顧客がフォールバックに複数回遭遇しても、そのエクスペリエンスが過度にロボット的であるとは感じられません。 必要なフォールバックの数は、顧客が会話の中で 追従する できるパスの数によって異なりますが、一般的には少なくとも3つを記述するようにしてください。
いつ引き継ぐべきかを知る
CUXがユーザーを理解できない場合や、ユーザーを支援できない場合に備えて、ハンドオフ プロセスを構築することが重要です。 顧客をサポート担当者に紹介したり、サポートWebサイトやオンライン ドキュメントなどのリソースに紹介したりすることもできます。 答えなければならない難しい質問の1つは、 CUXがユーザーを人間または他のリソースに誘導する必要があるのはいつなのか?
会話中にイライラする前に、何回質問を繰り返したり言い換えたりできるかを考えてみると役に立つかもしれません。 ユーザーを別の場所に誘導する前に、1回のセッションで フォールバックの質問を2つ以下に することをお勧めします。
アイデア をできるだけスムーズにします。 何が起こっているのか、人間に接続されているのか、別のリソースに接続されているのか、次に何をする必要があるのかをユーザーが理解していることを確認します。 たとえ行き詰まったとしても、必ずしも最初からやり直す必要があるわけではなく、彼らはやり直したくないのです。 優れた ハンドオフ は、ユーザーが中断した場所を効果的に記憶し、ユーザーが達成しようとしていた タスク の継続を支援します。 CUXが開始したのと同じプロセスを繰り返すようにユーザーに求めるのは、良いエクスペリエンスとは言えず、ユーザーがその作業を放棄してしまう可能性があります。
フィードバックを求める
CUXが会話を終えたときは、それが顧客の役に立ったかどうかに関係なく、フィードバックを求めるのに最適なタイミングです。 リクエストをシンプルかつ迅速にします。 人々に経験について尋ねる簡単な方法をいくつか紹介します。
- 親指を立てる/親指を下げます
- 笑顔/しかめっ面
- 数値評価（5段階評価が一般的）
- 肯定的/否定的（2値スケールまたはより広範な5段階スケール）
理想的には、顧客が何でも言いたいことを言えるように、評価の後に自由形式のテキスト フィールドを含めます。 質問を追加することもできますが、質問が増えるほど、ユーザーがフィードバック フォームに反応する可能性が低くなります。
フィードバックは貴重なものですが、フィードバックをどのくらいの頻度で求めるかについても慎重に考えることが同様に重要です。 あまり頻繁に尋ねると、よく言っても迷惑になり、最悪の場合、疎外感を抱かせてしまいます。 可能であれば、顧客からの頻度のシグナルを利用して、週に1回以上評価を依頼しないようにしてください。 それでも、新しいエクスペリエンスやより複雑なエクスペリエンスなど、フィードバックが最も役立つエクスペリエンスを優先する必要があるかもしれません。 また、電話番号を取得した後など、ユーザーがすぐに他の操作に移りたい場合には、フィードバックを求めることは避けたほうがよいでしょう。 アンケートを完了するという タスク で気を散らす前に、彼らが完了しようとしていた タスク が タスク であることを確認してください。
ただし、 管理する方法がない場合は、フィードバックを求めないでください。 顧客からのフィードバックが無駄になったり、フィードバックを確認、ラベル付け、タグ付け、保存、報告するプロセスがなかったりする場合は、フィードバックを求める必要はありません。 顧客は自分のフィードバックが検討されていないと感じると、信頼を失い、将来フィードバックを送信しなくなる可能性が高くなります。