Workshop Omada para integradores

Preséntate y pregunta a la sala cuántos han tocado ya algún controlador Omada, aunque sea brevemente. Eso te dice en qué punto afinar el ritmo de la sesión 1. No leas la lámina: úsala como fondo mientras hablas del contrato que estás haciendo con ellos: al terminar, tienen un sitio real y saben tomar una decisión de producto.

No leas las tarjetas. Señala cada número y di en voz alta si es teoría o práctica: 'El uno y el dos los trabajamos con debate y casos; del tres en adelante la consola está abierta y nadie avanza sin haber completado el paso anterior.' Pregunta a la sala: '¿Alguien ha tocado ya alguna vez la interfaz del controlador, aunque sea para mirar?' Según la respuesta, ajusta el ritmo que vas a llevar en el bloque 3.

No leas las tarjetas en voz alta: preséntate con una anécdota de una instalación real que ilustre por qué acabaste especializándote en Omada. Deja el slide como respaldo visual. Antes de pasar, pregunta a la sala: ¿alguien ha tocado ya algún controlador, aunque sea brevemente? Eso te dice en treinta segundos qué nivel tienes delante.

Deja que respondan antes de comentar los resultados. Si usas una herramienta de encuesta en vivo, muestra el gráfico en pantalla; si no, pide mano alzada. Anota mentalmente quién está en D: son los que pueden complementar con experiencia propia durante los ejercicios y también los que van a notar rápido cualquier imprecisión tuya, así que mantenlos activos con preguntas directas.

Pregunta a la sala antes de avanzar: ¿alguien ha entregado ya una instalación TP-Link sin controlador? Que cuenten qué pasó cuando el cliente quiso hacer un cambio. Esa respuesta es la mejor entrada al bloque. No des tú la respuesta: déjala salir del grupo.

Usa esta lámina para hacer un contrato verbal con la sala: 'Esto es lo que vamos a ver y en este orden.' Pregunta si alguien ha usado ya un controlador de otro fabricante —Cisco Meraki, Ubiquiti UniFi— porque esa experiencia previa cambia el ritmo: puedes ir más rápido en conceptos y detenerte más en las diferencias de nomenclatura. La parada 5 (límites) suele sorprender; avisa que la vas a tratar con honestidad y que no es para desanimar sino para que lleguen a la propuesta con argumentos sólidos.

No leas las tarjetas. Pregunta primero a la sala: '¿Alguno ha tenido que cambiar una contraseña en todos los APs de un sitio a mano? ¿Cuánto tardasteis?' Deja que respondan. Luego muestra la lámina como confirmación de lo que acaban de describir. El objetivo es que el dolor lo pongan ellos, no tú.

Antes de mostrar el diagrama, pregunta a la sala: '¿Alguien ha tenido que cambiar una contraseña de WiFi en un sitio con cinco APs sin controlador? ¿Cuánto tardó?' Deja que respondan; ese dolor es el argumento más limpio. Luego muestra el diagrama y señala explícitamente la línea discontinua del plano de gestión frente a las flechas sólidas del plano de datos: ese detalle es el que más confunde y el que más preguntas genera después. Insiste en que 'el controlador cae, la red no muere' porque los integradores van a tener que explicárselo a sus clientes cuando vendan la solución.

Antes de pasar la lámina, pregunta a la sala: '¿Alguien ha tenido que entrar a cada AP por separado para cambiar la contraseña del WiFi?' Deja que respondan. Eso es exactamente el dolor que resuelve la tarjeta 2. En la tarjeta 3, si alguien pregunta qué protocolo usa para la itinerancia, puedes mencionar 802.11r, pero avisa que eso llega en el bloque de configuración de redes inalámbricas, no aquí. El cierre es importante: hay integradores que venden el controlador como si mejorara la señal. Corrígelo ahora para no tener problemas en la entrega al cliente.

Pregunta a la sala antes de avanzar: ¿alguien ha intentado mezclar dispositivos de otra marca con un controlador Omada? Si hay experiencia, déjala salir, porque ilustra el punto mejor que cualquier diapositiva. Si nadie lo ha intentado, anticipa que algún cliente lo va a pedir y que la respuesta siempre es la misma: no es posible. No entres todavía en los tipos de controlador; eso viene en el bloque siguiente.

Ten el panel abierto en vivo o la captura preparada antes de llegar a esta lámina. No la leas en voz alta: deja unos segundos de silencio para que la sala la observe y luego pregunta '¿qué es lo primero en lo que os habéis fijado?'. Las respuestas te dicen qué zona del panel necesita más explicación en las láminas siguientes. Si algún participante ya ha visto Omada antes, pídele que señale algo que le resultó confuso la primera vez.

Pregunta a la sala antes de pasar: '¿alguien ha intentado adoptar un dispositivo y no lo ha encontrado en el listado?' Es el error más frecuente en el primer proyecto. Aprovecha para recordar que la lista exacta de modelos compatibles está en la web de Omada y varía con cada versión del controlador, así que conviene consultarla antes de presupuestar. No entres en detalle de modelos concretos aquí: eso va en el bloque de instalación.

Antes de mostrar el diagrama, pregunta a la sala: '¿Alguien ha visto un AP seguir funcionando después de apagar el controlador?' Si hay manos, úsalo como gancho para explicar por qué ocurre eso. Insiste en que el canal de gestión y el canal de datos son caminos físicamente distintos: es el malentendido más común en instaladores que vienen de soluciones donde el controlador sí está en el camino de datos. No entres todavía en puertos TCP concretos ni en el protocolo OMADA Discovery; eso es detalle de troubleshooting y se desvía del objetivo de esta lámina.

Antes de mostrar la lámina, pregunta a la sala: '¿Alguien ha recibido alguna de estas tres quejas de un cliente?' Deja que dos o tres personas respondan. Eso ancla el problema en su experiencia real antes de que vean la solución. No menciones aún el controlador por nombre; deja que el patrón emerja solo. El cierre es importante: subraya que la adopción tardía tiene coste real de tiempo, no es solo una incomodidad menor.

No leas los marcadores en voz alta como si fueran datos. Di explícitamente: 'Esta lámina la tenéis en blanco porque los números que importan son los vuestros, no los míos.' Pregunta a la sala si alguien ha cronometrado alguna vez cuánto tarda en tocar todos los APs de una instalación cuando tiene que cambiar algo. Deja que respondan. Ese tiempo, sea cual sea, es el argumento de venta del controlador. Si alguien trae un dato propio, pídele que lo comparta: es mejor que cualquier cifra de laboratorio. El límite honesto de esta lámina: los números varían mucho según el tamaño de la instalación y la experiencia del integrador, así que evita prometer ahorros concretos que no puedas demostrar en el contexto de ese cliente.

