Conecta dos herramientas sin integración nativa

Tu CRM no habla con tu calendario. Tu Airtable no avisa a tu Slack. Tu Drive no manda emails. Las apps no se conectan porque a sus dueños no les conviene, no porque sea difícil. La solución cabe en una tarde de trabajo.

01Por qué tu CRM y tu calendario no se hablan

Las dos herramientas existen, las dos guardan información que tendría sentido compartir, y las dos están diseñadas para no abrirse del todo a la otra. No es por torpeza técnica. Es modelo de negocio.

Cuando una app no se conecta nativamente con otra, te ofrece dos caminos: o pagas por una capa de integración suya, o lo arreglas tú. La buena noticia es que arreglarlo tú ya no es un proyecto de semana. Es un proyecto de tarde, si conoces el patrón.

El patrón se llama agente intermedio. Una pieza pequeña que lee de la herramienta A, traduce los datos al idioma de B, y los escribe en B. Sin pedir permiso a ninguna de las dos.

02La solución del agente intermedio

Un agente intermedio es código simple que se ejecuta cuando algo cambia en una app y reacciona escribiendo en otra. Lo importante no es el código, es la idea.

Funciona porque casi todas las apps modernas ofrecen dos cosas:

• Una API, que es la puerta de entrada para que un programa lea o escriba datos de la app sin pasar por la pantalla.
• Un webhook, que es un aviso automático que la app manda a una dirección que tú indicas cuando pasa algo (un nuevo registro, un cambio de estado).

El agente intermedio escucha por webhook, llama a la API de la otra, y escribe. Punto. Lo que cambia entre casos es qué entra y qué sale.

03Caso real: CRM y calendario

El problema clásico. Tu equipo cierra una llamada de ventas en el CRM. La fecha la apuntan ahí. Pero tu calendario no se entera. Resultado: doble apunte, agenda desincronizada, llamadas olvidadas.

Qué hace el agente, escena por escena:

• Nuevo deal con fecha de llamada en el CRM, sale evento creado a esa hora en el calendario
• Nombre del cliente en el CRM, sale como título del evento
• Notas del comercial en el CRM, salen como descripción del evento
• Email del cliente en el CRM, sale como invitado del evento
• Cambio de fecha en el CRM, sale evento movido en el calendario

El agente vive entre las dos. Si alguien borra el deal en el CRM, el evento desaparece del calendario. Si alguien mueve el evento en el calendario, el agente actualiza el CRM. Lo importante es decidir desde el principio cuál es la fuente de verdad: la herramienta que manda. Si las dos editan, te haces un lío en una semana.

04Caso real: Airtable y Slack

Trabajas con un equipo en Airtable, gestionas tareas ahí. Pero el equipo vive en Slack. Cada vez que alguien crea o cambia una tarea, hay que avisar. Avisar a mano se olvida. La integración nativa solo da el evento básico, no el contexto.

Qué hace el agente, escena por escena:

• Tarea cambia a estado "en revisión" en Airtable, sale mensaje al canal de revisiones de Slack con el enlace
• Tarea con fecha límite mañana, sale mensaje privado al asignado a las 18:00
• Tarea bloqueada con un comentario, sale hilo en el canal del proyecto avisando del bloqueo
• Tarea cerrada por alguien que no la abrió, sale mensaje privado al original con un resumen de qué cambió

El agente filtra. No avisa de cualquier cambio (eso es ruido). Avisa solo de los eventos que requieren una decisión humana. Esta es la clave de los agentes que ahorran tiempo en lugar de añadir notificaciones inútiles.

05Caso real: Drive y email

Compartes documentos con clientes desde Drive. Cuando alguien comenta o sube una nueva versión, te llega un correo de Google que se pierde entre los demás. Quieres saberlo en tu bandeja, con contexto, agrupado por cliente.

Qué hace el agente, escena por escena:

• Comentario en cualquier documento de la carpeta cliente X, sale email diario a las 19:00 con todos los comentarios del día agrupados
• Nueva versión subida por el cliente, sale email inmediato con el enlace a la versión y la diferencia respecto a la anterior
• Documento sin tocar en 7 días en estado "esperando cliente", sale email a ti recordando que toca enviar seguimiento

