ブラッシュアップ：理想のZendeskを組み立てる方法

このブラッシュアップセッションでは、Zendeskインスタンスを1つずつ構築する方法について説明します。

• グループとロール
• ユーザーフィールドおよび組織フィールド
• チケットフィールドおよびチケットフォーム

製品リリース担当マネージャー、Don Newtonは、2014年10月からZendeskに勤務し、カスタマーサポート、ソフトウェアのトレーニング、および導入に14年以上の経験を持っています。

Donのブラッシュアップセッション - パート2ではベストプラクティスとワークフローに関する役立つアドバイスを取り上げており、必見です。 

パート1：グループとロール

こどもの頃、一番好きだったおもちゃは何ですか？アクティブに遊ぶおもちゃでしたか？ごっご遊びをするおもちゃでしたか？それとも、何かを作るおもちゃが好きでしたか？

私は、アクションフィギュアやサッカーボール、水鉄砲、テレビゲームなどのおもちゃに囲まれて育ちましたが、一番のお気に入りのおもちゃはずっとレゴでした。自由自在に創造性を発揮することに関しては、レゴにかなうおもちゃはありませんでした。十分な時間と十分なレゴパーツがあれば、私は何でも作ることができました。

80年代から90年代にかけて、このデンマーク製のシンプルなブロックパーツを使って複雑な構造物を設計する仕事に就くことが、あらゆるこどもの夢だったのです。今日、私はその夢を叶えたと言えます。きっとあなたも。

Zendeskを構築することは、レゴを使って何かを組み立てることとよく似ています。すばらしいプラスチック製のブロックパーツ - レゴと同様に、Zendeskはモジュール式であり、各コンポーネントは他のコンポーネントと連携して機能するように作られています。パーツを組み合わせて、考えられる限り最強の宇宙船（あるいはチケットシステム）を構築することができます。

このブラッシュアップセッションでは、Zendeskの各コンポーネントを紹介し、さらに隠れた落とし穴、ベストプラクティス、インスタンスの構築前に確認すべきことについて説明します。

お見逃しなく！

グループ

グループを使用してエージェントを整理できます。Zendeskでグループを利用する方法はいくつかあります。

• 特定のエージェントのグループにチケットを割り当てる
• 特定のエージェントのグループ用のビューを作成する
• 特定のエージェントのグループ用のマクロを作成する
• 特定のエージェントのグループに通知を送信する
• グループ内のエージェントのパフォーマンスについてレポートを作成する

隠れた落とし穴：

グループは必ずしも組織の構造を完全に反映するものではありません。多くの管理者が、チームの親グループを作成しようとしますが、親グループがあるとチケットを再割り当てするときに混乱を招き、チケットが見落とされたり、処理が遅れる結果になりがちです。

親グループに割り当てられたチケットは、エージェントのビューに適切に表示されないことがあります。

ベストプラクティス：

Zendeskのすべてのグループに明確な目的を持たせるようにしてください。何よりも、エージェントがシンプルさを維持するために、使用するグループ数はできるだけ少なくします。

多くの会社はチケットを割り当てる目的で、ごく少数のグループを作成しています。この同じグループに、専用のビュー、マクロ、および通知を設定できます。これはグループを使う最も簡単な方法です。

同じ1つのマクロまたはビューを、複数のグループに割り当てたい場合もあります。Zendeskでは、ビューまたはマクロの使用を単一のグループに限定しているため、次のことを行う必要があるかどうかを検討する必要があります。

1. 重複したビューまたはマクロを作成し、それらを各グループに割り当てる。
2. ビューまたはマクロ用に追加のグループを作成して、該当するすべてのエージェントを追加する。

複数のビュー/マクロを作成すると、両方のグループに属するエージェントは重複して見えます。ビューまたはマクロ用に追加のグループを作成する場合、それらのグループにはチケットを割り当てないように、エージェントを訓練する必要があります。

確認事項：

• 不要なグループがありますか。
• 空のグループはありますか。
• 他のグループと重複しているグループはありますか。
• Zendeskの各グループの固有の目的をそれぞれ特定できますか？
• 必要な場合、Zendeskに価値を追加するために、どのようなグループを作成できますか？