No proyectes todavía ningún formulario ni guía. Pregunta a la sala: '¿Qué es lo primero que hacéis cuando llegáis a la instalación de un cliente?' Deja que dos o tres personas respondan. Después di que vais a contrastar esas respuestas con el checklist del ejercicio. El objetivo es que salgan ellos solos con las variables clave —número de dispositivos, cobertura de internet, acceso remoto sí o no— antes de que tú las nombres.

No des el escenario tú: pide a los participantes que usen un cliente real suyo, o uno inventado por ellos. El objetivo es que la incomodidad de no tener datos completos la sientan ahora, no en campo. Deja dos minutos de silencio para que escriban antes de abrir la discusión. Cuando alguien comparta su recomendación, pregunta siempre '¿y si esa razón desaparece, cambia la decisión?' para forzar el segundo nivel de análisis.

Pausa aquí y pregunta a la sala: '¿Alguien tiene dudas sobre alguno de estos tres puntos?' No sigas hasta que no haya manos levantadas o silencio confirmado. Si alguien pregunta algo que pertenece al bloque 2, anótalo en el chat o en la pizarra y dile que lo vas a responder en diez minutos. No anticipes el contenido siguiente.

Lanza la encuesta antes de mostrar las opciones en pantalla y deja que la gente piense un segundo. Cuando salgan los resultados, no los comentes tú primero: pregunta a alguien del grupo mayoritario qué le preocupa del controlador en ese escenario. Eso abre la conversación que va a sostener todo el bloque de elección. Si la opción D tiene peso, es una señal de que el bloque de criterios necesita más tiempo que los bloques de configuración.

Antes de pasar, pregunta a la sala: ¿alguien ha tenido que cambiar de controlador en un proyecto ya entregado? Deja que cuenten brevemente. Eso pone encima de la mesa exactamente el dolor que este bloque resuelve. No cierres la anécdota tú: que la sala la cierre sola.

Antes de avanzar, pregunta a la sala cuántos han tenido ya una conversación con un cliente donde no sabían qué controlador recomendar. No pidas que levanten la mano si el grupo es pequeño; hazlo conversacional. Eso sitúa el problema en su experiencia antes de que empiece la teoría. El paso 3 es el que más atención va a generar: no desveles todavía cuál es el mito, deja que la curiosidad trabaje durante los pasos anteriores.

Antes de mostrar las tarjetas, pregunta a la sala: '¿Alguno ha llegado a un cliente que ya tenía Omada instalado y ha tenido que cambiar de modelo?' Si alguien responde sí, pídele que cuente qué pasó; eso vale más que cualquier explicación tuya. Si nadie responde, usa la tarjeta 3 para abrir la pregunta de qué escenarios de sus clientes habituales quedarían fuera de la nube —no lo respondas tú, deja que ellos identifiquen sus propios casos.

Detente en la flecha verde y pregunta a la sala: '¿Alguien sabe si el tráfico de los usuarios pasa por TP-Link?' Es una confusión frecuente y vale la pena despejarla en voz alta antes de seguir. Si alguien pregunta qué pasa durante una caída de internet, confirma que los dispositivos siguen funcionando con su configuración en caché, pero que no puedes hacer ningún cambio remoto hasta que vuelva la conexión: ese es exactamente el argumento que vas a usar en la lámina de criterios de elección.

Pregunta a la sala antes de avanzar: ¿alguno ha tenido un cliente que te exija que sus datos no salgan de sus instalaciones? Ese es el caso de uso natural de esta opción, no lo expliques tú solo. Detente en el diagrama el tiempo suficiente para que quede claro dónde está la frontera entre lo que es LAN y lo que es internet: ese borde punteado es la decisión de arquitectura, no un detalle gráfico. Si alguien pregunta qué pasa con los APs cuando el controlador se apaga, confirma: siguen emitiendo SSID con la última configuración descargada, pero no aplicas cambios ni ves estadísticas hasta que el controlador vuelva.

No leas la tabla en voz alta fila a fila: da tiempo a que la sala la lea. Luego pregunta: '¿Qué criterio es el que más aparece en vuestros clientes habituales?' Eso orienta el resto del bloque hacia los casos reales de los participantes. Si alguien menciona clientes con regulación sectorial (sanidad, finanzas), anota el punto de privacidad: es el argumento que suele cerrar la decisión hacia hardware sin más debate. Recuerda mencionar que la red sigue funcionando aunque el controlador en la nube no sea accesible: es una confusión frecuente y genera mucha resistencia inicial.

Antes de mostrar las tarjetas, pregunta a la sala: '¿Alguien ha tenido ya una conversación con un cliente donde no sabía qué recomendarle?' Deja que dos o tres personas cuenten el caso brevemente. Luego presenta los criterios como el filtro que habría resuelto esa conversación. No leas las tarjetas en voz alta: deja que las lean y tú amplía solo el criterio que genere más preguntas. El tercero —número de sitios— suele sorprender a quienes vienen de gestionar instalaciones únicas; detente ahí si ves caras de duda.

Antes de mostrar las tarjetas, pregunta a la sala: '¿Alguien ha tenido que cambiar el controlador después de la entrega? ¿Qué pasó?' Deja que respondan 30 segundos; si nadie ha vivido el problema aún, el coste de equivocarse no es abstracto para ellos todavía, y vale la pena nombrarlo con una cifra de horas de trabajo real. En la tarjeta 3, subraya que la red local sigue funcionando aunque caiga la nube: ese matiz tranquiliza al cliente, pero no elimina el problema de gestión remota. No lo suavices.

No leas los marcadores en voz alta si aún no están rellenos: detente aquí y usa el caso real antes de dar esta sesión. Si ya tienes el caso, cuéntalo antes de mostrar la lámina — que la sala escuche la situación del cliente y luego vea cómo los datos la confirman. Pregunta a los participantes: '¿Alguno de vosotros ha tenido un cliente con restricciones similares? ¿Cómo lo resolvisteis?' Eso abre la discusión y ancla los criterios del bloque anterior a su propia experiencia.

No leer las tarjetas en orden lineal. Preguntar primero a la sala: '¿alguien ha tenido que volver a un sitio a readoptar dispositivos?' Si alguien responde, dejar que cuente brevemente antes de avanzar. El objetivo de esta lámina no es asustar, es que la decisión de nube vs hardware entre en la conversación con el cliente antes de la oferta, no durante la instalación.

