Zendeskインスタンスを使用する際の注意事項

あなたの会社には、プロセスやセキュリティニーズ、ワークフローの異なるさまざまな部門を含む複数の組織が存在するかもしれません。自社のサポート業務にとって、Zendeskのインスタンスの数が1つで足りるか、それとも複数のインスタンスを用意する必要があるか、検討しておくとよいでしょう。この記事では、Zendeskインスタンスを1つだけでなく、複数使用することの利点、考慮事項、および成果について説明します。この記事では、次のトピックについて説明します。

• 機能の検討事項
• チェックポイントを絞る
• まとめ

機能の検討事項

このトピックでは、複数のチームで以下の機能を使用するために、1つのZendeskインスタンスを使用する場合の効果について説明します。 

• グローバル設定
• ビジネスルール
• インテグレーション
• 認証とアクセス権
• エンドユーザー管理
• エージェントの権限とチケットアクセス
• レポーティング
• Web Widget（従来版）およびChatウィジェット
• Guide

グローバル設定

このセクションでは、グローバル設定に関する考慮事項について説明します。 

• サブスクリプション
  1つのZendeskインスタンスを共有する場合は、すべてのエージェントがSupport、Guide、Talk、およびChatで同じプランタイプである必要があります。特にGuideの場合、すべてのSupportエージェントがGuideエージェントでなければなりません。1つのチームだけがGuideを使用する場合は、これは、コスト節約になる選択肢です。

• エージェント署名
  Zendeskのネイティブのグローバルエージェント署名は、1インスタンスあたり1個です。回避策として、トリガやリキッドマークアップの条件に署名を入れて、チームごとにトリガをカスタマイズできます。

• メールテンプレート
  Zendeskのネイティブのメールテンプレートは、1インスタンスあたり1個です。回避策は、HTMLやCSS、リキッドマークアップをサポートするすべてのビジネスルールをカスタマイズすることです。詳しくは「リキッドマークアップとZendesk Supportについて
  」を参照してください。

• 登録完了通知メール/メールアドレス確認メール
  ネイティブのエンドユーザー登録完了通知/メールアドレス確認は、「設定」>「アカウント」でアカウント名を登録後に1回だけ送られます。

• サブドメイン
  すべてのエージェントが使用し、覚えておく必要のあるサブドメインは1つのみです。エージェントのサブドメインをチーム名にカスタマイズすることはできません。
  
  
• 誰でもチケットを送信可能か？
  1つのZendeskアカウントは、すべてのユーザーに対して公開、またはすべてのユーザーに対して非公開にされている必要があります。公開されている場合は誰でもリクエストを送信したり、Guideにログインしたり、ウィジェットでチケットを送信したりすることができます。非公開にされている場合、エンドユーザーがリクエストを送信したり、Guideにアクセスするには、Supportの登録ユーザーになっている必要があります。「エンドユーザーのZendesk Supportへのアクセスおよびサインイン方法の設定」を参照してください。
  
  
• アカウント名
  • アカウント名は1つだけです。詳しくは「Zendesk Supportでアカウント名を変更する方法」を参照してください。
  • プレースホルダが書式設定されている場合、アカウント名はメール上に表示されます。アカウント名は送信メールに含まれ、エンドユーザーに表示されます。メールにアカウント名が表示されないようにするには、書式設定プレースホルダの使用をやめ、代わりにリッチテキストをサポートするリッチコンテンツプレースホルダを使用する必要があります。しかし、書式設定プレースホルダによる美的な外観は失われます。
  • 最後に、アカウント名はログインページまたはプロンプトに表示され、編集できません。

• ユーザーに複数の組織に属することを許可する
  複数のチームで1つのZendeskインスタンスを使用する場合は、インスタンス全体に対して有効または無効になるグローバル設定は1つです。
  
  
• 満足度アンケート
  Supportインスタンス全体で満足度アンケートが有効または無効になっているかにかかわらず、ビジネスルールを編集して特定のユーザーグループを調査対象から除外できます。プレースホルダを使用すれば、どんなチケットにも満足度リンクを生成することができます。「カスタマー満足度評価のプレースホルダを使用する」を参照してください。
  
  
• データのエクスポート
  チケット、ユーザー、および組織のデータエクスポートは、アカウント全体でグローバルです。ただし、Zendesk Core APIを使用すると、特定のデータを取得できます。
  
  