Aquí lo importante es agrupar. Sin agrupación, recibes 30 emails al día y dejas de leerlos. Con agrupación, recibes 1 email útil al final de la jornada. Esa es la diferencia entre una integración hecha por un humano y una hecha por la app por defecto.

06El patrón en 4 pasos

Cualquier agente intermedio se monta siguiendo estos 4 pasos. Sin saltarse ninguno.

Paso 1: define el evento disparador

¿Qué tiene que pasar en la herramienta A para que tu agente arranque? Sé concreto. No "cuando cambia algo", sino "cuando un deal pasa a estado X y tiene fecha rellena". Si el evento no está bien definido, el agente se ejecuta a deshora y mete ruido.

Paso 2: mapea los campos

Coge cada dato del lado A y dile a qué dato corresponde en B. Hazlo en una tabla, como las de los casos de arriba. Mapear sobre el papel ahorra horas de depurar después. Si un campo de A no encaja con ninguno de B, decide ahí mismo si lo descartas o si necesitas un campo nuevo en B.

Paso 3: escribe el agente traductor

Esta es la parte de código. Y es más corta de lo que parece. Recibes el evento de A, transformas los datos según el mapeo, llamas a la API de B con esos datos. La parte que más cuesta no es escribir, es probar con casos raros: ¿qué pasa si el campo viene vacío?, ¿qué pasa si el cliente borra el dato a mitad?, ¿qué pasa si la API de B está caída?

Paso 4: conecta el cron o el webhook

Decides cómo se dispara el agente. Si la herramienta A ofrece webhook, úsalo: te avisa al instante. Si no, montas un cron que revisa cada X minutos. Para casos urgentes (calendario, ventas) usa webhook. Para casos diarios (resúmenes, reportes) basta con cron una vez al día.

Quieres ir más allá

El método Claude

El módulo de integraciones enseña a montar agentes intermedios reutilizables, con plantillas para los 12 conectores más típicos y una librería de errores comunes ya resueltos.

Ver el método →

07Cómo construirlo en una tarde

Si nunca has montado uno, plantéatelo en bloques de tiempo. Una tarde de 4 horas:

1. Hora 1: escribe en una nota qué tiene que pasar exactamente y mapea los campos de A a B en una tabla. Sin abrir ninguna herramienta.
2. Hora 2: abre las dos apps y verifica que ofrecen API y webhook. Si una no los ofrece, busca alternativa o cambia el caso. No fuerces.
3. Hora 3: monta la primera versión que funciona con un caso ideal. Sin manejo de errores, sin avisos. Solo: entra esto, sale esto.
4. Hora 4: añade los avisos para cuando algo falle, prueba con 3 casos raros, déjalo corriendo en producción.

El error típico es saltarse la hora 1. La gente abre las apps directo y empieza a tocar. Acaba con un agente que casi funciona pero que nadie entiende, ni siquiera la persona que lo montó hace tres semanas.

08Errores comunes

1. No definir cuál es la fuente de verdad. Si las dos apps editan el mismo dato, en una semana tienes datos contradictorios y nadie sabe cuál es el bueno. Decide al principio: una manda, la otra obedece.
2. Avisar de todo. Si tu agente manda 50 mensajes al día a Slack, el equipo lo silencia y deja de servir. Filtra solo lo que requiere acción humana.
3. No probar con datos raros. Lo que falla siempre es el campo vacío, la fecha en formato inesperado o el cliente con caracteres raros en el nombre. Prueba esos antes de pasar a producción.
4. No avisar cuando el agente se cae. Si la API de B deja de responder y tu agente se rompe en silencio, descubres el problema cuando un cliente se queja. Pon un aviso a tu Telegram cuando pasen 24 horas sin actividad.
5. Saltar el paso 2 del mapeo. Improvisar el mapeo dentro del código mientras escribes te lleva a duplicar lógica y olvidar campos. La tabla en una nota cuesta 15 minutos y se ahorra 4 horas de depurar.

Volver al inicio de la serie

Cómo hacer un reel como este

Vuelta al primer recurso. Ahora con producto que vender, mensaje validado y agentes limpios, el reel es la pieza que mete a la gente en el funnel completo.

Aprende gratis