グループへのアクセスおよび編集は、「管理」>「メンバー」>「組織」で行ないます。

グループの作成と管理の詳細については、こちらをご覧ください。

ロール

ロールは、エージェントの権限を定めるものです。各ユーザーは、1つのロールだけを持つことができます。ユーザーロールを作成すると、エージェントのアクセス権を次のように設定できます。

• すべてのチケット、または所属グループに割り当てられているチケットのみにアクセスする
• チケットに公開コメントを追加する
• チケットフィールドまたはタグを更新する
• チケットを統合または削除する
• エンドユーザーのプロフィールを編集する
• レポートを編集し、作成する
• ヘルプセンターを管理する
• ビジネスルールを管理する
• マクロおよびビューを管理する
• チャネルや拡張機能を管理する

隠れた落とし穴：

チケットに機密情報が含まれている場合は、個々のエージェントのチケットへのアクセス権を制限することが重要です。すべてのロールの最初のアクセス許可によって、そのロールのユーザーがアクセスできるチケットが決まります。エージェントにすべてのチケットの表示を許可すると、そのエージェントは、ビューに表示されないチケットを含め、インスタンス内のあらゆるチケットを表示できます。

エージェントが表示できるチケットを所属グループ内のチケットのみに制限すると、ユーザーや組織のチケット履歴を一部しか表示できなくなり、グループ外のチケットを検索することもできなくなります。このように制限することで、エージェントは、顧客の以前の問題または進行中の問題について一部の情報にアクセスできなくなります。

できれば、ロールを個々のユーザーに対して適用することは避けます。チームが成長するにつれて、多数のロールを管理することが難しくなるからです。「ロール」は単なる権限セットです。ビューやマクロ、さらにはチケットの割り当てに影響する可能性のある「グループ」とは混同しないようにしてください。

船頭多くして船山に登るということわざはよく知られています。このことわざは、Zendeskの管理にも当てはまります。管理者権限を持つユーザーが多数いると、ビュー、マクロ、トリガ、自動化などの命名規則に関して一貫性が損なわれるおそれがあります。また、ビジネスルールの設定やワークフローの矛盾を招く可能性があります。

エージェントの作業用に所定の共有ビューがある場合、エージェントに個人ビューの作成を許可することで、個人ビューから作業することを選択した場合にワークフローを迂回できます。個人ビューには異なるチケットが表示されるか、またはチケットの並び方が異なります。同じことが、共有マクロと個人用マクロについても言えます。

ベストプラクティス：

すべてのチケットへのアクセス権を与えるエージェントを決めます。エージェントがxチケットを除くすべてのチケットにアクセスできるようにZendeskを設定することはできません。ただし、エージェントにxチケットのみを表示するようにZendeskを設定することはできます。それには、当該のエージェントが所属グループ内のチケットのみを参照できるように設定してから、それらのエージェントを適切なグループに追加します。この場合、xは、エージェントのグループに割り当てられたチケットを表します。

作成するロール数は、できる限り少なく抑えてください。少数の一般的なロールを作成するやり方は、組織が成長して進化しても保守しやすいため、はるかにスケーラブルなソリューションです。

管理者権限を持つユーザーの数を制限します。一般的に推奨できるやり方としては、管理者を4〜5人に抑えることです。これにより、誰かが誤って（または意図的に）広範囲に及ぶ変更を加えて、成功に悪影響を及ぼすことを避けることができます。これには、チャネルやビジネスルール、ロール、スケジュール、またはワークフローに影響を与える可能性があるその他のアイテムへの変更が含まれます。

確認事項：

• エージェントは、現在のロールで目的を達成することができますか？
• お使いのZendeskに、いくつのロールがありますか？
• 必要のないロールがもしあれば、それはどれですか？
• ワークフローを改善するために追加・改善できるロールがあれば、それはどれですか？

ロールへのアクセスおよび編集は、「管理」>「メンバー」>「ロール」で行ないます。

Zendeskのロールの使用について詳しくは、こちらをご覧ください。

パート2：組織、組織フィールド、およびユーザーフィールド

組織

組織では、エンドユーザーをグループ分けできます。組織を使用して、以下のことが可能です。

