Construir un Fin Procedure que maneje bien un tema técnicamente complejo requiere iteración. Este artículo explica cómo se diseñó desde cero un procedimiento real, el Data Connectors Setup and Troubleshooting procedure, se refinó a través de sucesivas iteraciones y se moldeó con seis principios que lo mejoraron consistentemente. Úsalo para aplicar el mismo pensamiento a tus propios procedimientos.

Este artículo es para compañeros que construyen e iteran sobre Fin Procedures. Asume que trabajas en el editor de procedimientos y que has publicado al menos un procedimiento.

El procedimiento maneja toda la gama de preguntas sobre Data Connector: configuración inicial, fallos de autenticación, errores en llamadas API, tiempos de espera, problemas de mapeo de respuestas y regresiones. Cubre mucho terreno técnico y usa un Data Connector propio, construido específicamente para consultar datos de diagnóstico en vivo sobre el conector de un cliente antes de que Fin haga una sola pregunta. Esa decisión de diseño cambió cómo funciona todo el procedimiento.

En la superficie, "ayuda con Data Connectors" suena como un solo tema. En la práctica, cubre una variedad de situaciones distintas: una configuración por primera vez, un fallo de autenticación, una llamada API rota, un tiempo de espera, un problema de mapeo de datos, una regresión (algo que antes funcionaba y ahora no), un protocolo no soportado y un cliente que aún no sabe qué necesita. Manejar todo esto bien en un solo procedimiento solo es posible si Fin sabe, temprano en la conversación, en qué situación está.

La decisión de diseño más significativa en el procedimiento es un Data Connector dedicado que fue construido específicamente para extraer datos de salud en vivo sobre el propio conector de un cliente.

Cuando un cliente comparte la URL de su conector, Fin usa el ID del conector para hacer una solicitud GET. Recibe:

Fin usa estos datos para liderar su primera respuesta significativa con algo específico, no algo genérico. Esa es la diferencia entre un procedimiento que se siente como un formulario de soporte y uno que se siente como hablar con alguien que ya investigó tu problema antes de contestar el teléfono.

El procedimiento enruta en dos etapas. La primera es automática: Fin lee los datos de diagnóstico y enruta antes de preguntar algo al cliente. La segunda es basada en la intención: si la primera etapa no determina el camino, Fin lee lo que el cliente describe y enruta al subprocedimiento correspondiente.

La tabla a continuación muestra las 13 situaciones distintas que maneja el procedimiento Data Connectors Setup and Troubleshooting, cómo Fin detecta cada una y a qué subprocedimiento enruta.

Los seis principios a continuación explican cómo llegó el procedimiento allí y cómo aplicar el mismo pensamiento en el tuyo.

Cada principio incluye:

Antes de que Fin diga una sola palabra al cliente, debe determinar de qué está preguntando realmente el cliente.

Diferentes intenciones merecen diferentes caminos, y un procedimiento que hace las mismas preguntas iniciales a todos los clientes pierde tiempo para la mayoría de ellos.

Fin tampoco ejecuta procedimientos como un guion fijo de arriba hacia abajo. Usa un enfoque de planificación no lineal: puede revisar pasos anteriores, saltar adelante o cambiar de rumbo a medida que la conversación se desarrolla. En algunos casos, incluso puede cambiar a otro procedimiento a mitad de la conversación si otro es más adecuado.

Eso significa que el orden de los pasos no siempre controla el orden de la conversación. Diseña procedimientos alrededor de la intención que Fin necesita manejar, no alrededor de un camino estricto paso a paso.

Un procedimiento que maneja preguntas sobre Data Connectors ilustra esto bien.

"Pregunta sobre Data Connector" en realidad cubre al menos cinco conversaciones diferentes:

El paso de Instrucción inicial le dice a Fin que lea el primer mensaje del cliente y determine qué situación aplica.

Los pasos de Condición más adelante envían la conversación por el camino que coincide.

La dirección ocurre en el disparador, así que eso es lo que necesitas probar — y la herramienta correcta es la prueba en vivo, no simulaciones. Las simulaciones evitan la coincidencia de intención completamente; ejecutan un procedimiento directamente sin pasar por el disparador, por lo que no pueden decirte si Fin selecciona el procedimiento correcto en primer lugar.