• タグ
  1つのインスタンスを複数のチームで共有する場合は、タグを複数のワークフローやリソースでリサイクルしないでください。

ビジネスルール

このセクションでは、ビジネスルールに関する考慮事項について説明します。

• トリガ、自動化、ビュー、およびSLA
  • ビジネスルールはすべてのチケットで実行されますが、チケットグループまたはブランドを参照する条件によって簡単に制限できます。詳しくは「ビジネスルールでグループを使用する」を参照してください。 管理者の権限はグローバルで、管理するグループ以外のグループのルールを作成できます。このため、あるチームの管理者が編集したルールが、他のチームのチケットやワークフローに影響するおそれがあります。 
  • 1つのZendeskインスタンスを複数のチームで共有する場合、管理すべきルールが次第に増えていきます。 ルールの複雑さが増してくると、変更管理戦略とチーム間の継続的なコラボレーションが必要になります。 また、目的以外のグループにチケットが誤ってルーティングされるリスクも高くなり、SLAの遵守に影響がおよぶ可能性があります。
  • また、機密情報やセキュリティ保護された情報へのアクセス権のないエージェントに、それらの情報が表示される懸念への配慮が必要です。グループ単位でビジネスルールを調整するネイティブメソッドはありません。
  • ビジネスルールの調整/グループ化を支援するために、ルール名以外の機能を持たないプレースホルダトリガまたは自動化を作成できます。チームはルール名でルールを識別することができます。
    
    
• マクロ
  マクロの使用は、グループ内のすべてのエージェントまたはエージェントに対して設定できます。詳細については、「チケットに適用する個人マクロまたは共有マクロを作成する」を参照してください。
  
  
• チケットフィールドおよびチケットフォーム
  • チケットフィールドとチケットフォームは、インスタンス全体に対して機能します。すべてのチームが、すべてのフォームとフィールドを見ることができます。カスタムチケットフォームとは、チームやエンドユーザーのニーズに合わせて作成される独自のフォームです。
  • エージェントインターフェイスでは、チケットを表示するエージェントに応じて、カスタムアプリの特定のフィールドを表示または非表示にすることができます。詳しくは「チケットフォームの制限」に関する記事で説明したレシピの実装を検討してみてください。
  • ヘルプセンターのコードをカスタマイズすることで、リクエストフォームから、必須入力ではないエンドユーザー入力フィールドを非表示にすることができます。

インテグレーション

このセクションでは、インテグレーションに関する考慮事項について説明します。

• Jira
  Zendesk Jiraインテグレーションv3は1対1の対応です。1つのZendesk Supportアカウントに複数のJiraインテグレーションをリンクすることはできません。
  
  
• カスタムインテグレーション
  Supportインスタンスが複数ある場合は、それぞれにカスタムインテグレーションのセットアップと構成が必要です。 たとえば、データをエクスポートしたり、ユーザーデータベースに接続したりする場合、各Supportインスタンスの両面から開発と構成を行う必要があります。
  
  
• アプリ（ZAF）
  アプリは、各Supportインスタンスにインストールして設定する必要があります。 ネイティブオプションで細かく調整できない場合は、カスタムアプリをコーディングして、ユーザーグループの確認やアプリの表示/非表示の設定などができます。 グループまたはカスタムロールごとにアプリへのアクセスをネイティブに指定することは可能です。詳しくは「グループ別にアプリの表示を制限する方法」を参照してください。

認証とアクセス権

このセクションでは、認証とアクセス権に関する考慮事項について説明します。

• 基本認証
  Zendeskインスタンスが複数の場合、ログイン（ユーザー名とパスワード）はインスタンスごとに固有です。エージェントとエンドユーザーは、ネイティブのZendesk認証を使用する複数のZendeskインスタンスに対して、2組の認証情報を管理し、記憶しておく必要があります。
  
  
• APIアクセス
  APIトークンはグローバルに機能します。つまり、APIトークンを持つすべてのユーザーは、アカウント内のすべてのリソースとデータにアクセスできます。
  
  
• OAuth
  OAuthトークンは、アクセスのスコープを特定のリソースにのみ設定できます。 ただし、トークンのスコープをエージェントグループに設定することはできません。
  
  
