Cuando un Procedimiento Fin no resuelve una conversación como se esperaba, puedes usar herramientas de inspección integradas para investigar la lógica de toma de decisiones de Fin. Usa esta guía para identificar dónde se desvió un flujo y cómo refinar tus instrucciones.

Lo que aprenderás

Depura fallos en Procedimientos usando los pensamientos de Fin y eventos de conversación.
Diagnostica problemas comunes como activadores incorrectos de Procedimientos, pasos fuera de secuencia y fallos en ramificaciones.
Soluciona errores de conectores de datos, incluyendo fallos de autenticación y datos faltantes.
Valida las correcciones antes de implementarlas usando Simulaciones.

Accediendo al depurador de conversaciones

Para entender por qué Fin tomó una acción específica, primero debes habilitar la visibilidad técnica dentro del hilo de conversación.

Abre la conversación específica en el Inbox.
Haz clic en el icono de tres puntos en la parte superior derecha del encabezado de la conversación.
Selecciona Mostrar eventos de conversación.

Consejo: Usa el atajo de teclado ⌘ + E (Mac) o Ctrl + Shift + E (Windows) para alternar esta vista.

Inspeccionando los "pensamientos de Fin"

Una vez visibles los eventos de conversación, puedes ver el razonamiento detrás de cada paso que Fin tomó durante un Procedimiento. Para rastrear el proceso de toma de decisiones de Fin, localiza los eventos pensamientos de Fin en la línea de tiempo de la conversación. Estos eventos resumen el razonamiento de Fin antes de enviar un mensaje o realizar una acción.

Para más detalle granular, haz clic en Fin Thoughts y luego en Ver más. Esto revela:

El paso actual: El paso específico del Procedimiento que Fin estaba ejecutando.
Interpretación de intención: Cómo Fin entendió la solicitud del cliente.
Ruta lógica: Por qué Fin decidió saltar un paso, revisar uno anterior o moverse a una rama específica.

Nota: Este artículo cubre solución de problemas solo para Procedimientos Fin. La línea de tiempo y el depurador de "pensamientos de Fin" solo están disponibles cuando se activó un Procedimiento. Si Fin dio una respuesta inesperada en una conversación estándar, estas herramientas no estarán presentes en los eventos de conversación.

Fallos comunes en Procedimientos

Si Fin no funciona como se espera, generalmente se debe a cómo se redactan las instrucciones o cómo se ramifica la lógica.

El Procedimiento no se activa en absoluto

Antes de revisar los fallos numerados a continuación, repasa primero estos conceptos básicos:

Verifica que el procedimiento esté publicado: Los procedimientos en borrador no se activan para los clientes. Confirma que el estado esté en Publicado en el editor.
Verifica que Fin esté desplegado: Si Fin no está habilitado en la sección Simply Deploy, o el paso "Let Fin handle" no está activo en tu workflow, Fin no ejecutará ningún procedimiento.
Verifica la segmentación de audiencia: Un error común es dirigir a Users cuando el cliente es un Lead (o viceversa). En la sección "When to use this procedure", haz clic en el botón de audiencia y verifica que el tipo de audiencia y canal sean correctos.
Verifica workflows de mayor prioridad: Los workflows activos se ejecutan antes de que Fin evalúe la intención del procedimiento. Revisa tus workflows para asegurarte de que ninguno intercepte la conversación antes de que Fin pueda activar el procedimiento.
Revisa el alcance de los criterios de activación: Criterios demasiado restrictivos impiden que Fin coincida con mensajes válidos del cliente. Revisa la descripción de "When to use this procedure" y añade ejemplos positivos (mensajes que deberían activarlo) y negativos (mensajes que no deberían).
Verifica si hay una Guía o Regla de Escalación en competencia: Si el mensaje del cliente también coincide con una Guía o Regla de Escalación (Fin AI Agent > Train > Escalations), la escalación tiene prioridad — Fin pasa a un humano en lugar de activar el procedimiento, incluso cuando los criterios de activación del procedimiento son igual o mejor coincidencia. Revisa tus Guías y Reglas de Escalación para detectar solapamientos con el disparador del procedimiento (por ejemplo, ambos basados en el mismo código de error o frase), y añade ejemplos positivos y negativos a la Guía de Escalación igual que harías para un disparador de procedimiento, para que no compitan por el mismo mensaje.

