Cómo defender los Procedimientos Fin internamente

Conseguir que Fin responda preguntas es un primer paso importante. Los Procedimientos van más allá al ayudar a Fin a resolver problemas repetitivos y de múltiples pasos, no solo para explicar un proceso, sino para completarlo realmente.

Para eso, Fin generalmente necesita acceso a información o acciones en tus sistemas internos, lo que significa que puede que necesites ayuda del equipo de ingeniería o del equipo que posee esos sistemas internamente.

Esta guía es para líderes de soporte y operaciones que están promoviendo los Procedimientos internamente. Te ayudará a definir el alcance de la solicitud, hablar con los interesados técnicos con confianza y mantener el primer proyecto lo suficientemente pequeño para que sea aprobado.

Por qué esto importa

Fin ya maneja bien las preguntas informativas. Los Procedimientos desbloquean un tipo diferente de valor: resolver problemas que dependen de datos en tiempo real o acciones del sistema, como verificar el estado de un pedido, consultar una suscripción o procesar una devolución.

Ahí es donde comienza el trabajo de defensa interna. Si un problema del cliente depende de datos en vivo o una acción del sistema, tu equipo necesitará Data Connectors y acceso a API para hacer posible esa experiencia.

La oportunidad no es solo la desviación. Es una resolución más rápida, menos trabajo manual repetitivo y una experiencia del cliente más fluida para tus tareas de mayor volumen.

Sin Procedimientos vs. con Procedimientos

Sin Procedimientos	Con Procedimientos
Fin le dice a un cliente cómo presentar una reclamación por pedido dañado.	Fin procesa la reclamación, verifica el estado del pedido en tu base de datos y confirma el reemplazo, todo en una sola conversación.
Fin le dice a un cliente que inicie sesión para verificar la fecha de renovación de su suscripción.	Fin consulta la fecha de renovación y el estado de la suscripción en tiempo real y le da al cliente una respuesta inmediata, sin necesidad de iniciar sesión.

Según el Informe de Transformación del Servicio al Cliente 2026 de Intercom, los equipos que integran AI en workflows reales, en lugar de detenerse en preguntas frecuentes superficiales, reportan un ROI significativamente más fuerte y métricas mejoradas. La mayoría de los equipos están invirtiendo en AI, pero solo una pequeña minoría ha alcanzado un despliegue maduro.

Comienza antes que ingeniería: lo que puedes hacer ahora

No todos los Procedimientos requieren trabajo de ingeniería. Antes de involucrar a los interesados técnicos, explora lo que puedes construir con lo que ya tienes.

Procedimientos que no necesitan Data Connectors:

Flujos de solución guiada usando contenido de knowledge base
Recorridos paso a paso que recopilan información y la dirigen al equipo correcto
Procedimientos de triaje que hacen preguntas calificativas antes de escalar
Flujos de aplicación de políticas (por ejemplo, verificaciones de elegibilidad de garantía basadas en la fecha de compra)

Procedimientos que usan el paso Ask Teammate:

Si un Procedimiento necesita información de otro sistema pero ingeniería aún no está disponible, puedes usar el paso Ask Teammate como sustituto. Un compañero completa manualmente ese paso mientras se construye el Data Connector, para que puedas probar el flujo completo del procedimiento de principio a fin y recopilar datos sobre su impacto.

Comenzar aquí te da dos ventajas: aprendes a construir Procedimientos y generas resultados medibles que justifican la inversión en ingeniería cuando la necesites.

Consejo: Los equipos ahora pueden construir y gestionar Procedimientos usando lenguaje natural, aplicar los controles y datos necesarios para la precisión, y probar cada escenario antes de que llegue a un cliente. Muchos de los bloques de construcción como descripciones, disparadores, condiciones y guías no requieren habilidades técnicas en absoluto.

¿Nuevo en APIs y Data Connectors?

Si eres nuevo en estos términos, esta sección cubre lo que necesitas saber para definir el alcance de la solicitud y explicarlo internamente.

Una API (Interfaz de Programación de Aplicaciones) es una forma estructurada para que los sistemas de software intercambien información. Cuando un sistema necesita un dato de otro, envía una solicitud a través de una API y recibe una respuesta.

