Onboarding y conocimiento del producto, creados a partir de su propia documentación.

Wikis técnicas, runbooks y especificaciones de producto se convierten en itinerarios de aprendizaje para nuevas incorporaciones, equipos de soporte y clientes. Los ejemplos salen de su stack, no de un manual genérico.

Hablemos de un proyecto Ver el módulo de ejemplo

Destinatarios: Desarrolladores, equipos de soporte y ventas, nuevas incorporaciones, clientes y partners
Temas habituales: Onboarding técnico, Prácticas de seguridad y protección de datos, Formación de producto para ventas y soporte, Academias para clientes y partners
Módulo de ejemplo: Tratamiento de datos personales en nuestros servicios

Una lección terminada tal como la ve el alumnado: ilustración, texto de la lección y un reproductor de audio.

01 Temas

Lo que solemos tratar

1 Onboarding técnico
2 Prácticas de seguridad y protección de datos
3 Formación de producto para ventas y soporte
4 Academias para clientes y partners

Cualquier otro tema funciona igual: a partir de sus documentos o de un brief.

02 Formatos

Lo que mejor funciona para este público

Una persona sube una escalera de cinco recuadros de documento unidos por un camino punteado hasta una bandera, partiendo de una pila de hojas sueltas.

Itinerarios de aprendizaje

Creados a partir de sus documentos y runbooks, en un orden lógico.

Una persona ante una tableta con un cuestionario de escenarios: una campana de alarma, una tarjeta con la pregunta y tres opciones de respuesta, una de ellas marcada.

Preguntas de escenario

Basadas en el tipo de incidencias que sus equipos gestionan realmente.

Un cubo central distribuye contenidos formativos mediante conexiones de enchufe y nube a tres aplicaciones distintas: un portal, una plataforma de cursos y un panel de control.

Distribuidos a través de la API

En su propio portal, LMS o producto.

03 Módulo de ejemplo

Tratamiento de datos personales en nuestros servicios

Demo disponible en ¿Otro idioma? Contáctenos

1
Qué se considera dato personal aquí

Un dato personal es cualquier información que permite identificar a una persona viva, por sí sola o combinada con otra. Una dirección de correo electrónico, un ID de cliente, una dirección IP y un identificador de dispositivo cuentan. También un ticket de soporte que nombra al usuario. Si puedes averiguar de quién se trata, trátalo como un dato personal, aunque falte el nombre.

Narración, 0:25
2
Registrar logs sin filtrar datos

Los logs viajan más lejos que el código: a paneles, a proveedores, a copias de seguridad. Así que registra el evento, no a la persona. Escribe el ID de usuario en lugar del correo electrónico y nunca imprimas el cuerpo de una petición ni un token. Antes de añadir una línea de log, pregúntate qué podría averiguar un desconocido con ella. Enmascara lo que debas conservar y fija un periodo de retención corto.

Narración, 0:30
3
Solicitudes de acceso y eliminación

Las personas pueden preguntar qué datos tenemos sobre ellas y pedirnos que los eliminemos. Estas solicitudes llegan a través del formulario de privacidad y deben responderse dentro del plazo que indica el ticket. Nunca busques a mano. Abre la solicitud en la herramienta de privacidad, que encuentra los registros en todos nuestros servicios e inicia la eliminación. Las copias de seguridad se borran según su calendario habitual.

Narración, 0:30
4
Escenario: una dirección de correo en un stack trace

Un compañero pega un stack trace en el chat del equipo. A mitad, aparece la dirección de correo de un cliente dentro de un mensaje de error. ¿Qué haces? No lo reenvíes. Elimina el mensaje, avisa a tu compañero y abre un incidente por la filtración. Después corrige la causa, para que el código deje de incluir el correo en el texto del error.

Narración, 0:24