Las simulaciones te permiten validar procedimientos Fin, generar confianza en tu automatización y detectar problemas antes de que afecten a tus clientes. Al modelar conversaciones completas, las simulaciones ayudan a tu equipo a manejar escenarios complejos o de alto volumen, como cancelaciones y reembolsos, con certeza.

Diseñadas para reemplazar las comprobaciones manuales que consumen tiempo, las simulaciones te ayudan a identificar problemas o cambios graduales en el comportamiento de Fin a medida que evoluciona la lógica de tu negocio.

Accediendo a las simulaciones

Las simulaciones se encuentran dentro del panel de pruebas de un Procedimiento. Para acceder a ellas:

Abre el Procedimiento que deseas probar.
Haz clic en Test en la esquina superior derecha del lienzo.
Selecciona la pestaña Simulations en el panel derecho

Nota: Acceder a Simulations requiere el permiso "Can manage workspace data". Si el botón Simulations no responde, verifica que este permiso esté habilitado para tu rol en Configuración > Workspace > Teammates.

Las simulaciones omiten la coincidencia de intenciones. A diferencia de Preview o conversaciones en vivo, las simulaciones no verifican tus instrucciones de 'When to use this Procedure', asumen que el Procedimiento ya se ha activado y lo ejecutan directamente. Esto hace que las simulaciones sean ideales para probar la lógica de ejecución de forma aislada.

Importante:

Preview muestra la experiencia completa para el cliente; usarlo mientras tu procedimiento está activo puede exponer mensajes a clientes reales.
Simulations ejecutan el procedimiento en segundo plano sin salida visible para el cliente, siendo la forma más segura de validar la lógica antes de publicar. Usa Preview para revisiones rápidas; usa Simulations antes de cada publicación.

Creando una simulación

Puedes crear una simulación de dos maneras: usando sugerencias generadas por AI para un inicio rápido, o definiendo manualmente el escenario para tener control total.

Simulaciones generadas por AI: Úsalas para cubrir rápidamente escenarios comunes o esperados de clientes basados en tus instrucciones. Fin AI genera pruebas "listas para usar" para ahorrarte tiempo.

Simulaciones manuales: Úsalas cuando necesites control preciso sobre datos, casos límite específicos o ramas particulares en tu lógica.

Simulaciones generadas por AI

Basado en tus instrucciones, Fin AI generará pruebas iniciales para ayudarte a crear rápidamente simulaciones "listas para usar".

Abre la pestaña Simulations en el panel derecho de tu Procedimiento.
Bajo Suggested for these instructions, revisa la lista de escenarios propuestos (por ejemplo, "Solicitud de cancelación completa").
Haz clic en el ícono de reproducción junto a una sugerencia para ejecutarla al instante.
Una vez creada o aceptada una simulación de las sugerencias, aparecerá en tu lista. Luego puedes hacer clic en Run all para ejecutar todas tus simulaciones guardadas a la vez.

Simulaciones creadas manualmente

También puedes construir una simulación desde cero para probar casos límite específicos basados en las instrucciones del Procedimiento.

En la pestaña Simulations, haz clic en + New.
Nombre de la simulación: Dale un título claro a tu simulación.
Simular como: Elige un usuario o marca específica para probar la personalización. Puedes seleccionar de una lista desplegable de usuarios reales en tu workspace.
Mensaje inicial del cliente: Ingresa el primer mensaje que envía el cliente (por ejemplo, "Necesito ayuda con mi pedido"). También puedes adjuntar una imagen, como una captura de pantalla de un error, para probar cómo Fin maneja el contexto visual.
Detalles adicionales: Proporciona orientación sobre la situación del cliente o acciones específicas que haya tomado.

Selecciona un canal

Las simulaciones te permiten seleccionar el canal que Fin usará para esta simulación, para que puedas probar cómo se comporta Fin. Usa el menú desplegable de canales para cambiar entre Messenger y Email antes de ejecutar tu simulación.

