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