Recommended resources
The freely available resources this lesson will direct you to.
Hola. En la lección anterior diseñaste prácticas distintas para quienes atienden consultas, preparan materiales o supervisan el piloto. Todas exigían algo más que generar texto: usar el asistente dentro de su alcance, comprobar el borrador y saber cuándo corregirlo, descartarlo o pedir ayuda.
Ahora toca preparar la sesión de lanzamiento de ese mismo piloto: un asistente que propone respuestas a consultas habituales, pero no las envía. La sesión debe hacer visible por qué se introduce, mostrar el flujo de trabajo completo, dar a cada participante una oportunidad de practicar y dejar claros los límites y los canales de ayuda. El objetivo no es que el evento resulte espectacular; es que las personas salgan sabiendo qué pueden hacer en su siguiente turno de trabajo.
Decidir qué debe conseguir el lanzamiento
Una sesión de lanzamiento no equivale al despliegue técnico. Puede haber acceso configurado y, aun así, personas que no sepan cuándo usar la herramienta o que crean que sus respuestas son fiables sin revisión. Tampoco equivale a una formación exhaustiva: abre un uso acotado, comprueba una capacidad inicial y conecta a los participantes con el apoyo posterior.
Antes de preparar diapositivas, fija una conducta de salida. Para el personal que responderá consultas, podría formularse así:
«Ante una consulta incluida en el piloto, la persona obtiene un borrador con información permitida, identifica cualquier promesa no respaldada por la guía vigente y no envía la respuesta hasta haberla revisado según el procedimiento».
Esa conducta da forma a todo el encuentro. Necesitas una consulta ficticia, acceso a la herramienta o a un entorno de prueba, la guía con la que contrastar la respuesta, tiempo para practicar y alguien capaz de resolver dudas. Una presentación convincente no compensa la ausencia de cualquiera de esos elementos.
La Microsoft 365 Adoption Guide propone elegir el tipo de evento según los objetivos, la cultura y los recursos disponibles, y utilizar situaciones de trabajo reconocibles en la formación. Aunque la guía trata de otro producto, esos criterios ayudan a dimensionar este lanzamiento, no a copiar sus actividades sin adaptación.
[PDF] Microsoft 365 Adoption Guide
Lee estas partes de la guía de Microsoft para relacionar el formato del evento con su finalidad y para centrar la formación en tareas de trabajo, no en una lista de funciones.
En «Build Your Adoption Plan», localiza «How to choose your launch event». Lee los criterios: empieza en la pregunta sobre objetivos de negocio y termina en la pregunta sobre qué cabe en el calendario. Después, en «Build your training strategy», busca el apartado «Use real work scenarios» y lee la recomendación, desde la frase sobre tareas familiares hasta la frase que termina en «technology». En el mismo apartado, «Use multiple formats», lee los formatos, desde la indicación de ofrecer varias formas de formación hasta la mención de barreras geográficas y recursos.
La decisión práctica es a quién reunir y para qué. Si el piloto comienza con un equipo pequeño que atiende consultas durante turnos, una sesión breve, repetida en varios horarios y con práctica en su dispositivo puede ser más útil que un único acto multitudinario. Si participan también mandos, pueden asistir a la apertura común, pero necesitarán después un espacio distinto para tratar incidencias y decisiones de supervisión. El formato presencial o en línea importa menos que garantizar que cada persona pueda ver, probar y preguntar.
Demostrar una decisión, no solo una pantalla
Una demostración de lanzamiento suele perder su momento más valioso cuando el facilitador enseña un resultado impecable y pasa a la siguiente diapositiva. En un asistente de IA, conviene mostrar qué hace la persona cuando el resultado parece bueno, pero contiene un error. Es el puente entre la práctica formativa de la lección anterior y el trabajo real.
El vídeo How to Run a Training Session, de Alexander Lyon Communication Coach, organiza una sesión en cuatro movimientos: explicar, mostrar, dejar hacer y ofrecer comentarios. Obsérvalo pensando en cuál de esos movimientos suele quedar reducido cuando hay prisa por enseñar todas las funciones.
Mira How to Run a Training Session para obtener una estructura sencilla con la que ordenar la sesión de lanzamiento y proteger el tiempo de práctica.
Puedes ver el vídeo completo. Presta especial atención a la demostración, donde se hace visible una actuación, y a práctica y comentarios, donde los participantes ejecutan la habilidad y reciben indicaciones para mejorarla. Trasládalo al flujo de trabajo del piloto, no solo al manejo de la interfaz.
Para nuestro caso, la demostración puede comenzar con una consulta ficticia sobre un pedido retrasado. La persona facilitadora muestra la guía aprobada para el ejercicio: «Las incidencias de retraso requieren revisión por la persona responsable; la guía no garantiza compensaciones». A continuación, introduce únicamente información ficticia y permitida, solicita un borrador y deja que aparezca esta frase:
«Le garantizamos una compensación y resolveremos su caso hoy».
En vez de ocultarla, señala en voz alta las dos afirmaciones que no están respaldadas: la compensación y el plazo. Muestra dónde se consulta la guía, cómo se corrige o descarta el borrador y en qué momento se deriva la decisión sobre una posible compensación. Termina enseñando el punto exacto de control humano antes del envío: en este piloto, pulsar «generar» nunca significa «responder al cliente».
Así, la demostración incluye tanto el funcionamiento normal como la respuesta ante un fallo. No hace falta convertirla en una exhibición de errores extremos. Basta uno plausible, relacionado con el trabajo cotidiano, para mostrar por qué existen la revisión y el escalado.
Un guion de 40 minutos que deja espacio para actuar
La siguiente agenda es un modelo de sesión para personas usuarias del piloto, no una plantilla que debas imponer a cualquier cliente. Supone que el acceso, la guía de contraste y las reglas de datos ya han sido validados por sus responsables. Si eso no ha ocurrido, no presentes la sesión como autorización para empezar a usar la herramienta.
| Minutos | Momento | Qué debe ocurrir |
|---|---|---|
| 0–4 | Apertura | La persona patrocinadora o responsable explica qué problema intenta resolver el piloto y por qué participa este equipo. El facilitador indica qué tarea concreta se probará. |
| 4–9 | Expectativas | Se aclara quién puede usarlo, para qué consultas, con qué información y qué queda fuera. Se explica que el asistente propone borradores y que el envío sigue siendo una decisión humana. |
| 9–17 | Demostración | Se recorre una consulta ficticia completa: petición, borrador, contraste con la guía, corrección o descarte y decisión de derivar cuando corresponde. |
| 17–31 | Práctica guiada | Cada participante trabaja con un caso ficticio en el entorno preparado. La guía de apoyo indica la tarea permitida, la fuente de contraste y las señales de alerta. El facilitador y el apoyo asignado atienden bloqueos. |
| 31–36 | Comentarios y comprobación | Cada persona identifica una afirmación no respaldada y muestra qué decisión tomaría antes del envío. Recibe una indicación concreta si necesita repetir un paso. |
| 36–40 | Ayuda y cierre | Se muestran los canales reales de ayuda, se distingue duda de uso de incidencia y se explica qué sucederá después del lanzamiento. |
La agenda reserva más tiempo a actuar y recibir comentarios que a exponer diapositivas. Durante la práctica, nadie trabaja con datos reales de clientes: el caso, las entradas y la fuente de contraste deben estar preparados y aprobados para ese entorno. Si una persona no consigue entrar, necesita una alternativa prevista —por ejemplo, seguir el caso con un compañero y repetir individualmente la práctica cuando se resuelva el acceso—, no una anotación silenciosa de «asistencia completada».
Hay tres frases que merece la pena ensayar antes de abrir la sala:
- Propósito: «Vamos a probar si el asistente ayuda a preparar borradores de ciertas respuestas, manteniendo la revisión y la decisión de envío en manos del equipo».
- Límite: «Una respuesta convincente puede contener hechos o promesas que no figuran en nuestra guía. Si no puedes comprobarla, no la envíes».
- Continuidad: «Al terminar, sabrás dónde consultar la guía, dónde pedir ayuda con el uso y cómo comunicar un fallo repetido».
Son mensajes breves, pero deben coincidir con las reglas reales del piloto. Si estas cambian, cambia también el guion.
Hacer visibles los canales de ayuda
Decir «si tienes dudas, pregunta» deja una carga innecesaria a quien está atendiendo una consulta bajo presión. En el lanzamiento, muestra qué ayuda existe, para qué sirve y cómo acceder a ella. Conviene verificar los nombres y horarios concretos con el cliente antes de la sesión y dejarlos en una tarjeta o pantalla de consulta posterior.
La imagen de Microsoft representa seis niveles posibles de soporte: cuatro internos y dos externos. Úsala como mapa de opciones, no como indicación de que toda organización deba disponer de seis niveles ni de que este piloto dependa de Microsoft.
Para convertir ese mapa en instrucciones útiles, relaciona la necesidad con un destino validado:
| Si ocurre… | La sesión debe mostrar… |
|---|---|
| Alguien no recuerda el alcance o un paso habitual | Dónde está la guía breve vigente y cómo localizar una instrucción durante el turno. |
| Hay una duda sobre cómo aplicar la guía a una consulta | Qué persona o equipo autorizado puede resolverla y cuándo está disponible. |
| No funciona el acceso o la herramienta | Qué canal registra la incidencia técnica y cuál es el procedimiento de trabajo mientras se resuelve. |
| Aparece una promesa inventada repetidamente o un posible uso indebido de datos | Cómo detener el uso afectado y comunicar el problema al responsable del piloto por el canal de incidencias aprobado, sin copiar información sensible a un canal no autorizado. |
Los destinos no se improvisan delante del público: deben corresponder con las responsabilidades de adopción, soporte y escalado ya asignadas. Un compañero con experiencia puede ayudar a encontrar la guía, pero no por ello está autorizado a decidir una excepción de privacidad o una compensación. Asimismo, una duda funcional no debería perderse en un buzón técnico sin responsable de responderla.
Si el personal trabaja en turnos o lejos de un ordenador, verifica que la ayuda puede consultarse en su horario y dispositivo, y que existe una alternativa cuando nadie responde de inmediato. En la sesión no basta con proyectar una dirección durante tres segundos: muestra cómo abrir la guía y cómo se comunica una incidencia ficticia sin incluir datos de clientes. La red de apoyo y su seguimiento continuado se desarrollarán en la siguiente lección; aquí lo indispensable es que la ruta del primer día sea real y comprensible.
Preparar la sala y comprobar qué ha quedado aprendido
Una sesión así requiere una breve prueba previa con las personas que la facilitarán. Comprueba accesos, permisos, legibilidad de la pantalla, guía vigente, caso ficticio, tiempo de respuesta de la herramienta y disponibilidad del canal de ayuda. Si la demostración en directo falla, una captura o un borrador de ejemplo preparado puede permitir enseñar la decisión de verificación; no sirve para fingir que el acceso funciona. Un bloqueo que impida practicar debe registrarse y resolverse antes de considerar preparada a la persona afectada.
Al cerrar, separa tres señales que a menudo se confunden:
- Asistencia: la persona estuvo presente.
- Preparación inicial: pudo realizar la tarea observada o necesita apoyo adicional.
- Adopción y valor: más adelante utiliza la solución de forma adecuada en el trabajo y obtiene un resultado útil.
La sesión puede aportar evidencia de las dos primeras; por sí sola no demuestra la tercera. Recoge dudas recurrentes, bloqueos de acceso y errores que las personas no detectaron. Esa información permite ajustar la guía, ofrecer otra práctica o revisar el proceso antes de ampliar el piloto. También da al responsable una señal temprana de que algo del entorno —no necesariamente de la motivación de las personas— dificulta el uso seguro.
Una sesión de lanzamiento útil une propósito, límites, demostración, práctica con comentarios y ayuda disponible. Para este piloto, el momento decisivo no es ver aparecer un borrador: es comprobarlo, decidir si puede utilizarse y saber a quién acudir si no. Prepara el evento para observar esa conducta, no solo para anunciar que la herramienta existe.
En la próxima lección extenderás lo que aquí debe quedar operativo desde el primer día: una red de personas de apoyo y un circuito de seguimiento que recoja dudas, incidencias y señales de uso después del lanzamiento.