• 同じ会社/部門のユーザーをグループ化する。
• ルーティングまたはレポート用のチケットに重要な情報を追加する。
• どの顧客が最も多くチケットを作成しているかについてレポートを作成する。

隠れた落とし穴：

各チケットは1つの組織にしか属することができません。複数の組織に所属するユーザーがいる場合（ProfessionalとEnterpriseのみ）、そのようなユーザーのチケットは自動的にデフォルトの組織に割り当てられます。つまり、ユーザープロフィールで全員のデフォルト組織を確実に割り当てる必要があります。

組織タグは、チケットが作成されたときにのみチケットに追加されます。つまり、チケットの作成後にチケットの関連組織を変更しても、組織タグはチケットに渡されません。

HRの問題の追跡にZendeskを使用している場合は、組織内のユーザーに、互いのチケットへのアクセスを許可していないことを確認してください。この設定を見落とした場合、潜在的に機密性の高い人事担当のコミュニケーションを従業員同士に読まれてしまうという問題に直面する可能性があります。

ベストプラクティス：

組織を使用して、顧客のチケットをメールドメインに基づいて自動的に結び付けることができます。このようにすると、特にBtoBのユースケースに役立ちます。組織に1つのドメイン（または複数のドメイン）を追加すると、それらのドメインを含むメールアドレスを持つユーザー（およびチケット）が自動的に追加されます。これにより、各組織のユーザーを継続的に管理する必要がなくなります。

組織タグは、組織内のユーザーによって作成されたすべてのチケットに追加されます。特にメールチケットについて、ビジネスルールを結び付けるのに最適な方法です。「vip」や「product_x」などのタグを追加するだけで、優先順位の設定や、特定のグループまたはエージェントへのチケットのルーティング、または特定のSLAポリシーの設定ができます。

組織をCRMと同期させて、最新の状態に保つことができます。当社のAppsマーケットプレースで利用可能なアプリの一覧については、こちらをご覧ください。

確認事項：

• 外部のCRMからユーザーや組織の情報を同期していますか？または、その必要がありますか？

• ユーザーが複数の組織に所属できるようにしますか？

• その場合、ユーザーのデフォルトの組織をどれにしますか？

• タグがある場合、組織にどのようなタグを追加しますか。

• あなたの組織は、会社、部署、分類など、何を表していますか？

組織へのアクセスおよび編集は、「管理」>「メンバー」>「組織」で行ないます。

Zendeskの組織の使用について詳しくは、こちらをご覧ください。

 

ユーザーフィールドおよび組織フィールド

ユーザーフィールドは、ユーザープロフィールに存在し、ビジネスルールに影響を与えたり、ユーザーによって要求されたチケットに重要な情報を渡したりできます。組織フィールドは、組織内のユーザーからリクエストされたチケットに情報を渡すことができます。

作成できるカスタムのユーザーフィールドおよび組織フィールドには、次のタイプがあります。

• ドロップダウンリスト
• 本文
• 複数行テキスト
• 数値
• 小数
• チェックボックス
• 正規表現
• 日付

ドロップダウンリストとチェックボックスフィールドはどちらも、ユーザーがリクエストしたチケットに情報を追加できます。これらの各フィールドタイプは、ユーザーまたは組織にタグを追加し、それらのタグがユーザーによって作成されたチケットに追加されます。

隠れた落とし穴：

ユーザーフィールドが多すぎると、ユーザープロフィールを見たときに不要なノイズが発生する可能性があります。

なお、組織タグは、ユーザープロフィールに渡されないので注意が必要です。これは、新しいZendesk管理者における共通の前提です。

ユーザータグと組織タグは、チケット作成時にのみチケットに渡されます。つまり、チケットの作成後にチケットの組織やリクエスタを変更しても、新しいユーザータグや組織タグはチケットに追加されません。これにより、タグベースのワークフローが有効にならない可能性があります。

ベストプラクティス：

可能な場合は常に、ドロップダウンとチェックボックスのフィールドを使用するようにしてください。これにより、各ユーザーまたは各組織に関する一貫した情報を取得でき、ユーザーが作成したチケットにタグを介して情報を渡すことができます。これらのフィールドはまた、エージェントによる更新をより簡単にし、管理者によるレポーティングの選択肢を増やします（例：人口統計/産業別に作成されたチケット、VIP顧客のチケット満足度など）。