Nota: Aunque Slack puede aparecer como canal seleccionable, actualmente no se soportan activadores de procedimiento para conversaciones en Slack.

Fin activa el Procedimiento incorrecto

Problema: Fin inicia un Procedimiento que no coincide con la solicitud del cliente.

Solución: Revisa tus instrucciones de "When to use this procedure". Usa ejemplos positivos y negativos para ayudar a Fin a distinguir entre intenciones similares. Si un nuevo procedimiento comparte criterios de activación con uno publicado, el publicado puede tener prioridad. Para aislar el nuevo procedimiento durante pruebas: excluye temporalmente a tu usuario de prueba del procedimiento existente ajustando sus criterios de audiencia, o restringe el disparador del nuevo procedimiento a una frase única que solo tú enviarías. Usa Fin's thoughts > Expand thoughts en el depurador de conversaciones para confirmar qué procedimiento se activó realmente.

Pasos fuera de secuencia

Problema: Fin omite un paso previo o avanza a una resolución prematuramente.

Solución: Revisa si hay ambigüedad en tus instrucciones en lenguaje natural. Si un paso depende de un dato específico, asegúrate de que la instrucción diga explícitamente: "Solo procede si se proporciona [dato]."

Fallos en la lógica de ramificación

Problema: Fin sigue la ruta "Else" cuando debería haber seguido la ruta "If".

Solución: Inspecciona las Condiciones. Si usas lenguaje natural para ramificar, intenta reformular para mayor claridad. Para lógica compleja (por ejemplo, cálculos de fechas), considera usar bloques de código Python para aplicar reglas estrictas y deterministas.

Contenido del Help Center tomando prioridad

Problema: Fin responde desde el Help Center en lugar de ejecutar el procedimiento, incluso cuando la intención del cliente coincide claramente con los criterios de activación del procedimiento.

Solución: Si Fin predetermina una respuesta del Help Center en lugar de ejecutar el procedimiento, hay dos enfoques según tu configuración. Prueba la Opción 1 primero; si el problema persiste, pasa a la Opción 2.

Opción 1: Habilitar cambio de Procedimiento
Agentic Switch es una configuración por procedimiento que permite a Fin cambiar automáticamente del procedimiento actual a otro procedimiento activo cuando detecta que la intención del cliente cambió a mitad de la conversación, en lugar de quedarse bloqueado en el procedimiento original o recurrir a una respuesta del Help Center. Cuando está habilitado:
- Fin revisa la conversación y todas las descripciones de activación de procedimientos activos para decidir cuándo cambiar mejoraría la experiencia del cliente.
- Si varios procedimientos podrían aplicar, Fin puede hacer una pregunta aclaratoria para seleccionar el mejor.
- Solo el procedimiento origen (del que Fin está cambiando fuera) necesita tener esta configuración activada.
- El comando @Switch aún puede usarse para cambiar manualmente.
Para habilitarlo: Fin AI Agent > Train > Procedures > Settings > Agentic Switch

Opción 2: Eliminar o actualizar el contenido conflictivo del Help Center
Si habilitar Agentic Switch no resuelve el problema, la solución más confiable es eliminar o actualizar el contenido del Help Center que Fin está mostrando en lugar de ejecutar el procedimiento. Fin usa por defecto las respuestas del Help Center cuando existe contenido relevante para un tema; por lo tanto, si un artículo cubre la misma intención que tu procedimiento, Fin puede responder directamente desde él en lugar de activar el procedimiento.