Un Data Connector usa una llamada API para que Fin pueda recuperar o enviar de forma segura un dato específico, como el estado de un pedido o la fecha de renovación de una suscripción. Cada conector generalmente está diseñado para una tarea específica. Aprende más sobre Data Connectors.

Un Procedimiento usa esos conectores dentro de un proceso de múltiples pasos, para que Fin pueda hacer más que responder una pregunta, pueda ayudar a resolver el problema. Aprende más sobre Procedimientos.

Para tu primer proyecto, comienza pequeño, con un proceso repetible, un sistema y solo los pocos campos de datos que Fin realmente necesita. Cuanto más enfocada sea la solicitud, más rápido avanzará.

Ejemplo: cómo se conectan las piezas

Objetivo del cliente: “Verificar la fecha de renovación de mi suscripción”
Procedimiento: Fin confirma la identidad, llama al sistema de facturación y devuelve la fecha de renovación, todo en una sola conversación
Data Connector: Una llamada API de solo lectura a la plataforma de facturación, que devuelve tres campos: fecha de renovación, nombre del plan, estado de la suscripción
Resultado: Fin responde en segundos. No se necesita un compañero

Fin no necesita acceso a todo tu sistema. Generalmente necesita una forma segura de recuperar o enviar un pequeño conjunto de datos aprobados. Ingeniería o el propietario del sistema define exactamente qué campos puede acceder Fin, nada más.

Para la configuración técnica completa, consulta el artículo diseñando y usando tus APIs con Data Connectors.

Cómo elegir tu primer Procedimiento

El mejor caso interno comienza con un proceso concreto, no con una propuesta de función. Antes de involucrar a ingeniería, escribe el proceso exacto que quieres automatizar y los datos mínimos que Fin necesita para hacerlo bien.

Un buen primer Procedimiento suele ser estrecho, repetitivo y ya bien entendido por tu equipo de soporte.

Consejo profesional: Elige el proceso más valioso que puedas automatizar con el menor número de endpoints y el conjunto más pequeño de campos. Un Procedimiento que lee pocos campos de un sistema es mucho más fácil de aprobar, construir y lanzar que uno que toca múltiples sistemas. Comienza estrecho: la complejidad puede venir después una vez asegurado el primer éxito.

Criterios de selección

Usa los criterios a continuación para identificar a tu mejor candidato:

Criterios	Qué buscar
Volumen	Un problema de alta frecuencia que tu equipo maneja repetidamente
Repetibilidad	Un proceso con pasos consistentes que no requiere juicio humano cada vez
Disponibilidad de API	Ya existe una API bien documentada (por ejemplo, Stripe, Shopify) o se puede definir rápidamente
Propiedad del sistema	Sabes qué equipo interno o herramienta posee los datos o la acción (por ejemplo, "eso está en Salesforce" o "nuestro equipo de facturación maneja eso")
Claridad en la solicitud de ingeniería	Puedes describir lo que Fin necesita en una oración sin usar términos técnicos. Fin solo necesita un pequeño número de campos de un sistema
Medibilidad	Puedes definir una métrica clara de éxito antes de construir (por ejemplo, tasa de resolución)

Ejemplo: un buen primer Procedimiento

Uso: Verificar fecha de renovación de suscripción
Sistema: Plataforma de facturación
Lo que Fin necesita: Fecha de renovación, nombre del plan, estado de la suscripción — tres campos de un endpoint
Primera solicitud: "Necesitamos un endpoint de solo lectura que devuelva estos tres campos para un cliente autenticado."
Por qué funciona: Alto volumen, repetitivo, bajo riesgo y fácil de medir. No requiere acceso de escritura y un esfuerzo mínimo del equipo de ingeniería o del propietario del sistema.

Piensa en fases, no todo a la vez

Los equipos más exitosos adoptan Procedimientos en etapas:

1. No se necesita integración: Automatiza flujos tipo FAQ, guías de solución de problemas y lógica de enrutamiento usando solo contenido de knowledge base.

2. Acceso de solo lectura: Conecta Fin a un sistema para consultar información (por ejemplo, estado de pedido, detalles de cuenta, fechas de suscripción). Aquí es donde entra el primer Data Connector.