Antes de mostrar la tabla, pregunta a la sala: '¿Alguno ha tenido que cambiar de modelo después de instalar? ¿Qué provocó el cambio?' Eso abre la discusión desde la experiencia propia, no desde la teoría. Al llegar a la fila de privacidad de datos, detente: es el criterio que más sorprende a integradores nuevos en Omada y el que más preguntas genera de clientes del sector salud o legal. No leas cada celda en voz alta; recorre solo las filas donde el ganador cambia de columna, que es donde está la información nueva.

No leas las tarjetas: lánzalas como preguntas reales a la sala antes de mostrarlas. '¿Alguien ha tenido un cliente sin técnico local? ¿Qué pasó cuando algo falló?' Deja que emerja alguna anécdota: eso hace que la pregunta #1 se recuerde sola. En la tarjeta #2, si alguien del grupo trabaja con clínicas, colegios o administración pública, pídele que confirme si ha topado con esta restricción: lo hace concreto sin que tengas que inventar el caso. La tarjeta #3 es la que más conversación genera; no la cortes, pero sí redirígela hacia la siguiente lámina cuando llegue el momento.

No describas las capturas: pídele a la sala que las lea en silencio diez segundos antes de hablar. Pregunta después: '¿Alguien ve algo que no esperaba encontrar ahí?' Eso saca las diferencias que más pesan para ellos, no las que pesan para ti. Si alguien pregunta por funciones que no aparecen en ninguna de las dos capturas, anótalo visible para el bloque de configuración. El cierre sobre la CLI lo dices en voz, no lo leas: es el dato que ordena todo lo anterior y pierde fuerza si ya está leído.

Antes de repartir el enunciado, pregunta a la sala: '¿Alguien ha tenido ya un cliente donde la decisión entre nube y hardware fue complicada?' Si alguien responde, anota el caso en la pizarra y deja que el grupo lo use como cuarto escenario informal. Los tres escenarios del enunciado están calibrados para que ninguno sea obvio: uno favorece claramente la nube, otro claramente el hardware, y el tercero tiene argumentos serios en los dos lados. Ese tercero es donde está la discusión útil. No corrijas antes de que los grupos expongan; deja que el desacuerdo entre grupos sea visible.

Reparte los casos impresos o comparte el documento antes de arrancar el temporizador. Da 12-15 minutos para trabajo individual o en parejas y reserva al menos 10 para la puesta en común. En la puesta en común no valides respuestas tú primero: pregunta a alguien que haya elegido controlador en la nube y luego a alguien que haya elegido hardware para el mismo caso, y deja que el grupo vea si el criterio que usaron es el mismo o no. Si el tiempo aprieta, haz la puesta en común solo del caso que más desacuerdo haya generado.

Antes de avanzar, pregunta a la sala: '¿Alguien tiene ya un cliente en mente donde no tenía claro qué modelo recomendar? ¿Qué os dice ahora el criterio?' Deja que dos o tres personas respondan. Si alguien menciona un caso límite genuino —sitio con conectividad intermitente pero con requisito de gestión remota, por ejemplo—, tómalo como caso práctico del bloque 3 en lugar de descartarlo. No resumas el bloque: la lámina ya lo hace. Usa el tiempo de transición para que cada participante anote mentalmente qué modelo va a instalar en el siguiente bloque.

Lanza la encuesta y da 30 segundos antes de leer los resultados en voz alta. No comentes cada opción antes de votar: deja que la sala decida sin ancla. Cuando salgan los resultados, pregunta a alguien de la minoría por qué eligió esa opción: suele abrir el caso de uso más interesante de toda la sesión. Si la opción D tiene votos relevantes, anota qué dudas quedan pendientes y resuélvelas antes de cerrar del todo.

Pausa de transición. Pregunta a la sala: ¿alguien ya tiene el controlador descargado o el hardware en mano? Ajusta el ritmo según lo que contesten: si nadie lo tiene, avisa que ahora mismo lo van a hacer en vivo. Recuerda que este bloque es el más práctico de los tres primeros, así que el peso está en que ellos ejecuten, no en que tú expliques.

Antes de avanzar, pregunta a la sala qué plataforma va a usar cada uno en el laboratorio: nube o hardware. Si hay mezcla, avisa que los pasos 2 y 3 tienen pantallas distintas pero el resultado esperado es el mismo. No entres en detalle de ningún paso ahora: este mapa sirve para que sepan dónde están en cada momento, no para explicar el contenido por adelantado. Detente un momento en el paso 4 solo para advertir que la zona horaria mal configurada es la causa más frecuente de logs inútiles, sin desarrollarlo todavía.

Pregunta a la sala: '¿Alguien ha llegado a una instalación y no tenía control sobre el firewall del cliente?' Deja que cuenten. Este es el momento para que salgan esas historias antes de que les pase aquí. No entres en detalle técnico de los puertos todavía; la lámina siguiente los cubre. Si alguien pregunta por IPv6, diles que Omada lo soporta en versiones recientes pero que en este workshop trabajamos sobre IPv4 para no añadir variables.

Antes de mostrar el diagrama, pregunta a la sala: '¿Alguien ha intentado alguna vez conectar un AP antes de tener el controlador listo?' Es casi seguro que alguien lo ha vivido. Deja que cuenten brevemente qué pasó: eso hace el punto mejor que cualquier explicación. Luego muestra el diagrama como la solución a ese problema. Detente en la etiqueta de control de cada fase y explica que son las tres preguntas que tienes que poder responder con 'sí' antes de avanzar. No pases a la siguiente lámina sin confirmar que todos tienen claro qué necesitan preparar en su red antes de encender el controlador.

Pregunta a la sala antes de avanzar: ¿alguien ha intentado mover un sitio de región y ha visto qué pasa? Es un error frecuente y vale la pena nombrarlo en voz alta. Detente en la licencia: muchos integradores adoptan primero y buscan la licencia después, y el síntoma es que el dispositivo aparece en lista pero no responde a configuración. No leas las tarjetas; úsalas como índice y explica con el flujo real del portal abierto en pantalla si puedes.

Antes de pasar esta lámina, ten el controlador real encendido y con el asistente sin completar, para poder recorrerlo en vivo en lugar de mostrar solo capturas. Pregunta a la sala: '¿Alguien ya intentó abrir esto por su cuenta antes de hoy?' — las respuestas te dicen a qué ritmo puedes ir. Detente en el paso de la cuenta administradora: es el punto donde más se equivocan los integradores que luego quieren ceder el acceso al cliente sin perder el suyo propio.

Antes de pasar esta lámina, pregunta a la sala cuántos han tenido problemas de adopción en instalaciones previas. Casi siempre la causa fue exactamente esta: el controlador en DHCP (Protocolo de Configuración Dinámica de Host) y la IP cambió. Es el momento de insistir en que la IP fija no es opcional. Si alguien pregunta por el puerto 8043 frente al 443, menciona que 8043 es el puerto por defecto en la interfaz local del hardware; en la nube el acceso va por 443 estándar, diferencia que verán en el bloque de comparativa.

