Skip to main content
Loading...
Skip to article
  • Qualtrics Platform
    Qualtrics Platform
  • Customer Journey Optimizer
    Customer Journey Optimizer
  • XM Discover
    XM Discover
  • Qualtrics Social Connect
    Qualtrics Social Connect

階層を作成するためのユーザーファイルの準備(CX)


Was this helpful?


This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

The feedback you submit here is used only to help improve this page.

That’s great! Thank you for your feedback!

Thank you for your feedback!


ヒント:CX階層は、チケットを含むCXライセンスでのみ使用できます。この機能に関心がある場合は、営業担当にお問い合わせください。
ヒント:CX階層とEX階層は非常に似ていますが、いくつかの重要な違いがあります。EXクライアントの場合は、「参加者ファイルのインポート準備(EE)」を参照してください。

階層を作成するためのユーザファイルの準備について

CXダッシュボードにユーザーをインポートする際は、いくつかの重要な点に留意してください。たとえば、すべてのインポートに以下の列が必要です。

  • 名: ユーザの名。
  • 姓: ユーザーの姓。
  • 電子メール: ユーザーの電子メールアドレス。この詳細が最も重要です。電子メールは、各ユーザーのユーザー名として、またはユーザー管理にすでに存在するユーザーを記憶する方法として機能します。
  • ユーザー名:組織で SSO が使用されている場合は、[ユーザー名]列を含める必要があります。#brandId は自動的に末尾に追加されるため、この列には電子メール列と同じ情報が含まれている必要があります。
  • 言語: この列は技術的にはオプションです。ただし、これを含める場合は、ここに表示されているように言語を大文字化し、各ユーザの値を言語コードで入力するよう注意する必要があります。

また、CSV/TSVファイルに含めるユーザー属性またはユーザーデータのカスタム列に影響するため、プロジェクトに適した階層を選択したことを確認する必要があります。たとえば、親 – 子階層ファイルには社員 ID とマネージャー ID の列を含める必要がありますが、レベルベースの階層ファイルには異なる Level 列を含める必要があります。

ヒント:ファイルをアップロードする準備ができたが、方法がわからない場合は、このページの手順に従って階層ファイルを設定したら、ユーザーの追加サポートページに進みます。
ヒント:最初に正しいメタデータを含め忘れた場合は問題ありません。リンクの手順に従って、ファクトの後にユーザーの属性をいつでも更新できます。

親子階層のファイルの準備

親子階層は、最も一般的に使用される種類の階層です。これらは、HR データが書式設定されているために従業員 ID の一覧および各従業員が報告するマネージャがある場合に最適なオプションです。

ファイルの構築が完了し、階層を作成する準備ができたら、「親子階層の生成」を参照してください。

必要なメタデータ

親子階層を作成するには、次の 2 つのメタデータ列を含める必要があります。

  • EmployeeID: 参加者の従業員 ID です。ランダムに生成された新しい ID を作成するのではなく、会社の人事部門が内部的に割り当てた ID を使用することをお奨めします。
  • ManagerID: 参加者のマネージャーの従業員 ID です。

例: 下の画像では、John Doe の EmployeeID は 1 であるため、EmployeeID カラムは 1 になっています。Jill Davis、Sammy External、Joseph Miller は John Doe に直接レポートするため、ManagerID カラムには 1 と表示されます。

CSV。John Doe の EmployeeID EmployeeID カラムには 1 と表示される。Jill Davis、Sammy External、Joseph Miller ManagerID の各カラムも 1 と表示しています。

ヒント:技術的には、任意にEmployeeIDとManagerIDに名前を付けることができます。たとえば、組織で “従業員番号” という用語が優先される場合、または “QID” のような特別な用語がある場合は、列にこれらの名前を自由に指定してください。重要なのは、親子階層を生成するときに、これらのコンセプトを含めて正しいフィールドに入力することです。

