Preparação do arquivo Participante para importação (EX)

Sobre a preparação de seu arquivo de Participante

Ao importar participantes para seu projeto experiência dos colaboradores, Employee Experience, há alguns aspectos importantes a serem considerados. Por exemplo, toda importação precisará das seguintes colunas:

• Primeiro nome: O primeiro nome do colaborador.
• Sobrenome: O sobrenome do colaborador.
• E-mail: O endereço de e-mail do colaborador. Esse detalhe é o mais importante. O e-mail pode funcionar como nome de usuário para cada participante ou como uma forma de lembrar quais usuários já existem no diretório.
  Atenção: Se o campo de e-mail em seu arquivo de participante for deixado em branco, um e-mail artificial será gerado usando o formato UniqueID@BrandID.fake como um espaço reservado para completar as informações da pessoa. Como o e-mail gerado é artificial, as distribuições EX não serão enviadas ao participante até que o e-mail seja atualizado para um endereço válido. Esse comportamento não se aplicar se organização sua organização tiver SSO, pois você deve incluir endereços de e-mail ao fazer upload de participantes.
• UniqueIdentifier (Identificador único): Especifique os participantes pelo identificador que sua empresa preferir. Você pode usar qualquer coisa, desde IDs numéricos internos a nomes de usuário, até uma repetição da coluna EmployeeID (mas somente se isso for exclusivo dentro da organização e não for compartilhado com ninguém em nenhum outro projeto).
  Qdica: consulte a página de suporte dos Identificadores Únicos para obter mais detalhes.

Se estiver criando um projeto de envolvimento, certifique-se de ter escolhido a hierarquia correta para o projeto, pois isso afeta os metadados ou as colunas personalizadas de dados dos participante que serão incluídos no arquivo CSV/TSV. Por exemplo, o arquivo hierarquia Parent-Child deve incluir colunas para ID Colaborador e ID Gerente, enquanto o arquivo hierarquia Level-Based deve ter colunas de Nível diferentes. Nesta página, abordamos os metadados que você precisa incluir para cada hierarquia.

Se você esquecer de incluir os metadados corretos para começar, não tem problema! É sempre possível atualizar metadados dos participantes após o fato, seguindo as etapas na seção vinculada.

Importação de participantes para uma Hierarquia pai-filho

As hierarquias Parent-Child são o tipo de hierarquia mais comumente usado. Eles são a melhor opção se os dados de RH estiverem formatados de modo que você tenha uma lista de IDs de funcionários e os gerentes aos quais cada colaborador se relatórios.

Clique aqui para acessar o modelo de arquivo hierarquia Parent-Child.

Metadados necessários

Há duas colunas metadados que você deve incluir para criar uma hierarquia Parent-Child:

• EmployeeID: é a identificação do colaborador do participante. É melhor usar as IDs que o departamento de RH da sua empresa atribuiu internamente, em vez de tentar criar novas IDs geradas aleatoriamente.
• ManagerID: É a identificação do colaborador do gerente do participante.

Ao adicionar IDs de Colaborador e Gerente, é preciso ter em mente alguns aspectos importantes:

• A coluna Identificador exclusivo de seus dados pode ser usada para o campo ID do Colaborador ao gerar uma hierarquia pai-filho. Veja como o exemplo anterior ficaria nessa circunstância:
  
• Cada participante também deve ter um ID de Colaborador exclusivo. Vários participantes não podem compartilhar a mesma ID. Pode ser o mesmo que o identificador exclusivo.
• Todo participante deve ter um gerente. A única exceção são os membros mais altos da empresa que você inclui em sua hierarquia (por exemplo, CEOs). Deixe a coluna gerente vazia para mostrar que essa pessoa não se reporta a ninguém.
• As colunas Colaborador ID e Gerente ID de um colaborador nunca devem ser as mesmas. Os funcionários não se reportam a si mesmos!
• Cada ID de Gerente deve estar vinculada a um colaborador. Qualquer participante com uma ID de Gerente que não corresponda a uma ID de Colaborador existente será atribuído a um Gerente desconhecido. Observe que, quando alguém for atribuído a um Gerente Desconhecido, os membros da hierarquia abaixo dessa pessoa também serão quebrados. Para corrigir esse problema, você deve corrigir manualmente os dados e gerar novamente a hierarquia.
• Cuidado com a lógica circular. Se John Doe relatórios reporta a Jane Smith, e Jane Smith relatórios a Joseph Miller, Joseph Miller não pode se reportar a John Doe. Você não pode gerenciar o gerente do seu gerente.