Antes de mostrar la captura, pregunta a la sala: '¿Alguien ha tenido un AP que no aparece en adopción aunque responde al ping?' — casi siempre hay una mano levantada, y eso abre el error 2 desde la experiencia de quien escucha. No expliques los tres errores seguidos: muestra el primero, deja que alguien lo identifique en su propio historial, luego pasa al siguiente. En el error 3, insiste en que el indicador de sincronización no es decorativo: es la señal de salida del técnico. Si Luis reproduce el escenario en vivo, que lo haga con el controlador en hardware; el comportamiento es más visible que en la nube porque el estado de sincronización tarda más en resolverse.

Pregunta a la sala cuántos han entregado alguna vez un controlador sin cambiar las credenciales por defecto. No juzgues la respuesta: úsala para anclar por qué esto va antes que la adopción de APs. Si alguien pregunta por certificados SSL propios, confirma que Omada lo permite y apúntalo para la sección de validación y entrega; aquí no entráis en eso.

Dibuja el diagrama despacio, nivel a nivel, en lugar de mostrarlo completo de golpe si la herramienta lo permite. Pregunta a la sala: '¿Dónde ubicaríais el controlador hardware en una instalación donde el switch principal está en el cuarto de comunicaciones y el router es del ISP?' Esa pregunta destapa el error más frecuente: poner el controlador en un segmento al que los PAs no tienen ruta de gestión. No leas los elementos de la lista; úsalos solo como referencia visual mientras hablas.

Pregunta a la sala: '¿Alguno ha tenido que volver a un sitio por algo que podría haber comprobado antes de salir?' Deja que contesten antes de avanzar. El punto sobre el backup suele sorprender: mucha gente lo deja para después y después no lo hace. Insiste en que el backup inicial es el único que tiene un estado limpio y conocido.

No avances hasta tener las capturas reales. Esta lámina es el momento en que los participantes van a comparar lo que ven en pantalla con lo que tienen en su propio navegador: cualquier diferencia rompe la confianza. Pregunta a la sala: '¿Alguien ya tiene el controlador abierto? ¿Qué ven en su panel ahora mismo?' Usa esas respuestas para anclar la lectura del dashboard a su situación concreta, no a una imagen genérica.

Antes de mostrar la tabla, pregunta a la sala cuántos han llegado a un sitio y descubierto que el AP no aparecía en el controlador. Casi siempre es el paso 4: falta de conectividad a internet en nube, o subred incorrecta en hardware. Usa ese momento para anclar la diferencia entre los dos modelos. No leas cada celda; céntrate en las filas 1, 2 y 4 donde las columnas divergen. El paso 5 igual en ambas columnas es un punto de alivio para la sala: diles explícitamente que no tienen que aprender dos interfaces distintas. Reserva el veredicto para leerlo en voz alta y pedir confirmación: '¿Alguno tiene ya un caso en mente donde esto ya lo decide?'

Pregunta a la sala cuántos han tenido que recuperar acceso a un equipo porque el cliente perdió la contraseña. Deja que cuenten. No hace falta que tú pongas el ejemplo: ellos lo tienen. Después señala que con un controlador centralizado el daño se multiplica porque una sola cuenta da acceso a todos los dispositivos del sitio, no a uno solo. El punto sobre las dos cuentas separadas puede generar resistencia ('el cliente no va a tocar nada'): recuerda que no se trata de que el cliente opere, sino de que la titularidad del acceso quede en su nombre cuando el contrato de mantenimiento termina.

Antes de arrancar, comprueba que todos tienen acceso al entorno que van a usar: cloud o hardware según lo que hayan decidido en el bloque anterior. Si alguien no tiene claro aún qué modalidad usa, es el momento de resolverlo, no a mitad del laboratorio. Anuncia el tiempo disponible y señala cuál es el punto mínimo que todos deben alcanzar antes de pasar a la siguiente pantalla: controlador accesible desde el navegador y asistente de primera configuración completado.

Antes de que empiecen, pregunta quién está usando hardware físico y quién software en VM o PC. Los tiempos de arranque difieren bastante y conviene que los participantes con hardware no se desesperen viendo que otros ya están en el paso B. Pasa por las pantallas mientras trabajan; el error más frecuente aquí es poner una zona horaria incorrecta que luego desincroniza los logs, vale la pena mencionarlo en voz alta sin que lo busquen ellos solos. No avances al siguiente bloque hasta que al menos el 80 % tenga el panel visible.

Haz una pausa real aquí antes de pasar. Pregunta a la sala: '¿Alguien tiene el controlador sin responder todavía o con algún error en el acceso web?' Resuelve los casos bloqueantes antes de entrar al bloque 4, porque quien no tenga el controlador activo no puede adoptar nada. Si hay problemas de acceso en el controlador hardware, revisar primero si el navegador está en la misma subred que la IP de gestión.

Lanza la encuesta por el canal que tengas activo (chat, formulario, Mentimeter, mano alzada). No pases a la siguiente lámina hasta tener respuesta visible de al menos la mitad de la sala. Si una opción concentra más del 40 % de los votos, pregunta en voz alta: '¿alguien que marcó esa opción quiere decir en qué momento se atascó?' No resuelvas el problema ahora; identifica si es algo que cubre el material de apoyo o si necesitas añadirlo al seguimiento post-sesión.

Pausa antes de entrar. Pregunta a la sala cuántos han intentado adoptar un dispositivo sin controlador activo y qué pasó. Usa ese relato para enmarcar por qué el orden importa: primero el controlador, luego la adopción, nunca al revés. Si hay participantes con experiencia en otros fabricantes, señala que 'adopción' en Omada equivale a lo que otros llaman 'provisionamiento' o 'asociación', pero con descubrimiento automático en la misma subred.

Pregunta a la sala antes de avanzar: ¿alguien ha intentado alguna vez adoptar un equipo y no ha aparecido en la lista? Deja que cuenten qué pasó, casi siempre es el paso 1 mal resuelto. No expliques aún la solución: el laboratorio la va a dejar clara sola. Reserva tiempo para que quien tenga los equipos en modo 'standalone' (autónomo) entienda que ese estado desaparece tras la adopción y no es reversible sin un reset.

No avances a la adopción sin que la sala haya asimilado este punto: el error más común es adoptar dispositivos en el sitio equivocado y tener que reempezar. Pregunta directamente: '¿Alguien ha trabajado antes con un sistema que use esta lógica de sitios?' Si alguien menciona Meraki o UniFi, úsalo de contraste rápido —en Omada el sitio es el nivel operativo, no el organizativo. Detente aquí el tiempo que haga falta: todo lo que viene después depende de que este concepto esté claro.