3. Acciones de escritura: Permite que Fin tome acción en otro sistema (por ejemplo, procesar un reembolso, cancelar una suscripción, actualizar un registro). Esto requiere mayor participación de ingeniería y generalmente ocurre después de establecer confianza.

Comenzar con la Fase 1 o 2 significa que puedes mostrar resultados rápidamente y usar esos resultados para construir el caso para la Fase 3.

Consejo: El panel de recomendaciones Fin AI Agent > Analyze > Recommendations es la forma más rápida de encontrar tus mejores candidatos a Procedimientos.

Filtra por brechas de datos del cliente: donde Fin necesitó información de un sistema externo como estado de pedido o detalles de cuenta
Filtra por brechas de acción: donde Fin necesitó tomar una acción en otro sistema como cancelar un pedido o actualizar un registro.

Cada recomendación incluye una guía que detalla la API y los datos necesarios, convirtiéndola en un resumen listo para tu conversación con ingeniería. Extrae una muestra de conversaciones del panel de recomendaciones, identifica intenciones específicas del cliente que podrían convertirse en Procedimientos y estima la mejora en la tasa de resolución según la frecuencia de esas solicitudes. Esto convierte una idea general en un plan concreto y definido.

Mapea el proceso antes de la reunión

Antes de acercarte a ingeniería o al equipo que posee el sistema relevante, mapea exactamente lo que quieres automatizar. Este es el paso más importante: un proceso bien mapeado hace la conversación técnica más rápida y la solicitud más difícil de rechazar.

Cómo mapearlo

1. Escribe el proceso paso a paso en lenguaje sencillo. ¿Qué lo desencadena? ¿Qué sucede en cada paso? ¿Qué recibe el cliente al final?

2. Destaca exactamente dónde Fin necesita datos de otro sistema o necesita tomar una acción. Estos son tus puntos de contacto de Data Connector.

3. Para cada punto de contacto, lista los campos de datos específicos que Fin necesita. No toda la base de datos, solo los campos mínimos para este proceso.

4. Identifica qué equipo posee cada sistema. Esto no siempre es ingeniería. Puede ser el equipo que administra Salesforce, Jira, tu plataforma de facturación u otra herramienta interna.

Qué llevar a la reunión

El proceso mapeado con puntos de contacto claros de Data Connector
Los campos específicos que Fin necesita en cada paso (por ejemplo, "estado del pedido, número de seguimiento, fecha estimada de entrega")
Una métrica de éxito que puedas medir antes y después (por ejemplo, "tasa de resolución para consultas de estado de pedido")
Datos de volumen que muestran con qué frecuencia surge este problema (extrae esto del panel de recomendaciones o de tus reportes)

Consejo profesional: Considera mapear el proceso visualmente en una herramienta como Miro o un diagrama de flujo simple. Esto ayuda a todos, incluidos los interesados no técnicos, a ver el panorama completo e identificar dónde está realmente el trabajo de ingeniería.

Quién está involucrado y qué hacen

Construir un Procedimiento requiere dos tipos de alineación: claridad sobre quién posee qué día a día y saber qué interesados deben involucrarse para obtener aprobación.

Propiedad diaria

Equipo de CX / Soporte	Equipo de ingeniería
Escribe y actualiza el Procedimiento en lenguaje natural usando pasos, herramientas y guías dentro de Intercom	Expone acceso al sistema vía Data Connectors (llamadas API autenticadas)
Define la lógica del Procedimiento, escenarios de prueba y métricas de éxito	Define el endpoint, tipo de solicitud (por ejemplo, GET, POST) y campos específicos que Fin puede usar
Posee la iteración después del lanzamiento	Establezca encabezados de autenticación o tokens y confirme las restricciones de seguridad

Quién necesita estar en la sala

Rol	Quiénes suelen ser	Qué aportan
Campeón	Líder de soporte u operaciones que impulsa la iniciativa	Mapea el proceso de principio a fin y define qué necesita Fin para hacerlo bien
Patrocinador directo	Jefe de soporte, CX u operaciones	Aprueba el Procedimiento como prioridad y da al campeón el mandato para avanzar
Propietario del sistema	El equipo o individuo responsable de la herramienta interna relevante (por ejemplo, administrador de Salesforce, líder del equipo de facturación, propietario de Jira)	Confirma qué datos existen, quién puede acceder a ellos y qué restricciones aplican
Líder técnico	Desarrollador, arquitecto o líder de ingeniería del sistema que se conecta	Se alinea sobre la viabilidad, define el endpoint y los campos permitidos, y confirma el cronograma