Para identificar el contenido conflictivo:
- Encuentra la conversación en tu Inbox y abre Fin's thoughts.
- Busca referencias a artículos del Help Center en la ruta de respuesta.
- Elimina el artículo conflictivo o actualízalo para dirigir a los clientes a contactar soporte, de modo que Fin redirija al procedimiento en su lugar.

Ejemplo: Una empresa tiene un procedimiento que maneja solicitudes de reembolso: recopila el número de pedido, verifica la elegibilidad y procesa el reembolso automáticamente. También tienen un artículo en el Help Center titulado "¿Cómo obtengo un reembolso?" que explica la política de reembolsos. Cuando un cliente escribe "Quisiera un reembolso", Fin encuentra el artículo del Help Center y responde con la explicación de la política en lugar de activar el procedimiento. En este caso, actualizar el artículo para decir algo como "Para solicitar un reembolso, inicia un chat y nuestro asistente te guiará" elimina la respuesta conflictiva y dirige a los clientes al procedimiento.

El procedimiento se detiene o sale antes de completarse

Problema: El procedimiento llega a un cierto paso y se detiene, o sale a un estado final sin completar todos los pasos esperados.

Solución: Esto suele ser causado por patrones de diseño que confunden la capacidad de Fin para rastrear en qué parte del procedimiento se encuentra. Revisa lo siguiente:

Declaraciones redundantes de "Proceder inmediatamente": Si varios pasos incluyen instrucciones como "proceder inmediatamente al siguiente paso", Fin puede reevaluar pasos ya completados en lugar de avanzar. Elimina estas declaraciones y deja que Fin avance naturalmente según el flujo.
Instrucciones para saltar pasos: Frases como "volver al paso 2" o "repetir el paso de verificación" pueden hacer que Fin se quede en un bucle entre pasos en lugar de avanzar. Diseña cada paso para que haya un camino claro hacia adelante.
Lógica de condiciones superpuestas: Si dos condiciones pueden evaluarse como verdaderas al mismo tiempo, Fin puede ramificarse de forma impredecible o detenerse. Asegúrate de que tus condiciones sean mutuamente excluyentes: solo una rama debe ser verdadera en cualquier momento.
Salidas de subprocedimientos sin continuación: Si un subprocedimiento termina pero el procedimiento principal no tiene una instrucción clara sobre qué hacer después, Fin puede tratar el fin del subprocedimiento como el fin de todo el flujo. En el paso que llama al subprocedimiento, añade una instrucción explícita: "Una vez que el subprocedimiento termine, continúa con [nombre del siguiente paso]."

Usa Fin's thoughts > See more en el depurador de conversaciones para identificar exactamente en qué paso estaba Fin cuando el procedimiento salió inesperadamente.

Error de tipo de atributo causa fallos al guardar

Problema: El procedimiento falla al guardar una respuesta en un atributo de conversación.

Solución: Verifica que el tipo de atributo coincida con el valor que el procedimiento intenta guardar. Si el procedimiento guarda una cadena (por ejemplo, una respuesta del cliente recogida durante la conversación), el atributo destino debe ser de tipo cadena. Usar un atributo de tipo lista con el mismo nombre causará fallos al guardar. Para solucionarlo, actualiza el procedimiento para referenciar el atributo correcto o ve a Settings > Data > Conversations para cambiar el tipo de atributo.

Problemas en móvil (iOS) con Procedures

En móvil (iOS), Procedures tienen requisitos adicionales:

Solo para Users: Procedures solo se activan para Users en móvil; no se ejecutarán para Leads o Visitors sin importar cómo esté configurada la audiencia en el procedimiento.
El canal iOS debe estar seleccionado: En la sección "Cuándo usar este procedimiento", iOS debe estar seleccionado como canal. El procedimiento no se activará en móvil si solo está marcado Web.
El procedimiento debe estar Publicado: Los procedimientos en borrador no se sirven a clientes móviles.
Verifica que Fin esté desplegado para iOS: Los procedimientos necesitan que Fin esté activo en el canal iOS. Confirma que Simple Deploy esté habilitado en Fin AI Agent > Deploy > Chat, o que haya un bloque activo Let Fin Handle en el workflow relevante dirigido a iOS.
Workflows de mayor prioridad: Un workflow que se ejecute para el mismo disparador de conversación en iOS puede interceptar la conversación antes de que Fin evalúe la intención del procedimiento. Revisa tus workflows activos para solapamientos en el canal iOS.