社員とマネージャーの ID を追加する際には、いくつかの重要な点に留意してください。

  • すべての参加者には、一意の従業員 ID も必要です。複数の参加者が同じ ID を共有することはできません。
  • すべての参加者にマネージャーが必要です。唯一の例外は、階層に含める会社の最上位メンバー(CEO など)です。この個人が誰の部下にも報告しないことを示すには、manager 列を空白のままにします。
  • 個々の社員の [従業員 ID] 列と [マネージャー ID] 列は同じにできません。従業員は自分自身に報告しません。
  • すべてのマネージャー ID は、社員にリンクし直す必要があります。既存の従業員 ID に対応していないマネージャー ID を持つ参加者は、不明なマネージャーに割り当てられます。不明なマネージャーにユーザーが割り当てられると、そのユーザーの下にある階層のメンバーも破損することに注意してください。この問題を解決するには、データをマニュアルで修正し、階層を再生成する必要があります。
  • 循環ロジックに注意してください。John Doe が Jane Smith に報告し、Jane Smith が Joseph Miller にレポートした場合、Joseph Miller は John Doe に報告できません。あなたのマネージャーのマネージャーを管理することはできません。

オプションのメタデータ

参加者リストのアップロード時に、任意のメタデータを追加することができます。各社員の誕生日から所属事務所の場所まで何でも含めることができる。ただし、親子階層の書式設定に役立つ 2 つのオプションのメタデータがあります。

  • 組織ユニット ID: 組織ユニット ID は、チーム名が変更された場合でも、時間の経過とともに同じチームを識別するのに役立ちます。これは、一意の従業員 ID と同じ目的で使用されますが、従業員ではなくユニットに対して使用されます。
    ヒント:同じ名前の別のチームがありますか?または、同じ部署内に別々のチームとマネージャーのレポートが存在しますか。個別の組織ユニット ID 項目を設定することで、同じ組織ユニットテキストを再利用することができます。たとえば、ある営業マネージャは組織ユニット ID 001 で販売というチームを実行し、別の販売マネージャは組織ユニット ID 002 で販売というチームを実行することができます。

    組織ユニット ID は、マネージャが複数のチームに属する場合にも役立ちます。つまり、マネージャが John Doe で、John Doe がチーム A およびチーム B のマネージャである場合は、ユニット ID 項目で自分が属するチームを指定することができます。

  • 組織ユニットの説明: 階層の作成時に、ユニット名が自動的にマネージャに付けられます。組織ユニットの説明設定では、代わりにユニットの名前または説明に基づいてユニットに名前を付けることができます。

組織ユニットの説明は、基本的に、指定した組織ユニット ID に対して指定された名前であり、ユニット別にフィルタリングまたは展開すると、ダッシュボードのユニットのラベルとして表示されます。カラムには必ずしも同じ正確な値が含まれている必要はありませんが、ID は数値ですが、Description は記述です。たとえば、組織 ID 2 の組織ユニットの説明はヨーロッパの部署である可能性があります。

例:下の画像では、John Doe は 2 つの異なるチーム(欧州部門と先導調査)を管理しています。組織ユニット説明列には、これらのチームのうち、3 人の直属の部下が属するチームが指定されます。Jill Davis と Joseph Miller は European Division に所属していますが、Sammy External は Lead Investigation にあります。

John Doe の直属の部下が、同じマネージャーの異なるチームに所属していることを示すために、組織ユニットの説明にさまざまな内容が書き込まれる CSV

ヒント:技術的には、[組織ユニット IDフィールド]と[組織ユニットの説明]に任意の名前を付けることができます。たとえば、組織ユニットの説明の代わりに、Unit NameTeam、または Department 列の名前を付けることができます。重要なのは、これらのコンセプトを含め、親 – 子階層を生成するときに正しい項目に入力することです。

レベルベース階層のファイルの準備

レベルベース階層は、HR データに、階層の上から下まで、従業員が管理する各レベルが含まれている場合に適しています。レベルベース階層では、必ずしも社員のマネージャーを把握する必要はありません。プロジェクトに含める各社員の指揮系統を把握するだけで済みます。このデータ形式は、さまざまなレベル、場所、または職務上の詳細区分に基づいて従業員データを編成する会社によく見られます。

例:階層では、各参加者がダッシュボードで表示できるデータを管理することができます。たとえば、さまざまな場所に店舗があり、会社の賞を競い、参加者が自分のエンゲージメントダッシュボードを表示できるようにしますが、お互いのエンゲージメントダッシュボードを表示できないようにするとします。場所に基づいて階層を構築すると、後でダッシュボードの役割を構築したり、ダッシュボードのユーザー権限を設定したりするときに、各参加者に表示される場所のデータを制限することができます。