Metadados opcionais

Você pode adicionar quaisquer metadados adicionais que desejar ao fazer o upload da lista participante. É possível incluir desde a data de aniversário de cada colaborador até a localização de seus escritórios. No entanto, há dois metadados opcionais que podem ajudá-lo a formatar hierarquia Parent-Child.

• ID da unidade organizacional: Os IDs da unidade organizacional ajudam a identificar a mesma equipe ao longo do tempo, mesmo que o nome da equipe mude. Ele tem a mesma finalidade de um ID colaborador exclusivo, mas para uma unidade em vez de um colaborador. A inclusão de um ID de unidade organizacional estável significa que você não precisa mapear manualmente os dados hierarquia; o sistema reconhecerá o ID e mapeará adequadamente.
  Qdica: Tem equipes diferentes com o mesmo nome? Ou você tem conjuntos separados de equipes e gerentes que se reportam dentro da mesma divisão? Você pode reutilizar a mesma Descrição da unidade organizacional definindo campos separados de ID da unidade organizacional. Por exemplo, um gerente de vendas pode comandar uma equipe chamada Vendas com um ID de unidade organizacional 001 e outro gerente pode comandar uma equipe chamada Vendas com um ID de unidade organizacional 002.

  As IDs de unidades organizacionais também são úteis se um gerente estiver encarregado de várias equipes. Isso significa que, se meu gerente for Fulano de Tal, mas Fulano de Tal for o gerente da Equipe A e da Equipe B, posso especificar a qual equipe pertenço com o campo ID da unidade.

• Descrição da unidade organizacional: Ao criar sua hierarquia, as unidades serão automaticamente nomeadas para um gerente. A configuração Org Unit Description permite que você nomeie suas unidades com base em nomes ou descrições das unidades.

A Descrição da unidade organizacional é essencialmente o nome fornecido para o ID da unidade organizacional fornecido e aparecerá como o rótulo da unidade nos painéis ao filtrar ou separar por unidade. As colunas não devem necessariamente conter os mesmos valores exatos, mas enquanto a ID é numérica, a Description é descritiva. Por exemplo, a descrição da unidade organizacional da ID da organização 2 pode ser Divisão Europeia.

Importação de participantes para uma Hierarquia baseada em níveis

As hierarquias baseadas em níveis são uma boa opção se os seus dados de RH incluírem cada nível ao qual o funcionário se reporta, desde o topo da hierarquia até onde o funcionário se encontra. Com hierarquias baseadas em níveis, você não precisa necessariamente saber quem é o gerente do funcionário; você só precisa saber a cadeia de comando de cada funcionário que está incluindo no projeto. Esse formato de dados costuma ser mais comum em empresas que organizam os dados dos funcionários por níveis distintos, local ou divisão funcional.

Clique aqui para acessar o modelo de arquivo de hierarquia baseado em níveis.

Metadados necessários

Você precisará de uma coluna separada para cada nível da organização que deseja definir. O último nível preenchido para um participante indica sua posição na hierarquia. Para os que estão em um nível mais alto, isso geralmente significa que a coluna do primeiro Nível está preenchida, mas as demais não.

Exemplo: Digamos que sua empresa tenha filiais em todos os Estados Unidos. Nível 1 pode incluir todos os estados em que seus escritórios estão localizados. Em seguida, Nível 2 poderia ser a cidade em que esses escritórios estão localizados. Isso significa que um participante em um escritório em Dallas, Texas, teria um Nível 1 do Texas e um Nível 2 de Dallas. Outro participante com um Nível 1 de Texas pode ter um Nível 2 de Houston.

Metadados Gerente

Se você estiver interessado em atribuir gerentes a unidades em suas hierarquias baseadas em níveis, há duas maneiras diferentes de fazer isso.

• Gerente: Essa coluna indica se o participante é um gerente. O participante será designado como o gerente do nível mais baixo que ele tem listado. A maioria dos usuários usa “sim” para indicar um gerente, mas você também pode usar “1”, “gerente” ou qualquer formato que desejar, desde que tenha um valor na coluna que indique que o participante é um gerente.
  Exemplo: Na imagem abaixo, o nível mais baixo definido para Sammy Stanage é o Nível 1, no qual ele está em uma função de Sucesso do cliente. O “sim” em sua coluna Gerente indica que ele é gerente de todo o Customer Success. Enquanto isso, o último nível definido por Jeff Brown é experiência dos colaboradores, Employee Experience na Engenharia. Isso significa que, na Engenharia, ele é o chefe do nível experiência dos colaboradores, Employee Experience.
  