Solución de problemas con conectores de datos en Procedures

Esta sección cubre fallos específicos de conectores de datos que se ejecutan dentro de un Procedure. Si tu conector pasa pruebas independientes pero falla durante una ejecución en vivo del Procedure, comienza aquí.

El conector funciona en pruebas pero falla en un Procedure en vivo

Problema: El conector pasa pruebas independientes pero falla durante una ejecución en vivo.

Solución: Esto suele ser causado por una de las siguientes razones:

Credenciales: Guarda y publica de nuevo después de rotar una clave. Revisa si hay caracteres ocultos como espacios al final en los valores del token.
Permisos: Un cambio reciente de seguridad en tu sistema externo puede haber eliminado el acceso.
Lista blanca de IPs: Confirma que las IPs salientes de Intercom estén incluidas. Contacta a tu gerente de cuenta para los rangos actuales.

Importante: Si tu conector deja de funcionar sin cambios de tu parte, verifica si tu proveedor externo de API (por ejemplo, Shopify, Stripe) ha actualizado o eliminado un endpoint.

Errores de autorización 401 y 403

401 No autorizado: El token falta, está expirado o mal formado. Intercom reintenta automáticamente una vez. Revisa la pestaña Logs para confirmar si se intentó una actualización.
403 Prohibido: El token es válido pero no tiene permiso. Revisa los permisos en tu sistema externo.
Usuarios OAuth: Usa el botón Reauthenticate en lugar de eliminar y recrear el token.

El conector no parece activarse

Revisa los logs: Navega a Settings > Integrations > Data connectors > Logs. Si no hay entrada de log, probablemente se saltó el paso; revisa la lógica de la rama anterior.
Revisa eventos de conversación: Selecciona Logs de cualquier evento de error en el Inbox para detalles completos.

El conector devuelve datos pero Fin no los usa

Usa Fin's thoughts para ver cómo Fin interpretó la respuesta del conector.
Haz la instrucción del paso más explícita: "Usa @connector_name para responder esto—no uses contenido de knowledge base."
Verifica si la respuesta está vacía o nula; Fin puede recurrir a otras fuentes si no encuentra datos utilizables.
Fin llama a un conector por turno: Si tu procedimiento necesita hacer múltiples llamadas a conectores en secuencia, cada llamada debe ser un paso distinto. Fin procesa una llamada a herramienta por turno de conversación; no puede encadenar múltiples llamadas a conectores dentro de una sola instrucción de paso.

Importante: Fin solo puede procesar una llamada a conector por turno, así que si tu servidor MCP envía dos respuestas separadas por el mismo flujo SSE, Fin no podrá usar confiablemente la primera respuesta para construir su respuesta.

El conector no aparece en el editor de procedimientos

Problema: Tu conector de datos está publicado y configurado, pero no aparece cuando intentas agregarlo a un paso dentro del editor de procedimientos.

Solución: Realice estas comprobaciones en orden:

Confirme que el conector esté configurado en Vivo: Vaya a Settings > Integrations > Data connectors y verifique el estado del conector. Un conector en Draft no aparecerá en el editor de procedimientos.
Verifique que al menos una acción esté configurada: Un conector sin acciones definidas no aparecerá como opción en el editor de procedimientos, incluso si está en Vivo.
Verifique los permisos de su rol: Algunos roles pueden ver conectores en Settings pero no pueden acceder a ellos dentro del editor de procedimientos. Confirme que su rol tenga acceso a ambas áreas.
Actualice la página: El editor de procedimientos a veces necesita una actualización completa para reflejar conectores publicados recientemente. Use ⌘ + Shift + R (Mac) o Ctrl + Shift + R (Windows).
Contacte con Fin Support: Si nada de lo anterior lo resuelve, comuníquese con Fin Support con el nombre del conector y los detalles de su workspace. Algunas configuraciones de workspace requieren un paso manual para que un conector esté disponible dentro del editor de procedimientos.