• シングルサインオン（SSO）
  • ネイティブSSOは、エージェントとエンドユーザーのどちらの構成でもインスタンス全体に適用されます。すべてのチームのエージェントとエンドユーザーは、SSO IDプロバイダで構成する必要があります。
  • ユーザーが他の認証方法（Zendesk認証とSSO）を使用できるようにするための回避策がありますが、これは顧客側で構築する必要があります。詳しくは「アカウントに最適な認証オプションの選択」を参照してください。

エンドユーザー管理

このセクションでは、ユーザー管理に関する考慮事項について説明します。

• 組織フィールドとユーザーフィールド
  組織フィールドとユーザーフィールドは、インスタンス全体でグローバルに機能します。つまり、すべてのエージェントがすべてのフィールドを表示し、編集できます。チケットフィールドと同様に、カスタムアプリは、表示しているエージェントに応じて、特定の組織/ユーザーフィールドを表示または非表示にすることができます。
  
  
• 組織の管理
  • 組織は、インスタンス全体に対して機能します。エージェントグループごとに、組織や組織の表示権限を分けることはできません。
  • 組織チケット共有機能については、アクセス権限は組織内のすべてのチケットに対して適用されます。 このオプションを有効にすると、SupportとGuideを使用するすべてのチームのチケットに影響します。
  • 組織名は一意である必要があります。ユーザーが複数の組織に所属することは可能ですが、複数のチームに同じ組織名を付けることはできません。
    
    
• エンドユーザーの権限とアクセス
  • すべてのエンドユーザーは、インスタンス全体に対してグローバルに扱われます。1つのインスタンス内で、あるエンドユーザーにあるチームへのリクエスト送信は許可し、別のチームへの送信は許可しない、という扱いはできません。
  • ネイティブでサポートされる基本的なエンドユーザー認証方法は1つだけです。エンドユーザーはすべてのヘルプセンターインスタンスにログインできます。この動作を回避するワークフローがありますが、高度なカスタマイズが要求され、Zendeskカスタマー側で開発が必要になります。 

エージェントの権限とチケットアクセス

• エージェントによるエンドユーザーの編集権限
  プランのタイプによって考慮事項が異なります。
  • カスタムエージェントロール：プランにカスタムロールが含まれている場合、エージェントのあるグループにエンドユーザーのプロフィールの編集を許可し、別のグループには編集を許可しないように設定できます。エージェントは、すべてのエンドユーザーのプロフィールを表示できます。特殊なケースとして、エージェントに別のグループのチケットへのアクセス権限は付与せずに、エンドユーザープロフィールの編集権限のみを付与する設定もあります。これには、エンドユーザーが送信したすべてのリクエストチケットをエージェントが見ることができる代理ログインも含まれます。
  • エージェントのロール： カスタムエージェントロールのないプランタイプでは、すべてのチケットにアクセスできるエージェントだけが、エンドユーザーの追加、編集、または代理ログインが可能です。
  • 特殊なケースとして、あるチームのエージェントが別のチームのエンドユーザーになっていることがあります。この場合、エージェントはエンドユーザー用のフォームを使用できないため、ヘルプセンターでチケットを送信することができません。グループの権限に関係なく、エージェントは自身がリクエスタになっているチケットにアクセスできます。つまり、リクエスタとして、非公開のやりとりにアクセスできます。
    
    
• グループの管理とチケットアクセス
  • グループは、インスタンス全体に対して機能します。複数のチームを管理するためにグループを作成し、グループごとにチケットアクセスを制限することは可能です。
  • Enterpriseプランでは、プライベートチケットグループを作成することもできます。プライベートチケットグループにより、グループの割り当てに基づいてチケットの閲覧権限とアクセス権限をより細かく管理することができ、閲覧権限のないエージェントからプライベートチケットを完全に隠すことができます。
  • また、Enterpriseプランではカスタムエージェントロールを使用して、エージェントがプライベートチケットグループにチケットを割り当てられるかどうかなど、エージェントのプライベートグループへのアクセス権限を管理することができます。

レポーティング

このセクションでは、レポーティング機能の考慮事項について説明します。

• レポーティング
  
  • インスタンスが1つの場合、レポートは集中管理されます。 すべてのチケット、ユーザー、および組織のデータは、レポーティング機能を使用できるすべてのユーザーが利用できます。
  • プランによっては、チケットへのアクセス権限が、レポーティングへのアクセス権限を決定します。エージェントがレポーティング機能を表示するには、すべてのチケットにアクセスできる必要があります。
  • 既定のレポーティングダッシュボードは、すべてのSupportデータを包括します。したがって、グループまたはその他のチケットレベルの属性（カスタムチケットフィールド、チケットブランドなど）に基づいてレポーティングするには、カスタマイズが必要です。
    
    
