会話ユーザー エクスペリエンス (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 ポイント スケール)
顧客が好きなことを言えるように、評価の後に開いているテキスト フィールドを含めるのが理想的です。 質問を追加することはできますが、追加する質問が多いほど、フィードバック フォームに参加する可能性が低くなります。
フィードバックの価値はありますが、要求する頻度を慎重に考えることが同様に重要です。 あまりにも頻繁に尋ねると、良くて迷惑であり、最悪の場合は無視されます。 可能であれば、顧客からの頻度のシグナルを使用して、週に一度以上評価を尋ねないようにします。 それでも、新しいエクスペリエンスや複雑なエクスペリエンスなど、フィードバックが最も役に立つエクスペリエンスに優先順位を付けることができます。 また、電話番号を取得した後など、ユーザーが他の操作にすばやく進みたい場合は、フィードバックを求めないようにすることもできます。 アンケートを完了するタスクに注意を向ける前に、完了するように設定したタスクが完了していることを確認します。
ただし、管理する方法がない場合は、フィードバックを求めないでください。 顧客からのフィードバックが無視されてしまう場合、レビュー、ラベル付け、タグ付け、保存、報告のプロセスがなければ、わざわざ要求する必要はありません。 お客様がフィードバックがレビューされていないと感じた場合、信頼を失い、今後フィードバックを送信しない可能性があります。