El conector falla en modo de autoejecución

Problema: El data connector está configurado para ejecutarse automáticamente — sin solicitar al cliente — pero falla silenciosamente durante una conversación en vivo. Fin escala o da una respuesta inesperada, y no hay error visible en la conversación.

Solución: En modo de autoejecución, Fin no puede saltar un paso de conector fallido y continuar el procedimiento. Si el conector devuelve un error, Fin trata todo el paso como irresoluble y escala a un humano o vuelve a su comportamiento predeterminado.

Hay dos formas de manejar esto:

Modifique su API externa para devolver un valor de respaldo: En lugar de devolver un error cuando no hay datos disponibles (por ejemplo, un 404 cuando no se encuentra un pedido), configure su API para devolver un resultado vacío o predeterminado que Fin pueda usar. Esta es la solución más confiable porque Fin siempre recibe algo con lo que puede trabajar.
Agregue un paso de Condición después de la llamada al conector: Use la salida status_code del conector para ramificar a un mensaje amable o a una ruta de escalación controlada cuando el conector falle. Vea "Manejo avanzado de fallos con status_code" en este artículo para saber cómo configurarlo.

El conector devuelve 404 o no se escriben atributos de contacto a pesar de parecer que se ejecuta

Problema: El conector parece activarse — los registros muestran que se ejecutó — pero devuelve un error 404 y no se escriben atributos de contacto, aunque todos los conectores parecen estar configurados correctamente.

Solución: Esto casi siempre es causado por una píldora de atributo inválida en la URL de la solicitud. Uno de los parámetros de la URL se resuelve en un valor vacío en tiempo de ejecución, haciendo que la URL sea incorrecta.

La causa más común: un atributo fue escrito manualmente como {{Attribute Name}} en lugar de ser seleccionado desde el Inserter de Atributos. El editor convierte cualquier texto {{...}} en una píldora que parece un atributo válido — pero si el identificador no corresponde a un atributo real, se resuelve en vacío en tiempo de ejecución y la URL de la solicitud se vuelve inválida.

Para solucionarlo:

Abra el conector e inspeccione la URL de la solicitud y el cuerpo en busca de píldoras de atributo.
Elimine cualquier píldora que haya sido escrita manualmente y reemplácela seleccionando el atributo correcto desde el selector del Inserter de Atributos.
Si su URL requiere el ID de contacto de Intercom, seleccione Contact ID (user.id) del selector — no User ID (user_id). La API de Contacts espera el ID de contacto generado por Intercom (user.id), no el ID de usuario establecido externamente (user_id).

La salida del conector no llena atributos de conversación

Problema: Un paso de data connector se ejecuta y devuelve los datos esperados, pero el valor no aparece como atributo de conversación — y los pasos posteriores en el procedimiento no pueden acceder a él.

Solución: Los atributos de conversación se establecen al inicio de una conversación y no pueden actualizarse en tiempo real mientras se ejecuta un procedimiento. Un conector que se ejecuta dentro de un procedimiento no puede escribir un nuevo valor en un atributo de conversación a mitad de la conversación.

Lo que esto significa en la práctica:

Use la salida del conector directamente en pasos posteriores: Los datos que devuelve su conector están disponibles como salida de paso dentro del procedimiento. Refiérase a ellos en instrucciones de pasos posteriores usando la sintaxis de salida @connector_name. El valor es accesible dentro del procedimiento — simplemente no aparecerá como atributo de conversación en el Inbox.
Para persistir datos en un atributo de conversación: Use un paso Handoff to workflow y establezca el valor del atributo dentro del workflow en su lugar. Tenga en cuenta que el procedimiento no se reanudará después del traspaso, así que planifique su flujo para completarse antes del traspaso.

