組織とグループの定義
ユーザーの集まりはそれぞれ、次のように定義されます。
-
組織
「組織」は通常、エンドユーザーを集めたコレクションですが、チームメンバーを含めることもできます。Teamプランでは、ユーザーはひとつの組織にしか所属できません。ProfessionalプランとEnterpriseプランでは、ユーザーは最大で300の組織に所属できます。組織の使用は任意ですが、エンドユーザーを組織別にまとめることにより、これらの組織による要求の内容を追跡できるようになります。同じ組織内のユーザーどうしが、互いのチケットを確認できるようにすることも可能です。これにより、同じ組織内で発生したサポート案件を可視化できるため、重複するチケットを減らすことができます。
-
グループ
チームメンバー間で共通する条件に基づいてチームメンバーをグループ化します。グループ化できるのはチームメンバーのみです。エンドユーザーを含めることはできません。どのエージェントも、最低1つのグループに所属する必要がありますが、複数のグループに所属させることもできます。グループは、組織の下位区分として使用できます。1つのグループをアカウントのデフォルトグループとして指定することができ、また、チームメンバーごとにデフォルトグループを指定することもできます。新しく作成するチームメンバーはすべてデフォルトグループに追加されます。
エンドユーザーと組織
エンドユーザーを組織に追加することは必須ではありませんが、ワークフローの管理という観点からは、エンドユーザーを組織に追加しておくと便利です。まず、エンドユーザーの定義を明確にします。エンドユーザーとは、サポートリクエストを生成するメンバーを指します。小売業であれば、カスタマーがエンドユーザーとなり、企業であれば、社内のヘルプデスクによってサポートされる社員がエンドユーザーになります（この2例は、典型的なエンドユーザーのタイプです）。エンドユーザーを組織としてまとめる方法は管理者に一任されていますが、参考までに、組織の使用例を以下にいくつか示します。
-
SLA（サービスレベルアグリーメント）をサポートする
カスタマーとの間に結んだSLA（サービスレベルアグリーメント）を反映した組織を作成することができます。たとえば、有償で利用しているカスタマーに対しては、無償サービスのカスタマーよりも迅速な回答を保証しているため、この2種類のカスタマーを区別したいとします。または、カスタマーが購入した製品のバージョンまたはサービスのレベルに基づいてサポートのレベルが設定されている場合もあります（例：Basic、Professional、Enterpriseまたはシルバー、ゴールド、プラチナ）。カスタマーのグループに合わせて組織を作成し、サポートワークフローを通じてカスタマーを適宜振り分けることができます。そして、必要に応じてチケットを昇格させたり、SLA（サービスレベルアグリーメント）に照らしてパフォーマンスを追跡するためのビジネスルールやレポートを作成できます。
-
企業ごとにチケットを追跡、管理する
多くの場合、製品の販売先には企業も含まれます。販売先の企業ごとに組織を作成し、組織ごとにチケットの動向を管理、追跡することができます。
-
メールドメインに基づいてリクエストを管理する
メールドメインに基づいて、エンドユーザーを自動的に組織に追加することもできます。たとえば、社内と社外のエンドユーザーがいるとします。社内のエンドユーザー向けに組織を作成しておき、社員が初めてリクエストを送信したときに、メールドメインに基づいてその社員をその組織に追加することができます。新しいリクエストは、その組織向けに設定したワークフロールールでピックアップされます。
メモ：ドメインを組織に追加すると、そのドメインは許可リストに追加された場合と同様に処理され、ブロックリストよりも優先されます。これにより、そのドメインからのすべてのメールのスパム検出のしきい値が上がりますが、メールがスパムとしてマークされるのを防ぐことはできません。スパムと見なされるメールは引き続きスパムとしてマークされます。 -
地域と言語別にカスタマーをサポートする
サポートする組織または個人のカスタマーが世界各地に分散している場合は、地域や言語別に組織を作成し、各組織からのリクエストを同じ地域内の同じ言語を話すエージェントに振り分けることができます。
-
ヘルプセンターへのアクセスを指定する
組織を使用してユーザーセグメントを作成し、ヘルプセンターのどの記事の閲覧を誰に許可するかを指定できます。たとえば、ヘルプセンターの大半の内容はエンドユーザー全員に対して公開しますが、一部の内容については特定のグループのユーザー（プレミアムサービスプランのカスタマーなど）のみに閲覧を制限するように設定したいとします。組織を使用することで、それが可能になります。詳細については「Guideユーザー権限のユーザーセグメントを作成する方法」を参照してください。
組織を作成し、作成した組織にエンドユーザーを1人ずつ手動で追加することができますが、この処理は自動化することもできます。それには、ユーザーと組織を一括インポート操作で追加します。
チームメンバーを組織に追加することもできます。この処理は、Zendesk Supportのユーザーを組織別にまとめる操作の一環として行うことができます。また、エージェントのアクセスを、各自の所属組織にのみ限定することができます（この指定はエージェントの特権の設定時に行います）。
組織の設定が完了したら、さまざまな方法で活用し、Zendesk Supportでのワークフローの管理に役立てることができます。詳細については、後述の「組織とグループを使用する」を参照してください。
エージェントとグループ
グループはチームメンバーのみを対象としており、すべてのエージェントは必ず1つ以上のグループに所属する必要があります。グループをどのように設定するかは、組織と同様、ビジネスニーズと、優先するサポートワークフローに応じて決まります。以下に、グループのよくある使い方の例を示します。
-
複雑さに基づいてチケットをエスカレートする
エスカレーションは、階層化されたサポートグループ構造を設定することで管理できます。たとえば、緊急度や複雑さといった要素に基づいて、サポートレベル別のグループを作成します。デフォルトでは、すべてのチケットをレベル1グループに割り当てておき、問題の技術的な複雑さに基づいて、レベル2に手動でエスカレートするようにできます。レベル2のエージェントは（レベル1グループのメンバーを兼ねる場合もあります）、問題の解決に必要となる高度な技術を備えています。こ例については、「エスカレーションキューの管理」を参照してください。
-
SLA（サービスレベルアグリーメント）をサポートする
前述の組織の例と同じく、サービスレベルごとに定義された組織に対応するグループを設定することができます。
-
専門知識に基づくサポートを提供する
専門知識に基づいてグループを作成できます。たとえば、ソフトウェアとハードウェアの両方を開発している企業が、ソフトウェアをサポートするチームメンバーのグループと、ハードウェアをサポートするチームメンバーのグループを分けたいとします。その場合は、サポートを必要としている製品名をエンドユーザーが指定できるよう、サポートリクエストに製品名の入力を求めるカスタムフィールドを追加します。フィールドに入力された製品名に基づいて、チケットを正しいグループに割り振ることができます。
-
地域と言語別にカスタマーをサポートする
前述のように、地域および言語ごとに組織を設定し、チームメンバー（またはグループ）をチケットに割り当てることができます。地域や言語ことに組織を設定しなかった場合でも、エンドユーザーのメールドメイン（例：somecompany.fr）または言語環境設定に基づいて、該当するグループにチケットを転送できます。
-
機密性の高いチケットを非公開にする（Enterpriseのみ）
個人を特定できる情報（PII）やセキュリティ上の問題など、機密情報や保護された情報を含むチケットがある場合、プライベートグループを作成することができます。プライベートグループに所属する管理者とエージェントのみが、そのグループに割り当てられたチケットを閲覧できます。コラボレーターとフォロワーは、プライベートチケットに追加された場合、すべてのコメントを表示できますが、グループ内の他のチケットを閲覧することはできません。プライベートグループをパブリックに変換することはできません。詳しくは「プライベートチケットグループとその仕組みについて」を参照してください。
グループの作成時に、既存のチームメンバーをそのグループに追加することができます。新しいチームメンバーは、Zendesk Supportへの登録時に1つ以上のグループに追加することができます。また、新しいユーザーを一括インポートし、ロールとしてエージェントを定義してから、それらのユーザーをグループに手作業で追加することもできます。
グループによって組織をサポートする
では、グループはどのように組織をサポートするのでしょうか。広義では、グループは、組織のエンドユーザーから受け取ったチケットのサポートのハブとなります。組織のチケットへグループを割り当てる際には、前述の考慮事項（サポートのエスカレーションプロセス、セキュリティ、コロケーション、言語など）に基づいて振り分けが行われます。
サポートリクエストの内容に基づいて、チームメンバーが優先順位付けを行い、グループに割り当てるという柔軟なアプローチをとることもできます。または、割り当てを自動処理するビジネスルールを作成することもできます。詳細については、後述の「組織とグループを使用する」を参照してください。
ワークフローをより厳密に管理し、アクセス制限を課したエージェントにチケットを直接転送することで、セキュリティの境界を形成することもできます。このようにすると、エージェントは、閲覧を許可されているチケット以外は表示できなくなります。これを行う方法は、2つあります。ひとつ目の方法では、エージェントをグループに追加し、エージェントのアクセスをそのグループのみに制限します。もうひとつの方法では、エージェントを組織に追加します。そうすることで、そのエージェントはその組織内のエンドユーザーが送信したチケット以外にアクセスできなくなります。
組織とグループを使用する
組織およびグループの構成の整理を完了したら、組織やグループを使用したチケットワークフローの管理およびZendesk Supportアクティビティの監視が可能になります。
- グループマッピング：組織内のユーザーから受け取ったチケットを、特定のグループに自動的に割り当てる機能です（「グループを組織にマッピングする」を参照）。
- ユーザーマッピング：組織に新しく追加されたユーザーを、各自のメールドメインに基づいてマッピングします。
- 組織で共有：組織内のユーザーに、その組織に送られたすべてのチケットの閲覧を許可します（「エンドユーザーのために組織で共有機能を設定する」を参照）。
- チームメンバーを、特定の組織のサポート専任にする（「ユーザーを組織に追加する」を参照）。
- 組織を、グループまたはチームメンバーにリクエストを自動的に割り当てるトリガの条件として使用する（「トリガの条件文を作成する」を参照）。
- トリガの条件をタグのテストで使用し、それらのタグに基づいてリクエストをグループまたはチームメンバーに自動的に割り当てる（「チケットの更新と通知のためのトリガの作成」を参照）。
- 新規リクエストをグループまたはチームメンバーに割り当てるマクロを作成する（「マクロを使ったチケットの更新」を参照）。
- チケットをグループまたはチームメンバーにエスカレートする自動化を作成する（「時間ベースのイベント用の自動化の作成と管理」を参照）。
- 組織またはグループ別のビューを作成する（「組織またはグループ別のビューを作成する」を参照）。
- 組織またはグループ別のレポートを作成する（「Explore関連のリソース」を参照）。
ユーザー、グループ、組織向けの管理者とエージェントロール
ここでは、Zendeskにおけるユーザー、グループ、組織の管理について、誰が何を担当するかについて概要を示します。
- エンドユーザーを手作業で一度に1人ずつ登録するか、一括インポートで一度に多数のエンドユーザーを登録する
- 組織とグループを作成、編集する
- ある組織を別の組織に統合する
- エンドユーザーを組織に追加する
- チームメンバーを新規作成し、それらを1つ以上のグループと1つの組織に追加する
- ひとつまたは複数のグループへのエージェントのアクセスを制限する
- エージェントのアクセスを、エージェントが所属している組織から受け取ったリクエストのみに制限する
- ユーザーマッピングを設定する（エンドユーザーを各自のメールドメインに基づいて組織に自動的にマッピング）
- グループマッピングを設定する（組織内のユーザーから受信したリクエストを、特定のグループに割り当てる）
- 組織で共有を設定する（同じ組織内の全ユーザーから送られたチケットの閲覧を、その組織内のすべてのエンドユーザーに許可する）
- ユーザー、グループ、組織別に共有ビューと個人ビューの両方を作成する
- グループを含むビジネスルール（自動化、マクロ、トリガ）を作成する
- 組織を含むビジネスルール（自動化、マクロ、トリガ）を作成する
- グループと組織を含むレポートを作成する
- エンドユーザーの追加
- エンドユーザーを組織に追加する
- 組織内のすべてのチケットの表示をエンドユーザーに許可する（組織で共有機能が有効になっている組織にエンドユーザーが属している場合、そのエンドユーザーはその組織内の全チケットにアクセスできる）
- ユーザー、グループ、組織別の個人ビューを作成する
- グループにチケットを割り当てるマクロを作成する