Para probar la dirección, activa el procedimiento en vivo con la audiencia limitada a ti mismo — por ejemplo, una regla donde el correo electrónico contenga tu domain de empresa. Envía diez mensajes iniciales realistas y verifica dos cosas: que este procedimiento comience cuando debe, y que no comience cuando no debe. Incluye mensajes ambiguos; esos son los casos más propensos a redirigir mal. Cuando un mensaje se redirige incorrectamente, ajusta la descripción del disparador para ser más específico sobre cuándo Fin debe y no debe usar el procedimiento.

Lista los tipos distintos de conversaciones que tu procedimiento recibirá. Luego pregunta: ¿son estos el mismo trabajo con ligeras variaciones, o trabajos genuinamente diferentes? Si son genuinamente diferentes, tienes dos opciones: dividirlos en procedimientos separados con disparadores distintos, o manejarlos como ramas dentro de un solo procedimiento. Usa procedimientos separados cuando los trabajos sean lo suficientemente distintos como para querer ver su rendimiento reportado por separado. Usa ramas cuando los trabajos estén estrechamente relacionados y quieras mantener la lógica en un solo lugar.

Escribe tu disparador para que sea claro en ambos lados: cuándo Fin debe usar este procedimiento y cuándo no debe. Los disparadores vagos son la fuente más común de redirección incorrecta. Dentro del procedimiento, nunca pidas a los clientes que categoricen su propio problema — Fin lee su mensaje y redirige desde eso. El trabajo del cliente es describir su problema, no etiquetarlo.

Usa el paso de Condición para caminos principales mutuamente excluyentes — situaciones donde lo que Fin hace a continuación es completamente diferente según la respuesta. Para diferencias menores, mantén la lógica en un paso de Instrucción como lenguaje natural. Esto mantiene los procedimientos más simples y más fáciles para que Fin los siga.

Los siguientes factores te ayudan a elegir entre dividir trabajos en procedimientos separados o manejarlos como ramas dentro de un solo procedimiento:

Si tu procedimiento tiene acceso a un Data Connector que puede responder parte de la pregunta del cliente, llámalo antes de comenzar a entrevistar al cliente.

Los clientes perciben esto como competencia. Los procedimientos que entrevistan primero se sienten como formularios.

Cuando la pregunta del cliente es sobre un conector específico, el procedimiento Data Connectors Setup and Troubleshooting pregunta una vez por el nombre del conector. Luego llama a un Data Connector diagnóstico dedicado y recibe los siguientes campos:

La primera respuesta significativa de Fin usa esos datos. Aquí está la diferencia en la práctica (los valores a continuación son ilustrativos):

Después de que el Data Connector se ejecute, lee en voz alta el primer mensaje de Fin. Si hace preguntas que podrías haber respondido con los datos que ya obtuviste, no estás usando los datos con suficiente agresividad.

Empuja más decisiones a los pasos de Condición que leen los datos en lugar de trasladarlas al cliente.

Haz un inventario de los Data Connectors disponibles para tu procedimiento. Para cada uno, pregunta: "¿Podría llamar a este antes de la primera pregunta del cliente en lugar de después?" Si la respuesta es sí, reestructura para que la obtención de datos ocurra primero. El cliente debería sentir que Fin ya hizo la tarea.

Una vez que hayas obtenido datos de diagnóstico, ramifica directamente según esos datos. No hagas que el cliente describa un estado que ya puedes detectar.

Después de que el Data Connector se ejecute, su respuesta estará disponible como contexto temporal. Lee campos individuales usando la acción de atributo de lectura, luego usa pasos de Condición que ramifiquen directamente según esos valores.

La tabla a continuación muestra cómo los valores específicos de los campos del Data Connector se asignan a las ramas de pasos de Condición y la acción correspondiente que Fin debe tomar:

Cada rama produce un mensaje de apertura diferente escrito específicamente para ese estado.

Para cada rama, pregunta: "¿Tendría sentido la respuesta de Fin en esta rama si un cliente real en este estado exacto la leyera?"

La rama del conector saludable suele ser la más fácil de equivocarse porque el instinto es seguir diagnosticando. Resiste eso. Si el conector parece saludable, dilo y avanza la conversación.

Observa cada dato que obtienes y pregunta si debería conducir a un paso de Condición.