Data connector configurado en READ en lugar de UPDATE

Problema: El procedimiento se ejecuta pero no recopila ni almacena la entrada del cliente, aunque el paso de data connector parece ejecutarse.

Solución: Verifique el tipo de acción del data connector en el paso correspondiente. READ solo verifica un valor almacenado existente — no solicitará entrada al cliente ni guardará datos nuevos. UPDATE recopila la entrada del cliente y la guarda en el atributo. Si su procedimiento debe recopilar información del cliente (por ejemplo, una dirección de correo electrónico, número de pedido o motivo de contacto), cambie el tipo de acción a UPDATE.

Manejo avanzado de fallos con status_code

El status_code devuelto por una llamada a data connector se expone como un atributo de salida. Puede referenciarlo en un paso de Condición para ramificar según códigos HTTP específicos, dándole control preciso sobre cómo Fin maneja diferentes escenarios de fallo en lugar de depender de una sola rama de éxito/fallo.

Por ejemplo, puede dirigir un 404 (recurso no encontrado) a un mensaje diferente que un 500 (error de servidor), o escalar a un agente humano solo cuando se devuelve un código de error específico.

Consejo: Vea Cómo escribir condiciones de código para Fin Procedures para ejemplos de código usando status_code en un paso de Condición.

Validando correcciones con Simulaciones

Antes de poner su Procedimiento en vivo, use Simulaciones para verificar la corrección:

Vista previa vs. Simulaciones — ¿cuál debo usar? Vista previa muestra la experiencia completa para el cliente. Usar Vista previa mientras su procedimiento está en vivo puede exponer mensajes de pasos a clientes reales. Simulaciones ejecutan el procedimiento en segundo plano sin salida visible para el cliente — son la forma más segura de validar la lógica y la coincidencia de disparadores antes de ponerlo en vivo.

Navegue al editor de Procedimientos y haga clic en Test.
Ejecute una Simulación donde la IA actúe como el cliente en el escenario que falla.
Revise el resultado de aprobado/reprobado y el juicio de la IA para confirmar que la lógica es confiable.

Preguntas frecuentes

¿Funciona el depurador de conversaciones para conversaciones estándar de Fin?

No, la línea de tiempo y el depurador "Fin's thoughts" solo están disponibles cuando se activó un Procedimiento. Si Fin dio una respuesta inesperada en una conversación estándar, estas herramientas no estarán presentes; revise los eventos de conversación en el Inbox en su lugar.

¿Cuánto tiempo se almacenan los registros de Data connector?

Los registros de respuesta de Data connector se almacenan por hasta 14 días por defecto. Si su workspace tiene requisitos de seguridad de datos más estrictos, Intercom puede reducir esto a 7 días a solicitud — contacte a nuestro equipo de Support para habilitarlo. Acceda a sus registros en Settings > Integrations > Data connectors > Logs.

¿Puedo usar Simulaciones para probar respuestas de Data connector?

Sí — Las Simulaciones ejecutan el Procedimiento completo incluyendo cualquier paso de Data connector, siendo la forma más confiable de validar el comportamiento del conector antes de ponerlo en vivo.

¿Por qué mi Procedimiento está siendo bloqueado por un Workflow?

Los Workflows se ejecutan antes de que Fin evalúe la intención del procedimiento. Si un Workflow está activo para el mismo disparador de conversación, puede dirigir la conversación antes de que Fin tenga oportunidad de coincidir con un procedimiento. Para solucionarlo: revise sus workflows activos para disparadores superpuestos y asegúrese de que el bloque Let Fin Handle esté configurado correctamente en la ruta del workflow donde desea que los procedimientos estén disponibles.

¿Por qué mi Procedimiento pasó a un humano inesperadamente?

Hay dos formas en que un Procedimiento puede pasar a un humano:

Comportamiento predeterminado de escalada — Fin escala automáticamente según su lógica incorporada: cuando un cliente claramente pide hablar con un humano, cuando Fin detecta fuerte frustración o enojo, o cuando el cliente está atrapado en un ciclo repetitivo. Esto siempre se activa independientemente de cómo esté configurado tu Procedure.
Transferencia configurada — Un paso de Handoff to team que has añadido en un punto específico del Procedure, o una guía específica del Procedure que has escrito para indicar a Fin que transfiera en un escenario particular.

Si la transferencia fue inesperada, usa Fin's thoughts en el depurador de conversación para ver qué tipo se activó y en qué paso.

¿Qué sucede cuando tanto un Procedure como una Escalation Guideline coinciden con el mismo mensaje del cliente?

La escalada tiene prioridad. Si el mensaje de un cliente coincide tanto con los criterios de activación de un Procedure como con una Escalation Guideline (o una Escalation Rule), Fin transfiere a un humano en lugar de ejecutar el Procedure, incluso si el disparador del Procedure es una coincidencia más cercana o específica con el mensaje. Esta es una regla general de cómo Fin resuelve intenciones en competencia, no algo que se pueda configurar por Procedure.

Por ejemplo, un Procedure diseñado para manejar solicitudes de creación de casos de "API Error" no se activará para un cliente que describa un error de API si también existe una Escalation Guideline escrita para detectar el lenguaje "API Error" — la Escalation Guideline gana y el Procedure nunca se ejecuta.

¿Cómo evito que una Escalation Guideline reemplace involuntariamente mi Procedure?

Restringe la Escalation Guideline para que ya no se superponga con los criterios de activación del Procedure:

Abre Fin AI Agent > Train > Escalations y revisa tu Escalation Guidance y Escalation Rules para detectar redacciones que puedan coincidir con los mismos mensajes que el disparador del Procedure.
Agrega ejemplos positivos específicos (deben escalar) y ejemplos negativos (no deben escalar — debe ejecutarse el Procedure en su lugar) a la Escalation Guideline, de la misma manera que refinarías la sección "Cuándo usar este procedimiento" de un Procedure.
Si ambos se basan en la misma frase específica (por ejemplo, un código de error específico), reformula la Escalation Guideline para excluir mensajes de estilo creación de casos, o haz que los criterios de activación del Procedure sean más específicos para que ya no se superpongan.

Usa Fin's thoughts en el depurador de conversación para confirmar si se activó una escalada o el Procedure para un mensaje dado (ver "Accediendo al depurador de conversación" arriba).

¿Por qué no se activa mi Escalation Guidance dentro de un Procedure?

La Escalation Guidance no se aplica dentro de un Procedure por defecto — necesitas habilitarla explícitamente en el panel Guidance del Procedure:

Abre tu Procedure, haz clic en la rueda de configuración en la esquina superior derecha del editor de Instructions y haz clic en Guidance.
Selecciona las categorías de guidance a nivel de espacio de trabajo que deseas aplicar, incluyendo Handover and escalation.
Fin combinará la guidance seleccionada a nivel de espacio de trabajo con cualquier guidance específica del procedure que hayas escrito.

Nota: El comportamiento predeterminado de escalada de Fin (cliente pide un humano, se detecta frustración, ciclo repetitivo) siempre se activa dentro de un Procedure independientemente de la configuración de Guidance. El panel Guidance controla solo tu Escalation Guidance y Escalation Rules a nivel de espacio de trabajo.

¿Cuál es la diferencia entre Handoff to team y Handoff to workflow?

Ambos pasos terminan el Procedure, pero enrutan la conversación de manera diferente:

Handoff to team — Termina el Procedure y transfiere la conversación a un compañero humano. La conversación luego sigue la ruta de escalada configurada en tu Deploy workflow después del paso Let Fin handle (bloque Let Fin handle).
Handoff to workflow — Termina el Procedure y pasa la conversación a un Workflow reutilizable específico que ya has construido (por ejemplo, una encuesta de satisfacción o un flujo de enrutamiento a especialistas). El Procedure no se reanudará después de que el Workflow termine.

