Recommended resources
The freely available resources this lesson will direct you to.
Hola. En la sesión de lanzamiento del piloto quedó clara una regla: el asistente propone borradores de respuesta, pero una persona los contrasta con la guía y decide si pueden enviarse. También se mostraron los canales de ayuda del primer día. Ahora hay que conseguir que esa ayuda siga funcionando cuando termine la sesión: durante los turnos, ante errores repetidos y cuando surjan formas de usar la herramienta que la guía todavía no contempla.
En esta lección establecerás una red de champions —personas cercanas al trabajo cotidiano que ayudan a sus compañeros— y un circuito posterior al lanzamiento para atender consultas, escalar riesgos y comprobar que los problemas se resuelven. El resultado que buscamos es operativo: que cada persona sepa a quién acudir y que cada señal recogida tenga un responsable y una respuesta. Tiempo estimado: unos 40 minutos, incluidas las lecturas.
Qué puede aportar un champion y qué no debe asumir
Una persona que domina el asistente no es automáticamente un buen champion. Puede generar borradores excelentes y, sin embargo, no tener tiempo para ayudar durante un turno, no saber explicar la revisión humana o resolver por su cuenta cuestiones que requieren autorización. El valor de la red está en hacer repetible un uso seguro, no en reunir a quienes más utilizan la herramienta.
OpenAI Academy distingue entre champions que ayudan a orientar la adopción a escala organizativa y otros, más próximos a los equipos, que convierten las posibilidades de la IA en prácticas de trabajo. Lee esa distinción junto con los hábitos que mantienen útil la red después del lanzamiento.
The AI Champion role - Resource | OpenAI Academy
Lee «The AI Champion role», de OpenAI Academy, para distinguir la orientación general de la ayuda entre compañeros y para identificar qué mantiene activa una red tras el primer impulso.
En «Champion Roles», localiza los subtítulos «Leaders» y «Activators». Lee los dos perfiles, fijándote en la proximidad de cada uno al trabajo diario. Después, en «What Strong Champions Do Differently», lee los hábitos prácticos. Presta especial atención a la revisión humana, la reutilización de guías y el seguimiento de lo que ocurre después de formar al equipo.
En nuestro piloto, el champion de un turno podría ayudar a localizar la guía vigente, mostrar cómo contrastar un borrador con ella y recoger una dificultad que varias personas encuentran. No sustituye a quien autoriza excepciones del procedimiento, al soporte técnico ni al responsable de privacidad o seguridad. Tampoco debe convertirse en la única persona capaz de utilizar el asistente: su trabajo consiste en aumentar la autonomía del equipo.
Esta separación conecta con la matriz RACI que ya preparaste. La matriz asigna responsabilidades para decisiones y tareas; la red de champions añade proximidad y disponibilidad para el uso cotidiano. Si la matriz dice que la supervisión decide sobre una compensación, un champion no adquiere esa facultad porque sea la persona más accesible.
Construir una red con cobertura real
Antes de pedir voluntarios, determina dónde aparecerán las preguntas. En el piloto de respuestas a consultas, puede haber personal en dos turnos, personas que trabajan principalmente desde un móvil y otras que consultan la guía desde un ordenador. Una red concentrada en el horario de oficina dejaría sin apoyo precisamente a parte del equipo que debe usar la herramienta.
El relato de Microsoft sobre su comunidad de champions para Copilot describe un comienzo concreto: captación, bienvenida con recursos, encuentro inicial y consulta sobre conocimientos y necesidades. No hace falta reproducir su escala ni sus distintivos; interesa la idea de preparar y acompañar a las personas antes de presentarlas como referentes.
Inside Track - Driving Microsoft 365 Copilot adoption with our Copilot Champs Community
Lee cómo el equipo descrito por Microsoft constituye su comunidad de champions. Úsalo como ejemplo de organización de la red, no como una plantilla obligatoria para un piloto pequeño.
En «Building a community that drives change», empieza en la lista «Recruiting» y termina al final de «Baseline poll». Lee la puesta en marcha. Observa qué recibe una persona antes de empezar a ayudar y qué necesita saber el equipo coordinador sobre ella.
Para un piloto de 24 personas distribuidas en dos turnos, un diseño inicial podría contar con una persona champion por turno y una suplente que también haya recibido preparación. No es una proporción universal: la cobertura depende del volumen de consultas, la disponibilidad y los canales de trabajo. Antes de confirmar los nombres, acuerda con sus responsables cuánto tiempo podrán dedicar a esta función. El entusiasmo sin tiempo asignado produce un canal que existe sobre el papel, pero al que nadie puede responder.
Una ficha breve de cada champion debería dejar claros cinco puntos:
- Ámbito: qué equipo y horario cubre, y quién le sustituye.
- Ayuda permitida: orientación sobre el flujo aprobado, localización de recursos y práctica entre compañeros.
- Límites: qué decisiones e incidencias debe derivar, sin investigar por su cuenta datos sensibles ni aprobar excepciones.
- Preparación: uso del caso ficticio, detección de una promesa no respaldada y ensayo de la ruta de escalado.
- Contacto: por dónde recibe dudas y por dónde comunica patrones al responsable de adopción.
Presenta la red al equipo solo después de comprobar estos puntos. El diagrama de lanzamiento de Microsoft Teams sitúa a los champions tanto en el programa de primeros usuarios como en la comunidad, las comunicaciones y el aprendizaje posterior. Su utilidad aquí es recordar que la red no aparece mágicamente el día del evento ni desaparece al acabarlo; las actividades y los responsables concretos deben adaptarse a este piloto de IA.
Del «pregunta a alguien» a un circuito de soporte
En la lección anterior viste un mapa de posibles niveles de ayuda, desde recursos de autoservicio hasta soporte especializado. Ahora toca fijar qué sucede cuando una duda entra en el circuito. La regla básica es que el champion puede orientar y clasificar, pero cada tipo de problema debe llegar a quien tiene capacidad para resolverlo.
| Señal recibida | Primera actuación del champion | Destino responsable |
|---|---|---|
| «No encuentro el paso para revisar el borrador» | Indicar la guía vigente y observar el paso con un caso permitido. | Si la instrucción resulta confusa para varias personas, responsable de formación o adopción. |
| «No puedo acceder a la herramienta» | Confirmar que no es solo una duda de navegación; indicar cómo continuar con el procedimiento manual aprobado. | Mesa de ayuda o responsable técnico, mediante el canal de incidencias. |
| «El borrador promete una compensación que la guía no autoriza» | Indicar que no se envíe; ayudar a registrar el fallo sin copiar la consulta del cliente en un chat no autorizado. | Responsable del piloto y de la guía operativa; equipo técnico o de producto si debe investigarse el comportamiento. |
| «La herramienta parece haber mostrado datos que no corresponden a esta consulta» | Detener el uso de la función afectada y aplicar el procedimiento de contingencia aprobado. No investigar ni difundir el contenido en el grupo de champions. | Canal urgente de privacidad o seguridad y responsable del piloto, según el protocolo del cliente. |
La tabla no reemplaza las rutas aprobadas por el cliente: antes del lanzamiento hay que convertir cada «destino responsable» en un canal, una persona o equipo de guardia y una alternativa fuera de horario. Una incidencia de acceso no debe quedarse en una conversación informal; una posible exposición de datos no debe esperar a la próxima reunión semanal.
El circuito completo tiene cuatro momentos. Primero, recibir y clasificar la señal: duda de uso, incidencia técnica, fallo de calidad del resultado o posible riesgo. Segundo, actuar según el alcance: orientar, continuar temporalmente sin la herramienta o detener la tarea afectada cuando corresponda. Tercero, registrar y derivar con la información mínima necesaria: categoría, momento, impacto, canal y responsable asignado, evitando datos personales o contenido sensible en espacios no aprobados. Cuarto, cerrar el ciclo: comprobar que la persona recibió respuesta, comunicar cualquier cambio en la guía y verificar que el problema no se repite. Reenviar un mensaje, por sí solo, no significa que la incidencia esté resuelta.
Imagina que, tras el lanzamiento, dos personas de distintos turnos reciben durante una semana borradores que garantizan una compensación. Los champions les recuerdan que no deben enviar esa afirmación y comunican el patrón por el canal previsto, sin pegar consultas de clientes en el chat comunitario. La persona responsable comprueba el alcance, decide si se pausa esa tarea del piloto y coordina la corrección que proceda. Cuando se valida la solución, ambos turnos reciben la guía actualizada y se verifica con casos permitidos si el fallo persiste. La red ha servido para detectar y contener; la decisión y la corrección han permanecido en sus responsables.
Mantener viva la red y aprender del uso real
Una comunidad no se sostiene enviando un mensaje de bienvenida. El mismo caso de Microsoft describe espacios para compartir materiales, sesiones de preparación de champions y encuentros periódicos donde revisar novedades, obstáculos y prácticas útiles. Lee esa parte pensando en qué conservarías para una red pequeña, con personal en turnos.
Inside Track - Driving Microsoft 365 Copilot adoption with our Copilot Champs Community
Vuelve al artículo de Microsoft para examinar cómo mantiene el apoyo a sus champions una vez incorporados. Interesa la función de cada espacio y encuentro, no adoptar sus herramientas concretas.
En el apartado sobre la continuidad de la comunidad, busca la lista que empieza por «Viva Engage». Lee las formas de apoyo hasta «Shout-outs». Fíjate en la diferencia entre disponer de un canal para dudas, recibir preparación para ayudar a otros y reunirse para detectar patrones.
Para el piloto, puedes traducir esa continuidad a una cadencia proporcionada:
- Primeros tres días: comprobar en cada turno si se encuentra la guía, si se puede pedir ayuda y si existen bloqueos de acceso o dudas que impiden revisar los borradores.
- Final de la primera semana: reunión breve entre champions, responsable de adopción y responsable operativo para agrupar preguntas repetidas y confirmar el estado de las incidencias escaladas.
- Semanas segunda a cuarta: revisión semanal de cambios en la guía, problemas abiertos y ejemplos aprobados que merezca la pena compartir. Después, ajustar la frecuencia según la actividad real del piloto.
Cada encuentro necesita una salida visible: una respuesta para el equipo, una guía corregida, una incidencia con responsable y fecha de revisión, o la confirmación de que no hay cambios. Si las mismas dudas regresan semana tras semana, pedir a los champions que «lo expliquen otra vez» puede ocultar un defecto en la instrucción o en el proceso.
Conviene observar pocas señales, pero útiles: preguntas recurrentes por turno, incidencias sin respuesta, tiempo que tardan en resolverse los bloqueos y casos en los que se detecta un borrador incorrecto antes del envío. No conviertas el número de preguntas en una clasificación de champions ni interpretes que un turno silencioso no necesita apoyo: tal vez su canal no sea accesible. En el próximo módulo trabajarás las métricas de adopción con más rigor; aquí estas señales sirven para gobernar el acompañamiento.
Una comprobación antes de dar la red por establecida
La red está lista para acompañar el piloto cuando puedes responder con precisión: quién cubre cada turno y quién sustituye una ausencia; qué ayuda puede prestar; dónde empieza y termina su autoridad; qué canal atiende cada clase de incidencia; y cuándo se revisarán los problemas abiertos. También debe existir una manera de comunicar la respuesta a la persona que planteó la duda y al resto del equipo si les afecta, sin divulgar información que no deban conocer.
Los champions acercan la ayuda al trabajo real, pero no reemplazan ni las responsabilidades formales ni los controles de seguridad. Un circuito posterior al lanzamiento convierte sus observaciones en decisiones, correcciones y aprendizaje compartido. En la siguiente lección reunirás esta red, junto con las comunicaciones, la formación y las rutas de escalado ya diseñadas, en un playbook de gestión del cambio reutilizable para cada cliente.