レポートに加えて、チケットのルーティングまたは優先順位付けにユーザーフィールドや組織フィールドを使用することには、高い価値があります。特定のカテゴリの顧客を特定のエージェントグループにルーティングするようにZendeskを設定したり、サービスレベル、計画、または処理に基づいて優先度を設定したりできます。

ユーザープロフィール内の情報を、実用的な情報のみに制限するのに役立ちます。CRMと同期している場合は、Zendeskでチケットの解決およびルーティング、または優先順位付けするために必要な情報のみを渡す必要があります。情報を参照するだけの場合は、CRMと統合されているチケットサイドバーアプリを利用するほうが簡単な場合があります。

Zendeskアプリ・マーケットプレイスでは、多数のビルド済みのCRMおよびeコマース統合アプリケーションからお選びいただけます。

確認事項：

• 外部のCRMからユーザーや組織の情報を同期していますか？
• または、その必要がありますか？
• Zendeskに保存する必要がある情報（エージェント、エンドユーザ、組織）は何ですか？
• ユーザーまたは組織からリクエストされたチケットにどのような情報を渡しますか？
• ユーザーのチケットをルーティングまたは優先順位付けするときに知っておくべき重要な情報は何ですか？

ユーザーフィールドへのアクセスおよび編集は、「管理」>「管理」>「ユーザーフィールド」で行ないます。

カスタムユーザーフィールドの使用について詳しくは、こちらをご覧ください。

ユーザーフィールドへのアクセスおよび編集は、「管理」>「管理」>「組織フィールド」で行ないます。

カスタム組織フィールドの使用について詳しくは、こちらをご覧ください。

パート3：チケットフィールドおよびチケットフォーム

チケットフィールド

チケットフィールドはチケットサイドバーにあり、各チケットの情報の保存、ルーティング、および優先順位付けを行うことができます。チケットフィールドは、Zendeskエクスペリエンスの重要なコンポーネントです。

作成できるチケットフィールドには、次のタイプがあります。

• ドロップダウンリスト
• 本文
• 複数行テキスト
• 数値
• 小数
• チェックボックス
• 正規表現
• 日付
• クレジットカード番号

隠れた落とし穴：

エージェントの問題理解に役立てる以外の目的での情報の使用を意図している場合、テキストフィールドの使用は難しいかもしれません。テキストフィールドは、レポーティングやビジネスルールを介したアクションの実行には適していません。複数行のテキストフィールドは、レポートにも使用できません。

カスタム日付フィールドは、期日を設定して自動化を開始するには優れた方法です。ただし、カスタム日付フィールドでビューを並べ替えることはできません。

フィールドがエンドユーザーによる入力必須とマークされている場合、そのフィールドに値を設定しない限り、ユーザーはチケットを送信できません。これは、ヘルプセンターのカスタムコードや「条件設定フィールド」アプリで非表示になっている可能性があるフィールドにも当てはまります。

ベストプラクティス：

チケットフィールドでは、エージェント用のフィールドとエンドユーザー用のフィールドに、それぞれ異なる名前を付けることができます。つまり、フィールド名をエンドユーザーへの質問として使用することができます。これは、ユーザーを戸惑わせることなく必要な情報を収集するのに役立ちます。名前の使い分けは、チケットフィールド用に内部向けの簡単な名前がある場合に、特に便利です（チケットサイドバーのスペースが限られているため）。

たとえば、ITチケットを送信するときにエンドユーザーのトラブルシューティング手順を記録したい場合は、社内向けのフィールド名には「トラブルシューティング手順」と表示し、エンドユーザー向けのチケットフォームには「どのようなトラブルシューティング手順を実行しましたか？」と表示させることができます。

可能であれば、ドロップダウンフィールドを使用するのが最良の方法です。ドロップダウンを使用すると、整然としたレポートを作成したり、簡単なビジネスルールを効果的に適用したり、エージェントやエンドユーザーの操作を簡易化したりできます。エージェントが質問に「はい」または「いいえ」で応答することを要求する場合は、ドロップダウンをチェックボックスの代わりに使用することもできます。