¿Se factura una transferencia de Procedure como un Fin Outcome?

Un Procedure de Fin solo se factura como un Fin Outcome cuando la conversación termina de una de dos maneras:

Resolución — el cliente confirma que Fin resolvió su problema, o no pide más ayuda después de que Fin responde.
Procedure Handoff — Fin transfiere a un equipo, compañero o workflow mediante un paso de Handoff configurado o guidance específica del procedure que hayas establecido.
En ambos casos, se te cobra $0.99 — y solo una vez por conversación, sin importar cuántos pasos haya ejecutado Fin o cuántas preguntas haya hecho el cliente.

Nota: No se te cobrará si un Procedure no se completa, sale sin alcanzar uno de estos resultados, un cliente pide hablar con un humano en cualquier momento, o la conversación termina mediante el comportamiento predeterminado de escalada de Fin o las reglas de escalada a nivel de espacio de trabajo.

Para más detalles, consulta Understanding Fin Outcomes.

Mi Procedure se detiene a mitad de la conversación — ¿podría ser un tiempo de espera?

Sí. Los Procedures se ejecutan dentro de un bloque Let Fin Handle en tu Workflow, y ese bloque tiene un tiempo de espera por inactividad predeterminado. Si un cliente tarda más que eso en responder, el bloque puede cerrarse antes de que el procedure termine. Para solucionarlo, abre el bloque Let Fin Handle en la configuración de tu Workflow y aumenta el tiempo de espera por inactividad para que coincida mejor con la duración esperada de la conversación.

¿Puedo usar Guidance para activar un Procedure?

No. Guidance controla cómo responde y se comporta Fin — no puede iniciar un procedure ni enrutar una conversación hacia uno. Los dos sistemas son separados: Guidance da forma al tono y reglas de escalada de Fin; Procedures definen flujos paso a paso que Fin sigue cuando se detecta una intención específica.

Para cambiar de un procedure a otro a mitad de la conversación, usa el comando @Switch dentro del procedure de origen, o habilita Agentic Switch en la configuración del procedure (ver "4. Help Center content taking priority" en este artículo).

Si quieres que Fin decida inteligentemente cuándo llamar a un conector de datos o seguir un flujo específico basado en lo que dice el cliente, construye esa lógica en un procedure en lugar de en guidance.

Mi condición de código no está ramificándose — ¿cómo la depuro?

Las condiciones de código fallan silenciosamente cuando hay un error de sintaxis o cuando la ruta de datos a la que intentas acceder no existe en el contexto de la conversación. Fin no mostrará el error directamente — simplemente seguirá la rama Else o se detendrá. Aquí te explicamos cómo diagnosticarlo:

Abre la conversación en el Inbox y habilita Mostrar eventos de conversación (ver "Accediendo al depurador de conversación" arriba).
En Fin's thoughts, verifica qué valor recibió Fin como entrada para tu condición. Si el valor es null o undefined, la ruta de datos en tu código es incorrecta.
Verifica estos patrones comunes de acceso a datos: • Dirección de correo electrónico: inputs["user"]["email"] — devuelve el correo electrónico del cliente si está disponible, de lo contrario None • Salida del conector: usa el nombre exacto del campo del esquema de respuesta de tu conector • Atributo de conversación: inputs["conversation"]["attribute_name"]
Prueba tu bloque de código en un intérprete de Python antes de agregarlo al procedure. Esto detecta errores de sintaxis inmediatamente, sin necesidad de ejecutar una conversación en vivo.
Si la condición se evalúa pero enruta a la rama incorrecta, agrega una instrucción print() en tu bloque de código para registrar el valor real que Fin está recibiendo. La salida aparecerá en los eventos de conversación.

Nota: El tipo de cliente (user vs. lead) no está disponible actualmente como atributo de Procedure. Si necesitas ramificar según el tipo de cliente, usa una condición Type en tu Workflow antes del paso Fin.

Solución de problemas de Procedimientos Fin y conectores de datos