Esta no siempre es una conversación de ingeniería. Si los datos que Fin necesita están en Salesforce, Jira, su plataforma de facturación u otra herramienta interna, el interesado clave puede ser el equipo que posee ese sistema, no un ingeniero de software. Identifique primero al propietario del sistema y luego determine si se necesita la participación de ingeniería.

El caso de negocio por interesado

El mismo Procedimiento puede enmarcarse de manera muy diferente según quién esté en la sala. Antes de preparar la presentación, averigüe qué prioridades ya son responsabilidad de su liderazgo y luego presente el Procedimiento como una contribución directa a una de esas metas.

Para los líderes de ingeniería es mejor mantener la solicitud limitada

"No estamos pidiendo que ingeniería se encargue de un workflow de IA. Estamos pidiendo ayuda para exponer un endpoint seguro para que el equipo de soporte pueda automatizar un proceso repetible y de alto volumen por nosotros mismos. Una vez que el endpoint esté en su lugar, el equipo de CX construye y mantiene el Procedimiento de forma independiente, sin participación continua de ingeniería"
Qué compartir: El endpoint específico, los campos necesarios, el tipo de solicitud (GET o POST) y el método de autenticación. Cuanto más precisa sea la solicitud, más fácil será para un ingeniero estimar y programar.
Abordando la inversión de tiempo: Para equipos con APIs bien documentadas, la configuración del Data Connector suele ser un trabajo contenido. Hemos visto a un equipo de desarrollo de un cliente poner en marcha un conector de solo lectura en menos de una hora. El alcance es similar a construir cualquier otra integración API, no un sistema nuevo.

Para el liderazgo de soporte y CX es mejor centrarse en la resolución

"Sin esta integración, Fin solo puede explicar el proceso. Con ella, Fin puede completar el proceso. Esto elimina el esfuerzo humano evitable y hace que la experiencia del cliente se sienta instantánea."
Qué compartir: El volumen de conversaciones que este Procedimiento manejaría, el tiempo promedio actual de manejo y la mejora esperada en la tasa de resolución.

Para el liderazgo ejecutivo es mejor alinearse con una prioridad existente

"Dinos la meta por la que ya te están midiendo — ya sea CSAT, tiempo de manejo o reducción de carga manual — y ajustaremos este Procedimiento para mostrar un resultado directo contra eso. Esto no necesita su propio caso de negocio. Es una contribución directa a algo que ya estás siguiendo."
Una nota sobre el encuadre: Para algunas organizaciones, el valor en dólares de la automatización es significativo. Para otras, el ahorro financiero de un solo Procedimiento puede no mover la aguja a su escala. En esos casos, lidera con el impacto cualitativo: mejores puntuaciones de experiencia del cliente, resolución más rápida y reducción de fricción en workflows de alto volumen. Conoce a tu audiencia y lidera con lo que más les importa.

Manejando objeciones comunes

Ellos dicen...	Tú dices...
"No tenemos capacidad."	"Por eso este es un piloto limitado. Al eliminar esta carga manual recurrente del equipo, en realidad creamos capacidad para futuras sprints."
"No queremos acceso amplio al sistema."	"Los Data Connectors están limitados a endpoints específicos y campos de respuesta. Podemos comenzar con acceso de solo lectura para garantizar la seguridad."
"Necesitamos que la API esté completamente construida primero."	"Podemos empezar a diseñar ahora. Intercom soporta respuestas JSON de ejemplo en la configuración, y podemos validar la lógica usando Simulaciones antes de que la API esté activa." También puedes usar el paso Ask teammate como un sustituto temporal, permite que un compañero complete manualmente ese paso mientras se construye el conector, para que puedas probar el flujo completo del procedimiento de principio a fin.
"No está en nuestra hoja de ruta este trimestre."	"Entendido. ¿Podemos incluirlo en el próximo ciclo de planificación? Mientras tanto, tendremos el proceso mapeado, los campos documentados y la métrica de éxito definida — así que cuando se abra capacidad, la solicitud estará lista."