• ネイティブレポーティング
  ネイティブレポート（Explore以外）の概要、ランキング、ナレッジベース、コミュニティ、検索、およびTalkは、インスタンス全体をグローバルに解析します。

Web Widget（従来版）およびChatウィジェット

このセクションでは、Web Widget（従来版）およびChatウィジェットに関する考慮事項を説明します。考慮事項は、メッセージングWeb Widgetには該当しない場合があります。

• ネイティブのカスタマイズと外観（色、位置、ボタンテキスト）は全体に共通です。Widget APIを使用してチームごとにウィジェットをカスタマイズすることは可能ですが、カスタム開発が必要です。
• チケットフォームは、チームごとにフォーム/フィールドのインターフェイスのカスタマイズが必要になる場合があります。
• ウィジェット内のヘルプセンター検索では、ナレッジベース全体と1つのナレッジベースのみを検索します。ただし、カスタム開発によって、検索結果をカスタマイズできる可能性があります。
• 1つのチームだけがChatを使用している場合は、ウィジェットのChatをオン/オフのどちらかに設定できます。この設定は、Widget APIおよびChat APIのカスタマイズで上書きできます。

Guide

このセクションでは、Guideに関する考慮事項を説明します。

• エージェントの権限
  • 複数のチームで1つのGuideを共用している場合は、協調的な戦略が必要です。たとえば、マルチブランディング環境であっても、あるチームでマネージャーのロールを持っているエージェントは、他のチームのコンテンツを管理したり、テーマを編集したりすることができてしまいます。
  • 記事の編集権限と作成権限は、Supportの設定とGuideのセクションレベルの設定の両方で行います。Zendesk Supportの管理者は、デフォルトでGuideの管理者です。
  • カスタムロールが含まれるプランタイプの場合、カスタムロールを作成してGuideの管理者の権限を設定することができます。それ以外のプランでは、各エージェントのプロフィールページでエージェントにGuideの管理者または閲覧者の権限を設定できます。詳しくは「Guideのロールとアクセス権限の設定」を参照してください。
  • Supportでエージェントが閲覧者として設定された場合も、Guideのセクションレベルの権限で管理者とエージェントに設定されていれば、それらのセクションにおいて記事を作成および編集可能です。

• エンドユーザーエクスペリエンス
  • Zendeskインスタンスが1つの場合、すべてのエンドユーザーがすべてのヘルプセンターにログインできます。複数のチームが同じ1つのZendesk Supportインスタンスをチケット管理に使用している場合、チーム間で共通のエンドユーザーのログイン情報は1つで済みます。それに対して、各チームがそれぞれ別のSupportインスタンスを使用する場合は、インスタンスごとに異なるログイン情報が必要になります。
  • 1つのSupportインスタンスを共有する場合、エンドユーザーはすべてのチケットを1か所で見ることができます。ただし、ブランドが1つのみの場合に限ります。
  • 1つのSupportインスタンスに複数のヘルプセンターが関連付けられている場合、どのコンテンツの閲覧をどのユーザーに許可するかを管理するには、ユーザーセグメントと権限付与に関する戦略が必要になります。
  • 最後に、あるチームのエージェントが別のチームのエンドユーザーになっている場合、ヘルプセンターでの操作が制限されます。ヘルプセンターでリクエストを送信したり表示しようとすると、Supportにリダイレクトされます。

チェックポイントを絞る

最終決定する前に、以下のチェックポイントを検討してください。

すべてのエージェントがすべてのチケットにアクセスできる必要があるか？

複数のチームで1つのSupportインスタンスを共用している場合、すべてのチケットに対するアクセス権を許可するかどうかを検討する必要があります。

すべてのチケットへのアクセスを許可する場合：