No leas el diagrama en voz alta: deja que la sala lo lea sola diez segundos y después pregunta '¿alguien ve ya dónde se comete el error más frecuente?'. El error es adoptar en el sitio por defecto que crea el controlador y darse cuenta tarde. Cuando alguien lo diga, refuérzalo. Si nadie lo dice, señala el dispositivo flotante del diagrama y pregunta qué pasaría si lo adoptas sin haber creado primero el sitio del cliente. Usa ese momento para dejar claro que crear el sitio antes de enchufar el primer dispositivo no es un detalle de orden, es evitar un reseteo.

Pregunta a la sala antes de avanzar: '¿Alguien ha intentado reconfigurar un AP directamente por su IP después de haberlo adoptado? ¿Qué pasó?' Deja que respondan; la experiencia de ver la interfaz local bloqueada es el mejor anclaje para este concepto. No entres todavía en cómo se adopta (eso viene en la siguiente lámina); aquí solo interesa que quede claro el antes y el después.

No leas la pantalla: deja que la sala la mire cinco segundos. Luego pregunta: '¿Alguien ve algo que no esperaba?' Eso abre la conversación sobre por qué un equipo puede aparecer en gris, en rojo o directamente no aparecer. Si tienes el entorno de demo en vivo, muestra el panel real en lugar de la captura. El punto de cierre es importante: la causa más frecuente de 'no aparece' es VLAN de gestión mal asignada, no un fallo del controlador. Dilo antes de que alguien lo pregunte.

Antes de mostrar las tarjetas, pregunta a la sala: '¿Alguien ha intentado adoptar un dispositivo que no aparecía en la lista y no sabía por qué?' Usa esa respuesta para anclar el problema que resuelve la opción 138. Detente en la opción 2: es la que menos integradores conocen y la que más valor aporta en instalaciones reales con VLANs separadas. Recuerda mencionar que la opción 138 requiere acceso al servidor DHCP del cliente, algo que no siempre te van a dar.

Antes de mostrar el diagrama, pregunta a la sala: '¿Alguien ha visto un AP que emitía señal pero el controlador no lo reconocía? ¿Qué hicisteis?' Deja que respondan: casi siempre describen exactamente el estado AISLADO sin saber que tiene nombre. Luego nombras el estado y el diagrama cobra sentido inmediato. Detente en la transición PENDIENTE → ADOPTANDO para dejar claro que el salto no es automático: alguien tiene que pulsar Adoptar, o configurar la adopción por lotes. Es el punto donde más integradores pierden tiempo esperando algo que no va a pasar solo.

No leas las tarjetas. Abre el controlador en vivo y muestra el asistente de creación de sitio paso a paso mientras señalas cada parámetro en pantalla. Pregunta a la sala: '¿Alguien ha tenido que cambiar el país en un dispositivo ya adoptado? ¿Qué pasó?' Si nadie responde, cuenta tú qué implica ese cambio en el plano de canales. Detente en la elección de escenario de red: es la decisión con más consecuencias y la que más confunde a quien viene de configurar APs standalone.

No avances hasta que cada participante tenga su propio sitio creado y visible en el panel. Pregunta a la sala: '¿Alguien ve un campo que no sabe para qué sirve?' — ese es el momento de aclarar antes de que los dispositivos entren. Si alguien ya tiene un sitio de una sesión anterior, pídele que cree uno nuevo con nombre distinto para no mezclar configuraciones durante el taller.

Antes de mostrar la tabla, pregunta a la sala: '¿Alguien ha configurado un SSID en un AP de forma individual y luego le ha costado entender por qué ese AP se comportaba distinto al resto?' Es el síntoma típico de confundir los dos niveles. Usa esa respuesta para anclar la explicación. Al llegar a la fila de VLANs, detente: es el punto donde más integradores cometen el error de crear la VLAN directamente en el switch en lugar de hacerlo en el sitio, y luego el controlador no la reconoce. No leas el veredicto en voz alta; deja que lo lean y pasa a la siguiente lámina.

Pregunta a la sala: '¿Alguien ha visto logs con hora incorrecta y ha tenido que rastrear por qué?' Es un problema clásico de zona mal asignada. No leas las tarjetas: presenta cada campo como una decisión con consecuencia, no como un formulario. En el campo de país, recuerda mencionar que en instalaciones en el extranjero el error es especialmente frecuente porque el controlador puede estar en un país distinto al del sitio físico.

Pregunta a la sala cuántos han tenido ya este problema en alguna instalación anterior, aunque no fuera con Omada. Úsalo para normalizar que no es un fallo del producto sino de la capa de red. No avances a la tarjeta 3 sin haber pasado por la 1 y la 2 en voz alta: la adopción manual es el último recurso, no el atajo.

Antes de pasar la lámina, pregunta a la sala: '¿Alguien ha visto ya un dispositivo en estado distinto a Connected? ¿Qué hicisteis?' Deja que respondan antes de leer los indicadores. Si nadie ha adoptado todavía un dispositivo real, detente aquí y haz la adopción en vivo para que la pantalla sea la real, no la captura. El punto crítico que no está en pantalla: el estado que muestra el controlador depende de que el dispositivo tenga comunicación activa con él; si pierdes conectividad entre el controlador y el AP (Punto de Acceso), el estado puede quedar congelado en 'Connected' durante varios minutos antes de pasar a 'Disconnected'. Eso es importante para no confiar ciegamente en la vista de lista durante una incidencia.

Pregunta a la sala si alguien ha movido ya un AP entre proyectos y qué pasó. El error más común es adoptar en el sitio nuevo sin haber hecho el Forget, y el dispositivo aparece como 'aislado' o con comportamiento errático. Detente en la diferencia entre Forget y Factory Reset: Forget es el paso correcto aquí; Factory Reset es más agresivo y solo es necesario si el dispositivo estaba en otro controlador completamente distinto o no responde. No entres en el detalle de la migración entre controladores distintos: eso está fuera del alcance de este bloque.

Antes de arrancar el cronómetro, pregunta a la sala cuántos han creado ya algún sitio aunque sea de prueba. Ajusta el ritmo según la respuesta: si nadie lo ha tocado, dedica dos minutos a mostrar la pantalla de inicio antes de soltarlos. Recuérdales que el error más frecuente aquí es intentar adoptar antes de que el controlador y el dispositivo estén en la misma red o con el descubrimiento habilitado. Di explícitamente que los errores de adopción son parte del ejercicio, no un fracaso: los quieres ver aparecer para poder resolverlos en vivo.

