-
Qualtrics Platform -
Customer Journey Optimizer -
XM Discover -
Qualtrics Social Connect
インポート（EX）する参加者ファイルの準備
参加者ファイルの作成について
従業員エクスペリエンス プロジェクトに参加者をインポートする際には、いくつかの重要な点に留意する必要があります。例えば、すべてのインポートには以下の列が必要である：
- ファーストネーム：従業員のファーストネーム。
- 姓：従業員の姓。
- 電子メール従業員のEメールアドレス。このディテールが最も重要だ。電子メールは、参加者ごとのユーザー名として、またはディレクトリにすでに存在するユーザーを記憶する方法として機能します。
注意参加者ファイルのEメールフィールドが空白のままになっている場合、UniqueID@BrandID.fake という書式をプレースホルダとして使用した人工Eメールが生成され、個人情報が補完されます。生成されたEメールは人工的なものであるため、Eメールが有効なアドレスに更新されるまで、参加者にEX配信は行われません。参加者をアップロードする際にメールアドレスを含める必要があるため、組織にSSOがある場合はこの動作は適用されません。
- UniqueIdentifier：参加者を任意の識別子で指定します。社内の数値IDからユーザー名、EmployeeIDカラムの繰り返しまで、何でも使用できます（ただし、組織内で一意であり、他のプロジェクトの誰とも共有されない場合に限ります）。
Qtip:詳細はUnique Identifiersのサポートページをご覧ください。
Engagementプロジェクトを作成する場合、CSV/TSVファイルに含めるメタデータ（参加者データのカスタム列）に影響するため、プロジェクトに適切な階層を選択していることを確認する必要があります。例えば、親子階層ファイルには従業員IDとマネージャーIDのカラムを含める必要がありますが、レベルベース階層ファイルには異なるレベルのカラムを含める必要があります。このページでは、各階層に含めるべきメタデータについて説明する。
そもそも正しいメタデータを入れ忘れたとしても、それはそれで構わない！リンク先のセクションの手順に従って、参加者のメタデータを後からいつでも更新することができます。
親子階層の参加者のインポート
親-子階層は最もよく使われる階層である。従業員のIDと各従業員がレポートするマネージャーのリストがあるように、人事データがフォーマットされている場合は、これらのオプションが最適です。
ここをクリックして、親子階層のテンプレートにアクセスします。
必要なメタデータ
親子階層を作成するには、2つのメタデータカラムを含める必要があります：
- 従業員ID：参加者の従業員IDです。新しくランダム化されたIDを作ろうとするのではなく、会社の人事部が社内で割り当てたIDを使うのがベストです。
- マネージャーID：これは参加者のマネージャーの従業員IDです。
例 以下の画像では、John DoeのEmployeeIDは1であるため、彼のEmployeeIDカラムは1となります。Jill Davis、Sammy External、およびJoseph MillerはJohn Doeの直属の部下であるため、ManagerID列には1が表示されます。
Qtip: 技術的には、EmployeeIDとManagerIDに好きな名前を付けることができます。例えば、あなたの組織が「従業員番号」という言葉を好んだり、「QID」のような特別な言葉を使ったりする場合は、自由にこれらの名前を列につけてください。重要なのは、親子階層を作成する際に、これらの概念を含め、正しいフィールドに入力することです。
従業員IDやマネージャーIDを追加する際には、いくつか注意すべき点があります：
- データの一意識別子列は、親子階層を生成する際に従業員IDフィールドに使用できます。その場合、先の例はどうなるかというと、こうなる：
- また、参加者は全員、固有の従業員IDを持っていなければならない。複数の参加者が同じIDを共有することはできません。これは固有識別子と同じにすることができる。
- 参加者には必ずマネージャーが必要だ。唯一の例外は、階層に含める企業の最上位メンバー（CEOなど）である。マネージャー欄は空欄にし、この人物が誰にもレポートされていないことを示す。
- 個々の従業員の従業員IDとマネージャーIDの列は決して同じであってはならない。従業員は自分自身に報告しない！
- すべてのマネージャーIDは従業員にリンクしていなければなりません。既存の従業員IDに対応しないマネージャーIDを持つ参加者は、不明マネージャーに割り当てられます。不明マネージャーに誰かが割り当てられると、その下の階層のメンバーも壊れることに注意してください。この問題を解決するには、手動でデータを修正し、階層を再生成する必要がある。
- 循環論理に気をつけよう。ジョン・ドウがジェーン・スミスにレポートし、ジェーン・スミスがジョセフ・ミラーにレポートする場合、ジョセフ・ミラーがジョン・ドウにレポートすることはできない。マネージャーのマネージャーを管理することはできない。
オプションのメタデータ
参加者リストをアップロードする際に、ご希望のメタデータを追加することができます。各従業員の誕生日からオフィスの所在地まで、何でも記載することができる。しかし、親子階層をフォーマットするのに役立つオプションのメタデータが2つあります。
- 組織ユニットID：組織ユニットIDは、チーム名が変わっても、同じチームを識別するのに役立ちます。ITは、従業員ではなくユニットに対して一意の従業員IDと同じ目的を果たす。安定した組織階層の特定ユニットIDを含めることは、階層データを手作業でマッピングする必要がないことを意味します; システムはIDを認識し、適切にマッピングします。
Qtip:同じ名前の異なるチームがありますか？それとも、同じ部署内でチームとマネージャーを別々にレポートさせているのでしょうか？組織単位IDフィールドを別々に設定することで、同じ組織単位説明を再利用することができます。例えば、あるマネージャーは組織ユニットIDが001のSalesというチームを運営し、別のマネージャーは組織ユニットIDが002のSalesというチームを運営することができる。
マネージャーが複数のチームを統括している場合にも、Org Unit IDは役に立つ。つまり、私のマネージャーがJohn Doeで、John DoeがチームAとチームBのマネージャーである場合、私はユニットIDフィールドでどちらのチームに帰属するかを指定できる。
- 組織単位の説明：階層を作成する際、ユニットにはマネージャーの名前が自動的に付けられます。Org Unit Descriptionの設定では、代わりにユニットの名前や説明に基づいてユニット名を付けることができます。
Org Unit Descriptionは、基本的に提供されたOrg Unit IDに対して提供された名前であり、ダッシュボードでユニット別にフィルターまたはブレイクアウトする際にユニットのラベルとして表示されます。IDが数値であるのに対し、Descriptionは説明的なものである。例えば、組織ID2の組織単位の説明は欧州部署である。
例下の画像では、ジョン・ドウがヨーロッパ部署とリード調査部という2つの異なるチームをマネージャーしている。Org Unit Descriptionの欄には、直属の部下3人がどのチームに帰属しているかが明記されている。ジル・デイビスとジョセフ・ミラーはヨーロッパ部署にいるが、サミー・エクスターナルはリード捜査部にいる。
階層ベースの参加者のインポート
階層ベースの階層は、従業員がレポートする各レベル（階層の最上位から最下位まで）が人事データに含まれている場合に適しています。レベルベースの階層では、必ずしも従業員のマネージャーを知る必要はなく、プロジェクトに参加させる各従業員の指揮命令系統を知るだけでよい。このデータ形式は、従業員データをレベル別、勤務地別、詳細区分別に整理している企業でよく見られます。
ここをクリックして、レベルに基づく階層のテンプレートにアクセスします。
必要なメタデータ
定義したい組織のレベルごとに別の列が必要です。参加者の最後に記入されたレベルは、階層におけるその人の位置を示す。上位の選手にとって、これは通常、最初のレベル欄は埋まっているが、残りは埋まっていないことを意味する。
マネージャー メタデータ
レベル階層内のユニットにマネージャーを割り当てるには、2つの方法があります。
- マネージャー：この欄は、参加者がマネージャーであるかどうかを示す。参加者は、自分が一覧表示した最下位レベルのマネージャーとして割り当てられます。ほとんどのユーザーは、マネージャーであることを示すために「はい」を使用しますが、参加者がマネージャーであることを示す列の値が1つであれば、「1」、「マネージャー」、または任意の形式を使用することもできます。
例下の画像では、Sammy Stanageの最低レベルはレベル1で、カスタマーサクセスの役割に就いています。マネージャー欄の「はい」は、カスタマーサクセス全体のマネージャーであることを示している。一方、ジェフ・ブラウンが最後に定義したレベルは、エンジニアリング部門の従業員エクスペリエンスである。つまり、エンジニアリングの中では従業員エクスペリエンスレベルの責任者ということになる。
- マネージャーレベル：マネージャーレベルとは、マネージャーを識別するための手段であり、そのマネージャーが管理する特定のレベルを示すものである。前の例では、同じ値(“yes”)は参加者がマネージャーであるかどうかを示しますが、マネージャーレベルでは、レベルごとに別々の値があります。
例下の画像では、ジェフ・ブラウンのマネージャーレベルが「2」になっています。これは、ジェフが「エンジニアリング」のレベル1のポジションのマネージャーではなく、「従業員エクスペリエンス」のレベル2のポジションのマネージャーであることを示しています。
オプションのメタデータ
組織ユニットID：組織ユニットIDは、チーム名が変わっても、同じチームを識別するのに役立ちます。安定した組織階層の特定ユニットIDを含めることは、階層データを手作業でマッピングする必要がないことを意味します; システムはIDを認識し、適切にマッピングします。ITは、従業員ではなくユニットに対して一意の従業員IDと同じ目的を果たす。レベルと同数の組織単位IDを含める必要があるため、各レベルにIDを提供できます。
以下のスクリーンショットでは、レベル 2 のユニットが Org Unit ID 2 列に対応しています。従業員エクスペリエンス・エンジニアリングチームはユニット201で、カスタマーエクスペリエンス・エンジニアリングチームは224です。
スケルトン階層の参加者のインポート
スケルトン階層は、マネージャーの身元はわかっているが、直属の部下がわからない場合に使用する。直属の部下とその上の指揮命令系統のリストを中心に階層を組織するのではなく、マネージャーと彼らがロールアップするユニットのリストを構築するのだ。スケルトン階層の例を
以下に示す。CSV/TSVを作成し、各マネージャーの行を作成する。スケルトン階層を構築するには、少なくともマネージャー情報が必要だ。
マネージャーごとに、マネージャーのファーストネーム、 ラストネーム、 Eメール、、その他入れたいメタデータの列を追加する。次に、以下のメタデータを追加する必要がある：
- 組織ユニットID： 従業員がマネージャーを務めるユニットのID。
- 親ユニットのID：このユニットの直上のユニットのID。従業員がレポートする部署です。
- 組織の説明：このメタデータはオプションである。従業員が管理するユニットの名前を作成することができます。これはチーム名でもいいし、マネージャーの名前でもいい。
例以下の例では、IT部門はより大きな部門であり、エンジニアリング部門はその下にネストされている。John DoeはITのマネージャーなので、彼のOrg Unit ID欄にはITのユニットIDが1であることを示す1が書かれている。 Geoff BrownとJill Davisはエンジニアリングのマネージャーなので、彼ら2人のParent Org IDはITがエンジニアリングの親ユニットであることを示す1である。
回答者vs. 未回答者
回答者とは、アンケートに答えてくれる参加者のことです。無回答者とは、アンケートにアクセスできない参加者のことです。ダッシュボードの結果や組織階層の確認はさせたいが、アンケートに回答してほしくない参加者を無回答者にすると便利です。
追加する参加者がプロジェクトの回答者であるかどうかは、Respondentというヘッダーを含め、次の値のいずれかを使用することで判断できます：
- 0 – 無回答
- 1 – 回答者
ファイルにRespondent列を含めない場合、参加者全員がデフォルトで回答者として設定されます。
最大文字数とサポート文字数
各フィールドの最大文字数
- ファーストネーム50文字
- 名字：各姓50文字。
- Eメール：各メールに100文字
- 一意識別子：一意識別子ごとに100文字。
- その他すべてのメタデータ：メタデータ名は90文字まで、値は1000文字まで。
サポートされていない文字
以下の文字は、メタデータの名前や値に使用できません：
|
&
;
$
%
< >
( )
{ }
*
+
,
`.日付などのフィールドの値にはスラッシュ（/）を使用できますが、メタデータフィールド名には使用できません。