Mantén la lógica ajustada y escribe cada rama como si fuera la única respuesta que el cliente verá.

El modo de fallo más común en un procedimiento basado en datos no es un error del Data Connector. Es una llamada exitosa que no devuelve resultados.

Generalmente esto sucede porque la entrada del cliente no coincide con nada.

Las URLs del Data Connector deben ser exactas. Cuando los clientes proporcionan URLs que no coinciden con el conector que pretenden, ya sea por errores tipográficos, barras finales u otras variaciones, el Data Connector a menudo devuelve campos vacíos en lugar de un error.

Sin un manejo explícito, Fin puede continuar y generar respuestas basadas en datos que en realidad nunca encontró.

La solución es un paso de Condición que verifica si los campos clave están vacíos o nulos. Si es así, Fin pide al cliente que verifique la URL del data connector en sus configuraciones de Data Connectors y la proporcione exactamente como aparece. Luego, el Data Connector se ejecuta nuevamente usando la URL corregida.

Prueba entradas que casi coinciden pero no:

Si el procedimiento no detecta y se recupera de estos casos, la ruta de respaldo no es lo suficientemente fuerte.

Cada vez que llames a un Data Connector, añade un paso de Condición inmediatamente después para "sin resultados."

En esa rama:

Un procedimiento se vuelve confiable mediante pruebas. Intercom te ofrece tres herramientas que detectan problemas progresivamente diferentes — úsalas en orden, porque cada una encuentra problemas que la anterior no puede.

Haz clic en Review en el editor de procedimientos (arriba a la derecha, junto a Test).

Review ejecuta un análisis estático de la configuración de tu procedimiento y devuelve una lista de problemas señalados con soluciones específicas. Detecta problemas en tiempo de construcción como:

Review no ejecuta una conversación ni muestra cómo Fin se comportaría realmente en tiempo de ejecución — solo inspecciona la configuración. Ejecútalo primero para que corrijas problemas estructurales antes de invertir tiempo en simulaciones.

Las simulaciones ejecutan el procedimiento de principio a fin contra un mensaje de apertura, sin salida visible para el cliente. La transcripción muestra más que la respuesta final: el pensamiento de Fin en cada paso, qué rama se eligió, actualizaciones de atributos y llamadas al Data Connector. Puedes adjuntar criterios de éxito para afirmar la respuesta, valores de atributos, llamadas al conector y resultado, convirtiendo un escenario en una prueba repetible de aprobado/reprobado.

Las simulaciones evitan completamente la coincidencia de intención — ejecutan el procedimiento directamente y no prueban si tu disparador se activa correctamente. Para probar el enrutamiento de intención, usa pruebas en vivo limitadas a ti mismo (cubierto abajo).

Una vez que Review esté limpio y tus simulaciones pasen, prueba la experiencia genuina de principio a fin. Pon el procedimiento en vivo con la audiencia limitada a ti mismo — por ejemplo, una regla donde el email contenga tu company domain. Esto te permite probar la experiencia completa en una conversación real sin exponerla a clientes. Cuando estés satisfecho, actualiza la regla de audiencia para incluir a todos los clientes. Guardar el cambio de regla crea un nuevo borrador, así que haz clic en Set live nuevamente para que el cambio tenga efecto.

Las pruebas en vivo detectan cosas que las simulaciones no pueden: el disparo correcto del trigger, el flujo real de la conversación y la sensación de cada respuesta cuando llega en contexto.

Sigue el porcentaje de conversaciones de prueba donde la primera respuesta de Fin habría parecido adecuada para el cliente. No solo preguntes "¿Se enroutó correctamente?" — pregunta "¿Un humano reflexivo encontraría útil esta primera respuesta?"

Con el tiempo, conecta esto con señales objetivas ya disponibles en Intercom: tasa de resolución, CSAT y tiempo de manejo de la conversación. Si una mejora del procedimiento funciona, deberías ver estos indicadores moverse.

Trabaja las capas en orden:

Cada vez que pones un procedimiento en vivo, Intercom te pide escribir una nota de ‘¿Qué cambió?’. Trata ese campo como un changelog real, no una formalidad. Parece una tarea en el momento, pero es el registro que te permite conectar un cambio en la métrica con un cambio específico semanas después en lugar de adivinar.