Una vez que tengas alineación con ingeniería, comparte la guía Crear data connectors para Fin con tu desarrollador o propietario del sistema. Cubre todo el proceso de configuración incluyendo conexión API, autenticación, transformación de datos y pruebas.

Si los recursos internos son limitados

A veces el verdadero obstáculo es el tiempo en la hoja de ruta. Ingeniería puede apoyar en principio pero no estar disponible hasta el próximo ciclo de planificación. Eso es un resultado razonable, no un fracaso.

Qué hacer mientras esperas

1. Mapea el proceso de principio a fin en lenguaje sencillo. Documenta cada paso, cada campo de datos y cada punto de contacto del sistema.

2. Construye Procedimientos que no necesiten Data Connectors. La solución guiada, los flujos de triaje y la automatización basada en knowledge base crean valor ahora.

3. Usa el paso Ask Teammate como puente para pasos que eventualmente usarán un Data Connector.

4. Reúne datos de volumen y sigue los resultados de los Procedimientos que ya has construido — esto se convierte en la evidencia para tu próxima solicitud.

5. Reduce el alcance tanto como sea posible para que la solicitud de ingeniería esté lista para integrarse cuando se abra capacidad.

Obtén ayuda externa

Únete a las Horas de Oficina del Encuentro Comunitario semanal de Intercom para preguntas y respuestas y apoyo guiado por mentores

Para obtener ayuda con el alcance, discutir bloqueos y escuchar cómo otros equipos han navegado conversaciones internas similares. Útil en general y gratuito para asistir

Contrata a un Experto para soporte personalizado 1:1

Para un soporte más práctico y dedicado, el programa de Expertos verificados te conecta con consultores y desarrolladores independientes que se especializan en Fin y Data Connectors. Una buena opción si deseas orientación 1:1 y estás dispuesto a invertir en un camino más personalizado

Consejo: La Guía rápida: Crea un Procedimiento Fin te guía paso a paso para construir tu primer Procedimiento, incluyendo un ejemplo práctico usando un Data Connector.

Recursos relacionados

Preguntas frecuentes

¿Necesitamos construir una nueva API para usar Procedimientos?

No necesariamente, si ya existe una API bien documentada (por ejemplo, Stripe o Shopify), normalmente es una integración contenida y de bajo esfuerzo. Ingeniería solo necesita exponer el endpoint específico y los campos que Fin puede usar.

¿Podemos probar un Procedimiento antes de que la API esté lista?

Sí, Intercom soporta respuestas JSON de ejemplo en la configuración, así puedes construir y validar la lógica usando Simulaciones antes de conectar la API en vivo.

¿Necesita ingeniería construir el Procedimiento en sí?

Por lo general no, el equipo de soporte u operaciones es dueño de la lógica del Procedimiento: escribir los pasos, probarlo y hacer iteraciones después del lanzamiento. Ingeniería o el propietario del sistema habilita la capa de datos: exponiendo el endpoint correcto, definiendo qué campos Fin puede acceder y estableciendo el método de autenticación. Una vez hecho esto, el equipo de CX puede construir y actualizar el Procedimiento de forma independiente.

¿Qué pasa si solo podemos obtener acceso API de solo lectura para empezar?

Eso es un punto de partida perfectamente válido. Un Procedimiento de solo lectura, por ejemplo, para consultar el estado de una suscripción o detalles de un pedido, aún elimina un esfuerzo manual significativo y te da un resultado medible para construir sobre él.

¿Cuánto tiempo suele tardar ingeniería en configurar un Data Connector?

Depende de la complejidad, pero para equipos con APIs bien documentadas, un Data Connector de solo lectura puede configurarse relativamente rápido, a veces en menos de una hora. El alcance es similar a construir cualquier integración estándar de API: definir el endpoint, establecer la autenticación, mapear los campos de respuesta. El equipo de CX maneja todo lo demás.

¿Podemos construir Procedimientos sin ninguna participación de ingeniería?

Sí. Los Procedimientos que usan contenido de knowledge base, flujos guiados de solución de problemas, lógica de triaje o el paso Preguntar a un compañero no requieren Data Connectors ni trabajo de ingeniería. Estos son un buen punto de partida para comenzar y ganar confianza antes de expandirse a Procedimientos conectados.