Antes de que cada uno arranque, pídeles que confirmen en voz alta cuántos dispositivos tienen conectados. Así sabes si alguien va a tener sorpresas (equipos que no aparecen porque están en otra subred). Detente en el paso B si alguien ve el estado 'Pendiente de activación' en lugar de 'Pendiente': eso indica que el dispositivo tiene firmware muy antiguo y necesita actualización manual previa. No lo saltes, porque bloquea el resto del laboratorio.

Antes de pasar, pide a cada participante que confirme en voz alta o en el chat cuántos dispositivos le aparecen como Connected. Si alguien tiene alguno en Pending, resuélvelo ahora: entrar al Bloque 5 con un dispositivo sin adoptar genera problemas que son difíciles de diagnosticar más tarde. Es el momento de parar, no de avanzar con deuda técnica.

Lanza la pregunta y espera respuestas en voz alta o por el canal del chat, según el formato del workshop. No cierres la encuesta antes de tiempo: si hay empate entre dos opciones, es una señal para detenerte y preguntar qué hace que cada uno elija la suya. La opción D aparece como broma, pero casi siempre alguien la vota en serio; si ocurre, úsala para hablar de la importancia de aislar la ventana de configuración con el cliente antes de empezar.

Pausa antes de entrar. Pregunta a la sala: ¿alguien ha intentado segmentar invitados de corporativo sin controlador, solo con el router? Deja que respondan. Eso pone en contexto por qué este bloque existe. No adelantes los pasos: la promesa es suficiente para que sepan adónde van.

Antes de empezar el laboratorio, pregunta a la sala qué esquema de VLANs usan habitualmente en sus instalaciones: probablemente ya tienen un criterio de numeración propio y conviene respetarlo en el ejercicio para que la práctica sea transferible a su trabajo real. Detente en el paso 2 y recuerda que el ID de VLAN es el punto de fallo más frecuente en campo: un número mal copiado entre el controlador y el switch hace que el tráfico caiga sin ningún mensaje de error obvio. En la validación del aislamiento (paso 5), haz la prueba en pantalla compartida para que vean el resultado —sea cual sea— antes de seguir.

Antes de pasar a la siguiente lámina, pregunta a la sala: '¿alguien ha tenido problemas porque el puerto del switch no estaba en modo trunk y los dispositivos de un SSID no obtenían IP?' Es un error muy común en la primera instalación y vale la pena nombrarlo aquí. No expliques todavía cómo se configura en Omada; eso viene en la lámina de práctica. Esta lámina solo asienta el modelo mental de las tres piezas.

Antes de mostrar el diagrama, pregunta a la sala: '¿Alguien ha tenido que separar la red de invitados de la corporativa sin tirar cable nuevo?' Deja que respondan; el diagrama responde visualmente a ese problema. Insiste en que el ID de VLAN es un número que tienes que escribir igual en tres sitios: switch, AP y gateway. Ahí está el 80% de los fallos en instalación. Si alguien pregunta por VLANs en routers Omada o por el puerto WAN, apúntalo para la sección de validación; aquí solo establecemos el concepto.

Antes de avanzar, pregunta a la sala: ¿cuántos han configurado VLANs en un switch antes de hoy? La respuesta te dice si necesitas detenerte a explicar el concepto de etiquetado 802.1Q o puedes asumir que ya lo tienen. No expliques en pantalla lo del trunk: di en voz alta que ese es el punto donde más instalaciones fallan en campo, y que en la lámina de validación van a ver exactamente cómo comprobarlo antes de entregar el sitio.

Esta lámina es el momento de hacer la demo en vivo, no de describir la demo. Si algo falla en la conexión o el panel tarda, no improvises datos: di exactamente qué debería aparecer y por qué no está apareciendo. La sala de integradores va a valorar más esa honestidad que una captura de pantalla de archivo. Antes de pasar a la siguiente lámina, pregunta: '¿Alguien ya ha creado el suyo en paralelo? ¿Qué veis en vuestra pantalla que sea distinto a esto?'

Antes de avanzar, pregunta a la sala: '¿Alguien ha entregado un sitio donde la red de invitados estaba en la misma VLAN que la red interna?' Es un error muy común y abre bien la explicación del aislamiento y la VLAN. No leas las tarjetas en orden: empieza por la de VLAN porque es donde más errores se cometen en campo, luego enlaza con aislamiento, y deja la banda para el final como refuerzo de rendimiento.

Pregunta a la sala cuántos han tenido un incidente porque alguien conectó un móvil personal a la red corporativa. Úsalo para anclar por qué el aislamiento de cliente en invitados no es opcional. Detente en el punto de autenticación: muchos integradores ponen la misma contraseña en ambas redes durante semanas 'hasta que el cliente la cambie'. Nombra ese hábito sin juzgar y muestra cómo el portal cautivo elimina ese riesgo. Si el grupo trabaja con hoteles o espacios de coworking, menciona que el portal cautivo también puede recoger aceptación de términos legales, pero que eso es configuración avanzada fuera del alcance de esta sesión.

Pregunta a la sala si alguien ya trabaja con VLANs en switches no Omada: en ese caso el ID tiene que coincidir exactamente con el que está configurado aguas arriba, y ese detalle no aparece en pantalla. Es un buen momento para recordar que el controlador gestiona la lógica, pero la troncalización física sigue dependiendo del hardware del cliente.

Antes de mostrar el diagrama, pregunta a la sala: '¿Dónde creéis que se pone la etiqueta VLAN, en el cliente o en el AP?' La respuesta habitual es 'en el cliente', y corregirla es el momento de aprendizaje más valioso de esta lámina. Detente en el nodo del switch y recuerda que Omada configura el AP correctamente, pero el switch externo que no sea Omada hay que configurarlo a mano: eso queda fuera del controlador y es responsabilidad del integrador. Si alguien pregunta qué ocurre con un switch Omada gestionado, avanza que lo verán en la práctica del bloque.

Rellena los tres marcadores antes de la sesión y muestra la navegación en vivo, no solo la captura. Pregunta a la sala: '¿Alguien ha entregado un sitio sin tocar estos ajustes y le ha vuelto?' — es probable que más de uno haya tenido un incidente relacionado. Si el grupo es heterogéneo en tamaño de instalación, señala explícitamente qué ajustes cambian de criterio cuando el entorno escala.

Pregunta a la sala: '¿alguien ha tenido un cliente con equipos que solo ven 2,4 GHz?' Úsalo para anclar la tarjeta 1. En la tarjeta 2, si el grupo pregunta si merece la pena fijar canal manualmente, la respuesta corta es: solo cuando tienes una medición de espectro en mano, nunca por intuición. No entres todavía en steering de banda ni en BSS Coloring; eso queda fuera de este bloque.