• エージェントがすべてのチケットにアクセスできる場合、ビジネスルール（ビュー、トリガ、自動化、SLA、メールテンプレート）がインスタンス全体に対して適用される環境において、ビジネスルールによってチームごとにチケットのルーティングを設定および分離すると、システム管理はどの程度複雑になるか？ 
• たとえば、2つのチーム（サポート部門とセールス部門）が1つのZendeskを共有する場合、各チームのエンドユーザーエクスペリエンスをカスタマイズするために、チームごとにルーティングトリガ（および、自動返信/コメント更新ごとに個別のトリガ）が必要になります。
• SLAの観点で言えば、チケットが誤配信されるリスクが高くなります。

すべてのチケットへのアクセスを許可しない場合：

• アクセスを制限するには、グループまたはカスタムロールの設定が必要になります。
• チケットへのアクセスを許可しないグループにチケットが誤配信されないよう、チケットのルーティングを慎重に管理することが求められます。
• エージェントに関係のない、他のグループの過去または現在のリクエストの表示を制限します。チケットのアクセス制限により、レポーティング機能へのエージェントのアクセスを制限することもできます。
• 制限されたエージェントに対して、エンドユーザーの代理ログインを許可してしまった場合、ヘルプセンターの「マイアクティビティ」から他のグループのチケットにアクセスできてしまう可能性があります。

集中管理された、または既存のユーザー管理戦略があるか？

エージェントとエンドユーザーに関する考慮事項：

• Zendesk認証に関しては、両方のインスタンスのエージェントであるユーザーには2つのログイン資格情報があります。
• SSOを使用している場合、Zendeskを両インスタンスのサービスプロバイダとして設定する必要があります。カスタムユーザーデータをやりとりする場合は、両方のインスタンスでユーザーフィールドまたは組織フィールドを作成する必要があります。すべてのカスタムユーザーフィールド、組織、およびロールには一意のIDがあり、一意のSAML/JWTアサーションを構成する必要があります。

エンドユーザーに関するその他の考慮事項：

• HRとカスタマーサポートの両部門で1つのインスタンスを共有している場合などに、エンドユーザーに各部門のヘルプセンターの記事にアクセスさせる必要があるか？
• エンドユーザーがHRおよびカスタマーサポートのすべてのコンテンツにアクセスできる必要があるか？  

まとめ

ここでは、1つのインスタンスを共有する場合と、複数のインスタンスに分ける場合のそれぞれの利点と考慮事項を簡単にまとめています。

1つのZendesk Supportインスタンスを共有する場合の利点：

• 一貫性のあるカスタマーエクスペリエンス。
• 一貫性のあるレポーティング。
• エージェントに関するコスト：チーム間で1つのライセンスを共有。
• 1つのSupportインスタンス内で、部門間のエスカレーションや問題の追跡が容易。
• 統合されたユーザー管理と認証：
• 単一のユーザー認証情報。
• 全方位からの顧客管理。

考慮事項：

• 一部のプランタイプでは、チケットへのアクセス制限が複雑。
• 他のチームのエンドユーザーとなるエージェントのエクスペリエンスが低下。
• 定義された変更管理のプロセスと戦略が必要。
• チケットルーティングとビジネスルールの複雑さが増大。
• Supportのカスタマイズ可能な多数の機能（認証、メールテンプレート、アカウント名、最初に送信されるメールなど）がグローバルに適用。

複数のZendeskインスタンスに分ける場合の利点：

• 隔離が容易。
• 他のチームに影響が及ばないように柔軟に変更可能。
• 独立したカスタマイズ可能なTier 0/セルフサービスとナレッジワークフロー（KCS、Answer Bot、チームパブリッシング）。
• チームごとに完全にカスタマイズ可能なエンドユーザーエクスペリエンス（他のチームのエンドユーザーとなるエージェントには最適）。
• チーム単位でのチケットへのアクセスとセキュリティに関する制御。

考慮事項：

• 複数インスタンスの構成と分析のオーバーヘッドコスト。

• インスタンスごとにSSO、アプリ、およびインテグレーションの設定が必要。

• エンドユーザーが、リクエストやセルフサービスを送信するために、別の場所に移動する必要がある。

• Supportインスタンス間でのチケット共有のために、エージェントのコラボレーションの複雑さが増大。

• 2つのSupportインスタンス間で、エージェントコリジョン機能が機能しない。

• チケット共有により、Zendeskを使用して2つのチームが共同作業を行えるが、Supportインスタンス間でチケットの更新が同期されない。

• 一部のプランタイプでは、プライベートチケットグループを作成することによって、1つのインスタンス内でチーム別のチケットアクセスやセキュリティの管理が可能。