ネストしたドロップダウンフィールドも便利です。これにより、1つのフィールドに複数のレベルを追加することで、ユーザーエクスペリエンスを簡素化できます。

チケットフィールドを効果的に使用するためには、使用目的が以下に該当しているか確認してください。

• チケットを特定のグループまたはエージェントにルーティングする。
• トリガまたは自動化を介してチケットに対してさまざまなカスタムアクションを実行する。
• SLAポリシーを適用する。
• エージェントによる問題の特定とチケットの迅速な解決に役立てる。
• チケットをビューまたはレポート用に分類する。

確認事項：

• チケットをルーティングするには、どのような情報が必要ですか？
• チケットを解決するには、どのような情報が必要ですか？
• チケットに関するレポートを作成するには、どのような情報が必要ですか？
• どのフィールドがエンドユーザー向けであり、どのフィールドが社内専用である必要がありますか？
• エンドユーザーによるチケット送信の条件として、どのフィールドを必須入力としますか？
• エージェントによるチケット解決の条件として、どのフィールドを必須入力としますか？

チケットフィールドは、「管理」>「管理」>「チケットフィールド」で表示または編集できます。

チケットフィールドの使用について詳しくは、こちらをご覧ください。

チケットフォーム

チケットフォームはチケットサイドバーにあり、チケットフィールドを表示することができます。複数のフォームを使用して、担当者やエンドユーザーから関連情報のみを収集することができます。

すべてのZendeskアカウントはデフォルトのチケットフォームを使用します。Enterprise（および生産性向上パック付きのProfessional）アカウントには、追加のカスタムチケットフォームを作成するためのオプションがあります。

隠れた落とし穴：

エンドユーザーに表示されるチケットフィールドが多いほど、エンドユーザーによるチケット送信のハードルが高くなります。

フィールドの多いチケットフォームは（フォームの最後の方に必須入力がある場合は特に）、エージェントの生産性にも悪影響を与える可能性があります。

選択するフォームが多すぎると、エンドユーザーやエージェントにとってわかりづらくなります。

ベストプラクティス：

エンドユーザーに入力を求めるのは、チケットに関連する情報のみに限定してください。

フィールドの順序には、細心の注意を払ってください。特にレポーティング用のフィールドがある場合は、それらをフォームの一番下に配置するのが最善の方法です。エージェントにとって重要な情報をフォームの上部近くに配置すると、サイドバーを下にスクロールする必要がなくなります。

（Enterprise/生産性向上パックのみ）現在選択されているチケットフォームに関係なく、チケットはすべてのチケットフィールドに情報を保持します。つまり、システムが使用する重要なフィールド（レポート、ルーティング、ビューなど）が設定されていないか、エージェントにとって重要ではない場合は、これらのフィールド用に別の（社内向け）フォームを作成しても、そのままにしておいてかまいません。これにより、ZendeskのUIの簡潔さが維持できます。フィールド内の情報は、レポート作成およびビジネスルールで引き続き使用できます。

（Enterprise/生産性向上パックのみ）カスタムチケットフィールドと同様に、カスタムチケットフォームでも、エンドユーザー用のフォームとエージェント用のフォームに、それぞれ異なる名前を付けることができます。これにより、エンドユーザーは、送信するリクエストのタイプに合わせてフォームを選択できます。また、正式なフォーム名をバックエンドに保持することもできます。

確認事項：

• 複数のチケットフォームが必要ですか、それとも1つあれば大丈夫ですか？
• エンドユーザーに正しい情報を要求していますか？
• チケットフォームの流れは自然に感じられますか？そうでない場合、どこに違和感がありますか？
• （Enterpriseのみ）自分のフォームはエンドユーザーにとってわかりやすく命名されていますか？エージェントにとってはどうですか？

チケットフォームを表示または編集するには、「管理」>「管理」>「チケットフィールド」（Essential、Team、Professional）または「管理」>「管理」>「チケットフィールド」（Enterprise）を選択します。

カスタムチケットフォームの使用について詳しくは、こちらをご覧ください。