• Nível Gerente: Nível Gerente é um meio de identificar os gerentes, indicando o nível específico que eles gerenciam. No exemplo anterior, o mesmo valor (“sim”) indica se um participante é ou não um gerente; no entanto, para o Nível Gerente, há valores separados para cada nível.
  Exemplo: Na imagem abaixo, o Nível Gerente de Jeff Brown é 2 para indicar que ele é gerente de sua posição Nível 2 em experiência dos colaboradores, Employee Experience, e não gerente de sua posição Nível 1 em Engineering.
  

Metadados opcionais

IDs de unidades orgânicas: Os IDs da unidade organizacional ajudam a identificar a mesma equipe ao longo do tempo, mesmo que o nome da equipe mude. A inclusão de um ID de unidade organizacional estável significa que você não precisa mapear manualmente os dados hierarquia; o sistema reconhecerá o ID e mapeará adequadamente. Ele tem a mesma finalidade de um ID exclusivo colaborador, mas para uma unidade em vez de um colaborador. Você precisa incluir tantos IDs de unidade organizacional quanto níveis, para que possa fornecer um ID para cada nível.

Exemplo: As unidades no Nível 1 correspondem à coluna Org Unit ID 1. Finanças é a unidade 101, Engenharia é 123, e assim por diante. Se carregássemos uma hierarquia avançar ano e renomeássemos Finanças para The Penny Patrol, daríamos a ela o mesmo ID, 101, para que não precisássemos mapear manualmente os dados hierarquia a fim de gerar relatórios sobre dados de engajamento de vários anos em nosso dashboard.

Na captura de tela abaixo, as unidades no Nível 2 correspondem à coluna Org Unit ID 2. A equipe de engenharia experiência dos colaboradores, Employee Experience é a unidade 201 e a equipe de engenharia experiência de cliente, Customer Experience é a 224.

Importação de participantes para uma Hierarquia de esqueleto

As hierarquias esqueletais são usadas quando você conhece a identidade dos gerentes, mas não a dos relatórios diretos deles. Em vez de organizar uma hierarquia em torno de uma lista de relatórios diretos e da cadeia de comando acima deles, você constrói uma lista de gerentes e das unidades para as quais eles se dirigem.

Aqui está um exemplo de hierarquia Skeleton para você começar. Crie um CSV/TSV e crie uma linha com cada gerente. Você deve ter pelo menos informações gerente para criar uma hierarquia de esqueleto.

Para cada gerente, adicione uma coluna para o nome, sobrenome, e-mail,e quaisquer metadados adicionais que você queira incluir. Em seguida, você deve adicionar os seguintes metadados:

• ID da unidade organizacional: A ID da unidade que o colaborador gerencia.
• ID da unidade principal: O ID da unidade diretamente acima desta unidade. Essa é a unidade à qual o colaborador relatórios.
• Descrição da organização: Esses metadados são opcionais. Ele permite que você crie um nome para a unidade que o colaborador gerencia. Pode ser o nome da equipe ou até mesmo o nome do gerente.

Respondentes vs. Não respondentes

Um respondente é um participante que pode responder à sua pesquisa. Um não respondente é um participante que não pode acessar a pesquisa. Pode ser útil tornar alguns participantes não respondentes se você quiser que eles possam visualizar os resultados dashboard ou validar hierarquias de organizações, mas não quiser que eles preencham uma pesquisa.

Você pode determinar se o participante que está adicionando é um respondente do projeto incluindo um cabeçalho chamado Respondent (Respondente) e usando um dos seguintes valores:

• 0 – Não respondente
• 1 – Respondente

Se você não incluir a coluna Respondente em seu arquivo, todos os participantes serão definidos como respondentes por padrão.

Caracteres máximos e suportados

Máximo de caracteres para cada campo

• Primeiro nome: 50 caracteres para cada primeiro nome.
• Sobrenome: 50 caracteres para cada sobrenome.
• E-mail: 100 caracteres para cada e-mail.
• UniqueIdentifier (Identificador exclusivo): 100 caracteres para cada identificador exclusivo.
• Todos os outros metadados: Os nomes Metadados têm um limite de 90 caracteres cada, enquanto os valores têm um limite de 1.000 caracteres cada.

Caracteres não suportados

Os caracteres a seguir não podem ser usados em nenhum dos nomes ou valores metadados:

|
&
;
$
%
< >
( )
{ }
*
+
,
`

Você pode usar uma barra ( / ) em valores de campos como datas, mas não pode usá-la no nome do campo metadados.

Perguntas frequentes