Nota: Fin se comporta de manera diferente según el canal. En Email, Fin agrega múltiples piezas de información en una sola respuesta en lugar de enviar varios mensajes. La orientación y el contenido también pueden configurarse por canal; por ejemplo, las respuestas por Email pueden usar un tono más formal o incluir una introducción específica.

Definir datos disponibles

La sección Customer data available to Fin te permite definir los datos a los que Fin tiene acceso durante la prueba. Esto asegura que estés probando con valores de datos precisos en lugar de depender de descripciones vagas.

Hora de la simulación: Usa esto para definir "cuándo" ocurre el escenario. Establecer una fecha y hora específicas te permite probar lógica sensible al tiempo, como verificar si un cliente está dentro de una ventana de reembolso de 30 días.
Atributos y conectores de datos: Esta sección se llena automáticamente con los atributos referenciados en tu Procedimiento. Actualiza estos valores (por ejemplo, establece People.Plan en "Pro") para probar diferentes resultados de ramificación.

Nota: Para asegurar que tu simulación se ejecute con precisión, coloca los datos según cuándo Fin debería "saber" la información:

Usar atributos: Si Fin debe conocer la información al inicio de la conversación (por ejemplo, el Plan actual o la fecha de registro del cliente).
Usar detalles adicionales: Si la información debe ser proporcionada por el cliente durante la conversación (por ejemplo, el cliente proporciona su "Order ID" en una respuesta posterior). Esto te permite probar si Fin captura y almacena correctamente esos datos en un atributo.

Nota: Los conectores de datos no usan datos de usuarios en vivo en simulaciones. En lugar de llamar a tu sistema externo, Fin usa los valores de prueba que defines en la sección Customer data available to Fin. Asegúrate de haber completado los campos del conector de datos con los valores que quieres que Fin use durante la prueba; de lo contrario, el conector devolverá resultados vacíos.

Evaluar el comportamiento de Fin

Define los criterios que deben cumplirse para que la prueba sea exitosa. Haz clic en + Add criteria y selecciona:

Respuesta de Fin: Especifica lo que Fin debe (o no debe) decir durante la conversación.
Atributos: Verifica si un atributo fue establecido, no fue establecido, fue igual o no fue igual a un valor específico.
Conector de datos: Verifica si un conector se activó, no se activó o se activó exactamente X veces.
Resultado de la instrucción: Verifica si la conversación llegó a una conclusión específica, como finalizar, ser transferida a un compañero o a otros resultados como cambiar a un Procedimiento diferente.

Una vez configurado, haz clic en Guardar.

Nota: Al hacer clic en Guardar, Fin usa AI para revisar tu formulario de simulación. Si las instrucciones no son claras o los criterios de éxito son inconsistentes, verás recomendaciones para mejorar la prueba y obtener resultados más precisos.

Mejores prácticas para la cobertura de simulación

Para aprovechar al máximo las simulaciones, estructura tu suite de pruebas alrededor de estos principios:

Prueba una rama por simulación. Si tu Procedure tiene Conditions o subprocedimientos con múltiples caminos, crea una simulación separada para cada rama. Esto construye una red de seguridad para regresiones: si una edición futura rompe un camino específico, lo detectarás de inmediato.
Cubre tanto los caminos de éxito como de fallo para los Data Connectors. Ejecuta una simulación donde tu conector devuelve datos válidos y otra donde no devuelve nada o falla. Esto verifica que tu lógica de respaldo (por ejemplo, un paso @Condition que maneja una respuesta vacía) funcione correctamente.
Ejecuta todas las simulaciones antes de publicar cambios. Después de editar un Procedure, haz clic en Run all para volver a ejecutar toda tu suite antes de ponerla en producción. Cualquier simulación que falle por primera vez indica una regresión introducida por tu edición.
Usa nombres descriptivos para las simulaciones. Nombra cada simulación según el escenario que representa (por ejemplo, "Reembolso completo — dentro de 30 días" o "Cancelación — no se encontró pedido"). Esto facilita identificar qué prueba cubre qué camino al revisar los resultados.

Estrategia de pruebas: camino feliz, camino de riesgo y casos límite

