Es el checklist fundamental de lo que hay que probar manualmente en el simulador antes de publicar un flujo, junto con la guía de cómo interpretar y arreglar lo que falla.
🎯 Por qué no alcanza con el "camino feliz"
Que el flujo funcione cuando el cliente responde exactamente lo esperado no dice mucho. Los problemas reales aparecen cuando el usuario se sale del guion, cambia de tema de forma abrupta o responde algo ambiguo (lo cual representa la gran mayoría de las conversaciones reales).
⚠️ Atención: Las validaciones automáticas del sistema solo cubren lo estructural. Que el flujo compile correctamente no significa que el nodo se comporte bien a nivel conversacional o de negocio.
✅ Checklist antes de publicar
Asegúrate de marcar todos estos puntos en el simulador antes de presionar "Publicar".
🗣️ 1. Conversación
Camino feliz: El escenario típico, de punta a punta, termina exactamente donde corresponde.
Pregunta ambigua: El nodo ofrece la interpretación más probable junto con las alternativas, en el mismo mensaje.
Cambio de tema a mitad de camino: El nodo transfiere al nodo correcto o retoma el hilo original sin perder lo capturado previamente.
Respuesta contradictoria: El cliente se corrige a sí mismo. El nodo debe actualizar el dato y confirmar el cambio.
Consulta fuera de alcance: El nodo declina la solicitud de forma amable (sin inventar información) y deriva si corresponde.
🚪 2. Cada salida por separado
(Esto es lo que más se saltea en las pruebas y lo que más caro sale en producción).
Activación directa: Por cada Nodo Fin, prueba un caso exacto que debería activarlo.
Falso positivo: Por cada Nodo Fin, prueba un caso que está muy cerca pero que NO debería activarlo.
Escalamiento a humano: Verifica que se dispara solo cuando corresponde y no antes.
Sin respuesta (Inactividad): Verifica el comportamiento del flujo cuando el cliente deja de contestar repentinamente.
💡 Tip de Diagnóstico: Si una salida se activa cuando no debería, la condición está mal escrita (muy amplia). Si no se activa cuando debería, falta refuerzo en el prompt o la condición es demasiado estricta.
📝 3. Datos y clasificación
Campos obligatorios: Se piden en el momento exacto configurado y el nodo no avanza sin obtenerlos.
Campos de captura posterior: Se registran silenciosamente si el cliente los menciona, sin que el nodo los pregunte.
Cambios de etapa: La conversación se clasifica en la etapa correcta del embudo según lo conversado.
Tipificaciones y etiquetas: Se aplican correctamente en el sistema cuando la condición se cumple.
🔌 4. Herramientas y Formatos
Invocación correcta: Se invoca la herramienta adecuada en el momento correcto.
Parámetros exactos: Revisa en el panel de trazas que los argumentos enviados a la API/Code Tool sean los correctos.
Comportamiento ante fallo: Simula un error de herramienta y verifica que el nodo NO le muestre el error de código crudo al cliente.
Formatos enriquecidos: Los botones, listas y carruseles se envían cuando corresponde (no en cualquier momento) y no exceden los límites del canal.
Interactividad: Los botones y listas son 100% funcionales y hacen avanzar el flujo al tocarlos.
🛠️ Qué hacer con lo que falla (Troubleshooting)
Síntoma en el simulador | Causa probable | Dónde mirar / Qué hacer |
La conversación se transfiere al nodo equivocado | Condiciones de rama que se solapan (ambigüedad). | Revisa el aviso de similitud (Sección 3.4). |
El nodo repite una pregunta que ya estaba respondida | Falta la instrucción de verificar los campos capturados antes de preguntar. | Agrega la verificación explícita al prompt (Sección 3.5). |
El nodo cierra por la salida operativa equivocada | Ramas de finalización muy ambiguas entre sí. | Consolida Nodos Fin o diferencia mejor los textos (Sección 3.3). |
El nodo responde bien pero SIN consultar la base de conocimiento | Puede estar usando el conocimiento general del modelo (que suele estar desactualizado). | Revisa el log de consultas del turno (Sección 4.1). |
La tabla dinámica devuelve resultados inesperados | Falta un filtro clave en el prompt de búsqueda. | Revisa el código SQL generado en las trazas (Sección 4.2). |
El nodo envía varios mensajes seguidos | Falta establecer el límite de mensajería en el prompt. | Revisa las reglas de estructuración (Secciones 10.4 y 10.5). |
El formato enriquecido aparece en momentos raros | Dejaste la descripción de ejecución por defecto sin ajustar a tu caso. | Precisa cuándo usarlo desde la configuración (Sección 6.1). |
📈 Cuándo el simulador no alcanza
El simulador es excelente, pero prueba de a un caso por vez, y depende enteramente de que a ti (el creador) se te ocurran todos los escenarios posibles.
Cuando hace falta medir con criterios objetivos sobre muchas conversaciones —o sobre tráfico real masivo— corresponde utilizar una evaluación multi-turno (ver sección 7.4).
💡 Recomendación práctica: Corre una evaluación sobre el tráfico real durante las primeras dos semanas de cada flujo nuevo en producción. Es exactamente en ese período cuando aparecen todos los casos extraños y usos creativos que nadie del equipo anticipó.
¡Lanza tu agente con total confianza! 🚀
El testing riguroso separa a los bots frustrantes de las verdaderas Inteligencias Artificiales resolutivas. Al seguir este checklist, probar los casos límite y monitorear el tráfico real en sus primeras semanas, garantizas una experiencia de usuario impecable y proteges las operaciones de tu negocio. ✅