このページでは、効果的で魅力的な RCS ビジネス メッセージ エクスペリエンスを作成するためのベスト プラクティスについて説明します。技術的な実装と会話設計の両方について説明します。
技術に関するガイドライン
デバイスの機能を確認する
ユーザーとの会話を開始する前に、ユーザーのデバイスが RCS メッセージを受信できることを確認します。ユーザーの能力を特定するには、機能チェックを送信し、それに応じてエージェントのやり取りを調整します。デバイスがサポートする方法でのみユーザーとやり取りします。お客様のデバイスで RCS が有効になっていない場合は、SMS などの別のチャネルとの通信のフォールバック メソッドを設定します。
メッセージの最大サイズを遵守する
RBM メッセージの最大サイズと、そのメッセージに含めることができるメディア ファイルには上限があります。詳細については、最大メッセージサイズをご覧ください。
ロゴとヒーロー画像が適切に表示されるようにする
- ロゴの周囲には、切り抜きに対応し、視覚的な完全性を維持するのに十分なスペースを空けてください。
- ロゴやヒーロー画像を伸ばしたり歪ませたりしないでください。ブランドの認識に悪影響を及ぼす可能性があります。
- 明るいモードと暗いモードの両方でロゴとヒーロー画像をテストし、視認性と美観が最適になるようにします。
ロゴのデザインや問題のトラブルシューティングに役立つその他のリソースについては、ロゴのデザインに関するガイドラインをご覧ください。
ロゴ
- 円形の切り抜きを念頭に置いてロゴをデザインし、バランスと明瞭さを維持します。
- トリミングの問題を回避するため、画像内にロゴを中央に配置します。
- 背景が透明なロゴの場合は、ダークモードに対応できるよう、明るい背景と暗い背景の両方に対して十分なコントラストを確保してください。不明な場合は、白一色の背景を使用します。
ヒーロー画像
- 45:14 のアスペクト比を使用すると、不要な切り抜きを防ぎ、視覚的に魅力的なディスプレイを実現できます。
ヒーロー画像をデザインする際は、ロゴの重なりを考慮し、重要な要素が隠れないようにします。
受信したメッセージの重複を確認する
ユーザーからの受信メッセージを確認して返信する場合は、messageId をチェックして、そのメッセージがまだ受信されておらず、返信していないことを確認します。
分散システムでは、メッセージを送信する方法は 2 つあります。
- 最大 1 回: システムはメッセージを 1 回送信しますが、途中でネットワークまたは通信エラーが発生すると、メッセージが受信されないことがあります。
- 少なくとも 1 回: システムはメッセージを複数回送信する場合があります。ネットワークまたは通信エラーが発生しても、メッセージは受信できます。
Google Cloud Pub/Sub は at-least-once システムを使用します。これにより、受信メッセージが重複する可能性がありますが、messageId 文字列を追跡することで、メッセージを簡単に重複除去できます。すでにメッセージを受け取っている場合は、同じ messageId で受信した追加のメッセージは無視してかまいません。
メッセージの受信の詳細については、受信イベントを処理するをご覧ください。
指数バックオフでの再試行を実装する
API を呼び出すときに、インフラストラクチャの問題、サービス オーバーロード、QPS の上限などのエラーにより、呼び出しが失敗する可能性があります。失敗した API 呼び出しから正常に復旧するには、指数バックオフによる再試行を実装します。
指数バックオフでの再試行を使用すると、インフラストラクチャは自動的に次の処理を行います。
- 失敗した API 呼び出しを特定します。
- 最初の待機時間と再試行の最大回数を設定します。
- 指定した時間だけ一時停止します。
- API 呼び出しを再試行します。
API 呼び出しのレスポンスを評価します。
- 成功した場合は、ワークフローの次のステップに進みます。
- 失敗した場合は、待機時間を長くしてステップ 3 に戻ります。
- 再試行の最大回数を超えて失敗した場合は、失敗状態になります。
理想的な待機時間と理想的な再試行の最大回数は、ユースケースによって異なります。これらの数値は、インフラストラクチャとワークフローのレイテンシ要件に基づいて決定します。
リージョン エンドポイントを使用して API のパフォーマンスを最適化する
API のパフォーマンスを最適化してレイテンシを短縮するには:
ユーザーのリージョンに最も近いエンドポイントを使用します。
次の表に、ユーザーの電話番号に応じて使用するリージョン RBM エンドポイントの推奨事項を示します。
電話番号の接頭辞 推奨エンドポイント 地域 +1 us-rcsbusinessmessaging.googleapis.com 南北アメリカ +2 europe-rcsbusinessmessaging.googleapis.com ヨーロッパ +3 europe-rcsbusinessmessaging.googleapis.com ヨーロッパ +4 europe-rcsbusinessmessaging.googleapis.com ヨーロッパ +5 us-rcsbusinessmessaging.googleapis.com 南北アメリカ +6 asia-rcsbusinessmessaging.googleapis.com アジア +7 europe-rcsbusinessmessaging.googleapis.com ヨーロッパ +8 時間 asia-rcsbusinessmessaging.googleapis.com アジア +9 asia-rcsbusinessmessaging.googleapis.com アジア デフォルト us-rcsbusinessmessaging.googleapis.com 南北アメリカ 選択したエンドポイントの近くにサーバーを配置することを検討してください。
Google のデータセンターについては、https://www.google.com/about/datacenters/locations/ をご覧ください。
エージェントのリージョンの特定の詳細については、エージェントを作成するをご覧ください。
会話型 UI とユーザー エクスペリエンス
アプリの UI ではなく、会話型 UI
RBM エージェントは、会話型ユーザー インターフェースでユーザーに効率的で特定のタスクを提供する場合に適しています。最適に設計されたエージェントは、会話を焦点を絞り、わかりやすく、自然な会話のように構造化します。
エージェントは、アプリやウェブページのビジュアル UI に依存することはできず、また、それを模倣しようとすることもできません。代わりに、エージェントは、口頭での合図、提案、適切なエラー処理でユーザーをガイドし、ユーザーのニーズに対応する、慎重に作成された会話に頼る必要があります。
また、エージェントは電話ツリーや、ユーザーが特定のアクションを表す番号で応答することを前提としたインターフェースを模倣することもできません。ユーザーは、会話で他の人とやり取りするのと同じように、エージェントと自然にやり取りできる必要があります。
会話を開始する
会話の開始は、エージェントができることに対するユーザーの期待を設定します。エージェントの個性を示す、ユーザーが気にする情報を先に提示する、エージェントができることを伝える、など、会話を強烈な印象で始めましょう。エージェントとやり取りして会話を続けるための明確なオプションをユーザーに提供します。
エージェントの個性を示す: ユーザーに挨拶し、ブランドを紹介して、トーンにメリハリをつけます。エージェントのペルソナ（バーチャル アシスタントやデジタル コンシェルジュなど）を作成する場合は、エージェントが人間ではなく chatbot であることを明確にします。エージェント名はペルソナに合わせて設定できます。アバターは、自分のイメージを強化するのに最適な方法です。ロゴでもかまいませんが、漫画風のグラフィック キャラクターも効果的です。
エージェントの対応範囲を伝える: 適切な応答メッセージでは、会話で何ができるかを明確にします。エージェントの機能の概要を説明します。また、ユーザーを特定のパスへと誘導するための返信候補とアクションも含まれています。これらの候補を使用して、ユーザーが会話を進め、エージェントがサポートできるタスクを理解できるようにします。
明確で一貫性のあるメッセージを作成する
ユーザーが理解しやすく、返信しやすいメッセージを送信します。ユーザーに返信を促すメッセージ テキストを作成します。スタイル、形式、ペースを一貫して維持し、ユーザーとの信頼関係を築きます。
メッセージ テキストを作成する際は、以下のベスト プラクティスもご参照ください。
行き止まりを作らないでください。各メッセージは、有意義な次のステップにつながるものである必要があります。
- ユーザー ジャーニーに複数のステップを含むタスクがある場合は、ディスコース マーカーを使用してプロセスを案内します。
たとえば、[今すぐ]、[次へ]、[了解しました] などです。以下にご紹介します。
たとえば、「了解しました。担当のアカウント マネージャーが引き継ぎます。」
たとえば、「完璧です。お客様がご希望のものと思われます」と伝え、ウェブサイトへのリンクを提供します。
お客様のメッセージを認識したことを示す言葉やフレーズで返信します。
たとえば、「素晴らしい選択です」「OK」、「了解」、「承知しました」
ユーザーの名前（わかっている場合）または代名詞「you」を使用して、ユーザーに直接対応します。混乱を招く可能性があるため、お客様のことを「私」や「私自身」と表現しないでください。
タイトルとラベルは、単語ごとに 1 文字目を大文字にするのではなく、文の最初の 1 文字を大文字にします。
たとえば、「アカウント明細書」ではなく「アカウント明細書」と入力します。
短縮形を使用します。これは、真剣なトーンで話すエージェントにも適しています。
たとえば、「it's」は「it is」よりも会話的な表現です。
感嘆符は控えめに使う。
文の区切りを明確にするための読点を使用します（「A, B, and C」ではなく「A, B, and C」）。
数字は数字として記述します。
たとえば、「1、2、3」ではなく「one、two、three」と入力します。
絵文字を使用する場合は、ユーモラスなトーンがユースケースに適していることを確認してください。
たとえば、レッカー車を予約しているユーザーや健康診断の結果を調べているユーザーは、気分が乗らないかもしれません。
メッセージを順番に保持する
複数のメッセージを順番に送信する場合は、ユーザーがそれらのメッセージを順番に受信することが重要です。メディアを含むメッセージは、テキストのみのメッセージよりも処理に時間がかかります。ユーザーがメッセージを正しい順序で受信できるようにするには、メッセージの 200 OK レスポンスを受信するまで待ってから、次のメッセージを送信します。
返信の候補や操作の候補を使用して魅力的な会話を作成する
返信の候補とアクションは、ユーザーとの会話をガイドし、強化するための強力なツールです。メッセージやリッチカードに沿って、会話のトピックを続けるか変更するかのオプションを提供できます。
返信の候補: 事前定義されたオプションを提供することで、ユーザーがエージェントに迅速に返信できるようにします。特に特定の回答が期待される場合は、可能な限り返信文の候補を使用します。
推奨されるアクション: エージェントがデバイスの機能と統合できるようにし、サポートへの電話や場所の検索などのタスクを効率化します。
より魅力的で効率的な会話を作成するには、次の重要な考慮事項に従ってください。
- 関連性: 候補が現在の会話に沿っていることを確認します。
- 簡潔さ: ユーザーに圧迫感を与えないように、候補の数を制限します。
- 明確さ: 候補テキストには明確で簡潔な表現を使用します。
お客様をサポートする
エージェントは、ユーザーからの HELP メッセージに応答し、エージェントの機能について説明する必要があります。エージェントの機能に合わせてカスタマイズされた返信候補リストを使用すると、ユーザー エクスペリエンスを改善できます。
ユーザーがメッセージを望まない場合は尊重する
お客様の信頼を維持するには、お客様の連絡方法の設定を尊重する必要があります。ユーザーがメッセージの受信を停止したいと示した場合、エージェントはその選択を尊重する必要があります。これには、関連するすべての言語で「停止」などのオプトアウトのさまざまな表現を理解し、適切に対応することが含まれます。
「STOP」などの命令コマンドへの応じ方については、事業を行っている国の法律および最良の慣行を参考にしてください。
たとえば、CTIA のベスト プラクティスを参照してください。
オプトアウトを処理する
RBM プラットフォームには、ユーザーのオプトアウト リストを直接管理する方法はありません。メッセージの受信を停止したユーザーの独自のデータベースを維持する責任はお客様にあります。
会話を再開する
ユーザーがエージェントとの会話を削除した場合は、ウェブサイトのオプトイン、SMS ショートコード、その他の同意メカニズムなど、別のチャネルから再度連絡する必要があります。この新しいインタラクションにより、ユーザーがメッセージの受信に再び関心を持っていることが示されます。