Una suite de simulación bien equilibrada cubre tres tipos de escenarios. Juntos, te dan confianza de que tu Procedure funciona correctamente en condiciones normales, maneja fallos con gracia y no se rompe cuando los clientes se comportan de manera inesperada.

Camino feliz
El camino feliz representa el flujo ideal e ininterrumpido: un cliente que proporciona exactamente la información correcta y cumple todas las condiciones para que Fin complete el Procedure con éxito. Siempre comienza aquí. Si el camino feliz falla, depurar caminos más complejos se vuelve mucho más difícil.
Ejemplo: Un cliente solicita un reembolso dentro del plazo de 30 días, tiene un ID de pedido válido y el Data Connector devuelve los detalles de su pedido. Fin procesa el reembolso y lo confirma en una sola pasada.
Camino de riesgo
Los caminos de riesgo prueban los escenarios más propensos a fallar en producción, típicamente donde faltan datos externos, no se cumplen las condiciones o debe activarse una rama de respaldo. Estas son las pruebas que protegen a tus clientes de recibir respuestas incorrectas o incompletas.
Ejemplos: El Data Connector no devuelve ningún pedido (prueba que Fin pida al cliente su ID de pedido). El cliente está fuera del plazo de reembolso (prueba que Fin comunique la política correcta y ofrezca la transferencia adecuada). Un atributo está vacío cuando un paso Condition lo evalúa (prueba que la ruta de respaldo de Fin se active correctamente).
Casos límite
Los casos límite cubren entradas inusuales o en condiciones límite que son técnicamente válidas pero poco comunes. Estas pruebas son especialmente importantes para Procedures con lógica sensible al tiempo, umbrales numéricos o entradas de texto libre del cliente.
Ejemplos: Un cliente solicita un reembolso exactamente en el día 30 (el límite del plazo). Un cliente envía un mensaje inicial ambiguo que podría coincidir con múltiples intenciones. Un cliente proporciona su ID de pedido en un formato inesperado o incluye texto adicional junto a él.

Consejo: Usa nombres descriptivos para las simulaciones que indiquen a qué categoría pertenece cada prueba — por ejemplo, "Reembolso — camino feliz", "Reembolso — no se encontró pedido (riesgo)" o "Reembolso — día límite 30 (caso límite)". Esto facilita detectar brechas en tu cobertura de un vistazo.

Ejecución y revisión de resultados

Una vez que ejecutas una prueba, aparece en el panel Tests en el lado derecho con un indicador de estado:

En ejecución: La prueba se está ejecutando activamente.
Aprobada: La prueba se ejecutó y cumplió con todos los criterios de éxito definidos.
Fallida: La prueba se ejecutó pero no cumplió con los criterios de éxito definidos.
En cola: La prueba ha sido iniciada pero está esperando a que termine la simulación anterior antes de ejecutarse.

Para investigar un resultado, haz clic en See conversation. Esto abre la transcripción completa del ida y vuelta entre el cliente simulado y Fin, facilitando ver exactamente cómo se desarrolló el flujo y por qué una prueba pasó o falló.

Depuración de una simulación fallida

Cuando una simulación está marcada como Failed, la transcripción disponible a través de See conversation contiene todo lo que necesitas para identificar la causa raíz. Aquí te explicamos cómo leerla eficazmente:

Pensamientos de Fin
En cada paso de la conversación, expande el razonamiento de Fin para ver cómo interpretó el mensaje del cliente, qué paso del Procedure estaba ejecutando y qué decisión tomó. Si Fin tomó un camino inesperado, sus pensamientos usualmente te mostrarán exactamente dónde su interpretación divergió de tu intención. Busca pasos donde la interpretación de un atributo o condición por parte de Fin no coincida con lo que esperabas.
Eventos de conversación
Los eventos de conversación aparecen en línea en la transcripción y muestran acciones de bajo nivel como actualizaciones de atributos, llamadas a Data Connectors y activadores de transferencia. Úsalos para verificar que los conectores correctos se activaron en el momento adecuado y que los atributos se establecieron con los valores esperados antes de cada paso de ramificación.
Localización de la falla
Contrasta lo que ves en los pensamientos de Fin y los eventos de conversación con tus criterios de éxito definidos. Un patrón común es que un paso Condition evalúe la rama equivocada, típicamente porque un atributo estaba vacío o tenía un valor inesperado. Revisa tu configuración de Customer data available to Fin para asegurarte de que todos los atributos requeridos se completaron antes de que se ejecutara la simulación.