Pregunta a la sala antes de abrir la tabla: '¿Alguien ha tenido ya un cliente que no podía conectar porque le pusiste WPA3?' Es probable que alguno lo haya vivido sin saber por qué. Eso abre la conversación mejor que cualquier definición. No entres en el detalle matemático de SAE a menos que alguien lo pida explícitamente; lo que importa es el criterio de decisión. Cuando llegues al veredicto, insiste en la palabra 'inventario': el error más común es elegir el protocolo antes de saber qué dispositivos va a conectar el cliente.

Pregunta a la sala: '¿alguien ha entregado un site sin VLANs y con client isolation como única separación?' El debate que salga muestra exactamente por qué esto es un complemento, no un sustituto. No avances hasta dejar claro que activar esto no te exime de revisar el trunk en el switch.

No describas la captura: proyéctala y pregunta a la sala qué leen antes de explicarlo tú. Detente en el aviso de VLAN no propagada al switch, si aparece en la instalación real: es el error más frecuente en primeras entregas y vale más que cualquier explicación teórica. Si el panel de tu versión muestra la ruta de otra manera que la del esqueleto, corrígela aquí antes de exponer.

Antes de mostrar las tarjetas, pregunta a la sala: '¿Alguno ha tenido un cliente que dice que el WiFi no funciona y resulta que sí se conecta pero no tiene internet?' Es casi siempre uno de estos tres casos. Detente en la tarjeta 1 y dibuja en pizarra o comparte pantalla el diagrama trunk/access para que quede claro qué es tagged y qué es untagged; es el concepto que más participantes arrastran mal desde instalaciones anteriores. En la tarjeta 3, señala dónde está el perfil de radio en la interfaz del controlador para que lo localicen antes de seguir.

No leas la lámina. Di en voz alta qué van a conseguir al terminar: un cliente puede tener WiFi de empleados y WiFi de visitas sin que se vean entre sí, y eso lo acaban de construir ellos. Antes de que empiecen, pregunta a la sala: '¿alguien ya tiene un cliente que hoy resuelve esto con dos routers separados?' Si hay manos, pídeles que lo cuenten en 20 segundos, porque ese es exactamente el problema que este lab resuelve de forma limpia. Da el tiempo que necesiten; este laboratorio es el núcleo del bloque y no hay que comprimirlo.

Antes de empezar el paso A, pregunta a la sala qué IDs de VLAN han elegido: si dos participantes han elegido el mismo, es el momento de hablar sobre planificación de esquemas de VLAN con el cliente. En el paso C, si alguien obtiene respuesta al ping entre VLANs, detente y usa ese caso como ejemplo de depuración en vivo: vale más que cualquier escenario preparado. Recuerda mencionar que el controlador Omada no hace routing entre VLANs por sí solo; necesita un router o switch L3 (capa 3) configurado correctamente aguas arriba.

Pide a la sala que levanten la mano si ya verificaron el aislamiento con un ping real entre VLANs, no solo revisando la configuración en pantalla. Si pocos lo hicieron, dedica dos minutos aquí antes de pasar: es el error más común en entregas que luego generan tickets. Si el tiempo aprieta, señala que el bloque 6 arranca precisamente con ese paso de validación.

Deja la encuesta abierta 60-90 segundos. Mientras se vota, no avances: ese silencio hace que la gente piense de verdad en su proyecto actual, no en el abstracto. Cuando cierres la votación, lee los porcentajes en voz alta y di explícitamente cuál vas a usar como caso base en la siguiente sección. Si la opción D tiene peso significativo, señálalo: es el escenario donde el integrador tiene que hacer trabajo de consultoría antes de tocar el controlador, y eso vale la pena nombrarlo. Si alguien escribe en el chat con la opción E, pídele que lo describa en una línea: puede ser el ejemplo más útil de la sesión.

Marca el cambio de ritmo: los bloques anteriores eran de construcción, este es de cierre profesional. Pregunta a la sala cuántos tienen hoy algún protocolo de entrega formal con el cliente, o si la entrega es simplemente 'ya funciona'. Esa respuesta va a definir cuánto les aporta este bloque. No arranques hasta tener silencio; este separador debe sentirse como un punto y aparte real.

Antes de mostrar la ruta, pregunta a la sala: ¿alguno entrega hoy algo más que un 'ya funciona' de palabra? El silencio o las risas abren el argumento sin que tengas que forzarlo. En el paso 3, insiste en que el documento de credenciales no es opcional aunque el cliente 'lo tenga todo en la cabeza': ese cliente llama en seis meses cuando cambia de empleado. En el paso 5, si alguien pregunta por la forma del acta, di que en el laboratorio siguiente van a rellenar una plantilla real; no te extiendas aquí.

No leas las tarjetas. Pregunta a la sala: '¿Alguno ha entregado un sitio y recibido una llamada al día siguiente porque algo no funcionaba?' Deja que respondan. Luego pregunta cuál de estos tres puntos habría atrapado ese fallo. El objetivo es que conecten la comprobación con un dolor real suyo, no con una buena práctica abstracta. Si nadie responde, cuenta tú un caso genérico de fallo de aislamiento de VLAN en entrega: es el más común y el más embarazoso.

Antes de mostrar el diagrama, pregunta a la sala: '¿Cuál es el primer paso que hacéis normalmente al validar?' Escucha dos o tres respuestas. Lo habitual es que empiecen por WiFi o por Internet, saltando la física y la adopción. Usa eso como contraste para explicar por qué el orden importa. Insiste en el punto 4: la prueba por VLAN separada es el error que más se omite y el que más incidentes genera en campo. Si el tiempo aprieta, no cortes el punto 6: entregar un sitio sin alertas configuradas es uno de los argumentos más fáciles de usar para justificar una segunda visita no cobrada.

No leas las tarjetas. Toma cada una como un punto de parada: pregunta a la sala cuál de las tres suelen saltarse y por qué. La respuesta habitual es la segunda; si la dan, pregunta cómo saben entonces que el perfil está activo en el AP y no solo guardado. Ahí está el aprendizaje real de esta lámina. Reserva el cierre para decirlo en voz alta con pausa: es el marco mental con el que quieres que salgan.

No leas la lista en voz alta: pide a alguien de la sala que la lea y que diga cuál resolvería primero y por qué. Eso revela si el criterio de prioridad está claro. Antes de avanzar, pregunta: ¿alguien ha entregado un sitio con alertas activas porque el cliente tenía prisa? Que cuenten qué pasó. Si el controlador está levantado durante el workshop, navega en directo hasta el panel de alertas para que vean la ruta real.

