Jacquelyn Brewer

環境設定を調べる際に、その時点の設定をスナップショットに撮って保存することができます。

過去の環境設定を調べる必要がある場合、「バージョン」ページで、保存されている過去の設定の読み取り専用バージョンを開くことができます。

過去のバージョンは読み取り専用です。保存済みのバージョンで変更できるのはバージョン名だけです。

不要になったバージョンは削除できます。バージョンを一度削除すると、元には戻せません。

メッセージングのためにエンドユーザーを認証する前に、以下の点に十分注意してください。

訪問者が認証済みのエンドユーザーだった場合、会話内の名前の横に緑色のチェックマークアイコンが表示され、エンドユーザーの外部IDがユーザープロフィールに表示されます。

さらに、認証後にエンドユーザーが投稿した各応答には、チェックマークのアイコンが付きます。

認証済みのエンドユーザーは、複数のデバイスで行った会話をデバイス間で同期できます。

メッセージングにエンドユーザー認証を実装しても、エンドユーザーはあまり違いを感じないはずです。Zendeskによるエンドユーザー認証で本人確認が行われた後は、メッセージングのデフォルトの応答の中で、メッセージング用AIエージェントから名前やメールアドレスの入力を求められることはありません。

エンドユーザーが認証されると、認証されたエンドユーザーの会話がデバイス間で同期されます。未認証のエンドユーザーの場合、個別にユーザーレコードと会話が作成されます。エンドユーザーが会話の途中で認証を行うと、サインインする前に行なわれた匿名の会話が認証後の会話と自動的に統合され、会話の継続性が保たれます。

構成を検査することで、環境の全体像を把握することができます。

環境設定を調べる際に、その時点の設定をスナップショットに撮って保存することができます。バージョンを保存すると、管理センターの「バージョン」ページでバージョンの表示、編集、削除ができます。

Zendeskには、ユーザーとチケット（チケットのリクエスタ、担当者、フォロワー）、チケットと組織、エージェントとグループといった標準のリレーションシップがすでにいくつか定義されています。管理者は、ルックアップリレーションシップフィールドを使用して、オブジェクト間のカスタムリレーションシップを定義することもできます。ルックアップリレーションシップフィールドは、カスタムオブジェクトレコードのデータをZendeskワークフローに取り込む方法を決定します。また、これらのフィールドを使用することで、標準のZendeskオブジェクト間のカスタムリレーションシップを定義することもできます。ただし、多対一または多対多となる標準のオブジェクトリレーションシップとは異なり、ルックアップリレーションシップフィールドによる定義は常に多対一のリレーションレーションシップになります。

複雑な多対多のリレーションシップには、役に立つユースケースが数多くあります。たとえば、従業員に割り当てられた資産をITチームが管理する例を見てみましょう。このシナリオでは、従業員は通常複数の資産に割り当てられており、資産の中には一度に複数のユーザーに割り当てられていることがあります。

このシナリオでは、連結オブジェクトを使用して複数のユーザーと資産を関連付けます。これは、オブジェクトに少なくとも2つのルックアップリレーションフィールドを追加し、1つのフィールドをメインオブジェクトのそれぞれに接続することで実現します。

資産と従業員間のリレーションシップを作成するには、資産の割り当てレコードを作成します。ルックアップリレーションシップフィールドにより、資産の割り当てレコードのデータは関連オブジェクトのレコードにも表示されます。この場合、従業員のプロフィールには割り当てられているすべての資産がリストされ、資産のレコードには割り当てられているすべての従業員がリストされます。

この例では、2人のエージェント（William CarltonとHarper Yoshimotot）と3つの資産（A001、A002、A003）を含む資産の割り当てレコードを追加します。

リキッドはHTMLをレンダリングするためのテンプレート言語です。そのメカニズムによって、プレースホルダを使用するメール通知にデータを自動的に配置させることができます。プレースホルダの書式設定だけでなく、リキッドを使用して、if/else文、case文、変数割り当てなど、通知内のコンテンツの表現について、簡単なプログラミングロジックを作成することもできます。

リキッドマークアップの詳細と使用例については、「リキッドマークアップとZendesk Supportについて」を参照してください。

ShoeLaLaは、ランニングシューズ、ライフスタイルシューズ、ブーツ、サンダルなど、複数のカテゴリにわたって5,000品目以上のシューズを販売するシューズメーカーです。ShoeLaLa社のZendesk管理者として、チケットフォームで使用できる製品カタログを作成するよう依頼されたとします。これにより、カスタマーは製品に関する苦情をメーカーに連絡する際に、問題のあったシューズをカタログから選択することになりました。Zendesk管理者は、カスタマーからのこの情報に基づいて、チケットを適切なエージェントにルーティングし、製品の問題に関するレポートの精度を高めることができます。

Zendesk管理者がまず最初に行わなければならないのは、製品カタログに使用される「製品」というカスタムオブジェクトを作成することです。製品オブジェクトの各レコードは、ShoeLaLaが販売するシューズの種類を表します。

このワークフローでは、チケットでやりとりする製品レコードをエージェントとエンドユーザーが表示および選択できるようにします。

詳細については、「カスタムオブジェクトレコードへのアクセス権の設定」を参照してください。

カスタムオブジェクトをカタログとして使用する場合、カタログ内の各製品がレコードとなります。このシナリオでは、ShoeLaLaがすでに販売している既存の製品群をインポートする必要があります。このシナリオでは、データインポーターを使用します。他の方法として、Custom Object Records APIを使ってレコードを一括作成することもできます。どちらの場合も、オブジェクトトリガとwebhookを使用して、Zendesk内の製品データをセールスCRMなどの外部サービスと同期させることができます。

最初のインポートを行った後、定期的に追加の一括インポートを実行するか、管理者とエージェントが必要に応じて手動で新しい製品を追加することができます。

ShoeLaLaでは、エージェントはサポート担当する靴のスタイルによってグループ分けされています。たとえば、「スポーツ」というエージェントグループに、スニーカー、ハイキングブーツ、スパイクなどに関するすべての苦情の処理を担当させ、「フォーマル」というエージェントグループには、ヒール、ローファー、ファンシーフラットなどに関する苦情の処理を担当させます。エージェントをグループ化するこのアプローチは、この製品カタログのワークフローに向いています。

エージェントはサポート担当の靴のスタイルでグループ化されているため、チケットトリガの条件として製品スタイルの値を使用し、自動的に正しいグループに割り当てることができます。

カスタムオブジェクトのワークフローを設定したら、Exploreを使用してルックアップリレーションシップフィールドのデータに基づいてレポートを作成することができます。具体的には、関連するカスタムオブジェクトレコードの属性を使用して、製品別チケットの数、スタイル、製品の現在の入手性などのチケットデータを定量化することができます。