Consejo: Después de identificar la causa, ajusta tu Procedure o configuración de simulación y haz clic en Run en la misma simulación para volver a probar inmediatamente. No necesitas crear una nueva simulación: la existente conserva su configuración.

Límites de uso de simulación

Hay un límite en la cantidad de simulaciones que puedes ejecutar cada mes. Este límite se aplica a nivel de espacio de trabajo y se restablece el primer día de cada mes calendario.

Cada espacio de trabajo recibe una asignación mensual de ejecuciones de Simulation. La asignación se basa en el segmento de volumen de conversación de tu espacio de trabajo, con clientes más grandes recibiendo asignaciones mayores.

La asignación de Simulation se basa en el volumen de conversación de tu espacio de trabajo en Intercom.

Asignamos tu espacio de trabajo a un segmento usando el número de conversaciones del último mes calendario.
Tu segmento se reevalúa mensualmente y tu asignación reflejará el volumen de conversación más reciente de tu mes.
Si tu volumen de conversación aumenta o disminuye, tu asignación de Simulation puede cambiar en el siguiente ciclo mensual.

Segmento de volumen de conversación	Límite de Simulation por mes
Menos de 1K	50
1K–15K	200
15K–100K	350
100K–1M	1000
1M+	2500

Monitoreando tu uso

Para ayudarte a gestionar tus pruebas, Fin proporciona indicadores visuales dentro de la pestaña Simulations:

Advertencia de uso

Cuando tu espacio de trabajo alcance el 80% de su límite mensual, aparecerá un banner amarillo de advertencia. Muestra tu uso actual (por ejemplo, "85/100") y te recuerda cuándo se restablecerá el límite.

Límite alcanzado

Una vez que llegues al 100% de tu límite mensual, aparecerá un mensaje de error rojo. No podrás ejecutar más simulaciones hasta el inicio del próximo mes.

Nota: Si alcanzas tu límite, aún puedes revisar resultados y transcripciones de simulaciones anteriores haciendo clic en See conversation, pero los botones Run y Run all estarán deshabilitados.

Preguntas frecuentes

¿Las simulaciones interactúan con mis APIs en vivo o datos externos?

No. A diferencia de la herramienta Preview, las simulaciones no acceden a APIs reales ni a sistemas externos (como Shopify o Stripe). No es posible leer ni cambiar datos en una API externa durante una simulación. Esto garantiza que puedas probar la lógica de forma segura sin afectar datos reales.

¿Por qué usar Simulations en lugar de pruebas manuales?

Las Simulations te permiten validar Procedures a gran escala y asegurar que Fin funcione de manera confiable en escenarios complejos y de alto riesgo, a diferencia de las pruebas manuales, que son mejores para revisiones rápidas o de configuración. Ejecutar Simulations antes de cada lanzamiento te ayuda a detectar comportamientos inesperados temprano.

¿Qué pasa si una Simulation falla?

Una Simulation fallida puede revisarse completamente: abre la conversación simulada para entender por qué Fin no se comportó como se esperaba, ajusta tu Procedure y vuelve a ejecutar la Simulation sin afectar a los clientes.

¿Por qué mi simulation está marcada como "Failed" aunque Fin resolvió el problema con éxito?

Una Simulation marcada como "Failed" a pesar de que Fin resolvió el problema generalmente significa que tus Criterios de Éxito son demasiado rígidos. Por ejemplo, si requieres que Fin "Ask for an Order ID", pero Fin es lo suficientemente inteligente para encontrar el ID automáticamente, la prueba fallará porque Fin omitió la pregunta. Actualiza tus criterios para enfocarte en el resultado final (por ejemplo, "Procedure finished") en lugar de exigir pasos intermedios específicos.

