管理者はカスタムオブジェクトを作成して、Zendeskの標準オブジェクトに収まらないデータを取得することができます。カスタムオブジェクトでZendeskデータモデルを拡張することで、カスタムデータをチケット、トリガ、Explore分析にシームレスに統合することができます。ただし、いつ、どのようにカスタムオブジェクトを使用するのが最適かを判断するのは難しいものです。この記事では、この決定を下すために使用できる質問について解説します。
カスタムデータの目標を特定する
チケットを解決するために、エージェントは通常、Zendeskと外部のシステムを行き来して必要な情報を取得します。カスタムオブジェクトを使用すると、外部のシステムのデータをZendesk内に取り込むことができるため、システム間を行き来する必要がなくなります。エージェントの作業をこのように効率化するには、まず、エージェントが外部のシステムに求めている情報と、それを必要とするタイミングを特定する必要があります。
- エージェントがチケットに費やす時間の短縮
- カスタマー満足度の向上
- 製品のアップセル
- システムライセンスの統合によるコスト削減
- その他
- 現在、どのようなシステムにデータが格納されているか？
- 現在のプロセスのどの時点で、外部システムのデータを参照しているか？
- データを取得した後、そのデータをどのように使用しているか？
- 目標の達成を強化するために埋められるデータギャップはあるか？
- このデータをレポーティングやビジネスルールで使用したいか？（答えが何であれ、カスタムオブジェクトは選択肢になりますが、カスタムデータをレポーティングやビジネスルールで使用する予定がない場合は、サイドバーのカスタムアプリでもニーズが満たせるかもしれません。）
データを理解する
カスタムオブジェクトが適切なソリューションであると判断した場合、作成できるカスタムオブジェクトの数や定義できるルックアップリレーションシップフィールドについて、各プランの制限を理解することが重要です。また、カスタムオブジェクトを作成する前に、データモデルを検討する必要もあります。事前に計画をスケッチしておくと、長期的には時間の節約になります。
データモデルを視覚化する場合は、カスタムオブジェクトごとに簡単なスプレッドシートを作成することをお勧めします。オブジェクトとして問題なく機能しそうなデータのタイプまたはカテゴリから始めます。すべてのレコードには「名前」フィールドがあり、これはテキストベースなので、これを1番目の列のラベルにします。次に、引き続き必要な他のデータの列のラベル付けを行ないます。これらがカスタムオブジェクトのフィールドになります。たとえば、「賃貸物件」というカスタムオブジェクトの場合、スプレッドシートは以下のようになります。
| 賃貸物件 | ||||||
|---|---|---|---|---|---|---|
| 名前 | 番地 | 都道府県 | 郵便番号 | 資産管理者 | 借家人 | 賃貸開始日 |
| Royal Heights - 203 | 203 Herrick Lane | Richmond, VA | 23059 | John Doe | Christopher Garvey | January 17, 2023 |
この例を続けると、賃貸物件オブジェクトに関連して「家電製品」というカスタムオブジェクトも必要になるかもしれません。そこで、次のような2番目のスプレッドシートを作成します。
| 家電製品 | |||
|---|---|---|---|
| 家電製品ID | タイプ | 住居 | 最終メンテナンス日 |
| RF12345 | 冷蔵庫 | Royal Heights - 203 | 21 December 2022 |
作成するカスタムオブジェクトごとにスプレッドシートを作成し、データとZendeskの他のオブジェクトとの関連性を入力します。
データモデルを計画する
カスタムオブジェクトを作成する際に決定するもの
カスタムオブジェクトを作成すると、新しいスキーマを定義することになります。オブジェクトには独自の特徴があり、Zendesk内の他のオブジェクトやデータとの関係があります。そのため、オブジェクトのフィールドとリレーションシップを定義する際は、目的を持って行う必要があります。
フィールドタイプの決定
次に、使用するフィールドタイプを決定します。たとえば、Zendeskで賃貸物件オブジェクトを作成する場合、「番地」と「都道府県」はテキストフィールドかドロップダウンフィールドになるでしょう。「郵便番号」は数値フィールドで、「賃貸開始日」は日付フィールドになります。「資産管理者」と「賃借人」フィールドは、オブジェクトとユーザーの関係を定義するルックアップフィールドになります。ただし、これらのルックアップフィールドはカスタムオブジェクトに定義することも、ユーザーフィールドとして定義することもできます。詳しくは「リレーションシップの定義」を参照してください。
使用するフィールドタイプを決定する際に考慮しなければならないことは、データの検出が容易かどうかです。エージェントがZendeskでカスタムデータの検索を行なう際は、テキストベースのフィールドのみが一致するかがチェックされます。
リレーションシップの定義
ルックアップフィールドは、Zendesk内にリレーションシップを作成するためのものです。標準オブジェクトやカスタムオブジェクトのデータを連携させてデータモデルを作成する際の要となります。ルックアップフィールドが最も有用なるのは、多対一のリレーションシップを定義する場合です。たとえば、各賃貸物件には少なくとも1人の「賃借人」が存在しますが、そのリレーションシップをカスタムオブジェクトのフィールドとして定義するか、ユーザーフィールドとして定義するかを決定する必要があります。リレーションシップを賃貸物件オブジェクトのフィールドの1つとして定義した場合、各賃貸物件レコードを賃借人として指定された1人のユーザーにのみ関連付けることができます。ただし、ルックアップフィールドをユーザーに追加し、関連オブジェクトとして賃貸物件オブジェクトを指定すると、1つの物件レコードに関連付けられた複数の賃借人を定義できる可能性が広がります。通常、リレーションシップの「多」側にルックアップフィールドを定義すると、柔軟性が最も高くなります。
もう1つの例は家電製品です。各賃貸物件には、冷蔵庫、コンロ、食器洗い機など、おそらく複数の家電製品があります。したがって、ルックアップフィールドを家電製品オブジェクトのフィールドの1つとして定義することは理にかなっています。
上記の2つのケースでは、ルックアップフィールドは1つのオブジェクトに定義され、賃貸物件オブジェクトを参照しています。この場合、各賃貸物件レコードは、「リレーション」タブに賃借人と家電製品のリストを表示します。
また、オブジェクトがチケットにどのように関連し、カスタムデータの目標を達成するために使用できるかを考える必要があります。
初期データの取り込み
レコードを一括インポートすることで、外部システムからZendeskにデータを移した時点のデータを反映させることができますが、その後も同期され続けるわけではありません。外部システムのデータが保存され更新し続けると、Zendesk内のレコードは古くなります。その逆も同様で、エージェントがZendeskのレコードを更新しても、外部システムには反映されません。オブジェクトを作成して初期データをインポートした後、データ（レコード）の管理はZendeskで行なうことをお勧めします。ただし、外部システムで管理し続ける場合は、定期的な一括インポートを計画する必要があります。
カスタムオブジェクトを立ち上げて運用する簡単な方法として、カスタムオブジェクトを作成した後、一括インポートを実行して初期レコードを取り込むことができます。すでにオブジェクトのすべてのレコードをスプレッドシートにまとめ、Zendeskでオブジェクトを作成するときに定義したフィールドにマッピングしている場合は、データをカンマ区切り値（.CSV）ファイルにダウンロードまたはエクスポートできます。ほとんどの表計算ソフトウェアにはこの機能があり、また、現在データを保存している他の多くのシステムにもこのオプションがあります。詳しくは「カスタムオブジェクトレコードの一括アップロード」を参照してください。
カスタムデータモデルを活用する
カスタムオブジェクトを作成し、レコードデータを取り込んだら、次はそのデータを使用して目標を達成します。通常、これを行なうには、サポートリクエストフォームやチケットにカスタムフィールドを追加します。前のセクションで確認し作成した他のリレーションシップと同様に、ルックアップリレーションシップフィールドも使用します。チケットにカスタムオブジェクトを表示させることで、エージェントはチケットインターフェイス内で、関連するデータを設定および表示することができます。異なるシステムにコンテキストを切り替えることなく、データを最新の状態に保ち、アクセスできるようにすることで、エージェントは迅速かつ効果的にカスタマーの要望に応えることができます。