-
Qualtrics Platform -
Customer Journey Optimizer -
XM Discover -
Qualtrics Social Connect
Preparación de su archivo de participantes para la importación (EX)
Acerca de la preparación de su archivo de participante
Al importar participantes a su proyecto de Employee Experience, hay algunas cosas importantes que debe tener en cuenta. Por ejemplo, cada importación necesitará las siguientes columnas:
- Nombre: El nombre del empleado.
- Apellidos: El apellido del empleado.
- Correo electrónico: La dirección de correo electrónico del empleado. Este detalle es el más importante. El correo electrónico puede actuar como nombre de usuario para cada participante o como una forma de recordar qué usuarios ya existen en el directorio.
Atención: Si el campo de correo electrónico de su archivo de participante se deja en blanco, se generará un correo electrónico artificial utilizando el formato, UniqueID@BrandID.fake, como marcador de posición para completar la información de la persona. Dado que el correo electrónico generado es artificial, las distribuciones EX no se enviarán al participante hasta que el correo electrónico se actualice a una dirección válida. This behavior does not apply if your organization has SSO since you must include email addresses when uploading participants.
- UniqueIdentifier: Especifique los participantes por el identificador que prefiera su empresa. Puede utilizar cualquier cosa, desde los ID numéricos internos hasta los nombres de usuario, hasta la repetición de la columna ID de empleado (pero solo si es unívoco dentro de la organización y no se compartirá con nadie en ningún otro proyecto).
Consejo Q: Consulte la página de soporte técnico Identificadores únicos para obtener más detalles.
Si está creando un proyecto de compromiso, deberá asegurarse de que ha elegido la jerarquía correcta para su proyecto, ya que esto afecta a los metadatos o a las columnas personalizadas de los datos de los participantes que incluirá en su archivo CSV/TSV. Por ejemplo, el archivo de jerarquía superior-inferior debe incluir columnas para el ID de empleado y el ID de gestor, mientras que el archivo de jerarquía basado en niveles debe tener diferentes columnas de Nivel. Repasamos los metadatos que debe incluir para cada jerarquía en esta página.
Si olvida incluir los metadatos correctos para empezar, es correcto. Siempre puede actualizar los metadatos de los participantes después del hecho si sigue los pasos en la sección del enlace.
Importación de participantes para una jerarquía superior-inferior
Las jerarquías superior-inferior son el tipo de jerarquía más utilizado. Son la mejor opción si sus datos de RR. HH. están formateados para que tenga una lista de ID de empleados y los gerentes a los que informa cada empleado.
Haga clic aquí para acceder a la plantilla de archivo de jerarquía superior-inferior.
Metadatos necesarios
Existen dos columnas de metadatos que debe incluir para crear una jerarquía superior-inferior:
- EmployeeID: es la identificación del empleado del participante. Es mejor utilizar los ID que el departamento de RR. HH. de su empresa ha asignado internamente, en lugar de intentar crear nuevos ID generados aleatoriamente.
- ManagerID: Es la identificación del empleado del gerente del participante.
Ejemplo: en la imagen siguiente, el ID de empleado de John Doe es 1, por lo que la columna ID de empleado dice 1. Jill Davis, Sammy External y Joseph Miller informan directamente a John Doe, por lo que sus columnas de ManagerID dicen 1.
Consejo Q: Técnicamente, puede nombrar el EmployeeID y el ManagerID lo que desee. Por ejemplo, si su organización prefiere el término “número de empleado” o tiene un término especial como “QID”, no dude en dar a sus columnas estos nombres. Lo importante es que incluya estos conceptos e introdúzcalos en los campos correctos cuando genere su jerarquía superior-inferior.
Al añadir ID de empleado y de supervisor, hay algunas cosas importantes que se deben tener en cuenta:
- La columna Identificador único de sus datos se puede utilizar para el campo ID de empleado al generar una jerarquía superior-inferior. Así es como se vería el ejemplo anterior en esa circunstancia:
- Cada participante también debe tener un ID de empleado único. Varios participantes no pueden compartir el mismo ID. Puede ser el mismo que el identificador único.
- Cada participante debe tener un gerente. La única excepción son los miembros más altos de la empresa que incluye en su jerarquía (por ejemplo, CEO). Deje vacía la columna de supervisor para mostrar a esta persona que no está a cargo de nadie.
- Las columnas ID de empleado e ID de gerente de un empleado individual nunca deben ser iguales. Los empleados no se reportan a sí mismos.
- Cada ID de gerente debe vincularse a un empleado. Cualquier participante con un ID de gerente que no se corresponda con un ID de empleado existente se asignará a un gerente desconocido. Tenga en cuenta que una vez que se asigna una persona a un gestor desconocido, los miembros de la jerarquía por debajo de esta persona también se romperán. Para solucionar este problema, debe fijar manualmente los datos y volver a generar la jerarquía.
- Preste atención a la lógica circular. Si John Doe informa a Jane Smith y Jane Smith informa a Joseph Miller, éste no puede rendir cuentas a John Doe. No puede administrar el gerente de su gerente.
Metadatos opcionales
Puede agregar cualquier metadato adicional que desee al cargar su lista de participantes. Se puede incluir cualquier cosa, desde el cumpleaños de cada empleado hasta sus ubicaciones de oficina. Sin embargo, hay dos metadatos opcionales que pueden ayudarle a formatear la jerarquía superior-inferior.
- ID de unidad organizativa: los ID de unidad organizativa le ayudan a identificar el mismo equipo a lo largo del tiempo, incluso si cambia el nombre del equipo. Sirve para el mismo propósito que un ID de empleado único, pero para una unidad en lugar de un empleado. Incluir un ID de unidad organizativa estable significa que no tiene que asignar manualmente los datos de jerarquía; el sistema reconocerá el ID y lo asignará adecuadamente.
Consejo Q: ¿Tiene equipos diferentes con el mismo nombre? ¿O tiene conjuntos separados de equipos y gerentes que informan dentro de la misma división? Puede reutilizar la misma Descripción de unidad organizativa fijando campos de ID de unidad organizativa separados. Por ejemplo, un jefe de ventas puede ejecutar un equipo llamado Ventas con un ID de unidad organizativa de 001, y otro jefe puede ejecutar un equipo llamado Ventas con un ID de unidad organizativa de 002.
Los ID de unidad organizativa también son útiles si un gerente está en varios equipos. Esto significa que si mi gerente es John Doe, pero John Doe es el gerente del equipo A y el equipo B, puedo especificar a qué equipo pertenezco con el campo ID de unidad.
- Descripción de unidad organizativa: al crear la jerarquía, las unidades se nombrarán automáticamente para un gerente. La opción Descripción de unidad organizativa le permite nombrar las unidades en función de los nombres o descripciones de las unidades.
La Descripción de unidad organizativa es esencialmente el nombre proporcionado para el ID de unidad organizativa proporcionado y aparecerá como la etiqueta de la unidad en los dashboards al filtrar o desglosar por unidad. Las columnas no deben contener necesariamente los mismos valores exactos, pero si el ID es numérico, la descripción es descriptiva. Por ejemplo, la descripción de la unidad organizativa del ID de organización 2 puede ser una división europea.
Ejemplo: En la imagen de abajo, John Doe gestiona dos equipos diferentes: la División Europea y Dirige la Investigación. La columna Descripción de unidad organizativa especifica a cuál de estos equipos pertenecen sus 3 subordinados directos. Vemos que Jill Davis y Joseph Miller están en la División Europea, pero Sammy External está en Leads Investigation.
Importación de participantes para una jerarquía basada en niveles
Las jerarquías basadas en niveles son una buena opción si sus datos de HR incluyen cada nivel al que informa el empleado, desde la parte superior de la jerarquía hasta el lugar en el que se encuentra el empleado. Con las jerarquías basadas en niveles, no necesariamente tiene que saber quién es el gerente del empleado; solo necesita conocer la cadena de comandos de cada empleado que está incluyendo en el proyecto. Este formato de datos suele ser más común con las empresas que organizan los datos de los empleados por distintos niveles, ubicación o desglose funcional.
Haga clic aquí para acceder a la plantilla de archivo de jerarquía basada en nivel.
Metadatos necesarios
Necesitará una columna separada para cada nivel de su organización que desee definir. El último nivel rellenado para un participante indica su lugar en la jerarquía. Para los más altos, esto normalmente significa que la primera columna Nivel está rellenada, pero el resto no.
Metadatos de gestor
Si está interesado en asignar gestores a unidades de sus jerarquías basadas en niveles, existen dos formas diferentes de hacerlo.
- Gerente: Esta columna indica si el participante es un gerente. El participante será entonces asignado como el mánager de menor nivel incluido en la lista. La mayoría de los usuarios utilizan “sí” para indicar un gerente, pero también puede utilizar “1,” “gerente” o cualquier formato que desee, siempre que tenga un valor en la columna que indique que el participante es un gerente.
Ejemplo: En la imagen siguiente, el nivel más bajo definido para Sammy Stanage es el Nivel 1, donde está en un rol de Customer Success. El “sí” en su columna Gerente indica que es el gerente de todo Customer Success. Mientras tanto, el último nivel definido de Jeff Brown es Employee Experience dentro de Engineering. Esto significa que, dentro de Ingeniería, es el jefe del nivel de Experiencia del empleado.
- Nivel de gerente: El nivel de gerente es un medio para identificar gerentes llamando al nivel específico que gestionan. En el ejemplo anterior, el mismo valor (“sí”) indica si un participante es un gerente o no; sin embargo, para el nivel de gerente, hay valores separados para cada nivel.
Ejemplo: En la siguiente imagen, el Nivel de Gerente de Jeff Brown es 2 para indicar que es gerente de su puesto de Nivel 2 en Employee Experience, no gerente de su puesto de Nivel 1 en Ingeniería.
Metadatos opcionales
ID de unidad organizativa: los ID de unidad organizativa le ayudan a identificar el mismo equipo a lo largo del tiempo, incluso si cambia el nombre del equipo. Incluir un ID de unidad organizativa estable significa que no tiene que asignar manualmente los datos de jerarquía; el sistema reconocerá el ID y lo asignará adecuadamente. Sirve para el mismo propósito que un ID de empleado único, pero para una unidad en lugar de un empleado. Debe incluir tantos ID de unidad organizativa como niveles, de modo que pueda proporcionar un ID para cada nivel.
En la siguiente captura de pantalla, las unidades del Nivel 2 corresponden a la columna ID de unidad organizativa 2. El equipo de ingeniería de Employee Experience es la unidad 201 y el equipo de ingeniería de Customer Experience es el 224.
Importación de participantes para una jerarquía de esqueleto
Las jerarquías de esquema se utilizan cuando conoce la identidad de sus gerentes, pero no sus empleados a cargo. En lugar de organizar una jerarquía en torno a una lista de informes directos y la cadena de comando por encima de ellos, puede crear una lista de gerentes y las unidades a las que se incorporan.
Aquí hay un ejemplo de jerarquía de esqueleto para comenzar. Cree un CSV/TSV y cree una fila con cada administrador. Debe tener al menos información de gestor para crear una jerarquía de esqueleto.
Para cada gerente, agregue una columna para el Nombre, Apellido, Correo electrónico, y los metadatos adicionales que desee incluir. A continuación, debe añadir los siguientes metadatos:
- ID de unidad organizativa: El ID de la unidad que gestiona el empleado.
- ID de unidad superior: El ID de la unidad directamente por encima de esta unidad. Esta es la unidad a la que está subordinado el empleado.
- Descripción de la organización: estos metadatos son opcionales. Le permite crear un nombre para la unidad que gestiona el empleado. Puede ser el nombre del equipo o incluso el nombre del gerente.
Ejemplo: en el siguiente ejemplo, TI es un departamento más grande que Ingeniería está anidado debajo. John Doe es el gerente de TI, por lo que su columna ID de unidad organizativa dice 1 para indicar que el ID de unidad de TI es 1. Geoff Brown y Jill Davis son los gerentes de Ingeniería, por lo que ambos tienen un ID de organización matriz de 1 para indicar que TI es la unidad matriz de Ingeniería.
Encuestados vs. No encuestados
Un encuestado es un participante que puede responder a su encuesta. Un no encuestado es un participante que no puede acceder a la encuesta. Puede ser útil que algunos participantes no sean encuestados si desea que puedan ver los resultados del dashboard o validar las jerarquías de la organización, pero no desea que rellenen una encuesta.
Puede determinar si el participante que está agregando es un encuestado al proyecto incluyendo un encabezado llamado Encuestado y, a continuación, utilizando uno de los siguientes valores:
- 0 – No encuestado
- 1 – Encuestado
Si no incluye la columna Encuestado en su archivo, todos sus participantes se establecerán como encuestados de forma predeterminada.
Caracteres máximos y admitidos
Número máximo de caracteres para cada campo
- Nombre: 50 caracteres para cada nombre.
- Apellido: 50 caracteres para cada apellido.
- Correo electrónico: 100 caracteres para cada correo electrónico.
- UniqueIdentifier: 100 caracteres para cada identificador único.
- Todos los demás metadatos: los nombres de metadatos tienen un límite de 90 caracteres cada uno, mientras que los valores tienen un límite de 1000 caracteres cada uno.
Caracteres no admitidos
Los siguientes caracteres no se pueden usar en ninguno de los nombres o valores de metadatos:
|
&
;
$
%
< >
()
{ }
*
+
,
`Puede utilizar una barra inclinada ( / ) en valores para campos como fechas, pero no puede utilizarla en el nombre del campo de metadatos.