ファイルの構築が完了し、レベルベース階層を作成する準備ができたら、「レベルベース階層の生成」を参照してください。

必要なメタデータ

定義する組織のレベルごとに個別の列が必要です。参加者に対して最後に入力されたレベルは、階層における参加者の位置を示します。上位の場合は、通常、第 1 レベル列が入力されますが、残りの列は入力されません。

例: 会社に、米国全体の所在地があるとします。レベル 1 には、事業所があるすべての州が含まれる場合があります。レベル 2 は、これらの事業所がある市区町村です。つまり、テキサス州ダラスのオフィスでは、レベル1がテキサス、レベル2がダラスである。テキサス州のレベル1の別の参加者には、ヒューストンのレベル2があるかもしれない。

レベル 1 がテキサスである参加者を含む CSV。ダラスにレベル2、ヒューストンにレベル2があるものもある。

マネージャーメタデータ

レベルベース階層でマネージャを単位に割り当てる場合は、2 つの異なる方法があります。

  • マネージャ: この列は、参加者がマネージャであるかどうかを示します。参加者は、自分が一覧表示した最下位レベルのマネージャーとして割り当てられます。ほとんどのユーザーは、マネージャーを示すために “yes” を使用しますが、参加者がマネージャーであることを示す列の値が 1 つであれば、”1″、”manager”、または任意の形式を使用することもできます。
    例:以下の図では、Sammy Stanage に対して定義された最下位レベルは、カスタマーサクセスの役割を担っているレベル 1 です。マネージャー列の「はい」は、カスタマーサクセスのマネージャーであることを示しています。一方、Jeff Brown の最後のレベルはエンジニアリング内の従業員エクスペリエンスです。つまり、エンジニアリング部門では、従業員エクスペリエンスレベルの責任者です。
    Jeff Brown のレベル 1 と 2 が入力されているのに対し、Sammy External のレベル 2 は空白の CSV です。
  • マネージャーレベル:マネージャーレベルは、管理している特定のレベルを呼び出すことでマネージャーを特定する手段です。前の例では、同じ値 (“yes”) は参加者がマネージャーであるかどうかを示していますが、Manager Level の場合は、レベルごとに異なる値があります。
    :下の画像では、ジェフ・ブラウンの「マネージャーレベル」は、エンジニアリングにおけるレベル 1 のマネージャーではなく、従業員エクスペリエンスにおけるレベル 2 のポジションのマネージャーであることを示す 2 です。
    Jeff Brown のレベル 2 に値があり、マネージャーのレベルが 2 に設定された CSV

オプションのメタデータ

組織ユニット ID: 組織ユニット ID は、チーム名が変更された場合でも、時間の経過とともに同じチームを識別するのに役立ちます。これは、一意の従業員 ID と同じ目的で使用されますが、従業員ではなくユニットに対して使用されます。レベルごとに ID を指定できるように、実行するレベルと同じ数の組織ユニット ID を含める必要があります。

例: レベル 1 のユニットは、列組織ユニット ID 1 に対応します。財務はユニット 101、エンジニアリングは 123 などです。来年に階層をアップロードし、財務を The Penny Patrol に名称変更した場合、同じ ID 101 を割り当てます。

レベル 1 と組織ユニット ID 1 が強調表示されます。

以下のスクリーンショットでは、レベル 2 のユニットは組織ユニット ID 2 の列に対応しています。Employee Experience エンジニアリングチームはユニット 201 で、Customer Experience エンジニアリングチームは 224 です。

レベル 2 列と組織ユニット ID 2 列が強調表示されます。

ヒント:技術的には、これらのメタデータ列を任意の名前で指定できます。たとえば、階層を場所に基づく場合、レベル 1、レベル 2、およびレベル 3 ではなく、国、都道府県、および市区町村という名前の列を含めることができます。重要なのは、これらのコンセプトを含め、レベルベース階層を生成する際に正しいフィールドに入力することです。

FAQ

当サポートサイトの日本語のコンテンツは英語原文より機械翻訳されており、補助的な参照を目的としています。機械翻訳の精度は十分な注意を払っていますが、もし、英語・日本語翻訳が異なる場合は英語版が正となります。英語原文と機械翻訳の間に矛盾があっても、法的拘束力はありません。