Pregunta a la sala: ¿cuántos entregan algún documento escrito cuando terminan una instalación? Deja que respondan antes de avanzar. El objetivo no es avergonzar a nadie, sino calibrar desde dónde viene el grupo. Haz énfasis en la columna 'No pertenece aquí': es donde más errores se cometen. Las credenciales de redes internas en el informe de entrega son un riesgo de seguridad real. Si el grupo trabaja con PYME pequeñas, es probable que nadie les haya pedido nunca un informe formal. Aquí el argumento no es 'buenas prácticas' sino protección propia: si seis meses después el cliente dice que algo nunca se configuró, tú tienes el documento que lo demuestra.

Muestra la pantalla de Backup en vivo si el entorno de demo está activo. Pregunta a la sala: ¿alguien tiene ya un proceso documentado de entrega que incluya este archivo? Si nadie lo tiene, es el momento de fijar ese hábito como estándar de su flujo. Recuerda mencionar que este mismo .cfg sirve para restaurar o clonar el sitio, lo que ahorra tiempo en instalaciones repetidas para el mismo tipo de cliente.

No avances hasta tener la captura real: esta lámina es la que los participantes van a comparar con su propia pantalla en vivo. Si el panel de alguien muestra algo en rojo, detente ahí, es el mejor momento de diagnóstico del workshop. Pregunta a la sala antes de pasar: '¿Alguien tiene algo que no esté en verde?' Eso vale más que cualquier explicación teórica.

Pregunta a la sala: ¿alguien tiene por escrito lo que el cliente puede o no puede tocar? Normalmente nadie. Ese silencio solo hace falta dejarlo respirar. No des la respuesta tú: que ellos lo digan. Si el grupo trabaja con clientes PYME, menciona que el perfil que más llama no es el que menos sabe, sino el que sabe lo justo para entrar al panel y tocar algo. La tarjeta 2 va directamente a ese caso.

Pregunta a la sala: ¿alguien ha tenido que retomar un sitio de otro técnico sin documentación? Deja que cuenten un minuto. Eso establece el coste real de no documentar mejor que cualquier argumento tuyo. Recuerda mencionar que el gestor de contraseñas no es opcional si el integrador trabaja en equipo: una contraseña en un PDF es una vulnerabilidad. El diagrama es intencionadamente genérico; si los participantes usan alguna plantilla interna de su empresa, este es el momento de contrastarla con esta estructura y ver qué falta.

No leas las tarjetas en voz alta: deja que la sala las lea sola durante diez segundos y luego pregunta si alguien ha tenido un conflicto con un cliente por alguno de estos tres puntos sin tener nada firmado. Es casi seguro que alguien lo ha vivido. Ese relato vale más que cualquier explicación tuya. Si nadie habla, cuenta tú el escenario de las contraseñas cambiadas: es el más frecuente y el más evitable. El cierre de la lámina lo dices mirando a la sala, no leyéndolo de la pantalla.

Antes de mostrar la lámina, pregunta a la sala: ¿alguno entrega actualmente algún documento firmado al terminar una instalación? La respuesta habitual es que no, o que entregan un correo informal. Ese contraste es el que da peso a lo que viene. No leas las secciones en voz alta una por una: señala la de VLANs y la de credenciales, que son las dos que más se omiten, y deja que el resto lo lean ellos. Reserva un momento para que rellenen mentalmente si su última instalación habría pasado este checklist.

Antes de mostrar la tabla, pregunta a la sala: '¿Alguna vez habéis dado por cerrada una instalación y recibido una llamada al día siguiente porque el cliente no podía entrar al controlador?' Deja que respondan. Eso abre exactamente el problema que resuelve la columna derecha. Insiste en que la columna 'tú ya verificaste' no es para el cliente: es tu red de seguridad. Si algo falla en la demo del cliente y tú ya lo verificaste, el problema está en otro sitio y lo puedes acotar rápido. En el punto de documentación: recuerda que el controlador en la nube puede recuperarse si pierdes acceso, pero las contraseñas de los dispositivos AP y switches no están en la nube. Si no las documentaste, son irrecuperables sin un reset de fábrica. Ese detalle suele sorprender. Cierra la lámina dejando claro que la siguiente conversación con el cliente debería ser sobre soporte post-entrega, no sobre lo que faltó configurar.

Pregunta a la sala: ¿cuántos de vosotros habéis entregado alguna vez la cuenta de admin porque era lo más rápido? Deja que respondan, no juzgues. Ese es el hábito que queremos cambiar hoy. Recuerda mencionar que este paso es también tu protección legal: si el cliente tiene Viewer y algo cambia en la red, queda claro quién tenía permisos para tocar qué.

No empieces todavía. Antes de lanzar la práctica, pregunta a la sala: '¿Alguien tiene algún dispositivo sin adoptar o alguna VLAN que no le haya quedado clara?' Resuelve esos flecos en voz alta para que todos los escuchen. La validación tiene dos partes que conviene separar: primero la técnica (conectividad, VLANs, clientes asociados) y luego la documental (capturas, exportación de configuración, informe). Avisa que en la parte documental cada uno puede adaptar el formato a lo que ya usa con sus clientes, no hay un único modelo correcto.

Pide a los participantes que abran su sitio del laboratorio ahora mismo y ejecuten los pasos A, B y C en vivo. No sigas hasta que todos tengan el informe exportado en pantalla. Si alguien tiene un dispositivo en estado distinto de 'Conectado', detente con él y úsalo como caso real para el grupo: es más valioso que cualquier ejemplo preparado. Pregunta al final quién encontró algo que no esperaba en el informe.

Antes de cerrar, pregunta a la sala: ¿alguien tiene ya un proyecto en curso donde podría aplicar esto la semana que viene? Si alguien levanta la mano, dedícale 60 segundos a su caso concreto; eso vale más que cualquier resumen. Si nadie lo tiene, nombra tú un escenario típico de PYME y deja la pregunta abierta para el chat o el foro post-sesión. No repases los puntos del bloque: ya los vieron. Usa este cierre para que salgan con una acción clara, no con una sensación de repaso.

No leas las láminas anteriores ni hagas resumen. Este momento es para que los participantes lo procesen, no para que tú lo repitas. Puedes hacer silencio tres segundos antes de hablar. Pregunta a la sala: '¿Alguien tiene ya un cliente en mente donde aplicar esto?' Si alguien responde, deja que lo cuente en voz alta: cierra mejor que cualquier frase tuya. Si nadie responde, no fuerces: despide con la línea de cierre y deja el contacto visible en pantalla.