-
Customer Experience -
Employee Experience -
Brand Experience -
Core XM -
Design XM
Preparar seu arquivo de participantes para importação (EX)
Sobre a preparação do seu arquivo de participantes
Ao importar participantes para seu projeto de Employee Engagement, há alguns aspectos importantes a serem considerados. Por exemplo, cada importação precisará das seguintes colunas:
- Nome: o nome do empregado.
- Sobrenome: o sobrenome do colaborador.
- E-mail: o endereço de e-mail do funcionário. Este detalhe é o mais importante. O e-mail pode atuar 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 no seu arquivo de participante for deixado em branco, será gerado um e-mail artificial utilizando o formato UniqueID@BrandID.fake como caractere de preenchimento para completar as informações pessoais. Uma vez que o e-mail gerado é artificial, as distribuições EX não serão enviadas ao participante até o e-mail ser atualizado para um endereço válido.
- UniqueIdentifier: especifique os participantes por qualquer identificador que sua empresa preferir. Você pode usar desde IDs numéricos internos até nomes de usuário para repetir a coluna ID do funcionário (mas somente se for exclusivo na organização e não será compartilhado com ninguém em nenhum outro projeto).
Qdica: Confira a página de suporte Identificadores exclusivos para obter mais detalhes.
Além disso, você desejará garantir que escolheu a hierarquia correta para o projeto, pois isso afeta os metadados ou colunas personalizadas dos dados dos participantes que você incluirá no arquivo CSV/TSV. Por exemplo, o arquivo de hierarquia pai-filho deve incluir colunas para ID do funcionário e ID do gerente, enquanto o arquivo de hierarquia baseado em níveis deve ter colunas de nível diferentes. Vamos ver os metadados que você precisa incluir para cada hierarquia nesta página.
Se você esquecer de incluir os metadados corretos para começar, tudo bem! Você sempre pode atualizar os 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 pai-filho são o tipo de hierarquia mais usado. Eles são a melhor opção se seus dados de RH estiverem formatados, de modo que você tenha uma lista de IDs de empregados e os gerentes até os quais cada colaborador se reporta.
Clique aqui para acessar o arquivo de modelo de hierarquia pai-filho.
Metadados necessários
Existem duas colunas de metadados que você deve incluir para criar uma hierarquia pai-filho:
- EmployeeID: esta é a identificação do empregado do participante. É melhor usar os IDs atribuídos internamente pelo departamento de recursos humanos da sua empresa, em vez de tentar criar novos IDs gerados aleatoriamente.
- ID do gerente: esta é a identificação do funcionário do gerente do participante.
Exemplo: na imagem abaixo, o EmployeeID de John Doe é 1, então a coluna EmployeeID diz 1. Jill Davis, Sammy External e Joseph Miller se reportam diretamente a John Doe, por isso suas colunas ManagerID dizem 1.
Qdica: Tecnicamente, você pode nomear o EmployeeID e ManagerID como desejar. Por exemplo, se sua organização preferir o termo “número do funcionário” ou tiver um termo especial como “QID”, sinta-se à vontade para dar esses nomes a suas colunas. O importante é que você inclua esses conceitos e insira-os nos campos corretos quando gerar sua hierarquia Pai-Filho.
Ao adicionar IDs de empregado e de gerente, existem algumas coisas importantes a ter em mente:
- A coluna Identificador exclusivo de seus dados pode ser usada para o campo ID do funcionário ao gerar uma hierarquia pai-filho. Veja como ficaria o exemplo anterior nessa circunstância:
- Cada participante também deve ter um ID de funcionário exclusivo. Vários participantes não podem compartilhar o mesmo ID. Este pode ser o mesmo que o identificador exclusivo.
- Cada participante deve ter um gerente. A única exceção são os membros mais altos da empresa que você inclui na hierarquia (por exemplo, CEOs). Deixe a coluna do gerente em branco para mostrar que esta pessoa não se reporta a ninguém.
- As colunas ID do empregado e ID do gerente de um empregado individual nunca devem ser iguais. Os funcionários não se reportam a si mesmos!
- Cada ID de gerente deve ser vinculada de volta a um empregado. Qualquer participante com um ID de gerente que não corresponda a um ID de empregado 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 corrompidos. Para resolver esse problema, você deve fixar manualmente os dados e gerar novamente a hierarquia.
- Cuidado com a lógica circular. Se o João Silva se reporta a Jane Smith, e a Jane Smith se reporta a Joseph Miller, Joseph Miller não pode se reportar a João Silva. Você não pode gerenciar o gerente do seu gerente.
Metadados opcionais
Você pode adicionar quaisquer metadados adicionais que desejar ao carregar sua lista de participantes. Qualquer coisa desde o aniversário de cada funcionário até a localização de seu escritório pode ser incluída. No entanto, há dois metadados opcionais que podem ajudá-lo a formatar sua hierarquia pai-filho.
- ID da unidade organizacional: os IDs da unidade organizacional ajudam você a identificar a mesma equipe ao longo do tempo, mesmo que o nome da equipe mude. Ele serve a mesma finalidade que um ID de empregado único, mas para uma unidade em vez de um empregado. Incluir um ID de unidade organizacional estável significa que você não precisa mapear manualmente os dados de hierarquia; o sistema reconhecerá o ID e mapeará adequadamente.
Qdica: Tem equipes diferentes com o mesmo nome? Ou você tem conjuntos separados de relatórios de equipes e gerentes dentro da mesma divisão? Você pode reutilizar a mesma descrição de unidade organizacional definindo campos separados de ID da unidade organizacional. Por exemplo, um gerente de vendas pode executar uma equipe chamada Vendas com um ID de unidade organizacional 001, e outro gerente pode executar uma equipe chamada Vendas com um ID de unidade organizacional de 002.
Os IDs de unidade organizacional também são úteis se um gerente tiver mais de várias equipes. Isso significa que, se meu gerente for John Doe, mas John Doe for o gerente da equipe A e B, posso especificar a qual equipe eu 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 Descrição da unidade organizacional 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 dividir por unidade. As colunas não devem necessariamente conter os mesmos valores exatos, mas o ID é numérico, a descrição é descritiva. Por exemplo, a descrição da unidade organizacional do ID da organização 2 pode ser uma divisão europeia.
Exemplo: Na imagem abaixo, John Doe gerencia duas equipes diferentes: a Divisão Europeia e a Liderança de Investigação. A coluna Descrição da unidade organizacional especifica a qual dessas equipes pertencem seus 3 subordinados diretos. Vemos que Jill Davis e Joseph Miller estão na Divisão Europeia, mas Sammy External está em Leads Investigation.
Importação de participantes para uma hierarquia baseada em níveis
As hierarquias baseadas em níveis são uma boa opção se seus dados de RH incluírem cada nível ao qual o funcionário se reporta, desde o topo da hierarquia até onde ele se encontra. Com as hierarquias baseadas em níveis, você não precisa necessariamente saber quem é o gerente do empregado; você só precisa saber a cadeia de comando de cada empregado que estiver incluindo no projeto. Esse formato de dados é frequentemente mais comum com empresas que organizam dados de empregados por níveis distintos, localização ou divisão funcional.
Clique aqui para acessar o arquivo de modelo de hierarquia baseada em níveis.
Metadados necessários
Você precisará de uma coluna separada para cada nível da sua organização que deseja definir. O último nível preenchido para um participante indica sua posição na hierarquia. Para aqueles mais altos, isso geralmente significa que a primeira coluna Nível está preenchida, mas o restante não.
Metadados do gerente
Se você estiver interessado em atribuir gerentes a unidades em suas hierarquias baseadas em níveis, existem duas formas diferentes de fazer isso.
- Gerente: esta coluna indica se o participante é 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 gostaria, desde que você tenha um valor na coluna que indica que o participante é um gerente.
Exemplo: Na imagem abaixo, o nível mais baixo definido para Sammy Stanage é Nível 1, onde ele está em uma função de Sucesso do cliente. O “sim” na coluna Gerente indica que ele é gerente de todo o Customer Success. Enquanto isso, o último nível definido de Jeff Brown é a experiência do funcionário na engenharia. Isso significa que, dentro da engenharia, ele é chefe do nível de experiência do colaborador.
- Nível de gerente: o nível de gerente é um meio de identificar gerentes chamando 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 de gerente, existem valores separados para cada nível.
Exemplo: na imagem abaixo, o nível de gerente de Jeff Brown é 2 para indicar que ele é gerente de sua posição de nível 2 em Employee Experience, não gerente de sua posição de nível 1 na engenharia.
Metadados opcionais
IDs da unidade organizacional: os IDs da unidade organizacional ajudam você a identificar a mesma equipe ao longo do tempo, mesmo que o nome da equipe mude. Incluir um ID de unidade organizacional estável significa que você não precisa mapear manualmente os dados de hierarquia; o sistema reconhecerá o ID e mapeará adequadamente. Ele serve a mesma finalidade que um ID de empregado único, mas para uma unidade em vez de um empregado. Você precisa incluir tantos IDs de unidade organizacional quanto níveis, para poder fornecer um ID para cada nível.
Na captura de tela abaixo, as unidades no Nível 2 correspondem à coluna ID da unidade organizacional 2. A equipe de engenharia do Employee Experience é a unidade 201 e a equipe de engenharia do Customer Experience é 224.
Importação de participantes para uma hierarquia de esqueletos
As hierarquias do esqueleto são usadas quando você conhece a identidade de seus gerentes, mas não seus subordinados diretos. Em vez de organizar uma hierarquia em torno de uma lista de subordinados diretos e da cadeia de comando acima deles, você cria uma lista de gerentes e as unidades para as quais eles são transferidos.
Aqui está um exemplo de hierarquia Skeleton para começar. Crie um CSV/TSV e crie uma linha com cada gerente nele. Você deve ter pelo menos informações de gerente para criar uma hierarquia Skeleton.
Para cada gerente, adicione uma coluna para o Nome, Sobrenome, E-mail, do gerente 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 empregado gerencia.
- ID da unidade principal: o ID da unidade diretamente acima desta unidade. Esta é a unidade à qual o empregado se reporta.
- Descrição da organização: estes metadados são opcionais. Permite que você crie um nome para a unidade que o empregado gerencia. Pode ser o nome da equipe ou até mesmo o nome do gerente.
Exemplo: no exemplo abaixo, a TI é um departamento maior que a Engenharia está aninhada abaixo. John Doe é o gerente de TI, por isso, sua coluna de ID da unidade organizacional diz que 1 indica que o ID de unidade de TI é 1. Geoff Brown e Jill Davis são os gerentes da engenharia, por isso ambos têm um ID de organização superior de 1 para indicar que TI é a unidade controladora da engenharia.
Entrevistados x Não entrevistados
Um entrevistado é 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 entrevistados se você quiser que eles possam visualizar os resultados do dashboard ou validar hierarquias organizacionais, mas não quiser que eles preencham uma pesquisa.
Você pode determinar se o participante que está adicionando é um entrevistado ao projeto, incluindo um cabeçalho chamado Entrevistado e, em seguida, usando um dos seguintes valores:
- 0 – Não participante
- 1 – Entrevistado
Se você não incluir a coluna Entrevistado em seu arquivo, todos os seus participantes serão definidos como entrevistados 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: 100 caracteres para cada identificador exclusivo.
- Todos os outros metadados: os nomes de metadados têm um limite de 90 caracteres cada, enquanto os valores têm um limite de 1000 caracteres cada.
Caracteres não suportados
Os seguintes caracteres não podem ser usados em nenhum de seus nomes ou valores de metadados:
|
&
;
$
%
< >
(
*
+
,
`Você pode utilizar uma barra ( / ) em valores para campos como datas, mas não pode utilizá-la no nome do campo de metadados.