Un procedimiento nunca está terminado — seguirás refinándolo, y cada cambio es una pequeña apuesta a que el procedimiento mejore. El historial de versiones es el registro de esas apuestas. Si la tasa de resolución, CSAT o el tiempo de manejo cambian tras un cambio, una nota clara te dice qué cambió y cuándo, para que puedas rastrear el cambio a una edición específica en lugar de adivinar.

Escribe qué hace el cambio y por qué, no solo dónde está:

La segunda versión es una nota sobre la que puedes actuar seis semanas después. La primera no.

Si un cambio degrada el rendimiento, revierte desde Historial de versiones:

También puedes editar una nota existente (el icono de lápiz en Historial de versiones) para aclarar qué hizo realmente un cambio pasado.

Cuando una métrica baja, abre primero Historial de versiones. Compara la fecha de la caída con tus notas de cambio. La causa suele ser el cambio que se publicó justo antes.

La primera versión del procedimiento Data Connectors Setup and Troubleshooting entrevistaba a los clientes antes de buscar cualquier información. Fin hacía tres o cuatro preguntas antes de decir algo útil. Técnicamente funcionaba, pero parecía un formulario.

El Data Connector diagnóstico llegó en la siguiente iteración. Esa sola adición cambió el carácter de todo el procedimiento. En lugar de empezar con preguntas, Fin podía comenzar con observaciones específicas — "Tu connector tiene una tasa de éxito del 64% en los últimos 7 días y el error más reciente fue un 401" — y luego pasar directamente a solucionar el problema.

Después, el enrutamiento de intención se separó del flujo diagnóstico. Los clientes que preguntaban qué pueden hacer los Data Connectors tenían un camino diferente a los clientes con un connector roto. Eso eliminó muchas preguntas diagnósticas irrelevantes para personas que solo necesitaban una respuesta rápida sobre capacidades.

Cada iteración fue impulsada por un patrón de fallo específico detectado en conversaciones reales: un cliente que llegó a la rama equivocada, un caso que el enrutamiento no había anticipado, una respuesta técnicamente correcta pero poco útil en contexto. Ninguna iteración vino de adivinar. Todas vinieron de evidencia.

La señal más clara de que un procedimiento funciona es la calidad de la primera respuesta de Fin. Antes de que existiera este procedimiento, un cliente que preguntaba por un connector que fallaba respondía varias preguntas antes de recibir alguna guía. Con el procedimiento, la primera respuesta significativa de Fin comienza con lo que realmente encontró: el estado del connector, su tasa de éxito en la última semana y su código de error más reciente. El diagnóstico empieza con datos, no con una entrevista.

La profundidad del enrutamiento también importa. 13 caminos distintos significan que cada situación recibe una guía que realmente le corresponde. Un cliente que pregunta por integración SOAP recibe una respuesta directa y honesta sobre lo que se soporta — no un flujo de solución de problemas que no lleva a ninguna parte. Un cliente cuyo connector está sano pero cuyos datos no se mapean correctamente no pasa primero por solución de problemas de autenticación.

Y cuando una conversación necesita un agente humano, la nota de traspaso ya contiene el nombre del connector, la URL del connector y la categoría del problema. El compañero tiene contexto antes de leer un solo mensaje del cliente. Eso es algo pequeño desde la perspectiva del diseño — un paso de nota al final del procedimiento — pero cambia el traspaso de un reinicio a una continuación.

Cuando se combinan estos seis principios, un procedimiento como el ejemplo de Data Connectors tiende a seguir una estructura predecible:

El Principio 6 — mantener un changelog honesto — no es un paso en la estructura, pero es lo que hace que todo sea mejorable con el tiempo. Sin un registro claro de qué cambió y cuándo, cada iteración es una suposición.

Los mejores Fin Procedures no se vuelven efectivos por un primer borrador ingenioso. Se vuelven efectivos porque cada iteración está impulsada por evidencia de conversaciones reales.

Comienza con tu procedimiento de mayor volumen. Aplica primero el Principio 1: mapea cada intención que pueda recibir y verifica que el enrutamiento funcione. Luego construye a partir de ahí.

La primera versión es el punto de partida. La buena versión es la que has refinado repetidamente.