Fin se detiene a mitad de la simulación. ¿Por qué se queda atascado?

Fin a menudo se detiene si encuentra un "dead end" en tus instrucciones, como verificar una variable que resulta estar vacía (por ejemplo, People.signed_up). Si no le has indicado a Fin qué hacer cuando faltan datos, se detendrá. Asegúrate de que tus instrucciones tengan un plan de "fallback", como: "Verifica si la variable tiene un valor. Si está vacía, pregunta al cliente por la fecha."

¿Dónde debo ingresar datos de prueba como "Sign up dates" o "Order history"?

Los datos de prueba como las fechas de registro o el historial de pedidos deben ingresarse en la sección Customer data available to Fin de la configuración de la simulación, no en el mensaje inicial del cliente ni en los campos de Detalles adicionales, ya que Fin podría no detectarlos. Ingresa valores exactos (por ejemplo, 2024-06-01) en los Atributos o Variables específicas que estás probando.

Mi herramienta funciona en la vida real, pero falla en la simulación. ¿Por qué?

Las simulaciones no obtienen datos reales de sistemas externos, por lo que tu Data Connector no devolverá resultados en vivo como en una conversación real. Si tu conector funciona en conversaciones en vivo pero falla en simulación, probablemente sea porque no se definieron los valores esperados en la sección Customer data available to Fin. Agrega los datos que tu conector normalmente devolvería como valores de prueba allí y vuelve a ejecutar la simulación.

¿Las Simulations se facturan por separado de los Procedures?

Las Simulations están incluidas con los Procedures y no se facturan como un ítem separado. No incurrirás en cargos adicionales por ejecutar simulaciones.

¿Por qué debería probar mi Procedure por Email?

Probar tu Procedure por Email valida el comportamiento específico del canal que difiere de Messenger. En Email, Fin agrega múltiples piezas de información en un solo correo en lugar de enviar varios mensajes. La Guía y el Contenido también pueden dirigirse a canales específicos; por ejemplo, las respuestas por Email pueden configurarse para usar un tono más formal o incluir una introducción específica. Simular conversaciones por Email te permite validar este comportamiento y desplegar con confianza.

¿Por qué hay un límite en las ejecuciones de Simulation?

Cada ejecución de simulation requiere recursos para generar predicciones precisas de IA. Proporcionamos una asignación mensual para que puedas probar tus Procedures libremente en casos de uso estándar, evitando que un uso extremo genere costos descontrolados.

¿Puedo simular un sub-procedure de forma independiente?

No. Los sub-procedures no tienen su propio panel de simulación y no pueden ejecutarse de forma aislada. Para probar un sub-procedure, ejecuta una simulación en el Procedure principal y configura el escenario para que la ruta de ejecución llegue al sub-procedure, estableciendo el mensaje del cliente, atributos y detalles adicionales para activar la rama específica que lo llama.

Si tienes múltiples sub-procedures dentro del mismo padre, crea una simulación separada para cada uno, con cada simulación cubriendo el escenario que lleva a que se llame a ese sub-procedure.

Mi Data Connector devuelve resultados vacíos en la simulación. ¿Qué debo hacer?

Los resultados vacíos del Data Connector en una simulación suelen deberse a datos de prueba faltantes. Las simulaciones no obtienen datos en vivo de sistemas externos; debes definir los valores que tu Data Connector debe devolver en la sección Customer data available to Fin de la configuración de la simulación. Verifica que hayas completado los campos relevantes del Data Connector con los valores de prueba que quieres que Fin use.

Si estás probando intencionalmente la ruta 'connector returns nothing', este es un comportamiento esperado y exactamente lo que debes probar. Asegúrate de que tu Procedure tenga un paso de fallback @Condition que maneje respuestas vacías del conector:

Si el conector devuelve vacío incluso para un usuario con datos reales, verifica que tu contacto de prueba tenga un external_id válido que coincida con el identificador de cliente de tu sistema externo.

Ejecutar simulaciones para procedimientos Fin