# FCG Systems: contenido completo > FCG Systems construye los sistemas detrás de los negocios de formación online que ya venden: un CRM a medida para setters y closers, una academia donde el alumno paga y entra solo y desarrollo a medida, todo a nombre del cliente y documentado. Empresa con sede en Huelva, España, fundada por Gabriel Florencio Calvo. Este fichero reúne el texto de las páginas clave y de todos los artículos del blog. Índice breve: https://fcgsystems.es/llms.txt Generado: 2026-10-09 --- # FCG Systems: Construimos el sistema que hace que controles tu negocio de formación. > Construimos el sistema que hace que controles tu negocio de formación: CRM para setters y closers, academia donde el alumno paga y entra solo, y desarrollo a medida. Fuente: https://fcgsystems.es/ Un CRM hecho a tu proceso comercial, una academia donde el alumno paga y entra solo, y el desarrollo que haga falta entre medias. Todo a tu nombre y documentado. ## FCG Systems en breve - **Qué es:** FCG Systems es una empresa de tecnología que construye los sistemas detrás de los negocios de formación online que ya venden: un CRM a medida, una academia donde el alumno paga y entra solo, y el desarrollo a medida que haga falta, trabajados como un solo sistema. - **Dónde:** Tiene su sede en Huelva, España, y trabaja en remoto con clientes en Madrid, Barcelona, Andorra y Dubái. - **Quién la dirige:** La fundó Gabriel Florencio Calvo, que pasó de setter al equipo técnico de un gran negocio de formación online. Quien diseña la solución está en el proyecto desde la primera llamada. Si hace falta otro especialista, el cliente lo sabe y lo aprueba antes de firmar. - **Forma jurídica:** Actividad profesional de Gabriel Florencio Calvo, autónomo con NIF 49236244Y y domicilio en Huelva. - **Para quién:** Fundadores de negocios de formación e infoproductos que ya venden de forma recurrente, con setters, closers y soporte, y a sus CTO y CMO. También agencias creativas y de marketing que necesitan un partner técnico para sus clientes. - **Cómo se trabaja:** Por proyectos cerrados con precio cerrado por fase (auditoría de sistemas de 5 a 10 días laborables, sprint de automatización de 1 a 3 semanas, construcción del sistema de 3 a 8 semanas, IA en un proceso e infraestructura de lanzamiento) o con una cuota mensual como partner tecnológico, en planes Core, Growth y Scale. Todo queda a nombre del cliente y documentado. - **Qué no es:** No es una agencia de marketing, ni soporte informático, ni programadores a sueldo sin dirección técnica ni objetivo de negocio. - **Producto propio:** CommunityRedirect, un sistema que reparte el tráfico de un lanzamiento entre grupos y comunidades de WhatsApp sin enviar a nadie a un grupo lleno. - **Contacto:** hola@fcgsystems.es. Responde en un día laborable. ## Servicios - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Sistemas de IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. - [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/): Servidores, despliegues, backups y alertas para que tu operación no se caiga y sea tuya. - [Infraestructura de lanzamientos](https://fcgsystems.es/servicios/infraestructura-de-lanzamientos/): Captación, tracking, reparto a tu equipo comercial y WhatsApp listos para miles de registros. - [Partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/): Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. ## Formatos de trabajo Cuatro formas de trabajar juntos, de un diagnóstico de días a una relación continua. Si no tienes claro cuál encaja, empieza por la auditoría. - **Auditoría de sistemas** (5–10 días laborables): Negocios de formación con muchas herramientas, automatizaciones y procesos, pero sin una foto clara de qué funciona y qué cuesta. Mapa de sistemas y procesos; Riesgos y puntos de fallo; Arquitectura objetivo; Roadmap de 90 días. - **Sprint de automatización** (1–3 semanas): Un cuello de botella concreto: reparto de leads, altas de alumnos, accesos, seguimiento comercial o reporting. Diseño y automatización; Integraciones y pruebas; Avisos de error y documentación; Traspaso a tu equipo. - **Construcción del sistema** (3–8 semanas): Un proceso crítico que necesita un CRM, una academia o un panel completos, no otra automatización suelta. Base de datos y panel interno; Automatizaciones e integraciones; Permisos por rol; Tracking e infraestructura. - **Partner tecnológico** (Mensual): Negocios que quieren un equipo técnico que responda cuando algo se rompe, sin montar un departamento interno. Mantenimiento e incidencias; Desarrollo continuo; Roadmap y arquitectura; Capacidad mensual definida. ### Cómo empezar sin riesgo 1. **Primero, la auditoría.** Auditoría de sistemas, de 5 a 10 días laborables. Alcance, entregables e inversión quedan cerrados por escrito antes de empezar, sin sorpresas. 2. **Lo que recibes es tuyo.** Mapa de sistemas, riesgos, arquitectura objetivo y roadmap de 90 días. Te lo quedas aunque no sigas con nosotros y puedes construirlo con quien quieras. Sin depender de nadie. 3. **Después, la construcción.** Solo si tiene sentido. Con el roadmap delante, la propuesta llega con alcance, plazos y precio cerrado por fase. ## Para quién Fundadores de infoproductos y academias que ya venden de forma recurrente, con setters, closers y soporte, pero sin nadie dentro que entienda de verdad la parte técnica. La operación crece más rápido que las herramientas. - **Fundadores de infoproductos y academias:** Quieren quitarse el marrón técnico de encima sin montar un departamento, y fiarse de los números que ven. - **CMO y responsables de captación:** Necesitan saber qué canal trae alumnos que pagan, no solo registros. - **CTO o responsable técnico:** Llevan la tecnología solos o con poco equipo y necesitan un socio que construya, documente y se quede después. - **Agencias creativas y de marketing:** Un partner al que delegar desarrollos que su equipo no puede asumir, o llevar a producción lo que prototiparon con IA. Si mañana duplicaras tus ventas, ¿qué parte de tu negocio dejaría de funcionar? ## Casos - [Un campus propio conectado al CRM de ventas](https://fcgsystems.es/casos/campus-propio-conectado-al-crm/): Cursos, clases en directo, diario de operativa y revisión de trabajos en un solo sitio, conectados al CRM. El equipo ve qué consume cada alumno sin ir herramienta por herramienta. - [Un CRM a medida que sustituye a Airtable, con comisiones por agente](https://fcgsystems.es/casos/crm-a-medida-con-comisiones-por-agente/): Leads, oportunidades, cobros, comisiones por agente y permisos según el rol de cada uno, en un CRM hecho a la medida del proceso comercial. - [Una bandeja compartida sobre la API oficial de WhatsApp](https://fcgsystems.es/casos/bandeja-compartida-api-oficial-whatsapp/): Las conversaciones de venta dejan de vivir en móviles personales: una bandeja compartida, asignada por comercial y sincronizada con el CRM. - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/): Formularios, tracking, CRM y agenda comercial conectados en un solo sistema, con el origen de cada lead a la vista. Las tres etapas del funnel mejoraron. - [Infraestructura para lanzamientos con miles de registros](https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/): Miles de registros desde cinco canales, sin duplicados, repartidos al equipo comercial y medidos mientras el lanzamiento sigue en marcha. - [CommunityRedirect: un enlace para no perder registros en grupos llenos](https://fcgsystems.es/casos/communityredirect-distribucion-comunidades-whatsapp/): Un enlace único que consulta la capacidad, rota destinos y evita enviar usuarios a grupos de WhatsApp llenos. ## Blog (en español) - ["Funciona" no es el listón: lo que reviso antes de dar algo por terminado](https://fcgsystems.es/blog/funciona-no-es-el-liston/): La demo siempre sale bien: la haces tú, con datos limpios y sin prisa. Lo que de verdad decide si algo está terminado son las preguntas del día malo. - [Agente de voz con IA: cuándo automatizar una llamada tiene sentido (y cuándo es humo)](https://fcgsystems.es/blog/agente-de-voz-ia/): Qué es un agente de voz con IA, cómo funciona por dentro y en qué llamadas compensa: latencia, interrupciones, traspaso a humano y qué no se delega al modelo. - [Agentes de IA para negocios: qué son, cuándo compensan y cómo se construyen sin perder el control](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/): Qué es un agente de IA, en qué se diferencia de un chatbot o una automatización, cuándo compensa en un negocio digital y cómo crearlo paso a paso con control. - [Automatización de marketing: qué se automatiza bien y qué se rompe cuando el dato está sucio](https://fcgsystems.es/blog/automatizacion-de-marketing/): Qué se automatiza bien en marketing, qué se rompe cuando los datos del CRM están sucios y la higiene mínima que necesita un flujo antes de activarlo. - [Automatizar sin vigilar es peor que no automatizar](https://fcgsystems.es/blog/automatizar-sin-vigilar-es-peor/): Una automatización sin alertas y sin dueño no te ahorra trabajo: te lo esconde. Por qué el fallo silencioso hace más daño que el proceso manual que sustituye. - [Cerrar clientes sin audiencia: se vende por criterio, no por postureo](https://fcgsystems.es/blog/cerrar-clientes-sin-audiencia/): Se puede cerrar trabajo serio con una cuenta de tres cifras de seguidores. No es carisma ni volumen: es diagnosticar mejor que nadie y saber decir que no. - [Cómo funciona n8n: cuatro ejemplos reales de flujos para un negocio digital](https://fcgsystems.es/blog/como-funciona-n8n-ejemplos/): Cómo funciona n8n explicado con cuatro ejemplos de negocio: leads al CRM, acceso tras el pago, conciliación nocturna y clasificación con IA, con sus fallos. - [CRM para pymes y negocios digitales: para qué sirve, cómo elegirlo y cuándo compensa uno a medida](https://fcgsystems.es/blog/crm-para-pymes-saas-o-a-medida/): Para qué sirve un CRM en una pyme o negocio digital, qué exigirle antes de elegirlo y cuándo compensa un CRM SaaS, uno a medida o una combinación de ambos. - [Dar permisos a un agente de IA es una decisión de riesgo, no una casilla de configuración](https://fcgsystems.es/blog/permisos-de-un-agente-decision-de-riesgo/): Qué no se delega nunca a un modelo: accesos, cobros, precios e identidad. Cómo decidir los permisos de un agente de IA con criterio de riesgo, no de setup. - [De prototipo con IA a producción: lo que siempre falta cuando la demo ya funciona](https://fcgsystems.es/blog/de-prototipo-ia-a-produccion/): Qué falta siempre para llevar a producción una app creada con IA: permisos, datos, pagos, límites, observabilidad, costes y propiedad. Con checklist accionable. - [Diferencia entre CRM y ERP: qué resuelve cada uno y cuándo necesitas los dos](https://fcgsystems.es/blog/diferencia-crm-erp/): Qué diferencia hay entre un CRM y un ERP, qué procesos cubre cada uno, por dónde empezar en un negocio digital y cómo conectarlos sin duplicar datos. - [El caos técnico no aparece en la cuenta de resultados hasta que ya es tarde](https://fcgsystems.es/blog/caos-tecnico-coste-invisible/): El desorden técnico no tiene una línea propia en tus cuentas: se reparte en cobros que fallan, accesos mal dados y horas a mano. Cómo ponerle número. - [El piloto de IA que nunca llega a producción: por qué la demo funciona y el sistema no existe](https://fcgsystems.es/blog/el-piloto-de-ia-que-nunca-llega-a-produccion/): Por qué tantas pruebas de IA se quedan en demo eterna, qué separa un piloto de un sistema en producción y qué exijo antes de dar por buena una prueba. - [Facturación electrónica obligatoria: qué sistemas tuyos tienen que hablar entre sí](https://fcgsystems.es/blog/facturacion-electronica-integracion/): Qué es la facturación electrónica obligatoria en España, qué plazos marca el Real Decreto 238/2026 y cómo integrarla con tu CRM, tus pagos y tus altas. - [Funnel de ventas: las etapas y las piezas técnicas que lo hacen medible](https://fcgsystems.es/blog/funnel-de-ventas-sistema/): Qué es un funnel de ventas, cuáles son sus etapas y qué pieza técnica necesita cada una para que el embudo se pueda medir y operar sin cifras inventadas. - [Herramientas de automatización: qué categorías hay y cuándo cada una se queda corta](https://fcgsystems.es/blog/herramientas-de-automatizacion/): Panorama de las herramientas de automatización por categorías, con los criterios que deciden la elección y las señales de que la tuya se ha quedado corta. - [KPI: qué es, cuáles mirar de verdad en un negocio digital y de dónde sale cada número](https://fcgsystems.es/blog/kpis-negocio-digital/): Qué es un KPI, en qué se diferencia de una métrica y qué indicadores mirar en un negocio digital: CAC, LTV, conversión por etapa y de dónde sale cada dato. - [La IA no elimina la revisión del código: la convierte en el cuello de botella real](https://fcgsystems.es/blog/la-ia-no-elimina-la-revision/): Generar código dejó de ser el límite. Ahora lo es el criterio para revisarlo. Por qué el volumen de código generado por IA hace la revisión más necesaria. - [Lead scoring con reglas o con IA: qué necesitas antes de puntuar y qué hacer con el score](https://fcgsystems.es/blog/lead-scoring-reglas-o-ia/): Qué es el lead scoring, qué datos necesitas antes de puntuar, cómo se calcula con reglas, cuándo aporta la IA y qué hacer con el score en el reparto comercial. - [Lovable vs Bolt vs v0: comparativa honesta por criterios de uso real](https://fcgsystems.es/blog/lovable-vs-bolt-vs-v0/): Lovable vs Bolt vs v0: para qué sirve cada una, qué código genera, qué control te deja, qué pasa al exportar y cuándo ninguna de las tres es la respuesta. - [Lovable: qué es, qué resuelve de verdad y hasta dónde llega antes de ser un producto](https://fcgsystems.es/blog/lovable-que-es-y-hasta-donde-llega/): Qué es Lovable, qué construye realmente con IA y dónde está su límite: datos, permisos, pagos, dominio, copias y costes antes de llamarlo producto. - [Modelos de atribución: último clic, lineal, basado en datos y por qué ninguno te va a cuadrar solo](https://fcgsystems.es/blog/modelos-de-atribucion/): Qué son los modelos de atribución, cómo reparte el crédito cada uno, qué sesgo tiene y por qué un negocio digital necesita su propia atribución en el CRM. - [Prototipos con IA para clientes de agencia: vender y validar sin prometer lo que no se sostiene](https://fcgsystems.es/blog/prototipo-con-ia-para-clientes-de-agencia/): Cómo usar Lovable, Bolt o v0 para vender y validar con tu cliente sin prometer de más, qué entregar al equipo técnico, qué preguntar y qué no firmar. - [Qué es el vibe coding: de dónde viene, dónde funciona de verdad y dónde te la juegas](https://fcgsystems.es/blog/que-es-vibe-coding/): Qué es el vibe coding, quién acuñó el término y en qué casos funciona: prototipos e internas sí, dinero, datos y accesos no. Con el límite explicado sin humo. - [Qué es la atribución en marketing (y por qué nunca cuadra entre canales)](https://fcgsystems.es/blog/que-es-la-atribucion/): Qué es la atribución en marketing, qué significa atribuir una venta a un canal, por qué las cifras no coinciden entre herramientas y qué mirar para decidir. - [Qué es la automatización de procesos (y qué no lo es)](https://fcgsystems.es/blog/que-es-automatizacion-de-procesos/): Qué es la automatización de procesos, para qué sirve, qué tipos hay y cuándo no compensa automatizar. Explicado desde quien construye y opera los sistemas. - [Qué es MCP (Model Context Protocol) y qué cambia para un negocio que ya tiene sus sistemas](https://fcgsystems.es/blog/que-es-mcp-model-context-protocol/): Qué es el Model Context Protocol, en qué se diferencia de una API, cuándo compensa montar un servidor MCP propio y qué permisos no deberías exponer nunca. - [Qué es n8n y para qué sirve: la guía para un negocio que ya factura, no un tutorial de instalación](https://fcgsystems.es/blog/que-es-n8n/): Qué es n8n y para qué sirve en un negocio que ya factura: qué procesos resuelve, qué cuesta operarlo, qué dice su licencia y cuándo no es la respuesta. - [Qué es Stripe y cómo se integra con tus accesos, tu CRM y tu embudo de venta](https://fcgsystems.es/blog/que-es-stripe/): Qué es Stripe, en qué se diferencian Link y los enlaces de pago, qué comisiones cobra en España y cómo conectarlo con tu CRM, tus accesos y tu facturación. - [Qué es un chatbot (y en qué se diferencia de un agente de IA)](https://fcgsystems.es/blog/que-es-un-chatbot/): Qué es un chatbot, cómo funciona, qué tipos hay y en qué se diferencia de ChatGPT o de un agente de IA. Con las desventajas reales y cuándo no hace falta. - [Qué es un CRM (y qué es en realidad para un negocio digital)](https://fcgsystems.es/blog/que-es-un-crm/): Qué es un CRM, para qué sirve en una empresa, qué tipos hay y en qué se diferencia de un ERP. Con el criterio de cuándo un Excel deja de ser suficiente. - [Qué es un dashboard (y por qué el tuyo no sirve para decidir)](https://fcgsystems.es/blog/que-es-un-dashboard/): Qué es un dashboard, qué significa en español, qué debe tener y en qué se diferencia de un informe. Y por qué muchos paneles no sirven para decidir nada. - [Qué es un infoproducto y qué infraestructura necesita por debajo para funcionar](https://fcgsystems.es/blog/infoproductos-que-son/): Qué es un infoproducto, qué tipos hay y qué necesita cada uno por debajo: pagos, accesos, entregas y datos. La parte técnica que decide si aguanta o no. - [Qué es un lead (en marketing, en ventas y dentro de tu CRM)](https://fcgsystems.es/blog/que-es-un-lead/): Qué es un lead, qué significa en español, qué tipos existen y en qué se diferencia de un contacto. Con el matiz que importa: cómo se define en tu CRM. - [Qué es un UTM y cómo montar una nomenclatura de campañas que no se rompe](https://fcgsystems.es/blog/que-es-utm/): Qué es un UTM, para qué sirve cada parámetro y cómo fijar una nomenclatura de campañas que no rompa la atribución cuando cada persona escribe lo que quiere. - [Revisar código generado por IA: qué mirar antes de que toque dinero, datos o accesos](https://fcgsystems.es/blog/revisar-codigo-generado-por-ia/): Cómo revisar el código que genera la IA antes de publicarlo: permisos, secretos, dependencias, validación y registro, ordenado por las categorías de OWASP 2025. - [Si todo depende de una persona no tienes un sistema, tienes un rehén](https://fcgsystems.es/blog/cuando-el-sistema-eres-tu/): Un negocio donde todo pasa por una cabeza no es un negocio ágil, es un negocio secuestrado. Cómo saber si el rehén eres tú y por dónde se empieza a soltar. - [Tipos de CRM: operativo, analítico, colaborativo y el cuarto que casi nadie menciona](https://fcgsystems.es/blog/tipos-de-crm/): Qué tipos de CRM existen, qué resuelve cada uno, en qué se quedan cortos y cuándo un negocio digital necesita un CRM a medida en vez de otro SaaS. - [Transcripción de audio a texto con IA: cómo automatizarla para llamadas, reuniones y contenido](https://fcgsystems.es/blog/transcripcion-audio-texto-ia/): Cómo pasar audio a texto con IA y automatizarlo de verdad: llamadas de ventas al CRM, actas y contenido, con criterios de precisión, idioma y coste. - [Tu stack no está roto por usar no-code, está roto por no saber dónde vive la verdad](https://fcgsystems.es/blog/no-code-fuente-de-verdad/): Defensa honesta del no-code y de su límite real. El problema casi nunca es la herramienta: es que el mismo dato vive en cuatro sitios y ninguno manda. - [Vendí un infoproducto en el que dejé de creer, y eso decide lo que construyo hoy](https://fcgsystems.es/blog/vendi-un-infoproducto-en-el-que-deje-de-creer/): Me fui del primer infoproducto que vendí porque no cumplía lo que prometía. Lo que aquello me enseñó sobre construir sistemas que se pueden defender. - [Verifactu: qué cambia en tu facturación y qué tiene que hacer tu software (no tu asesor)](https://fcgsystems.es/blog/verifactu-que-es/): Qué es Verifactu, qué exige el reglamento a tu software de facturación, qué plazos marca el BOE y qué tienes que tocar en tus sistemas antes de 2027. - [Sistemas para negocios digitales: qué son, qué capas tienen y cuándo los necesitas](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/): Qué es un sistema para negocios digitales, qué capas tiene (automatización, software, IA, infraestructura y datos) y cómo saber si tu operación ya lo necesita. - [Atribución rota: por qué GA4, Meta y tu CRM nunca dan la misma cifra](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/): Seguimos el recorrido de un registro para ver dónde se pierde su origen entre anuncio, formulario, WhatsApp y CRM, y cómo montar una atribución de leads fiable. - [Automatización de procesos con IA: qué automatizar primero, qué dejar en reglas y dónde todavía no compensa](https://fcgsystems.es/blog/ia-aplicada-negocios-digitales/): Qué procesos se pueden automatizar con IA y cuáles no, en qué se diferencia de una automatización normal, y cómo controlar la calidad en producción. - [Cuando todo depende de una persona: capacidad técnica sin montar un departamento](https://fcgsystems.es/blog/dependencia-de-una-persona-capacidad-tecnica/): Si tus automatizaciones dependen de una sola persona, tienes un riesgo operativo. Cómo repartirlo: documentación, ownership y un departamento técnico externo. - [El problema de muchas automatizaciones no es que fallen: es que nadie sabe que han fallado](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/): Por qué las automatizaciones que fallan sin avisar son más peligrosas que las que se rompen del todo, y cómo hacer observable un flujo de n8n, Make o Zapier. - [Leads que se pierden: del formulario al comercial sin un Excel de por medio](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/): Por qué se pierden leads entre formulario, WhatsApp y comercial, cuándo un Excel deja de servir como CRM y cómo automatizar la asignación sin parar las ventas. - [n8n precios: Cloud o self-hosted, qué cuesta de verdad y qué necesitas para operarlo en producción](https://fcgsystems.es/blog/n8n-precios-cloud-self-hosted/): Precios de n8n Cloud, qué cuenta como ejecución, cuánto cuesta de verdad n8n self-hosted y qué necesita en producción: Postgres, clave de cifrado y backups. - [n8n vs Make y otras alternativas a n8n: cuál elegir para un negocio digital que ya tiene volumen](https://fcgsystems.es/blog/n8n-vs-make/): n8n vs Make y otras alternativas a n8n para un negocio digital: coste por ejecución o por crédito, gestión de errores, servidor propio y cuándo elegir cada una. - [Pagos fallidos en Stripe: cómo recuperarlos y dar o quitar el acceso al curso sin hacerlo a mano](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/): Qué hace Stripe con un pago recurrente fallido, qué estado de suscripción debe dar o quitar el acceso a tu curso o membresía y cómo automatizarlo sin errores. - [Píxel de Meta y API de conversiones: cómo usar los dos sin contar cada conversión dos veces](https://fcgsystems.es/blog/pixel-meta-api-conversiones-duplicados/): Por qué Meta cuenta leads y compras dos veces al usar píxel y API de conversiones, cómo funciona la deduplicación con event_id y qué revisar paso a paso. - [Qué tiene que estar listo antes de abrir registros en un lanzamiento: checklist técnico](https://fcgsystems.es/blog/checklist-tecnico-lanzamiento/): Checklist técnico de un lanzamiento por fases: captación, tracking, deduplicación, CRM, asignación, WhatsApp y dashboards listos antes de abrir registros. - [Software a medida o no-code: señales de que Make, n8n o Airtable se os han quedado cortos](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/): Qué es el software a medida, cuándo compensa frente al no-code, señales de que Make, n8n o Airtable no bastan y cómo migrar por piezas sin parar la operación. - [Webhook de n8n que no funciona: causas, cómo diagnosticarlo y cómo evitar que vuelva a fallar](https://fcgsystems.es/blog/webhook-n8n-no-funciona/): Por qué un webhook de n8n funciona en pruebas y no en producción, qué significan 404 y 524 y cómo diagnosticarlo paso a paso sin perder los datos que llegan. - [WhatsApp Business API: qué es, cuánto cuesta y cuándo usarla para vender, automatizar o poner un chatbot](https://fcgsystems.es/blog/whatsapp-business-api/): Qué es la WhatsApp Business API, en qué se diferencia de la app, cómo cobra Meta, sus límites y cuándo compensa para ventas, automatización o un chatbot con IA. ## Preguntas frecuentes ### ¿Qué hace exactamente FCG Systems? Construimos el sistema que hace que controles tu negocio de formación: un CRM hecho a tu proceso comercial, una academia donde el alumno paga y entra solo, y el desarrollo a medida que no encuentras en el mercado. Primero entendemos cómo funciona tu negocio y después decidimos qué tecnología necesita. No vendemos horas de programación: vendemos que tus números cuadren y que tu equipo deje de hacer a mano lo que puede hacer el sistema. ### ¿Con quién voy a trabajar de verdad? Con quien te atiende en la primera llamada: es quien diseña la solución y se queda en el proyecto hasta la entrega. Sin intermediarios ni comerciales que luego desaparecen. Si un proyecto necesita a otro especialista, lo sabes y lo apruebas antes de firmar. Y todo queda documentado, para que tu negocio no dependa de ninguna persona en concreto, tampoco de nosotros. ### ¿En qué os diferenciáis de un freelance o de una agencia? Un freelance barato a menudo se va a medias y deja algo que nadie entiende. Una agencia de desarrollo puede ser cara, lenta y no entender tu negocio. Nosotros empezamos por entender cómo vendes y cómo trabaja tu equipo, entregamos por fases con precio cerrado, dejamos todo documentado y a tu nombre, y seguimos ahí después de la entrega, no solo hasta cobrar. Si algo se rompe, hay alguien que responde. ### ¿Con qué herramientas trabajáis? Con las que pida tu sistema: n8n, Make, Airtable, Postgres, la API oficial de WhatsApp, código propio en TypeScript y Python, GA4 y Google Tag Manager, servidores propios, entre otras. La herramienta se elige según tu negocio, no al revés. Si lo que ya usas funciona, lo aprovechamos: no sustituimos por sustituir. ### ¿Trabajáis con empresas fuera de España? Sí. Tenemos base en España y trabajamos en remoto, en español o en inglés, con clientes en Madrid, Barcelona, Andorra y Dubái. Las reuniones se organizan en el horario que funcione para ti y para tu equipo. ### ¿Cómo empieza un proyecto y cuánto tarda? Con una llamada de diagnóstico sobre tu negocio: cómo vendes, cuántos leads y alumnos manejas, qué herramientas pagas y qué te está frenando. Si encaja, lo habitual es empezar por la auditoría: de 5 a 10 días laborables, con un mapa de tus sistemas, los riesgos, la arquitectura objetivo y un roadmap que te quedas aunque no sigas. Después, una llamada para presentarte la propuesta y, si te encaja, cerramos. Un CRM o una academia suelen llevar entre 3 y 8 semanas, con plazos escritos antes de empezar. Si lo necesitas, firmamos un acuerdo de confidencialidad antes de que compartas información sensible. ### ¿Cuánto cuesta y cuándo se amortiza? ¿Precio cerrado o por horas? Precio cerrado por fase y con alcance escrito: antes de empezar recibes entregables, plazos e inversión de esa fase. Para valorarlo, compáralo con lo que ya pagas: suscripciones que suben con cada usuario, herramientas que no encajan y horas de tu equipo haciendo a mano lo que debería hacer el sistema. Con el equipo sustituimos cinco herramientas de pago por sistemas propios, con un ahorro de entre 5.000 y 15.000 € al año en suscripciones. Cuando eso ya cuesta más que tener el sistema propio, ahí está la amortización. El partner tecnológico es una cuota mensual fija con capacidad definida. Si aparece algo fuera del alcance, se presupuesta aparte antes de hacerlo, y sin tu visto bueno no se ejecuta. ### ¿Todo queda a mi nombre? ¿Voy a depender de vosotros? No. El código, los repositorios, los servidores y las cuentas de terceros quedan a nombre de tu empresa, con tus accesos de administración. Si durante el proyecto algo se aloja temporalmente en infraestructura de FCG Systems, se indica por escrito y se migra a tu nombre en la entrega. Nosotros trabajamos con usuarios propios que puedes retirar cuando quieras. Las credenciales viven en un gestor, nunca en un documento ni en un chat. ### ¿Qué pasa al entregar el proyecto o si dejamos de trabajar juntos? Recibes el sistema funcionando, con documentación, arquitectura, instrucciones de uso y un plan de mantenimiento. Puedes llevarlo con tu equipo, con otro proveedor o con nosotros como partner tecnológico. Si dejamos de trabajar juntos, te llevas todo lo anterior, retiras nuestros accesos y hacemos el traspaso a quien elijas. Nada queda en una caja negra. ### ¿Podéis enseñarme documentación de otro proyecto o darme referencias? La documentación de cada proyecto pertenece a su cliente y está bajo confidencialidad, así que no la compartimos. Publicamos los casos anonimizados, sin nombres. La forma de ver cómo documentamos es la auditoría, cuyos entregables te quedas. Si necesitas hablar con un cliente anterior, se lo pedimos a ese cliente y solo facilitamos el contacto con su permiso. ### ¿Usáis IA de verdad o es solo marketing? La usamos donde hay retorno medible: clasificar mensajes de leads, resumir llamadas de venta, puntuar leads o responder a tus alumnos con tu documentación. Cada automatización con IA se pone en producción con su registro, sus límites y su control de costes. Si una regla simple resuelve el problema, no hace falta un modelo. ### ¿Mi negocio encaja? ¿Hay un tamaño mínimo? No hay una cifra fija, pero encajamos mejor con negocios de formación que ya venden de forma recurrente, tienen equipo (setters, closers, soporte) y pierden dinero o tiempo por errores y trabajo manual. Si todavía no vendes, o tu problema no es urgente, te lo diremos con claridad: antes de construir sistemas toca validar la oferta. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. - Empresa: https://fcgsystems.es/empresa/ --- # Construimos el sistema que hace que controles tu negocio de formación > FCG Systems es la empresa de tecnología de los negocios de formación online que ya venden. Entendemos cómo funciona tu operación y construimos el CRM, la academia y el software que necesita, a tu nombre y documentado. Fuente: https://fcgsystems.es/empresa/ ## FCG Systems en breve - **Qué es:** FCG Systems es una empresa de tecnología que construye los sistemas detrás de los negocios de formación online que ya venden: un CRM a medida, una academia donde el alumno paga y entra solo, y el desarrollo a medida que haga falta, trabajados como un solo sistema. - **Dónde:** Tiene su sede en Huelva, España, y trabaja en remoto con clientes en Madrid, Barcelona, Andorra y Dubái. - **Quién la dirige:** La fundó Gabriel Florencio Calvo, que pasó de setter al equipo técnico de un gran negocio de formación online. Quien diseña la solución está en el proyecto desde la primera llamada. Si hace falta otro especialista, el cliente lo sabe y lo aprueba antes de firmar. - **Forma jurídica:** Actividad profesional de Gabriel Florencio Calvo, autónomo con NIF 49236244Y y domicilio en Huelva. - **Para quién:** Fundadores de negocios de formación e infoproductos que ya venden de forma recurrente, con setters, closers y soporte, y a sus CTO y CMO. También agencias creativas y de marketing que necesitan un partner técnico para sus clientes. - **Cómo se trabaja:** Por proyectos cerrados con precio cerrado por fase (auditoría de sistemas de 5 a 10 días laborables, sprint de automatización de 1 a 3 semanas, construcción del sistema de 3 a 8 semanas, IA en un proceso e infraestructura de lanzamiento) o con una cuota mensual como partner tecnológico, en planes Core, Growth y Scale. Todo queda a nombre del cliente y documentado. - **Qué no es:** No es una agencia de marketing, ni soporte informático, ni programadores a sueldo sin dirección técnica ni objetivo de negocio. - **Producto propio:** CommunityRedirect, un sistema que reparte el tráfico de un lanzamiento entre grupos y comunidades de WhatsApp sin enviar a nadie a un grupo lleno. - **Contacto:** hola@fcgsystems.es. Responde en un día laborable. ## Por qué existe FCG Systems FCG Systems existe porque vimos lo mismo una y otra vez dentro de negocios de formación online: mucho flujo de ventas y, por dentro, trabajo manual, herramientas que no se hablan entre ellas y datos en los que nadie se fía. Contratar un departamento técnico completo no siempre compensa. Encadenar freelances tampoco lo resuelve. Trabajamos como partner tecnológico, no como proveedor de horas. Quien te atiende en la primera llamada es quien diseña tu sistema, sin intermediarios. Si un proyecto necesita a otro especialista, lo sabes y lo apruebas antes de firmar. Cada sistema se documenta y queda a nombre de tu empresa, para que su funcionamiento no dependa de nadie en concreto, tampoco de nosotros. ## Quién está detrás Gabriel Florencio Calvo fundó FCG Systems tras pasar de setter al equipo técnico de uno de los negocios de formación más grandes de habla hispana. Ha sido comercial y técnico en el mismo negocio, y trabaja con clientes en Madrid, Barcelona, Andorra y Dubái. ## Cómo trabajamos contigo Tres formas de relación, según el momento de tu negocio. - **Proyecto cerrado:** Un CRM, una academia o un desarrollo a medida, con alcance, plazos y entregables escritos antes de empezar, y precio cerrado por fase. - **Partner tecnológico:** Una cuota mensual fija como tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas, con alguien que responde cuando algo se rompe. - **Productos propios:** Cuando un problema se repite en muchos negocios, lo convertimos en producto. CommunityRedirect nació así, de los grupos de WhatsApp que se llenaban en cada lanzamiento. ## Qué recibes siempre Un sistema no está terminado cuando funciona en una demo. Está terminado cuando tu equipo lo puede usar, mantener y recuperar sin depender de nadie. ### Todo proyecto entrega - El sistema funcionando en producción - Todo a nombre de tu empresa, con tus accesos - Documentación - Arquitectura - Instrucciones de uso para tu equipo - Un responsable claro de cada pieza - Plan de mantenimiento y soporte ### Reglas que no negociamos - **Una cifra de verdad:** Cada dato crítico tiene un sistema principal. Los demás leen de él, así que el CRM, la pasarela y el banco dejan de contarte cosas distintas. - **Sin duplicados:** Si un proceso se reintenta, no duplica leads, cobros ni accesos, siempre que la plataforma lo permita. - **Avisos de fallo:** Un proceso crítico sin registro no está terminado. Si algo falla, tiene que saberse cuándo, dónde y por qué, antes de que lo note tu equipo. - **Copias de seguridad:** Si un dato no se puede reconstruir, necesita copia. Y una copia que nunca se ha restaurado no cuenta. - **Claves a salvo:** Las contraseñas viven en un gestor, nunca en documentos, en Notion ni en un chat. - **Nada a producción sin probar:** Ningún cambio llega a tu negocio sin validarse antes. Tampoco los cambios pequeños. ## Cómo tomamos decisiones - **Entender antes que vender:** Empezamos por cómo funciona el negocio y después decidimos qué tecnología necesita. Nunca al revés. - **Sistemas simples:** La complejidad técnica se queda dentro. Tu equipo recibe algo sencillo de usar y de mantener. - **Responsabilidad completa:** Entregar no basta. Pensamos en errores, avisos, mantenimiento y evolución desde el primer día. - **Negocio primero:** Cada decisión técnica depende de lo que cambia en el negocio, no de la herramienta de moda. - **Reutilizable por diseño:** Cuando un patrón aparece varias veces, se documenta y se reutiliza. Cada proyecto parte de algo probado. ## Lo que no hacemos Decir que no a lo que no encaja es lo que nos permite hacer bien lo que sí. Si lo que necesitas no te va a resolver nada, te lo decimos, aunque perdamos la venta. - Marketing 360 de agencia, community management ni compra de medios - Soporte informático de oficina ni mantenimiento de ordenadores - Programadores a sueldo sin dirección técnica ni objetivo de negocio - Sistemas para negocios que todavía no venden: primero toca validar la oferta - Proyectos pensados solo para ganar el precio más bajo ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Arquitectura de sistemas > Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. Fuente: https://fcgsystems.es/servicios/arquitectura-de-sistemas/ · FCG Systems **Antes de gastar en código o en otra herramienta, sabe qué tienes.** Tu negocio vende, pero nadie tiene la foto completa. El CRM dice una cosa, la pasarela de pago otra y el banco otra distinta. Eso pasa porque el stack no se diseñó: se acumuló, un formulario aquí, un CRM allí, tres automatizaciones montadas un viernes por la tarde. Revisamos cómo circula la información en tu negocio, dónde se rompe y qué depende de una sola persona. Sales con un mapa de lo que tienes, lo que te cuesta y un roadmap priorizado por impacto en el negocio, no por la herramienta de moda. Es el primer paso de cualquier proyecto con nosotros, y lo que recibes es tuyo aunque no sigamos: puedes ejecutarlo con tu equipo, con otro proveedor o con nosotros. ## Señales de que lo necesitas - Cada herramienta te da una cifra distinta y no sabes cuál es la buena - Nadie tiene un mapa completo de las integraciones - Una automatización falla y tardáis días en enteraros - Cada herramienta nueva añade trabajo en vez de quitarlo - Hay procesos que solo entiende una persona - Pagas suscripciones que nadie sabe si se siguen usando ## Qué construimos - **Mapa de herramientas:** Inventario de cada plataforma: quién la usa, qué datos toca y cuánto cuesta al mes. - **Recorrido del lead al alumno:** Cómo viaja un lead, un pago o un alta entre sistemas, paso a paso. - **Mapa de procesos:** Qué hace tu equipo a mano, qué está automatizado y dónde se pierde tiempo. - **Puntos de fallo:** Integraciones sin avisos de error, dependencias críticas y datos sin copia de seguridad. - **Una cifra de verdad:** Qué sistema manda para cada dato crítico: contactos, ventas, pagos y accesos. - **Roadmap a 90 días:** Qué construir primero, en qué orden y cuánto compensa frente a lo que pagas hoy. ## Cómo lo hacemos 1. **Entrevistas y accesos:** Hablamos con quien vende, quien cobra y quien toca las herramientas, y pedimos acceso de solo lectura a lo que usas. 2. **Mapa de sistemas:** Qué herramientas hay, qué datos se mueven entre ellas y qué depende de una sola persona. 3. **Dónde se rompe:** Cifras que no cuadran, integraciones frágiles, trabajo manual y suscripciones que nadie usa. 4. **Prioridades:** Ordenamos lo que hay que arreglar o construir por impacto en tu negocio, no por la herramienta de moda. 5. **Entrega del roadmap:** Un documento tuyo con el mapa, lo que te cuesta y el plan a 90 días, aunque no sigamos juntos. ## Entregables - Mapa de sistemas y de datos - Mapa de procesos actual - Riesgos y puntos de fallo - Arquitectura objetivo documentada - Roadmap de 90 días - Sesión de presentación con tu equipo ## Qué cambia - **Control:** Tu equipo sabe qué sistema manda para cada dato y puedes fiarte de lo que ves. - **Prioridades:** Inviertes primero donde el cuello de botella te cuesta más. - **Gasto bajo control:** Detectas herramientas duplicadas y automatizaciones que sobran antes de renovarlas. ## Formato - Formato: Auditoría de sistemas · proyecto cerrado - Duración: 5–10 días laborables - Herramientas habituales: n8n, Make, Airtable, Postgres, REST APIs, Webhooks, GA4 ## Preguntas frecuentes ### ¿Qué pasa después de la auditoría? Recibes la arquitectura y el roadmap, y decides tú. Puedes ejecutarlo con tu equipo, con otro proveedor o con nosotros. Si seguimos juntos, el roadmap se convierte directamente en el alcance del primer proyecto, con precio cerrado por fase. ### ¿Necesitáis acceso a todas nuestras herramientas? Para mapear bien, sí, con permisos de solo lectura siempre que la plataforma lo permita. Las credenciales se comparten a través de un gestor de contraseñas, nunca por chat ni en documentos. ### ¿Tiene sentido si ya tenemos a alguien técnico? Sí, y suele ir más rápido. Aportamos una visión externa de toda la operación, no solo del código, y dejamos a tu CTO o a tu equipo un mapa y unas prioridades sobre las que trabajar. ### ¿Y si ya nos fue mal con un freelance o una agencia? La auditoría está pensada para eso. Dejamos por escrito qué hay, qué falla y qué hace falta, así que no empiezas a ciegas con nadie, nosotros incluidos. Y como todo queda documentado, no dependes de quien lo construyó. ## Casos relacionados - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/) ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Academia y automatización > El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. Fuente: https://fcgsystems.es/servicios/automatizacion-de-procesos/ · FCG Systems **Academia a medida: el alumno paga, entra solo y tú lo ves todo.** Una academia a medida es el circuito completo desde que alguien paga hasta que entra: pago, alta automática, acceso al contenido, avisos de bienvenida y de renovación, control de accesos y bajas por impago, y un panel con matrículas y asistencia. Si dejan de pagar, pierden el acceso. Sin que nadie lo haga a mano. Si hoy tu equipo da de alta a los alumnos uno a uno, o tienes automatizaciones que fallan justo cuando más matrículas entran, el problema no es el volumen: es que nadie se fía del circuito. Cada fallo es un alumno que no puede entrar, un cobro que no cuadra o un acceso que sigue abierto sin pagar. Lo construimos con n8n, Make, APIs y código propio, según lo que pida tu academia, y cubrimos también la migración desde tu stack actual. Cada flujo crítico sale con registro de errores, reintentos y documentación, y todo a nombre de tu empresa. Una automatización que falla en silencio no está terminada. ## Señales de que lo necesitas - Alguien da de alta a los alumnos uno a uno - Hay alumnos con acceso sin haber pagado, o al revés - Las altas fallan justo en pleno lanzamiento - El equipo de soporte vive de "no me deja entrar" - Las automatizaciones fallan y nadie se entera - Para saber cuántos alumnos activos hay, abres tres herramientas ## Para quién - **El fundador de una academia:** Controlas quién ha pagado, quién tiene acceso y quién debería haberlo perdido, sin preguntar a nadie. - **Tu CMO:** Cada alta lleva su origen hasta el final, así que sabe qué captación termina en alumnos que pagan. - **Tu CTO o quien lleve la parte técnica:** Automatizaciones con registro de errores, reintentos seguros y documentación, en lugar de flujos que solo entiende quien los montó. - **Tu equipo de soporte:** Menos mensajes de "no me deja entrar" y un panel para resolver incidencias sin pedir ayuda técnica. ## Qué construimos - **Pago, alta y acceso:** Pago confirmado, alumno creado, acceso concedido y bienvenida enviada. Y el proceso inverso al cancelar. - **Bajas por impago:** Si deja de pagar, pierde el acceso. Control de accesos sincronizado con el estado de cobro. - **Avisos y renovaciones:** Recordatorios de renovación y avisos de cobro fallido antes de que se conviertan en una baja. - **Panel de academia:** Matrículas, asistencia, accesos y bajas en una sola pantalla, sin exportar nada. - **Migración y material:** Paso desde tu plataforma actual y entrada de todo el contenido, sin perder alumnos ni histórico. - **Del lead al alumno:** Formularios, CRM, email y WhatsApp trabajando sobre el mismo dato, con el origen de cada alta. - **Alertas y registro:** Registro, reintentos seguros y avisos de error en cada flujo crítico. ## Reglas, IA o software a medida. No todo se automatiza igual, y tu academia no necesita lo mismo en cada punto. Esto es lo que valoramos antes de construir. | Criterio | Automatización con reglas | Automatización con IA | Software a medida | |---|---|---|---| | Qué resuelve | Mover datos y ejecutar pasos fijos entre herramientas | Pasos que exigen leer o interpretar texto: clasificar, resumir, extraer | Procesos centrales con lógica propia y un panel para el equipo | | Ejemplo | Pago confirmado, acceso concedido y bienvenida enviada | Mensajes de alumnos etiquetados y enviados a quien corresponde | Panel de matrículas, accesos y bajas con permisos y registro de actividad | | Herramientas | n8n, Make, webhooks y APIs | n8n o código con modelos de IA y validación de la salida | TypeScript, Python y Postgres | | Cuándo deja de bastar | Cuando la lógica acumula excepciones o el volumen dispara el coste | Cuando el resultado no se puede comprobar ni medir | Rara vez: se amplía sobre el mismo sistema | ## Cómo lo hacemos 1. **Cómo entra un alumno hoy:** Recorremos el circuito entero: pago, alta, acceso, avisos. Cuántos alumnos mueve, qué excepciones tiene y qué se hace a mano. 2. **Diseño:** Qué sistema manda para cada dato, qué herramienta encaja y qué pasa cuando algo falla. 3. **Construcción:** Flujos versionados en un entorno de pruebas, conectados con lo que ya usas, sin parar tus lanzamientos. 4. **Pruebas:** Casos reales y límite: pagos duplicados, datos incompletos, reintentos y picos de matrículas. 5. **Migración y puesta en marcha:** Paso desde tu stack actual y entrada de todo el material, con avisos de error y documentación de cada flujo. 6. **Operación:** Mantenimiento, revisión de errores y mejoras. Si algo se rompe, hay alguien que responde. ## Entregables - Circuito de pago, alta y acceso en producción - Panel con matrículas, asistencia y bajas - Migración desde tu stack actual - Pruebas con casos reales y casos límite - Registro y alertas de error - Documentación y traspaso, todo a tu nombre ## Qué cambia - **Control:** Sabes quién entró, de dónde vino, qué pagó y quién debería haber perdido el acceso. - **Menos soporte:** Menos incidencias de acceso y menos horas de tu equipo dando de alta a mano. - **Margen para crecer:** El mismo circuito aguanta el siguiente lanzamiento sin añadir horas manuales. ## Formato - Formato: Sprint de automatización · proyecto cerrado - Duración: 1–3 semanas - Herramientas habituales: n8n, Make, Airtable, Postgres, Webhooks, REST APIs, JavaScript, Python ## Preguntas frecuentes ### ¿Qué incluye una academia a medida? El circuito completo desde que alguien paga hasta que entra: alta automática, acceso al contenido, avisos de bienvenida y de renovación, control de accesos y bajas, y un panel con matrículas y asistencia. Incluye la migración desde tu stack actual y la entrada de todo el material. ### ¿Qué pasa si un alumno deja de pagar? Pierde el acceso de forma automática, con aviso previo si lo quieres. El acceso sigue siempre el estado de cobro, así que no depende de que alguien se acuerde de revisar quién debe qué. ### ¿Qué conviene automatizar primero? Lo que se repite a diario, mueve muchos alumnos y cuesta errores cuando se hace a mano: altas y accesos tras un pago, avisos de renovación, reparto de leads y reporting. Empezamos por el cuello de botella que más te cuesta hoy, no por el más fácil. ### ¿Qué pasa si una automatización falla en pleno lanzamiento? Cada flujo crítico registra lo que hace y avisa cuando algo no sale bien. Los procesos admiten reintentos sin duplicar altas ni cobros, así que un fallo se detecta cuando ocurre y se corrige sin rehacer trabajo a mano. Si un webhook de n8n deja de responder, aquí tienes [cómo diagnosticarlo](/blog/webhook-n8n-no-funciona/). ### ¿Podéis arreglar las automatizaciones que ya tenemos? Sí. Empezamos revisando qué hace cada flujo, dónde falla y qué depende de él. A veces basta con reforzarlo; otras conviene rehacerlo con una estructura que se pueda mantener, y que no dependa de quien lo montó. ### ¿Trabajáis con n8n, Make o Zapier? Sobre todo con n8n y Make, y con código propio cuando el volumen o la lógica lo piden. Si ya tienes flujos en otra herramienta, los evaluamos antes de proponer una migración. La herramienta se elige por tu sistema, no por costumbre. Si dudas entre ellas, aquí tienes [la comparativa de n8n y Make](/blog/n8n-vs-make/). ### ¿Usáis no-code o código? Las dos, según lo que pida el proceso. Para mover datos y ejecutar pasos fijos, n8n o Make bastan y salen antes. Cuando hay mucho volumen, lógica con excepciones o un panel propio, escribimos código. Lo decidimos con tu caso delante y lo dejamos documentado para que no dependa de quien lo montó. ### ¿Cuándo deja de ser suficiente una automatización? Cuando la lógica acumula demasiadas excepciones, el coste por ejecución se dispara o tu equipo necesita un panel propio. Ahí suele compensar pasar a software a medida, y la transición se hace sin parar la operación. ## Casos relacionados - [Un campus propio conectado al CRM de ventas](https://fcgsystems.es/casos/campus-propio-conectado-al-crm/) - [Un CRM a medida que sustituye a Airtable, con comisiones por agente](https://fcgsystems.es/casos/crm-a-medida-con-comisiones-por-agente/) - [Una bandeja compartida sobre la API oficial de WhatsApp](https://fcgsystems.es/casos/bandeja-compartida-api-oficial-whatsapp/) - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/) - [Infraestructura para lanzamientos con miles de registros](https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/) ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # CRM y software a medida > CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. Fuente: https://fcgsystems.es/servicios/software-a-medida/ · FCG Systems **CRM a medida para tu equipo de setters y closers.** Un CRM a medida es el CRM construido para tu proceso comercial, no un producto genérico al que adaptas a tu equipo. Cada lead llega con su origen, su responsable y su historial, y los cobros y las comisiones por agente cuadran solos. Con permisos según el rol de cada uno. Si hoy repartes los leads a mano entre hojas de cálculo, WhatsApp y correo, o pagas un CRM que nunca encaja con tu forma de vender, lo notas en lo mismo: nadie sabe a quién le toca el siguiente lead, el reporte no coincide con el banco y tus comerciales trabajan como manda la herramienta. Lo construimos alrededor de tu venta: el panel donde cada closer ve sus leads, la cadencia de seguimientos, los cobros y las comisiones, la bandeja de WhatsApp sobre la API oficial. Código propio, versionado y documentado, a nombre de tu empresa. ## Señales de que lo necesitas - Los leads se reparten a mano entre hojas, WhatsApp y correo - Nadie sabe a quién le toca el siguiente lead - Cobros y comisiones se calculan en una hoja aparte - Si un comercial se va, se lleva las conversaciones con él - Pagas un CRM y tu equipo sigue trabajando fuera de él - El CRM, la pasarela y el banco dan cifras distintas ## Para quién - **El fundador:** Ves en un solo sitio quién ha entrado, de dónde vino, qué compró, cuánto pagó y cuánto falta por cobrar. - **Tu CMO:** Cada lead conserva su origen hasta la venta, así que sabes qué captación acaba en cierres y no solo en registros. - **Tu CTO o quien lleve lo técnico:** Código propio, versionado y documentado, con permisos por rol y base de datos a nombre de tu empresa. - **Tus setters y closers:** La vista que cada uno necesita, con leads asignados, recordatorios de llamada y sus comisiones a la vista. ## Qué construimos - **CRM a tu proceso:** Las etapas, campos y reglas de tu venta, con el origen y el historial de cada lead. - **Asignación de leads:** Reparto por reglas y carga a setters y closers, con un único responsable por lead. - **Cobros y comisiones:** Pagos y comisiones por agente calculados en el sistema, sin hojas de cálculo aparte. - **Permisos por rol:** Cada persona ve lo que necesita para trabajar, y nada más. - **WhatsApp sobre la API oficial:** Bandeja compartida con conversaciones asignadas, plantillas, cadencia de seguimientos y recordatorios de llamada. - **Dashboards:** Métricas de negocio conectadas a la fuente de verdad, sin exportar nada. - **Portales y paneles internos:** Cuando el proceso lo justifica, el portal de cliente o el backoffice que completan el sistema. ## CRM de mercado, no-code o a medida. No siempre compensa construir. Esta es la comparación que hacemos antes de proponerte un CRM a medida. | Criterio | CRM de mercado (SaaS) | No-code (n8n, Make, Airtable) | CRM a medida | |---|---|---|---| | Encaja cuando | Tu proceso es estándar y la herramienta lo cubre casi entero | Necesitas conectar herramientas o probar un proceso rápido | Tu venta es lo central del negocio y ningún producto la cubre sin parches | | Arranque | Inmediato | Días o semanas | Semanas: de 3 a 8 para construir el sistema | | Coste que crece | Licencias por usuario y funciones que no usas | Ejecuciones, operaciones y excepciones acumuladas | Desarrollo inicial y mantenimiento | | Control de datos y reglas | El del proveedor y su hoja de ruta | Parcial: depende de la plataforma | Total: código, base de datos y accesos a tu nombre | | Riesgo típico | Que tu equipo trabaje como manda la herramienta | Flujos frágiles cuando crece la lógica | Construir algo que ya existía: por eso lo revisamos antes | ## Cómo lo hacemos 1. **Cómo vende tu equipo hoy:** Etapas, setters, closers, cobros y comisiones. Decidimos qué se construye y qué se queda como está. 2. **Diseño:** Modelo de datos, permisos por rol, integraciones y qué sistema manda para cada dato. 3. **Construcción por entregas:** Entorno de pruebas, código versionado y entregas que tu equipo usa pronto, no al final. 4. **Validación:** Casos reales y límite, permisos y volumen de lanzamiento antes de pasar a producción. 5. **Puesta en marcha:** Producción con copias de seguridad, avisos de error, documentación y traspaso a tu equipo. 6. **Soporte y evolución:** Plan de mantenimiento definido y alguien que responde cuando algo se rompe. ## Entregables - CRM desplegado en producción - Código en un repositorio a nombre de tu empresa - Base de datos con copias de seguridad - Usuarios y permisos por rol - Documentación técnica y operativa - Plan de mantenimiento y soporte ## Qué cambia - **Control:** Sabes quién entró, de dónde vino, qué compró, cuánto pagó y cuánto falta por cobrar. - **Un sistema que se adopta:** El equipo vende dentro del CRM porque sigue su forma real de trabajar. - **Sin depender de nadie:** El código y los datos son tuyos. No dependes de la hoja de ruta de un proveedor ni de quien lo construyó. ## Formato - Formato: Construcción del sistema · proyecto cerrado - Duración: 3–8 semanas - Herramientas habituales: TypeScript, JavaScript, Python, Postgres, Xano, REST APIs, Docker ## Preguntas frecuentes ### ¿Qué es un CRM a medida? Es un CRM diseñado y desarrollado para el proceso comercial de tu empresa, en lugar de un producto genérico que se configura. Tiene tus etapas, tus reglas de asignación y tus permisos por rol, y está integrado con formularios, pagos y WhatsApp. Tú decides qué hace y eres dueño del código y de los datos. ### ¿Cuánto cuesta y cuándo se amortiza? Depende del alcance: usuarios y roles, integraciones, volumen de datos y seguridad. No publicamos tarifas; tras el diagnóstico recibes una propuesta con entregables, plazos y precio cerrado por fase. Para valorarlo, compara con lo que pagas hoy en licencias por usuario y en horas de tu equipo repartiendo leads y cuadrando comisiones a mano: ahí suele estar la amortización. ### ¿Cuánto tarda? La construcción del sistema suele durar entre 3 y 8 semanas, con entregas parciales que tu equipo prueba desde el principio. El plazo exacto lo fijamos por escrito antes de empezar. ### ¿El código es nuestro? Sí. El repositorio, la base de datos y las credenciales quedan a nombre de tu empresa, con tus accesos de administración. Documentamos la arquitectura para que cualquier equipo técnico pueda continuar el trabajo, sin depender de nosotros. ### ¿Y si ya nos dejó tirados un freelance o una agencia fue demasiado lenta? Por eso entregamos por fases con precio cerrado, con un entorno de pruebas que tu equipo usa desde el principio y con todo documentado. Y después de la entrega hay soporte: si algo se rompe, hay alguien que responde. ### ¿Cuándo compensa construir en lugar de contratar un CRM del mercado? Cuando tu venta es central para el negocio, el CRM obliga a trabajar con parches o las licencias crecen más rápido que el valor que aportan. Si una herramienta existente resuelve casi todo, te lo diremos, aunque perdamos la venta. ### ¿Podéis mover nuestros leads desde el CRM que usamos hoy? Sí. La migración forma parte del proyecto: paso de contactos, historial y etapas desde tu herramienta actual, con pruebas antes de cambiar de sistema y sin parar a tu equipo comercial. ### ¿Quién mantiene el CRM después? Tu equipo, con la documentación que entregamos, otro proveedor, o nosotros con un plan de partner tecnológico. Todo proyecto termina con un plan de mantenimiento definido. ## Casos relacionados - [Un campus propio conectado al CRM de ventas](https://fcgsystems.es/casos/campus-propio-conectado-al-crm/) - [Un CRM a medida que sustituye a Airtable, con comisiones por agente](https://fcgsystems.es/casos/crm-a-medida-con-comisiones-por-agente/) - [Una bandeja compartida sobre la API oficial de WhatsApp](https://fcgsystems.es/casos/bandeja-compartida-api-oficial-whatsapp/) - [CommunityRedirect: un enlace para no perder registros en grupos llenos](https://fcgsystems.es/casos/communityredirect-distribucion-comunidades-whatsapp/) ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Sistemas de IA > Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. Fuente: https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/ · FCG Systems **IA aplicada a tu negocio de formación, medida por lo que cambia.** Metemos IA en los procesos de tu negocio de formación donde ahorra horas de verdad: mensajes de alumnos y leads clasificados, llamadas resumidas en el CRM, leads priorizados antes de repartirlos y un asistente que responde con tu documentación. Cada caso parte de una métrica, se prueba con situaciones reales y se mide en producción. La IA no es un proyecto en sí misma. Es una pieza más del sistema, útil cuando hace algo concreto mejor, más rápido o más barato que la alternativa. Si una regla simple resuelve el problema, te lo decimos y no te vendemos un modelo. Si ya probaste IA y se quedó en una demo, el motivo suele ser que nadie definió qué tenía que mejorar. Aquí se define antes de construir, con límites claros, aprobación humana donde un error cuesta caro y un coste por ejecución que conoces. ## Señales de que lo necesitas - Alguien lee y clasifica cientos de mensajes al día - Las notas de las llamadas nunca llegan al CRM - El equipo pregunta lo que ya está documentado - Probaste IA y se quedó en una demo - No sabes qué respuestas del asistente son correctas - Los leads se priorizan a ojo ## Para quién - **Fundadores con el equipo saturado:** Mensajes de alumnos, admisiones y llamadas que hoy alguien lee, resume y clasifica a mano. Recuperas horas sin contratar a nadie. - **CMO y equipos comerciales con volumen de leads:** Leads priorizados con criterios que puedes revisar, resumen de cada llamada en el CRM y contexto para el closer antes de llamar. - **CTO o responsable técnico:** IA en producción con registro, límites de coste, casos de prueba y posibilidad de cambiar de modelo sin rehacer la integración. - **Agencias con clientes de formación:** Asistentes y flujos con IA para vuestros clientes, construidos y mantenidos sin ampliar plantilla técnica. ## Qué construimos - **Clasificación y enrutado:** Mensajes, formularios y tickets etiquetados y enviados a quien corresponde. - **Resúmenes y extracción:** Llamadas, reuniones y documentos convertidos en datos ordenados dentro de tu CRM. - **Scoring de leads:** Priorización de leads y oportunidades con criterios explícitos que puedes revisar. - **Agentes con herramientas:** Agentes que consultan tu CRM, agenda o base de datos y hacen pasos acotados, con aprobación humana donde un error cuesta caro. - **Asistentes y chatbots:** Respuestas basadas en tu documentación para el equipo o para alumnos, con fuentes citadas, límites definidos y paso a una persona. - **Análisis de conversaciones:** Patrones en chats y llamadas comerciales: objeciones, dudas y motivos de pérdida. - **Flujos con revisión humana:** La IA propone y una persona valida en los pasos donde un error cuesta caro. ## Chatbot, agente de IA o automatización con IA. Tres formas de usar IA que se confunden a menudo. Elegir bien evita pagar un agente donde bastaba un flujo, o un chatbot que no puede hacer nada. | Criterio | Chatbot | Agente de IA | Automatización con IA | |---|---|---|---| | Qué hace | Responde preguntas dentro de una conversación | Decide los pasos y usa herramientas (CRM, agenda, base de datos) para cumplir un objetivo | Ejecuta un flujo fijo con un paso de IA: clasificar, resumir o extraer datos | | Cuándo encaja | Dudas frecuentes de alumnos o leads cuya respuesta está en tu documentación | Tareas de varios pasos con variación real entre un caso y otro | Tareas repetitivas y de volumen con un resultado que se puede comprobar | | Riesgo principal | Respuestas inventadas si no se limita a fuentes | Acciones equivocadas si no tiene límites ni aprobación | Errores silenciosos si no hay casos de prueba ni logs | | Control que ponemos | Respuestas con fuentes y paso a una persona | Herramientas acotadas, condiciones de parada y aprobación humana en pasos sensibles | Validación de la salida, reintentos y alertas | ## Cómo lo hacemos 1. **Descubrimiento:** Elegimos un proceso, medimos cómo funciona hoy y fijamos la métrica que tiene que mejorar. 2. **Diseño:** Decidimos qué hace el modelo, qué resuelve una regla y en qué pasos valida una persona. 3. **Construcción:** Se integra en las herramientas que ya usa tu equipo: CRM, WhatsApp, email o soporte, con todo versionado. 4. **Validación:** Casos de prueba reales y casos límite antes de tocar producción. 5. **Despliegue:** Producción con registro, límites de coste y una alternativa si el modelo falla. 6. **Mejora:** Revisamos precisión, uso y coste con datos reales y ajustamos lo que no rinde. ## Entregables - Caso definido y métrica de éxito - Integración en las herramientas de tu equipo - Prompts y modelos versionados, a tu nombre - Casos de prueba para controlar la calidad - Métricas de uso, coste y precisión - Documentación ## Qué cambia - **Tiempo:** La lectura, clasificación y transcripción repetitivas salen del día a día de tu equipo. - **Calidad:** Cada cambio se evalúa contra casos de prueba antes de llegar a producción. - **Coste controlado:** Sabes cuánto cuesta cada ejecución y qué valor aporta, sin sorpresas en la factura. ## Formato - Formato: IA en un proceso · proyecto cerrado - Duración: Según el caso, definida tras el diagnóstico - Herramientas habituales: OpenAI, Anthropic, Vercel AI SDK, TypeScript, Python, n8n, Postgres, pgvector ## Preguntas frecuentes ### ¿Qué hacéis exactamente con IA en un negocio de formación? La conectamos a tus herramientas para resolver tareas concretas: clasificar mensajes, resumir llamadas en el CRM, puntuar leads o responder con tu documentación. La probamos con casos reales y medimos qué cambia en tiempo, calidad o coste. No la vendemos como fin. ### ¿Hacéis consultoría de IA o también la implantáis? Las dos cosas, en ese orden. Primero se define el caso, la métrica de éxito y si la IA es la mejor opción; después lo construimos, lo desplegamos y lo mantenemos. Si una regla o una automatización simple resuelve el problema, te lo decimos aunque nos quedemos sin proyecto. ### ¿Qué procesos de mi negocio se pueden automatizar con IA? Los que implican leer, interpretar o resumir información con volumen: mensajes de alumnos y leads, documentos, llamadas comerciales, priorización de leads o preguntas que ya están respondidas en tu documentación. Las decisiones con impacto legal, económico o sobre alumnos llevan siempre validación humana. ### ¿Cuánto cuesta y cuándo se amortiza? Depende del proceso, las integraciones y el volumen, así que no publicamos tarifas cerradas. Tras el descubrimiento recibes un alcance cerrado con entregables y plazos. El uso de los modelos se mide por ejecución: sabes qué cuesta cada tarea y la comparas con las horas manuales que sustituye. ### ¿Qué IA es mejor para mi empresa? No hay un modelo mejor para todo. Trabajamos con OpenAI y Anthropic, entre otros, y elegimos por tarea comparándolos con los mismos casos de prueba en precisión, coste y velocidad. El sistema se diseña para poder cambiar de modelo sin rehacer la integración, así que no quedas atado a un proveedor. ### Ya probamos IA y se quedó en una demo. ¿Qué cambia? Que aquí la IA resuelve una tarea concreta dentro de un proceso que ya existe, y se mide el antes y el después. No hacemos demos ni chatbots decorativos. Si una regla simple resuelve el problema, usamos la regla. ### ¿Se usan nuestros datos para entrenar modelos? Trabajamos con proveedores y configuraciones que no entrenan con tus datos, y al modelo solo le enviamos la información necesaria. Cuando el caso lo exige, anonimizamos los datos antes de procesarlos. ### ¿Cómo controláis que la IA no se equivoque? Con casos de prueba reales antes de desplegar, validación humana en los pasos sensibles y métricas de precisión en producción. Un modelo puede fallar: el sistema tiene que detectarlo y tener una alternativa. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Datos, tracking y analítica > Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. Fuente: https://fcgsystems.es/servicios/datos-tracking-analitica/ · FCG Systems **Tracking y atribución hasta la venta, con cifras que coinciden.** Ads dice una cifra, el CRM otra y la hoja de cálculo del lanzamiento una tercera. Cuando los datos no coinciden, las decisiones se toman por intuición y el presupuesto se reparte a ciegas. Medimos cada paso, desde el primer clic hasta la venta cerrada por llamada, y conectamos todas las fuentes en una base de datos de referencia. Cuando la pérdida de señal lo justifica, enviamos las conversiones desde un servidor que controlas (GTM server-side o la API de conversiones de Meta) en lugar de depender solo del navegador. Sobre esa base construimos los dashboards que usan dirección, marketing y ventas: registros por fuente, conversión por etapa y rendimiento por closer. El resultado: sabes qué canal vende, a qué campaña le subes el presupuesto y en qué cifras puedes fiarte. ## Señales de que lo necesitas - Cada plataforma da una cifra de conversiones distinta - Sabes qué canal trae registros, pero no qué canal vende - El informe se monta exportando CSV a mano - Los UTM se pierden entre el formulario y el CRM - GA4 está instalado, pero nadie se fía de él - Los dashboards se rompen cuando cambia una herramienta ## Para quién - **CMO o responsable de captación:** Lanzamientos con Ads y varias fuentes donde la venta se cierra por llamada, lejos del píxel. Sabes qué campaña trae ventas, no solo registros. - **Fundadores que no se fían de sus números:** Ads dice una cifra, el CRM otra y la hoja del lanzamiento otra. Una fuente de referencia y dashboards que leen de ella. - **CTO o responsable técnico:** Plan de medición documentado, eventos deduplicados entre navegador y servidor, y paneles que no se rompen cuando cambia una herramienta. - **Equipos comerciales:** El origen de cada lead visible en el CRM y el rendimiento por closer sin montar informes a mano. ## Qué construimos - **Plan de medición:** Qué se mide, con qué nombre y dónde, documentado antes de tocar una etiqueta. - **GA4 y Google Tag Manager:** Eventos y conversiones implementados con limpieza en web, formularios y checkout. - **Tracking server-side:** Contenedor de GTM server-side cuando la pérdida de señal lo justifica, no por defecto. - **API de conversiones:** Eventos de navegador y de servidor deduplicados con el mismo identificador, incluidas las ventas que se cierran fuera de la web. - **Atribución:** UTM y fuentes que viajan del primer clic al CRM y a la venta cerrada. - **Integración de fuentes:** Ads, CRM, pagos y plataformas volcados en una base de datos común. - **Dashboards:** Paneles de negocio por área, actualizados sin exportar nada. - **KPIs comerciales:** Definiciones claras de conversión, ciclo de venta y rendimiento por closer. ## Tracking en el navegador o server-side. El tracking server-side no sustituye a una buena implementación en el navegador: la complementa. Estas son las diferencias que importan al decidir dónde gastar. | Criterio | Tracking en el navegador | Tracking server-side | |---|---|---| | Cómo viajan los eventos | Del navegador del usuario a cada plataforma, etiqueta a etiqueta | Del navegador o del backend a un servidor que controlas, y de ahí a cada plataforma | | Pérdida de señal | Más expuesto a bloqueadores y restricciones del navegador | Menos expuesto, aunque no recupera a quien rechaza el consentimiento | | Control de los datos | Cada etiqueta decide qué envía | Decides qué datos salen hacia cada plataforma | | Ventas fuera de la web | Difícil de medir | Se pueden enviar desde el CRM o los pagos con la API de conversiones | | Coste y mantenimiento | Bajo: etiquetas en Google Tag Manager | Servidor o servicio gestionado, configuración y vigilancia | ## Cómo lo hacemos 1. **Auditoría de medición:** Qué se mide hoy, dónde se pierde la señal y cuánto se desvía cada fuente del CRM y los pagos. 2. **Plan de medición:** Eventos, nombres, parámetros y la fuente de referencia para cada cifra, por escrito. 3. **Implementación:** GA4 y Google Tag Manager, y server-side o API de conversiones cuando compensa. 4. **Validación:** Eventos de prueba, deduplicación entre navegador y servidor y cruce con CRM y pagos. 5. **Dashboards:** Fuentes volcadas en una base de datos común y paneles por área sobre ella. 6. **Mantenimiento:** Revisión cuando cambian las herramientas, las campañas o el embudo. ## Entregables - Plan de medición documentado - Implementación de GA4 y GTM, en tus cuentas - Atribución de la fuente hasta el CRM - Base de datos analítica a tu nombre - Dashboards por área - Guía de KPIs y definiciones ## Qué cambia - **Una sola cifra:** Marketing, ventas y dirección discuten decisiones, no qué número es el bueno. - **Presupuesto con criterio:** Sabes qué fuentes generan ventas, no solo registros, y a dónde mover el gasto. - **Menos informes manuales:** Los paneles se actualizan solos y nadie monta hojas de cálculo los lunes. ## Formato - Formato: Proyecto cerrado - Duración: 1–3 semanas para tracking; 3–8 con base de datos y dashboards - Herramientas habituales: GA4, Google Tag Manager, Server-side GTM, Meta Conversions API, Postgres, Airtable, Looker Studio, Tally ## Preguntas frecuentes ### ¿Qué es el tracking server-side y me hace falta? Es medir enviando los eventos a un servidor que controlas y desde ahí a cada plataforma, en lugar de que el navegador hable con todas. No siempre hace falta: compensa cuando la pérdida de señal afecta a campañas con presupuesto relevante o cuando quieres más control sobre los datos. Antes revisamos que la medición básica esté bien hecha. ### ¿Qué herramienta de tracking server-side conviene usar? Lo habitual es un contenedor de GTM server-side, en tu propia infraestructura o en un servicio gestionado. Depende del volumen de eventos, del control que quieras y de quién lo va a mantener. Queda todo en tus cuentas y documentado, sin depender de nosotros. ### ¿El tracking server-side evita pedir consentimiento? No. Cambia dónde se procesan los eventos, no las obligaciones de privacidad: si el usuario no consiente, esa medición no debe hacerse igual. Lo configuramos respetando el consentimiento y documentamos qué datos se envían y a quién, para que tu asesoría legal pueda revisarlo. ### ¿Qué es la API de conversiones? Es la vía por la que una plataforma publicitaria, como Meta, recibe eventos directamente desde tu servidor o tu CRM en lugar de desde el navegador. Sirve para informar de ventas que se cierran por llamada. Se usa junto al píxel, con el mismo identificador de evento, para que no cuente dos veces la misma conversión. ### ¿Por qué no coinciden los datos de Ads, GA4 y el CRM? Porque cada plataforma cuenta con sus propias reglas, ventanas de atribución y bloqueos. Que coincidan al 100 % no es realista, pero sí definir una fuente de referencia y saber cuánto se desvía cada una y por qué. ### ¿Cuánto tarda y cuándo se nota? El tracking suele llevar de 1 a 3 semanas; con base de datos y dashboards, de 3 a 8. Si tienes un lanzamiento cerca, se prioriza lo que necesitas medir en esa fecha y el resto se entrega después. ### ¿Podéis conectar los dashboards con nuestro CRM? Sí. Integramos CRM, formularios, pagos y plataformas publicitarias en una base de datos común, y los dashboards leen de ahí. Así cambiar una herramienta no rompe todos los informes. ## Casos relacionados - [Un campus propio conectado al CRM de ventas](https://fcgsystems.es/casos/campus-propio-conectado-al-crm/) - [Un CRM a medida que sustituye a Airtable, con comisiones por agente](https://fcgsystems.es/casos/crm-a-medida-con-comisiones-por-agente/) - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/) - [Infraestructura para lanzamientos con miles de registros](https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/) ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Infraestructura y DevOps > Servidores, despliegues, backups y alertas para que tu operación no se caiga y sea tuya. Fuente: https://fcgsystems.es/servicios/infraestructura-devops/ · FCG Systems **Que tu negocio no se pare el día que algo se cae.** Tu CRM, tu academia y tus automatizaciones corren en algún servidor. Demasiadas veces lo montó alguien que ya no está, sin copias probadas y sin documentar. Funciona hasta el día del lanzamiento, que es justo cuando no puede fallar. Montamos y cuidamos la base técnica de tus sistemas: servidores, bases de datos, dominios y despliegues. Con copias que se pueden restaurar, accesos a tu nombre y alertas que te avisan antes de que lo note un alumno o un comercial. ## Señales de que lo necesitas - Nadie sabe qué corre en cada servidor - Hay backups, pero nunca se ha restaurado ninguno - Tocar algo en producción da miedo - Las contraseñas circulan por chat - Te enteras de las caídas por tus alumnos - La infraestructura la montó alguien que ya no está ## Qué construimos - **Servidores y alojamiento:** Puesta a punto y blindaje de los servidores donde viven tu CRM, tu academia y tus automatizaciones. - **Despliegues sin sustos:** Cada cambio se publica de forma repetible y se puede deshacer si algo sale mal. - **Dominios y certificados:** Tus dominios, SSL y subdominios ordenados y a tu nombre, sin caducidades por sorpresa. - **Base de datos:** Los datos de leads, alumnos y cobros con permisos, mantenimiento y copias automáticas. - **Copias y restauración:** Copias fuera del servidor y restauraciones probadas, no solo programadas. - **Alertas:** Aviso cuando cae un servicio, se llena un disco o falla algo crítico, antes de que lo note tu equipo. - **Accesos y credenciales:** Cada persona con el acceso mínimo que necesita y las claves en un gestor, nunca en un chat. ## Cómo lo hacemos 1. **Inventario:** Qué corre en cada servidor, quién tiene acceso, dónde están los dominios y qué se rompería si algo cae. 2. **Diseño:** Entornos, base de datos, copias y alertas pensados para tu operación, con todo a nombre de tu empresa. 3. **Montaje y migración:** Servidores y despliegues versionados, y paso de lo que ya corre sin parar tus ventas ni tus clases. 4. **Prueba de restauración:** Restauramos una copia de verdad y simulamos una caída para comprobar que todo vuelve. 5. **Documentación y traspaso:** Accesos ordenados, cómo se despliega y qué hacer si algo falla, escrito para que no dependa de nadie. 6. **Vigilancia:** Alertas que te avisan antes que tus alumnos, revisión de copias y actualizaciones. ## Entregables - Infraestructura documentada, a tu nombre - Despliegues repetibles y reversibles - Backups automáticos con restauración probada - Alertas de caídas y errores - Inventario de accesos y credenciales - Qué hacer si algo se cae, por escrito ## Qué cambia - **Lanzamientos tranquilos:** Los sistemas aguantan el pico y los problemas se detectan antes de que los sufra un cliente. - **Recuperación:** Si algo se rompe, hay copia de seguridad y un procedimiento para volver, sin perder leads ni alumnos. - **Propiedad:** Todo está documentado y a tu nombre. No depende de la memoria de una persona ni de un proveedor. ## Formato - Formato: Puesta a punto y operación mensual - Duración: 1–3 semanas de puesta a punto; después, mensual - Herramientas habituales: Linux, Docker, Traefik, Nginx, Postgres, Redis, GitHub Actions, Cloudflare ## Preguntas frecuentes ### ¿Puedo seguir con mi infraestructura actual o hay que migrarlo todo? Primero la revisamos: qué corre, quién tiene acceso, qué backups existen y qué no está documentado. Después la estabilizamos antes de tocar nada. Solo proponemos migrar si supone un riesgo real para tu operación. ### ¿Qué pasa si se cae algo en pleno lanzamiento? Por eso las alertas y las copias se preparan antes. Los tiempos de respuesta se definen por escrito según la prioridad: un sistema crítico caído no se trata igual que una mejora. Y queda un procedimiento para que tu equipo sepa qué hacer mientras tanto. ### ¿Quedo atado a vosotros? No. Servidores, dominios, cuentas y claves quedan a tu nombre y la infraestructura va documentada. Puedes mantenerla con tu equipo, con otro proveedor o con nosotros. Si dejamos de trabajar juntos, retiras nuestros accesos y no se rompe nada. ### ¿Cuánto cuesta? La puesta a punto se cierra con precio por alcance antes de empezar, y la operación mensual es una cuota fija. Suele salir más barato que pagar servicios cloud que nadie revisa y que pasar un día entero de caída sin vender. ## Casos relacionados - [Una bandeja compartida sobre la API oficial de WhatsApp](https://fcgsystems.es/casos/bandeja-compartida-api-oficial-whatsapp/) - [CommunityRedirect: un enlace para no perder registros en grupos llenos](https://fcgsystems.es/casos/communityredirect-distribucion-comunidades-whatsapp/) ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Infraestructura de lanzamientos > Captación, tracking, reparto a tu equipo comercial y WhatsApp listos para miles de registros. Fuente: https://fcgsystems.es/servicios/infraestructura-de-lanzamientos/ · FCG Systems **Un lanzamiento que aguanta, con números en los que te puedes fiar.** Un lanzamiento concentra en pocos días lo que otros negocios reciben en meses: miles de registros desde YouTube, Instagram, Telegram, Ads y email, grupos de WhatsApp que se llenan, setters y closers esperando leads y tú pidiendo cifras cada hora. Construimos o reforzamos lo que sostiene ese pico: captación y tracking por fuente, leads sin duplicar antes de repartirlos, reparto a tu equipo comercial, distribución a comunidades y datos en tiempo real. Probado con volumen antes de abrir registros, no durante. ## Señales de que lo necesitas - Grupos de WhatsApp llenos en plena campaña - Leads duplicados que llaman dos comerciales - No sabes qué fuente vende hasta que todo termina - Setters y closers reciben leads tarde o sin contexto - El panel del lanzamiento es una hoja de cálculo - Cada lanzamiento se monta de nuevo desde cero ## Qué construimos - **Captación y registros:** Formularios y páginas conectados a una base de datos preparada para picos de tráfico. - **Atribución por fuente:** Cada registro llega con su origen: canal, campaña, anuncio y afiliado. Sabes qué inversión vende. - **Leads sin duplicar:** Registros limpios antes de entrar en el CRM y antes de repartirse. - **Reparto a setters y closers:** Cada lead con un único responsable, por reglas y carga de trabajo, y visible para todo el equipo. - **WhatsApp y comunidades:** Reparto entre grupos controlando la capacidad, para que ningún registro caiga en un grupo lleno. - **Webinar y admisiones:** Recordatorios, asistencia y admisiones conectados al CRM. - **Datos en tiempo real:** Registros, asistencia, llamadas y ventas por fuente mientras el lanzamiento está en marcha. ## Cómo lo hacemos 1. **Cómo captas y vendes hoy:** Fuentes de tráfico, formularios, CRM, reparto a setters y closers, WhatsApp y cómo medís el lanzamiento. 2. **Diseño del pico:** Qué tiene que aguantar, cómo se reparte cada lead y qué datos necesitas ver mientras el lanzamiento sigue abierto. 3. **Construcción:** Captación y tracking por fuente, deduplicación, reparto comercial y distribución a comunidades. 4. **Prueba con volumen:** Simulamos registros masivos antes de abrir: duplicados, picos, grupos llenos y reparto. 5. **Acompañamiento en el lanzamiento:** Estamos pendientes en los días clave para resolver incidencias y ajustar mientras vendes. 6. **Después del lanzamiento:** Revisamos qué fuente vendió, qué falló y dejamos la base lista para el siguiente. ## Entregables - Plan técnico del lanzamiento - Tracking y atribución por fuente - Leads sin duplicar y reparto comercial - Reparto a comunidades de WhatsApp - Panel en tiempo real - Pruebas de volumen antes de abrir - Soporte técnico en los días críticos ## Qué cambia - **Menos registros perdidos:** El sistema está preparado para el pico antes de que llegue, no se improvisa en caliente. - **Ventas con contexto:** Cada setter y closer recibe leads limpios, a tiempo y con su origen. - **Decisiones en plena campaña:** Ves qué fuentes funcionan mientras todavía puedes mover presupuesto. ## Formato - Formato: Proyecto por lanzamiento o cuota mensual - Duración: Mejor empezar varias semanas antes de abrir registros - Herramientas habituales: n8n, Airtable, Postgres, GA4, Google Tag Manager, Tally, Calendly, WhatsApp, CommunityRedirect ## Preguntas frecuentes ### ¿Con cuánta antelación hay que empezar? Cuanto antes, mejor: lo razonable son varias semanas, para tener el sistema construido y probado con volumen antes de abrir registros. Si el lanzamiento está muy cerca, priorizamos lo crítico: tracking, leads sin duplicar y reparto comercial. ### ¿Puedo seguir con las herramientas que ya uso? Sí. Normalmente reforzamos lo que ya funciona e integramos lo que falta. Solo proponemos cambiar una herramienta si es un riesgo real para el lanzamiento. ### ¿Qué hacéis con los grupos de WhatsApp que se llenan? Un único enlace consulta la capacidad de cada grupo y reparte el tráfico entre varios destinos. Es CommunityRedirect, un producto propio que nació de este problema. ### ¿Y si algo falla durante el lanzamiento? Hay soporte en los días críticos, dentro de lo acordado en el proyecto: antes de empezar fijamos por escrito las ventanas de soporte y las prioridades. Y como el sistema se prueba antes con volumen, lo normal es que no haya sorpresas. ### ¿Qué queda después del lanzamiento? Todo queda a tu nombre y documentado, listo para el siguiente lanzamiento. No se monta de cero cada vez. ## Casos relacionados - [Infraestructura para lanzamientos con miles de registros](https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/) - [CommunityRedirect: un enlace para no perder registros en grupos llenos](https://fcgsystems.es/casos/communityredirect-distribucion-comunidades-whatsapp/) ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Partner tecnológico > Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. Fuente: https://fcgsystems.es/servicios/partner-tecnologico/ · FCG Systems **Quítate el marrón técnico sin montar un departamento.** Tu negocio ya vende y ya necesita a alguien que entienda toda su tecnología, pero todavía no compensa contratar un CTO y dos desarrolladores. Mientras tanto, la parte técnica se queda para después y cada proveedor solo ve su pieza. Nos convertimos en tu equipo técnico externo: mantenemos lo que existe, resolvemos incidencias, construimos lo siguiente y coordinamos al resto de proveedores. Con una capacidad mensual explícita y una hoja de ruta priorizada, no con la promesa de «todo lo que necesites». ## Señales de que lo necesitas - Cada proveedor conoce solo su parte del sistema - Las incidencias esperan a que alguien tenga hueco - Nadie decide la hoja de ruta técnica - Montar un equipo interno todavía no compensa - Los proyectos terminan y nadie los mantiene - El freelance que lo montó ya no responde ## Para quién - **Fundadores que son el cuello de botella:** Todo pasa por ti, incluida la parte técnica. Con un partner dejas de apagar fuegos y te centras en vender y en tu producto. - **CTO o responsable técnico en solitario:** Alguien que ya lleva mucho y necesita capacidad extra, criterio externo y documentación que no dependa de nadie. - **CMO o responsable de captación:** Tracking, atribución y herramientas de captación cuidados de forma continua, sin esperar a que haya hueco. - **Agencias con clientes de formación:** Un partner técnico al que delegar lo que vuestro equipo no cubre. ## Qué construimos - **Mantenimiento:** Actualizaciones, revisión de errores y arreglos antes de que lleguen a tus alumnos o a tu equipo comercial. - **Incidencias:** Cuando algo se rompe, hay alguien que responde. Por prioridad y con tiempos de respuesta definidos en el plan. - **Evolución:** Nuevas automatizaciones, mejoras y funciones dentro de la capacidad mensual. - **Hoja de ruta:** Revisión periódica de las prioridades técnicas en función de lo que necesita el negocio. - **Servidores y copias:** La base técnica bajo control continuo: servidores, copias de seguridad y alertas. - **Coordinación con proveedores:** Un único interlocutor técnico entre tu equipo, tus agencias y tus herramientas. - **Refuerzo en lanzamientos:** Más atención técnica en los momentos de más carga del negocio. ## Cómo lo hacemos 1. **Diagnóstico inicial:** Revisamos tus sistemas, tus proveedores y lo que hoy depende de ti o de una sola persona. 2. **Capacidad y prioridades:** Acordamos la capacidad mensual y una hoja de ruta priorizada por impacto en el negocio. 3. **Traspaso y orden:** Documentamos accesos, flujos y responsables para que lo que existe deje de ser un misterio. 4. **Ejecución mensual:** Mantenemos lo que existe, resolvemos incidencias y construimos lo siguiente dentro de la capacidad acordada. 5. **Revisión periódica:** Repasamos contigo qué se hizo, qué viene y qué ajustar en las prioridades. ## Entregables - Capacidad mensual definida por escrito - Hoja de ruta técnica priorizada - Gestión de incidencias por prioridad - Informe mensual de trabajo y estado - Documentación siempre actualizada - Revisión trimestral de la arquitectura ## Qué cambia - **Soporte después de la entrega:** El conocimiento de tus sistemas no se va cuando termina un proyecto ni cuando se va una persona. - **Prioridad:** Cada mes se trabaja en lo que más impacto tiene en el negocio, no en lo que más ruido hace. - **Previsibilidad:** Coste mensual conocido y capacidad explícita, sin sorpresas ni horas que se disparan. ## Formato - Formato: Cuota mensual · planes Core, Growth y Scale - Duración: Mensual, con revisión trimestral - Herramientas habituales: n8n, TypeScript, Python, Postgres, Docker, GA4, Airtable, REST APIs ## Preguntas frecuentes ### ¿En qué se diferencia de contratar a un freelance? Un freelance suele ejecutar tareas y, si se va, se lleva el conocimiento. Nosotros asumimos el sistema completo: arquitectura, prioridades, mantenimiento y documentación. Todo queda a tu nombre y escrito, así que no dependes de una sola persona. ### ¿Y de una agencia de desarrollo? La capacidad mensual está definida por escrito y las incidencias se atienden por prioridad, sin colas de semanas. Además, entendemos cómo vende un negocio de formación: no hace falta explicarnos qué es un setter o un lanzamiento. ### ¿Qué incluye cada plan y cuánto cuesta? Core cubre mantenimiento y mejoras pequeñas. Growth añade desarrollo continuo y nuevos sistemas. Scale es una colaboración tecnológica completa. Es una cuota mensual fija y la capacidad de cada plan se define por escrito antes de empezar. ### ¿Qué pasa con las peticiones fuera de lo acordado? Se registran, se estiman y se aprueban antes de ejecutarse. Así la capacidad mensual se dedica a lo prioritario y no se diluye en cambios pequeños sin control. ### ¿Puedo salirme cuando quiera? Sí. Código, servidores y cuentas están a tu nombre y documentados. Si dejamos de trabajar juntos, retiras nuestros accesos y haces el traspaso a quien elijas. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Un campus propio conectado al CRM de ventas > Cursos, clases en directo, diario de operativa y revisión de trabajos en un solo sitio, conectados al CRM. El equipo ve qué consume cada alumno sin ir herramienta por herramienta. Fuente: https://fcgsystems.es/casos/campus-propio-conectado-al-crm/ · FCG Systems - Cliente: Infoproductor con formación online y venta recurrente - Año: - Servicios: [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/), [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/), [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/) ## Contexto Un infoproductor con formación online y venta recurrente. Tenía el contenido en una plataforma, los alumnos en otra y el seguimiento comercial en otra distinta. ## Problema Nadie tenía una foto completa de nada. Para saber si un alumno avanzaba o se había quedado atascado había que ir mirando herramienta por herramienta, y al final eso no lo hacía nadie. Con la información repartida, además, no se sabía cuál era la información real. ## Restricciones ## Sistema construido - **Campus propio:** Cursos por niveles y módulos en una plataforma del negocio, no de un tercero. - **Clases en directo:** Las sesiones en directo viven dentro del mismo campus que el resto del contenido. - **Diario de operativa:** El registro de la operativa de cada alumno vive dentro del campus. - **Revisión de trabajos:** Las entregas se revisan y se corrigen sin salir de la plataforma. - **Conexión con el CRM:** El campus comparte datos con el CRM de ventas: la parte comercial y la formativa leen de la misma fuente. - **Panel del equipo:** Desde un panel se ve qué consume cada alumno y en qué punto está, y se resuelven las incidencias sin depender del equipo técnico. ## Resultado Un campus propio, con los cursos por niveles y módulos, las clases en directo, el diario de operativa y la revisión de trabajos, todo conectado con el CRM de ventas. El alumno entra en un solo sitio. El equipo ve desde un panel qué consume cada uno y en qué punto está, y soluciona las incidencias sin depender del equipo técnico. ## Aprendizajes Stack: Campus, CRM --- # Un CRM a medida que sustituye a Airtable, con comisiones por agente > Leads, oportunidades, cobros, comisiones por agente y permisos según el rol de cada uno, en un CRM hecho a la medida del proceso comercial. Fuente: https://fcgsystems.es/casos/crm-a-medida-con-comisiones-por-agente/ · FCG Systems - Cliente: Negocio digital con varios comerciales vendiendo a la vez - Año: - Servicios: [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/), [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/), [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/) ## Contexto Un negocio digital con varios comerciales vendiendo a la vez. Su proceso comercial vivía en un sistema montado sobre Airtable. ## Problema El sistema no terminaba de encajar con todo el proceso comercial, y dependía de automatizaciones que fallaban. ## Restricciones ## Sistema construido - **Leads y oportunidades:** Un pipeline con las etapas del proceso comercial real, en lugar de una base adaptada a la fuerza. - **Cobros:** El CRM incluye el registro de cobros. - **Comisiones por agente:** Las comisiones se gestionan por agente dentro del propio CRM. - **Permisos por rol:** Cada persona ve y toca solo lo que le corresponde según su rol. ## Resultado Un CRM hecho a su medida, con leads, oportunidades, cobros, comisiones por agente y permisos según el rol de cada uno. ## Aprendizajes Stack: CRM, Permissions --- # Una bandeja compartida sobre la API oficial de WhatsApp > Las conversaciones de venta dejan de vivir en móviles personales: una bandeja compartida, asignada por comercial y sincronizada con el CRM. Fuente: https://fcgsystems.es/casos/bandeja-compartida-api-oficial-whatsapp/ · FCG Systems - Cliente: Negocio digital con varios comerciales que venden por WhatsApp - Año: - Servicios: [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/), [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/), [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/) ## Contexto Un negocio digital con varios comerciales vendiendo a la vez, que usan WhatsApp para contactar con los leads. ## Problema La venta pasaba en los móviles personales de los comerciales. Si alguien se iba, se llevaba la conversación con él. Nadie sabía a quién tocaba seguir ni cuántas veces se le había escrito. No quedaba registro de las bajas ni de los consentimientos, que es un problema serio en cuanto entra protección de datos. A eso se sumaban los baneos frecuentes de WhatsApp. ## Restricciones ## Sistema construido - **API oficial de WhatsApp:** Una bandeja compartida construida sobre la API oficial, no sobre móviles personales. - **Conversaciones asignadas:** Cada conversación tiene un comercial responsable, y se sabe a quién le toca seguir. - **Plantillas:** Mensajes preparados para los contactos habituales de la venta. - **Cadencia de seguimientos:** Una secuencia de seguimientos que deja constancia de cuántas veces se ha escrito a cada lead. - **Recordatorios de llamada:** Los comerciales reciben el aviso de las llamadas pendientes. - **Sincronización con el CRM:** Lo que pasa en la bandeja queda en el CRM, y la conversación se queda en la empresa. ## Resultado Una bandeja compartida sobre la API oficial de WhatsApp, con las conversaciones asignadas a cada comercial, plantillas, una cadencia de seguimientos, recordatorios de llamada y sincronización con el CRM. ## Aprendizajes Stack: WhatsApp API, CRM --- # Funnel, tracking y CRM conectados en una academia online > Formularios, tracking, CRM y agenda comercial conectados en un solo sistema, con el origen de cada lead a la vista. Las tres etapas del funnel mejoraron. Fuente: https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/ · FCG Systems - Cliente: Academia de formación online - Año: 2024–2025 - Servicios: [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/), [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/), [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/) ## Métricas publicadas - Opt-in: 70,81 % → 77,61 % - Preinscripción: 36,85 % → 44,72 % - Llamadas: 9,89 % → 16,22 % ## Contexto Una academia de formación online que capta alumnos con contenido gratuito, formularios de registro y llamadas con un equipo comercial. El funnel funcionaba, pero cada pieza vivía en una herramienta distinta: formularios por un lado, agenda por otro, seguimiento en hojas de cálculo y conversaciones por WhatsApp. ## Problema No había una lectura fiable de qué fuente traía registros que acababan en llamada. Las cifras de cada herramienta no coincidían y el reporting se montaba a mano. Los leads llegaban al equipo comercial tarde o sin contexto, y el paso de registro a preinscripción y de preinscripción a llamada perdía gente sin que nadie pudiera señalar dónde. ## Restricciones - El funnel no podía detenerse: las campañas seguían activas durante todo el proyecto. - El sistema tenía que construirse sobre las herramientas que el equipo ya usaba. - Las mejoras se midieron con el funnel en marcha, así que no se atribuyen a una única pieza del sistema. ## Sistema construido - **Tracking de fuentes:** GA4 y Google Tag Manager con eventos definidos para cada paso, y el origen de cada registro conservado hasta el CRM. - **Formularios conectados:** Formularios en Tally enviando cada registro, con su fuente, a una base de datos común en Airtable. - **CRM comercial:** Un pipeline con las etapas reales de la venta: registro, preinscripción, llamada agendada y resultado. - **Agenda y asignación:** Reservas de Calendly vinculadas al lead y asignación de cada llamada al comercial correspondiente. - **WhatsApp en el flujo:** Los contactos por WhatsApp forman parte del seguimiento en lugar de quedarse en conversaciones sueltas. - **Dashboards:** Conversión por etapa y por fuente, actualizada sin exportar datos a mano. ## Resultado Las tres etapas medidas del funnel mejoraron durante el proyecto. Las tasas exactas, medidas antes y después, están arriba. El equipo comercial pasó a trabajar con leads asignados y con su origen visible, y dirección dejó de depender de informes montados a mano. ## Aprendizajes - Sin tracking fiable no hay optimización: primero se mide cada paso, después se discute qué cambiar. - El mayor salto estuvo en la última etapa. Que el lead llegue al comercial a tiempo y con contexto importa tanto como captarlo. - Una base de datos común vale más que cualquier dashboard. Los paneles solo son útiles si leen de una fuente en la que todos confían. Stack: GA4, Google Tag Manager, Tally, Airtable, Calendly, WhatsApp --- # Infraestructura para lanzamientos con miles de registros > Miles de registros desde cinco canales, sin duplicados, repartidos al equipo comercial y medidos mientras el lanzamiento sigue en marcha. Fuente: https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/ · FCG Systems - Cliente: Operación de lanzamientos de infoproducto - Año: 2024–2025 - Servicios: [Infraestructura de lanzamientos](https://fcgsystems.es/servicios/infraestructura-de-lanzamientos/), [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/), [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/) ## Contexto Una operación de infoproducto que trabaja por lanzamientos: campañas intensivas que concentran en pocos días la mayor parte de la captación y de las ventas. Los registros llegan a la vez desde YouTube, Instagram, Telegram, Ads y email, y detrás hay un equipo comercial y varias comunidades esperando a esos usuarios. ## Problema Con miles de registros en pocos días, los errores pequeños se multiplican: la misma persona registrada desde dos canales, leads que llaman dos comerciales y fuentes que no se pueden comparar. Las cifras del lanzamiento se reconstruían después, cuando ya no servían para mover presupuesto ni para repartir mejor el trabajo del equipo. ## Restricciones - Picos de tráfico concentrados en ventanas cortas, sin margen para arreglar nada en caliente. - Cinco canales de captación con formatos y datos de origen distintos. - Un equipo comercial que necesitaba leads limpios en el momento, no al día siguiente. ## Sistema construido - **Tracking multicanal:** Cada registro entra con su canal y su campaña, venga de YouTube, Instagram, Telegram, Ads o email. - **Deduplicación:** Los registros repetidos se detectan y se fusionan antes de llegar al CRM y antes de asignarse. - **Asignación comercial:** Reparto de leads al equipo por reglas y capacidad, para que cada contacto tenga un único responsable. - **Sistemas de comunidad:** Distribución de usuarios a las comunidades del lanzamiento sin saturar ningún grupo. - **Dashboards del lanzamiento:** Registros, asignaciones y ventas por fuente, visibles mientras la campaña está activa. ## Resultado El lanzamiento pasó a operarse con un único registro por persona, un responsable comercial por lead y una lectura por fuente disponible durante la campaña. Las cifras detalladas de esta operación no se publican. Lo que sí queda es un sistema reutilizable de un lanzamiento a otro en lugar de montarse desde cero cada vez. ## Aprendizajes - La deduplicación va antes de la asignación, nunca después. Deshacer un reparto con duplicados cuesta mucho más que evitarlo. - Un lanzamiento se prueba con volumen antes de abrir registros. Durante el pico no hay tiempo para diagnosticar. - Los problemas que se repiten en cada lanzamiento son candidatos a producto. Así nació CommunityRedirect. Stack: GA4, Google Tag Manager, Airtable, Postgres, WhatsApp, Telegram, Docker --- # CommunityRedirect: un enlace para no perder registros en grupos llenos > Un enlace único que consulta la capacidad, rota destinos y evita enviar usuarios a grupos de WhatsApp llenos. Fuente: https://fcgsystems.es/casos/communityredirect-distribucion-comunidades-whatsapp/ · FCG Systems - Cliente: Producto propio de FCG Systems - Año: 2025 - Servicios: [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/), [Infraestructura de lanzamientos](https://fcgsystems.es/servicios/infraestructura-de-lanzamientos/), [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/) - Producto: CommunityRedirect (https://communityredirect.com) ## Contexto Muchos lanzamientos usan grupos y comunidades de WhatsApp para calentar a la audiencia, enviar recordatorios y abrir ventas. Cada campaña publica enlaces de invitación en anuncios, emails, páginas de registro y redes sociales, a menudo miles de veces en pocas horas. ## Problema Los grupos tienen un límite de participantes y se llenan justo cuando más tráfico llega. Un enlace que apunta a un grupo lleno es un registro perdido en el peor momento posible. Cambiar enlaces a mano en anuncios, emails y páginas durante la campaña es lento, propenso a errores y deja la analítica repartida entre destinos. ## Restricciones - El enlace publicado no puede cambiar: ya está en anuncios, emails y piezas programadas. - La redirección tiene que ser inmediata incluso con picos de tráfico concentrados. - Tenía que funcionar para cualquier lanzamiento, no solo para uno. ## Sistema construido - **Enlace único:** Un solo enlace estable para toda la campaña, independiente de los grupos que haya detrás. - **Consulta de capacidad:** Antes de redirigir, el sistema comprueba qué destinos todavía tienen plazas. - **Rotación de destinos:** El tráfico se reparte entre varios grupos y pasa al siguiente cuando uno se completa. - **Protección contra grupos llenos:** Ningún usuario se envía a un grupo sin plazas. - **Analítica centralizada:** Clics y destinos de todos los grupos medidos en un único lugar. ## Resultado Los lanzamientos pueden publicar un único enlace y olvidarse de qué grupo está lleno: el sistema lo resuelve en cada clic. Un problema operativo que se repetía en cada campaña se convirtió en un producto reutilizable. ## Aprendizajes - Los problemas que aparecen en cada lanzamiento merecen producto, no un parche nuevo cada vez. - En los momentos críticos, lo que no se ve importa más: un enlace que funciona siempre vale más que una interfaz vistosa. - Centralizar la analítica en el punto de redirección da una lectura que ningún grupo por separado ofrece. Stack: WhatsApp, Postgres, Docker, VPS, REST APIs --- # Gabriel Florencio Calvo > Fundador de FCG Systems. Escribe sobre los sistemas que sostienen un negocio digital: captación, CRM, automatización, software a medida, datos e infraestructura. - URL: https://fcgsystems.es/blog/autor/gabriel-florencio/ - Cargo: Fundador de FCG Systems (https://fcgsystems.es/empresa/) - Ubicación: Huelva, España - LinkedIn: https://www.linkedin.com/in/gabrielflorencioo/ - Correo: hola@fcgsystems.es - Artículos publicados: 56 ## Quién escribe Gabriel Florencio Calvo fundó FCG Systems tras años construyendo funnels, tracking, CRMs, infraestructura y sistemas de lanzamiento para negocios digitales de alto volumen. Dirige la arquitectura de cada proyecto y es el interlocutor directo de quien contrata. Es la persona de tecnología detrás de negocios online: la que conecta lo que ya usan y construye lo que todavía no existe. Automatizaciones y embudos, flujos conversacionales, pagos y membresías, bases de datos, analítica, agentes e integraciones con IA. El trabajo que marca la diferencia suele empezar donde se acaban las herramientas estándar. Usa la IA a diario, pero no le deja decidir lo que importa: los accesos, los cobros y los precios los decide código determinista, no un modelo que acierta estadísticamente. Y revisa lo que genera antes de fiarse. Que funcione una demo no es el listón. Llegó a los negocios digitales desde dentro, vendiendo un infoproducto en el que dejó de creer. Se fue. Desde entonces solo construye lo que entiende y puede defender delante de quien lo paga. De crío reparaba ordenadores, no para que arrancaran, sino para saber por qué arrancaban. La caja ahora es la operativa de un negocio. ## En qué trabaja - **Arquitectura y datos:** Fuentes de verdad, atribución de extremo a extremo y modelos de datos que aguantan cuando el negocio crece. - **Automatización que se puede operar:** Flujos con logs, reintentos idempotentes y alertas, para que un fallo se vea el día que ocurre y no en el cierre de mes. - **Software a medida e IA aplicada:** Backoffices, CRMs y agentes dentro de procesos reales, con límites de herramienta, aprobación humana y control de calidad. - **Infraestructura de lanzamientos:** Captación, deduplicación, reparto comercial y medición listos antes del pico, no durante. ## Artículos - ["Funciona" no es el listón: lo que reviso antes de dar algo por terminado](https://fcgsystems.es/blog/funciona-no-es-el-liston/) · Software · 2026-09-16: La demo siempre sale bien: la haces tú, con datos limpios y sin prisa. Lo que de verdad decide si algo está terminado son las preguntas del día malo. - [Agente de voz con IA: cuándo automatizar una llamada tiene sentido (y cuándo es humo)](https://fcgsystems.es/blog/agente-de-voz-ia/) · IA aplicada · 2026-09-16: Qué es un agente de voz con IA, cómo funciona por dentro y en qué llamadas compensa: latencia, interrupciones, traspaso a humano y qué no se delega al modelo. - [Agentes de IA para negocios: qué son, cuándo compensan y cómo se construyen sin perder el control](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/) · IA aplicada · 2026-09-16: Qué es un agente de IA, en qué se diferencia de un chatbot o una automatización, cuándo compensa en un negocio digital y cómo crearlo paso a paso con control. - [Automatización de marketing: qué se automatiza bien y qué se rompe cuando el dato está sucio](https://fcgsystems.es/blog/automatizacion-de-marketing/) · Automatización · 2026-09-16: Qué se automatiza bien en marketing, qué se rompe cuando los datos del CRM están sucios y la higiene mínima que necesita un flujo antes de activarlo. - [Automatizar sin vigilar es peor que no automatizar](https://fcgsystems.es/blog/automatizar-sin-vigilar-es-peor/) · Automatización · 2026-09-16: Una automatización sin alertas y sin dueño no te ahorra trabajo: te lo esconde. Por qué el fallo silencioso hace más daño que el proceso manual que sustituye. - [Cerrar clientes sin audiencia: se vende por criterio, no por postureo](https://fcgsystems.es/blog/cerrar-clientes-sin-audiencia/) · Sistemas · 2026-09-16: Se puede cerrar trabajo serio con una cuenta de tres cifras de seguidores. No es carisma ni volumen: es diagnosticar mejor que nadie y saber decir que no. - [Cómo funciona n8n: cuatro ejemplos reales de flujos para un negocio digital](https://fcgsystems.es/blog/como-funciona-n8n-ejemplos/) · Automatización · 2026-09-16: Cómo funciona n8n explicado con cuatro ejemplos de negocio: leads al CRM, acceso tras el pago, conciliación nocturna y clasificación con IA, con sus fallos. - [CRM para pymes y negocios digitales: para qué sirve, cómo elegirlo y cuándo compensa uno a medida](https://fcgsystems.es/blog/crm-para-pymes-saas-o-a-medida/) · Sistemas · 2026-09-16: Para qué sirve un CRM en una pyme o negocio digital, qué exigirle antes de elegirlo y cuándo compensa un CRM SaaS, uno a medida o una combinación de ambos. - [Dar permisos a un agente de IA es una decisión de riesgo, no una casilla de configuración](https://fcgsystems.es/blog/permisos-de-un-agente-decision-de-riesgo/) · IA aplicada · 2026-09-16: Qué no se delega nunca a un modelo: accesos, cobros, precios e identidad. Cómo decidir los permisos de un agente de IA con criterio de riesgo, no de setup. - [De prototipo con IA a producción: lo que siempre falta cuando la demo ya funciona](https://fcgsystems.es/blog/de-prototipo-ia-a-produccion/) · Software · 2026-09-16: Qué falta siempre para llevar a producción una app creada con IA: permisos, datos, pagos, límites, observabilidad, costes y propiedad. Con checklist accionable. - [Diferencia entre CRM y ERP: qué resuelve cada uno y cuándo necesitas los dos](https://fcgsystems.es/blog/diferencia-crm-erp/) · Sistemas · 2026-09-16: Qué diferencia hay entre un CRM y un ERP, qué procesos cubre cada uno, por dónde empezar en un negocio digital y cómo conectarlos sin duplicar datos. - [El caos técnico no aparece en la cuenta de resultados hasta que ya es tarde](https://fcgsystems.es/blog/caos-tecnico-coste-invisible/) · Sistemas · 2026-09-16: El desorden técnico no tiene una línea propia en tus cuentas: se reparte en cobros que fallan, accesos mal dados y horas a mano. Cómo ponerle número. - [El piloto de IA que nunca llega a producción: por qué la demo funciona y el sistema no existe](https://fcgsystems.es/blog/el-piloto-de-ia-que-nunca-llega-a-produccion/) · IA aplicada · 2026-09-16: Por qué tantas pruebas de IA se quedan en demo eterna, qué separa un piloto de un sistema en producción y qué exijo antes de dar por buena una prueba. - [Facturación electrónica obligatoria: qué sistemas tuyos tienen que hablar entre sí](https://fcgsystems.es/blog/facturacion-electronica-integracion/) · Automatización · 2026-09-16: Qué es la facturación electrónica obligatoria en España, qué plazos marca el Real Decreto 238/2026 y cómo integrarla con tu CRM, tus pagos y tus altas. - [Funnel de ventas: las etapas y las piezas técnicas que lo hacen medible](https://fcgsystems.es/blog/funnel-de-ventas-sistema/) · Sistemas · 2026-09-16: Qué es un funnel de ventas, cuáles son sus etapas y qué pieza técnica necesita cada una para que el embudo se pueda medir y operar sin cifras inventadas. - [Herramientas de automatización: qué categorías hay y cuándo cada una se queda corta](https://fcgsystems.es/blog/herramientas-de-automatizacion/) · Automatización · 2026-09-16: Panorama de las herramientas de automatización por categorías, con los criterios que deciden la elección y las señales de que la tuya se ha quedado corta. - [KPI: qué es, cuáles mirar de verdad en un negocio digital y de dónde sale cada número](https://fcgsystems.es/blog/kpis-negocio-digital/) · Sistemas · 2026-09-16: Qué es un KPI, en qué se diferencia de una métrica y qué indicadores mirar en un negocio digital: CAC, LTV, conversión por etapa y de dónde sale cada dato. - [La IA no elimina la revisión del código: la convierte en el cuello de botella real](https://fcgsystems.es/blog/la-ia-no-elimina-la-revision/) · Software · 2026-09-16: Generar código dejó de ser el límite. Ahora lo es el criterio para revisarlo. Por qué el volumen de código generado por IA hace la revisión más necesaria. - [Lead scoring con reglas o con IA: qué necesitas antes de puntuar y qué hacer con el score](https://fcgsystems.es/blog/lead-scoring-reglas-o-ia/) · Automatización · 2026-09-16: Qué es el lead scoring, qué datos necesitas antes de puntuar, cómo se calcula con reglas, cuándo aporta la IA y qué hacer con el score en el reparto comercial. - [Lovable vs Bolt vs v0: comparativa honesta por criterios de uso real](https://fcgsystems.es/blog/lovable-vs-bolt-vs-v0/) · Software · 2026-09-16: Lovable vs Bolt vs v0: para qué sirve cada una, qué código genera, qué control te deja, qué pasa al exportar y cuándo ninguna de las tres es la respuesta. - [Lovable: qué es, qué resuelve de verdad y hasta dónde llega antes de ser un producto](https://fcgsystems.es/blog/lovable-que-es-y-hasta-donde-llega/) · Software · 2026-09-16: Qué es Lovable, qué construye realmente con IA y dónde está su límite: datos, permisos, pagos, dominio, copias y costes antes de llamarlo producto. - [Modelos de atribución: último clic, lineal, basado en datos y por qué ninguno te va a cuadrar solo](https://fcgsystems.es/blog/modelos-de-atribucion/) · Sistemas · 2026-09-16: Qué son los modelos de atribución, cómo reparte el crédito cada uno, qué sesgo tiene y por qué un negocio digital necesita su propia atribución en el CRM. - [Prototipos con IA para clientes de agencia: vender y validar sin prometer lo que no se sostiene](https://fcgsystems.es/blog/prototipo-con-ia-para-clientes-de-agencia/) · Software · 2026-09-16: Cómo usar Lovable, Bolt o v0 para vender y validar con tu cliente sin prometer de más, qué entregar al equipo técnico, qué preguntar y qué no firmar. - [Qué es el vibe coding: de dónde viene, dónde funciona de verdad y dónde te la juegas](https://fcgsystems.es/blog/que-es-vibe-coding/) · Software · 2026-09-16: Qué es el vibe coding, quién acuñó el término y en qué casos funciona: prototipos e internas sí, dinero, datos y accesos no. Con el límite explicado sin humo. - [Qué es la atribución en marketing (y por qué nunca cuadra entre canales)](https://fcgsystems.es/blog/que-es-la-atribucion/) · Sistemas · 2026-09-16: Qué es la atribución en marketing, qué significa atribuir una venta a un canal, por qué las cifras no coinciden entre herramientas y qué mirar para decidir. - [Qué es la automatización de procesos (y qué no lo es)](https://fcgsystems.es/blog/que-es-automatizacion-de-procesos/) · Automatización · 2026-09-16: Qué es la automatización de procesos, para qué sirve, qué tipos hay y cuándo no compensa automatizar. Explicado desde quien construye y opera los sistemas. - [Qué es MCP (Model Context Protocol) y qué cambia para un negocio que ya tiene sus sistemas](https://fcgsystems.es/blog/que-es-mcp-model-context-protocol/) · IA aplicada · 2026-09-16: Qué es el Model Context Protocol, en qué se diferencia de una API, cuándo compensa montar un servidor MCP propio y qué permisos no deberías exponer nunca. - [Qué es n8n y para qué sirve: la guía para un negocio que ya factura, no un tutorial de instalación](https://fcgsystems.es/blog/que-es-n8n/) · Automatización · 2026-09-16: Qué es n8n y para qué sirve en un negocio que ya factura: qué procesos resuelve, qué cuesta operarlo, qué dice su licencia y cuándo no es la respuesta. - [Qué es Stripe y cómo se integra con tus accesos, tu CRM y tu embudo de venta](https://fcgsystems.es/blog/que-es-stripe/) · Infraestructura · 2026-09-16: Qué es Stripe, en qué se diferencian Link y los enlaces de pago, qué comisiones cobra en España y cómo conectarlo con tu CRM, tus accesos y tu facturación. - [Qué es un chatbot (y en qué se diferencia de un agente de IA)](https://fcgsystems.es/blog/que-es-un-chatbot/) · IA aplicada · 2026-09-16: Qué es un chatbot, cómo funciona, qué tipos hay y en qué se diferencia de ChatGPT o de un agente de IA. Con las desventajas reales y cuándo no hace falta. - [Qué es un CRM (y qué es en realidad para un negocio digital)](https://fcgsystems.es/blog/que-es-un-crm/) · Sistemas · 2026-09-16: Qué es un CRM, para qué sirve en una empresa, qué tipos hay y en qué se diferencia de un ERP. Con el criterio de cuándo un Excel deja de ser suficiente. - [Qué es un dashboard (y por qué el tuyo no sirve para decidir)](https://fcgsystems.es/blog/que-es-un-dashboard/) · Sistemas · 2026-09-16: Qué es un dashboard, qué significa en español, qué debe tener y en qué se diferencia de un informe. Y por qué muchos paneles no sirven para decidir nada. - [Qué es un infoproducto y qué infraestructura necesita por debajo para funcionar](https://fcgsystems.es/blog/infoproductos-que-son/) · Infraestructura · 2026-09-16: Qué es un infoproducto, qué tipos hay y qué necesita cada uno por debajo: pagos, accesos, entregas y datos. La parte técnica que decide si aguanta o no. - [Qué es un lead (en marketing, en ventas y dentro de tu CRM)](https://fcgsystems.es/blog/que-es-un-lead/) · Automatización · 2026-09-16: Qué es un lead, qué significa en español, qué tipos existen y en qué se diferencia de un contacto. Con el matiz que importa: cómo se define en tu CRM. - [Qué es un UTM y cómo montar una nomenclatura de campañas que no se rompe](https://fcgsystems.es/blog/que-es-utm/) · Sistemas · 2026-09-16: Qué es un UTM, para qué sirve cada parámetro y cómo fijar una nomenclatura de campañas que no rompa la atribución cuando cada persona escribe lo que quiere. - [Revisar código generado por IA: qué mirar antes de que toque dinero, datos o accesos](https://fcgsystems.es/blog/revisar-codigo-generado-por-ia/) · Software · 2026-09-16: Cómo revisar el código que genera la IA antes de publicarlo: permisos, secretos, dependencias, validación y registro, ordenado por las categorías de OWASP 2025. - [Si todo depende de una persona no tienes un sistema, tienes un rehén](https://fcgsystems.es/blog/cuando-el-sistema-eres-tu/) · Sistemas · 2026-09-16: Un negocio donde todo pasa por una cabeza no es un negocio ágil, es un negocio secuestrado. Cómo saber si el rehén eres tú y por dónde se empieza a soltar. - [Tipos de CRM: operativo, analítico, colaborativo y el cuarto que casi nadie menciona](https://fcgsystems.es/blog/tipos-de-crm/) · Sistemas · 2026-09-16: Qué tipos de CRM existen, qué resuelve cada uno, en qué se quedan cortos y cuándo un negocio digital necesita un CRM a medida en vez de otro SaaS. - [Transcripción de audio a texto con IA: cómo automatizarla para llamadas, reuniones y contenido](https://fcgsystems.es/blog/transcripcion-audio-texto-ia/) · IA aplicada · 2026-09-16: Cómo pasar audio a texto con IA y automatizarlo de verdad: llamadas de ventas al CRM, actas y contenido, con criterios de precisión, idioma y coste. - [Tu stack no está roto por usar no-code, está roto por no saber dónde vive la verdad](https://fcgsystems.es/blog/no-code-fuente-de-verdad/) · Automatización · 2026-09-16: Defensa honesta del no-code y de su límite real. El problema casi nunca es la herramienta: es que el mismo dato vive en cuatro sitios y ninguno manda. - [Vendí un infoproducto en el que dejé de creer, y eso decide lo que construyo hoy](https://fcgsystems.es/blog/vendi-un-infoproducto-en-el-que-deje-de-creer/) · Sistemas · 2026-09-16: Me fui del primer infoproducto que vendí porque no cumplía lo que prometía. Lo que aquello me enseñó sobre construir sistemas que se pueden defender. - [Verifactu: qué cambia en tu facturación y qué tiene que hacer tu software (no tu asesor)](https://fcgsystems.es/blog/verifactu-que-es/) · Automatización · 2026-09-16: Qué es Verifactu, qué exige el reglamento a tu software de facturación, qué plazos marca el BOE y qué tienes que tocar en tus sistemas antes de 2027. - [Sistemas para negocios digitales: qué son, qué capas tienen y cuándo los necesitas](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/) · Sistemas · 2026-09-15: Qué es un sistema para negocios digitales, qué capas tiene (automatización, software, IA, infraestructura y datos) y cómo saber si tu operación ya lo necesita. - [Atribución rota: por qué GA4, Meta y tu CRM nunca dan la misma cifra](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/) · Sistemas · 2026-09-15: Seguimos el recorrido de un registro para ver dónde se pierde su origen entre anuncio, formulario, WhatsApp y CRM, y cómo montar una atribución de leads fiable. - [Automatización de procesos con IA: qué automatizar primero, qué dejar en reglas y dónde todavía no compensa](https://fcgsystems.es/blog/ia-aplicada-negocios-digitales/) · IA aplicada · 2026-09-15: Qué procesos se pueden automatizar con IA y cuáles no, en qué se diferencia de una automatización normal, y cómo controlar la calidad en producción. - [Cuando todo depende de una persona: capacidad técnica sin montar un departamento](https://fcgsystems.es/blog/dependencia-de-una-persona-capacidad-tecnica/) · Sistemas · 2026-09-15: Si tus automatizaciones dependen de una sola persona, tienes un riesgo operativo. Cómo repartirlo: documentación, ownership y un departamento técnico externo. - [El problema de muchas automatizaciones no es que fallen: es que nadie sabe que han fallado](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/) · Automatización · 2026-09-15: Por qué las automatizaciones que fallan sin avisar son más peligrosas que las que se rompen del todo, y cómo hacer observable un flujo de n8n, Make o Zapier. - [Leads que se pierden: del formulario al comercial sin un Excel de por medio](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/) · Automatización · 2026-09-15: Por qué se pierden leads entre formulario, WhatsApp y comercial, cuándo un Excel deja de servir como CRM y cómo automatizar la asignación sin parar las ventas. - [n8n precios: Cloud o self-hosted, qué cuesta de verdad y qué necesitas para operarlo en producción](https://fcgsystems.es/blog/n8n-precios-cloud-self-hosted/) · Infraestructura · 2026-09-15: Precios de n8n Cloud, qué cuenta como ejecución, cuánto cuesta de verdad n8n self-hosted y qué necesita en producción: Postgres, clave de cifrado y backups. - [n8n vs Make y otras alternativas a n8n: cuál elegir para un negocio digital que ya tiene volumen](https://fcgsystems.es/blog/n8n-vs-make/) · Automatización · 2026-09-15: n8n vs Make y otras alternativas a n8n para un negocio digital: coste por ejecución o por crédito, gestión de errores, servidor propio y cuándo elegir cada una. - [Pagos fallidos en Stripe: cómo recuperarlos y dar o quitar el acceso al curso sin hacerlo a mano](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/) · Automatización · 2026-09-15: Qué hace Stripe con un pago recurrente fallido, qué estado de suscripción debe dar o quitar el acceso a tu curso o membresía y cómo automatizarlo sin errores. - [Píxel de Meta y API de conversiones: cómo usar los dos sin contar cada conversión dos veces](https://fcgsystems.es/blog/pixel-meta-api-conversiones-duplicados/) · Sistemas · 2026-09-15: Por qué Meta cuenta leads y compras dos veces al usar píxel y API de conversiones, cómo funciona la deduplicación con event_id y qué revisar paso a paso. - [Qué tiene que estar listo antes de abrir registros en un lanzamiento: checklist técnico](https://fcgsystems.es/blog/checklist-tecnico-lanzamiento/) · Infraestructura · 2026-09-15: Checklist técnico de un lanzamiento por fases: captación, tracking, deduplicación, CRM, asignación, WhatsApp y dashboards listos antes de abrir registros. - [Software a medida o no-code: señales de que Make, n8n o Airtable se os han quedado cortos](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/) · Software · 2026-09-15: Qué es el software a medida, cuándo compensa frente al no-code, señales de que Make, n8n o Airtable no bastan y cómo migrar por piezas sin parar la operación. - [Webhook de n8n que no funciona: causas, cómo diagnosticarlo y cómo evitar que vuelva a fallar](https://fcgsystems.es/blog/webhook-n8n-no-funciona/) · Automatización · 2026-09-15: Por qué un webhook de n8n funciona en pruebas y no en producción, qué significan 404 y 524 y cómo diagnosticarlo paso a paso sin perder los datos que llegan. - [WhatsApp Business API: qué es, cuánto cuesta y cuándo usarla para vender, automatizar o poner un chatbot](https://fcgsystems.es/blog/whatsapp-business-api/) · Automatización · 2026-09-15: Qué es la WhatsApp Business API, en qué se diferencia de la app, cómo cobra Meta, sus límites y cuándo compensa para ventas, automatización o un chatbot con IA. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Sistemas: cómo diseñar operaciones que escalan > Artículos sobre arquitectura de sistemas para negocios digitales: fuentes de verdad, datos, atribución y cómo operar sin depender de una sola persona. - URL: https://fcgsystems.es/blog/sistemas/ - Tipo: archivo del blog de FCG Systems (índice de artículos, no un artículo) - Artículos: 18 - Índice del blog: https://fcgsystems.es/blog/ · Autor: Gabriel Florencio Calvo (https://fcgsystems.es/blog/autor/gabriel-florencio/) Arquitectura, fuentes de verdad y operación: lo que hace que un negocio digital crezca sin multiplicar su complejidad. ## Artículos - [Sistemas para negocios digitales: qué son, qué capas tienen y cuándo los necesitas](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/) · 2026-09-15: Qué es un sistema para negocios digitales, qué capas tiene (automatización, software, IA, infraestructura y datos) y cómo saber si tu operación ya lo necesita. - [Cerrar clientes sin audiencia: se vende por criterio, no por postureo](https://fcgsystems.es/blog/cerrar-clientes-sin-audiencia/) · 2026-09-16: Se puede cerrar trabajo serio con una cuenta de tres cifras de seguidores. No es carisma ni volumen: es diagnosticar mejor que nadie y saber decir que no. - [CRM para pymes y negocios digitales: para qué sirve, cómo elegirlo y cuándo compensa uno a medida](https://fcgsystems.es/blog/crm-para-pymes-saas-o-a-medida/) · 2026-09-16: Para qué sirve un CRM en una pyme o negocio digital, qué exigirle antes de elegirlo y cuándo compensa un CRM SaaS, uno a medida o una combinación de ambos. - [Diferencia entre CRM y ERP: qué resuelve cada uno y cuándo necesitas los dos](https://fcgsystems.es/blog/diferencia-crm-erp/) · 2026-09-16: Qué diferencia hay entre un CRM y un ERP, qué procesos cubre cada uno, por dónde empezar en un negocio digital y cómo conectarlos sin duplicar datos. - [El caos técnico no aparece en la cuenta de resultados hasta que ya es tarde](https://fcgsystems.es/blog/caos-tecnico-coste-invisible/) · 2026-09-16: El desorden técnico no tiene una línea propia en tus cuentas: se reparte en cobros que fallan, accesos mal dados y horas a mano. Cómo ponerle número. - [Funnel de ventas: las etapas y las piezas técnicas que lo hacen medible](https://fcgsystems.es/blog/funnel-de-ventas-sistema/) · 2026-09-16: Qué es un funnel de ventas, cuáles son sus etapas y qué pieza técnica necesita cada una para que el embudo se pueda medir y operar sin cifras inventadas. - [KPI: qué es, cuáles mirar de verdad en un negocio digital y de dónde sale cada número](https://fcgsystems.es/blog/kpis-negocio-digital/) · 2026-09-16: Qué es un KPI, en qué se diferencia de una métrica y qué indicadores mirar en un negocio digital: CAC, LTV, conversión por etapa y de dónde sale cada dato. - [Modelos de atribución: último clic, lineal, basado en datos y por qué ninguno te va a cuadrar solo](https://fcgsystems.es/blog/modelos-de-atribucion/) · 2026-09-16: Qué son los modelos de atribución, cómo reparte el crédito cada uno, qué sesgo tiene y por qué un negocio digital necesita su propia atribución en el CRM. - [Qué es la atribución en marketing (y por qué nunca cuadra entre canales)](https://fcgsystems.es/blog/que-es-la-atribucion/) · 2026-09-16: Qué es la atribución en marketing, qué significa atribuir una venta a un canal, por qué las cifras no coinciden entre herramientas y qué mirar para decidir. - [Qué es un CRM (y qué es en realidad para un negocio digital)](https://fcgsystems.es/blog/que-es-un-crm/) · 2026-09-16: Qué es un CRM, para qué sirve en una empresa, qué tipos hay y en qué se diferencia de un ERP. Con el criterio de cuándo un Excel deja de ser suficiente. - [Qué es un dashboard (y por qué el tuyo no sirve para decidir)](https://fcgsystems.es/blog/que-es-un-dashboard/) · 2026-09-16: Qué es un dashboard, qué significa en español, qué debe tener y en qué se diferencia de un informe. Y por qué muchos paneles no sirven para decidir nada. - [Qué es un UTM y cómo montar una nomenclatura de campañas que no se rompe](https://fcgsystems.es/blog/que-es-utm/) · 2026-09-16: Qué es un UTM, para qué sirve cada parámetro y cómo fijar una nomenclatura de campañas que no rompa la atribución cuando cada persona escribe lo que quiere. - [Si todo depende de una persona no tienes un sistema, tienes un rehén](https://fcgsystems.es/blog/cuando-el-sistema-eres-tu/) · 2026-09-16: Un negocio donde todo pasa por una cabeza no es un negocio ágil, es un negocio secuestrado. Cómo saber si el rehén eres tú y por dónde se empieza a soltar. - [Tipos de CRM: operativo, analítico, colaborativo y el cuarto que casi nadie menciona](https://fcgsystems.es/blog/tipos-de-crm/) · 2026-09-16: Qué tipos de CRM existen, qué resuelve cada uno, en qué se quedan cortos y cuándo un negocio digital necesita un CRM a medida en vez de otro SaaS. - [Vendí un infoproducto en el que dejé de creer, y eso decide lo que construyo hoy](https://fcgsystems.es/blog/vendi-un-infoproducto-en-el-que-deje-de-creer/) · 2026-09-16: Me fui del primer infoproducto que vendí porque no cumplía lo que prometía. Lo que aquello me enseñó sobre construir sistemas que se pueden defender. - [Atribución rota: por qué GA4, Meta y tu CRM nunca dan la misma cifra](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/) · 2026-09-15: Seguimos el recorrido de un registro para ver dónde se pierde su origen entre anuncio, formulario, WhatsApp y CRM, y cómo montar una atribución de leads fiable. - [Cuando todo depende de una persona: capacidad técnica sin montar un departamento](https://fcgsystems.es/blog/dependencia-de-una-persona-capacidad-tecnica/) · 2026-09-15: Si tus automatizaciones dependen de una sola persona, tienes un riesgo operativo. Cómo repartirlo: documentación, ownership y un departamento técnico externo. - [Píxel de Meta y API de conversiones: cómo usar los dos sin contar cada conversión dos veces](https://fcgsystems.es/blog/pixel-meta-api-conversiones-duplicados/) · 2026-09-15: Por qué Meta cuenta leads y compras dos veces al usar píxel y API de conversiones, cómo funciona la deduplicación con event_id y qué revisar paso a paso. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Automatización: qué automatizar y qué no > Artículos sobre automatización para negocios digitales: leads, CRM, integraciones, reintentos, logs y automatizaciones que no fallan en silencio. - URL: https://fcgsystems.es/blog/automatizacion/ - Tipo: archivo del blog de FCG Systems (índice de artículos, no un artículo) - Artículos: 17 - Índice del blog: https://fcgsystems.es/blog/ · Autor: Gabriel Florencio Calvo (https://fcgsystems.es/blog/autor/gabriel-florencio/) Qué automatizar, qué no y cómo hacerlo para que siga funcionando cuando sube el volumen. ## Artículos - [Automatización de marketing: qué se automatiza bien y qué se rompe cuando el dato está sucio](https://fcgsystems.es/blog/automatizacion-de-marketing/) · 2026-09-16: Qué se automatiza bien en marketing, qué se rompe cuando los datos del CRM están sucios y la higiene mínima que necesita un flujo antes de activarlo. - [Automatizar sin vigilar es peor que no automatizar](https://fcgsystems.es/blog/automatizar-sin-vigilar-es-peor/) · 2026-09-16: Una automatización sin alertas y sin dueño no te ahorra trabajo: te lo esconde. Por qué el fallo silencioso hace más daño que el proceso manual que sustituye. - [Cómo funciona n8n: cuatro ejemplos reales de flujos para un negocio digital](https://fcgsystems.es/blog/como-funciona-n8n-ejemplos/) · 2026-09-16: Cómo funciona n8n explicado con cuatro ejemplos de negocio: leads al CRM, acceso tras el pago, conciliación nocturna y clasificación con IA, con sus fallos. - [Facturación electrónica obligatoria: qué sistemas tuyos tienen que hablar entre sí](https://fcgsystems.es/blog/facturacion-electronica-integracion/) · 2026-09-16: Qué es la facturación electrónica obligatoria en España, qué plazos marca el Real Decreto 238/2026 y cómo integrarla con tu CRM, tus pagos y tus altas. - [Herramientas de automatización: qué categorías hay y cuándo cada una se queda corta](https://fcgsystems.es/blog/herramientas-de-automatizacion/) · 2026-09-16: Panorama de las herramientas de automatización por categorías, con los criterios que deciden la elección y las señales de que la tuya se ha quedado corta. - [Lead scoring con reglas o con IA: qué necesitas antes de puntuar y qué hacer con el score](https://fcgsystems.es/blog/lead-scoring-reglas-o-ia/) · 2026-09-16: Qué es el lead scoring, qué datos necesitas antes de puntuar, cómo se calcula con reglas, cuándo aporta la IA y qué hacer con el score en el reparto comercial. - [Qué es la automatización de procesos (y qué no lo es)](https://fcgsystems.es/blog/que-es-automatizacion-de-procesos/) · 2026-09-16: Qué es la automatización de procesos, para qué sirve, qué tipos hay y cuándo no compensa automatizar. Explicado desde quien construye y opera los sistemas. - [Qué es n8n y para qué sirve: la guía para un negocio que ya factura, no un tutorial de instalación](https://fcgsystems.es/blog/que-es-n8n/) · 2026-09-16: Qué es n8n y para qué sirve en un negocio que ya factura: qué procesos resuelve, qué cuesta operarlo, qué dice su licencia y cuándo no es la respuesta. - [Qué es un lead (en marketing, en ventas y dentro de tu CRM)](https://fcgsystems.es/blog/que-es-un-lead/) · 2026-09-16: Qué es un lead, qué significa en español, qué tipos existen y en qué se diferencia de un contacto. Con el matiz que importa: cómo se define en tu CRM. - [Tu stack no está roto por usar no-code, está roto por no saber dónde vive la verdad](https://fcgsystems.es/blog/no-code-fuente-de-verdad/) · 2026-09-16: Defensa honesta del no-code y de su límite real. El problema casi nunca es la herramienta: es que el mismo dato vive en cuatro sitios y ninguno manda. - [Verifactu: qué cambia en tu facturación y qué tiene que hacer tu software (no tu asesor)](https://fcgsystems.es/blog/verifactu-que-es/) · 2026-09-16: Qué es Verifactu, qué exige el reglamento a tu software de facturación, qué plazos marca el BOE y qué tienes que tocar en tus sistemas antes de 2027. - [El problema de muchas automatizaciones no es que fallen: es que nadie sabe que han fallado](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/) · 2026-09-15: Por qué las automatizaciones que fallan sin avisar son más peligrosas que las que se rompen del todo, y cómo hacer observable un flujo de n8n, Make o Zapier. - [Leads que se pierden: del formulario al comercial sin un Excel de por medio](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/) · 2026-09-15: Por qué se pierden leads entre formulario, WhatsApp y comercial, cuándo un Excel deja de servir como CRM y cómo automatizar la asignación sin parar las ventas. - [n8n vs Make y otras alternativas a n8n: cuál elegir para un negocio digital que ya tiene volumen](https://fcgsystems.es/blog/n8n-vs-make/) · 2026-09-15: n8n vs Make y otras alternativas a n8n para un negocio digital: coste por ejecución o por crédito, gestión de errores, servidor propio y cuándo elegir cada una. - [Pagos fallidos en Stripe: cómo recuperarlos y dar o quitar el acceso al curso sin hacerlo a mano](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/) · 2026-09-15: Qué hace Stripe con un pago recurrente fallido, qué estado de suscripción debe dar o quitar el acceso a tu curso o membresía y cómo automatizarlo sin errores. - [Webhook de n8n que no funciona: causas, cómo diagnosticarlo y cómo evitar que vuelva a fallar](https://fcgsystems.es/blog/webhook-n8n-no-funciona/) · 2026-09-15: Por qué un webhook de n8n funciona en pruebas y no en producción, qué significan 404 y 524 y cómo diagnosticarlo paso a paso sin perder los datos que llegan. - [WhatsApp Business API: qué es, cuánto cuesta y cuándo usarla para vender, automatizar o poner un chatbot](https://fcgsystems.es/blog/whatsapp-business-api/) · 2026-09-15: Qué es la WhatsApp Business API, en qué se diferencia de la app, cómo cobra Meta, sus límites y cuándo compensa para ventas, automatización o un chatbot con IA. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Software: cuándo necesitas software propio > Artículos sobre software a medida para negocios digitales: cuándo dejar el no-code, qué falta para llevar a producción lo que genera la IA y cómo migrar sin parar. - URL: https://fcgsystems.es/blog/software/ - Tipo: archivo del blog de FCG Systems (índice de artículos, no un artículo) - Artículos: 9 - Índice del blog: https://fcgsystems.es/blog/ · Autor: Gabriel Florencio Calvo (https://fcgsystems.es/blog/autor/gabriel-florencio/) Cuándo una empresa necesita software propio, y qué separa una demo generada con IA de un producto que aguanta. ## Artículos - ["Funciona" no es el listón: lo que reviso antes de dar algo por terminado](https://fcgsystems.es/blog/funciona-no-es-el-liston/) · 2026-09-16: La demo siempre sale bien: la haces tú, con datos limpios y sin prisa. Lo que de verdad decide si algo está terminado son las preguntas del día malo. - [De prototipo con IA a producción: lo que siempre falta cuando la demo ya funciona](https://fcgsystems.es/blog/de-prototipo-ia-a-produccion/) · 2026-09-16: Qué falta siempre para llevar a producción una app creada con IA: permisos, datos, pagos, límites, observabilidad, costes y propiedad. Con checklist accionable. - [La IA no elimina la revisión del código: la convierte en el cuello de botella real](https://fcgsystems.es/blog/la-ia-no-elimina-la-revision/) · 2026-09-16: Generar código dejó de ser el límite. Ahora lo es el criterio para revisarlo. Por qué el volumen de código generado por IA hace la revisión más necesaria. - [Lovable vs Bolt vs v0: comparativa honesta por criterios de uso real](https://fcgsystems.es/blog/lovable-vs-bolt-vs-v0/) · 2026-09-16: Lovable vs Bolt vs v0: para qué sirve cada una, qué código genera, qué control te deja, qué pasa al exportar y cuándo ninguna de las tres es la respuesta. - [Lovable: qué es, qué resuelve de verdad y hasta dónde llega antes de ser un producto](https://fcgsystems.es/blog/lovable-que-es-y-hasta-donde-llega/) · 2026-09-16: Qué es Lovable, qué construye realmente con IA y dónde está su límite: datos, permisos, pagos, dominio, copias y costes antes de llamarlo producto. - [Prototipos con IA para clientes de agencia: vender y validar sin prometer lo que no se sostiene](https://fcgsystems.es/blog/prototipo-con-ia-para-clientes-de-agencia/) · 2026-09-16: Cómo usar Lovable, Bolt o v0 para vender y validar con tu cliente sin prometer de más, qué entregar al equipo técnico, qué preguntar y qué no firmar. - [Qué es el vibe coding: de dónde viene, dónde funciona de verdad y dónde te la juegas](https://fcgsystems.es/blog/que-es-vibe-coding/) · 2026-09-16: Qué es el vibe coding, quién acuñó el término y en qué casos funciona: prototipos e internas sí, dinero, datos y accesos no. Con el límite explicado sin humo. - [Revisar código generado por IA: qué mirar antes de que toque dinero, datos o accesos](https://fcgsystems.es/blog/revisar-codigo-generado-por-ia/) · 2026-09-16: Cómo revisar el código que genera la IA antes de publicarlo: permisos, secretos, dependencias, validación y registro, ordenado por las categorías de OWASP 2025. - [Software a medida o no-code: señales de que Make, n8n o Airtable se os han quedado cortos](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/) · 2026-09-15: Qué es el software a medida, cuándo compensa frente al no-code, señales de que Make, n8n o Airtable no bastan y cómo migrar por piezas sin parar la operación. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # IA aplicada: casos reales dentro de procesos > Artículos sobre IA aplicada a negocios digitales: clasificación, resúmenes, scoring y asistentes dentro de procesos reales, con control de calidad. - URL: https://fcgsystems.es/blog/ia/ - Tipo: archivo del blog de FCG Systems (índice de artículos, no un artículo) - Artículos: 8 - Índice del blog: https://fcgsystems.es/blog/ · Autor: Gabriel Florencio Calvo (https://fcgsystems.es/blog/autor/gabriel-florencio/) IA dentro de procesos reales, con métricas de calidad, no como escaparate. ## Artículos - [Agente de voz con IA: cuándo automatizar una llamada tiene sentido (y cuándo es humo)](https://fcgsystems.es/blog/agente-de-voz-ia/) · 2026-09-16: Qué es un agente de voz con IA, cómo funciona por dentro y en qué llamadas compensa: latencia, interrupciones, traspaso a humano y qué no se delega al modelo. - [Agentes de IA para negocios: qué son, cuándo compensan y cómo se construyen sin perder el control](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/) · 2026-09-16: Qué es un agente de IA, en qué se diferencia de un chatbot o una automatización, cuándo compensa en un negocio digital y cómo crearlo paso a paso con control. - [Dar permisos a un agente de IA es una decisión de riesgo, no una casilla de configuración](https://fcgsystems.es/blog/permisos-de-un-agente-decision-de-riesgo/) · 2026-09-16: Qué no se delega nunca a un modelo: accesos, cobros, precios e identidad. Cómo decidir los permisos de un agente de IA con criterio de riesgo, no de setup. - [El piloto de IA que nunca llega a producción: por qué la demo funciona y el sistema no existe](https://fcgsystems.es/blog/el-piloto-de-ia-que-nunca-llega-a-produccion/) · 2026-09-16: Por qué tantas pruebas de IA se quedan en demo eterna, qué separa un piloto de un sistema en producción y qué exijo antes de dar por buena una prueba. - [Qué es MCP (Model Context Protocol) y qué cambia para un negocio que ya tiene sus sistemas](https://fcgsystems.es/blog/que-es-mcp-model-context-protocol/) · 2026-09-16: Qué es el Model Context Protocol, en qué se diferencia de una API, cuándo compensa montar un servidor MCP propio y qué permisos no deberías exponer nunca. - [Qué es un chatbot (y en qué se diferencia de un agente de IA)](https://fcgsystems.es/blog/que-es-un-chatbot/) · 2026-09-16: Qué es un chatbot, cómo funciona, qué tipos hay y en qué se diferencia de ChatGPT o de un agente de IA. Con las desventajas reales y cuándo no hace falta. - [Transcripción de audio a texto con IA: cómo automatizarla para llamadas, reuniones y contenido](https://fcgsystems.es/blog/transcripcion-audio-texto-ia/) · 2026-09-16: Cómo pasar audio a texto con IA y automatizarlo de verdad: llamadas de ventas al CRM, actas y contenido, con criterios de precisión, idioma y coste. - [Automatización de procesos con IA: qué automatizar primero, qué dejar en reglas y dónde todavía no compensa](https://fcgsystems.es/blog/ia-aplicada-negocios-digitales/) · 2026-09-15: Qué procesos se pueden automatizar con IA y cuáles no, en qué se diferencia de una automatización normal, y cómo controlar la calidad en producción. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Infraestructura: lo que sostiene una operación fiable > Artículos sobre infraestructura para negocios digitales: lanzamientos, servidores, backups, monitorización y todo lo que debe existir antes del pico. - URL: https://fcgsystems.es/blog/infraestructura/ - Tipo: archivo del blog de FCG Systems (índice de artículos, no un artículo) - Artículos: 4 - Índice del blog: https://fcgsystems.es/blog/ · Autor: Gabriel Florencio Calvo (https://fcgsystems.es/blog/autor/gabriel-florencio/) Todo lo que debe existir detrás de una operación fiable, del servidor al lanzamiento. ## Artículos - [Qué es Stripe y cómo se integra con tus accesos, tu CRM y tu embudo de venta](https://fcgsystems.es/blog/que-es-stripe/) · 2026-09-16: Qué es Stripe, en qué se diferencian Link y los enlaces de pago, qué comisiones cobra en España y cómo conectarlo con tu CRM, tus accesos y tu facturación. - [Qué es un infoproducto y qué infraestructura necesita por debajo para funcionar](https://fcgsystems.es/blog/infoproductos-que-son/) · 2026-09-16: Qué es un infoproducto, qué tipos hay y qué necesita cada uno por debajo: pagos, accesos, entregas y datos. La parte técnica que decide si aguanta o no. - [n8n precios: Cloud o self-hosted, qué cuesta de verdad y qué necesitas para operarlo en producción](https://fcgsystems.es/blog/n8n-precios-cloud-self-hosted/) · 2026-09-15: Precios de n8n Cloud, qué cuenta como ejecución, cuánto cuesta de verdad n8n self-hosted y qué necesita en producción: Postgres, clave de cifrado y backups. - [Qué tiene que estar listo antes de abrir registros en un lanzamiento: checklist técnico](https://fcgsystems.es/blog/checklist-tecnico-lanzamiento/) · 2026-09-15: Checklist técnico de un lanzamiento por fases: captación, tracking, deduplicación, CRM, asignación, WhatsApp y dashboards listos antes de abrir registros. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # "Funciona" no es el listón: lo que reviso antes de dar algo por terminado > La demo siempre sale bien: la haces tú, con datos limpios y sin prisa. Lo que de verdad decide si algo está terminado son las preguntas del día malo. - URL: https://fcgsystems.es/blog/funciona-no-es-el-liston/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Software · Formato: Opinión · Lectura: 4 min - Palabra clave: cuándo está terminado un desarrollo (también: la demo engaña, checklist antes de producción, criterios de calidad en automatizaciones) La demo siempre sale bien. Siempre. Y no porque nadie engañe, sino porque una demo se hace en las mejores condiciones que existirán jamás. La ejecuta quien construyó la cosa. Con datos que conoce. En un orden que ha repetido cinco veces. Sin nadie más usando el sistema a la vez. Sin la API de terceros teniendo un mal día. Sin el cliente que escribe su nombre en mayúsculas con un emoji al final. Por eso "funciona" nunca me ha parecido un criterio de entrega. Es el punto de partida, no la meta. Lo que enseña una demo es que el camino feliz existe. Estupendo. El negocio no se rompe en el camino feliz. ## Lo que la demo no puede enseñarte Un sistema en producción vive rodeado de cosas que no controlas, y ahí es donde aparecen los problemas de verdad. Falla lo de fuera. La pasarela de pago tarda ocho segundos en responder. El CRM devuelve un error de límite de peticiones justo el día del lanzamiento. Un servicio cambia un campo de su respuesta sin avisar a nadie. Llegan datos raros. Un teléfono con prefijo internacional escrito de tres formas distintas. Un email con espacio al final. Un formulario enviado dos veces porque el usuario tenía mala cobertura y le dio otra vez al botón. Y llegan a la vez. Lo que funciona con un registro por minuto no tiene por qué funcionar con trescientos en cinco minutos, que es exactamente lo que pasa cuando un vídeo funciona o se abre un carrito. Ninguna de esas tres cosas aparece en una demo. Las tres aparecen en producción, normalmente el mismo día. ## Las cuatro preguntas del día malo No tengo una lista de cincuenta puntos. Tengo cuatro preguntas, y las hago siempre, sea un desarrollo a medida o una automatización de diez minutos. Si alguna se queda sin respuesta clara, para mí el trabajo no está terminado aunque la funcionalidad esté hecha. **¿Qué pasa si el sistema del que depende no responde?** No "si falla", que eso ya se contempla. Si no responde: si se queda colgado, si tarda veinte segundos, si devuelve un error raro. Necesito saber si el proceso reintenta, cuántas veces, con qué espera entre intentos, y qué hace cuando se rinde. Un flujo que se rinde en silencio es peor que uno que no existe, porque el que no existe al menos nadie cree que esté cubriéndole. **¿Qué pasa si el mismo evento llega dos veces?** Los webhooks se repiten. Es normal y está en la documentación de casi todos los proveedores. La pregunta es si tu sistema lo sabe. Si el mismo aviso de pago crea dos accesos, dos contactos y dos emails, no tienes un sistema, tienes un generador de trabajo manual. El detalle de cómo se depuran estos casos lo cuento en [webhook de n8n que no funciona](https://fcgsystems.es/blog/webhook-n8n-no-funciona/). **¿Quién se entera si esto falla un domingo por la noche?** Esta es la que más incomoda, y por eso la hago siempre. Si la respuesta es "lo veríamos el lunes", vale, puede ser aceptable según lo que haga el proceso. Si la respuesta es "un cliente nos escribiría", entonces tu sistema de monitorización son tus clientes enfadados. Eso lo desarrollo entero en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). **¿Cómo se deshace si sale mal?** Si un proceso da accesos, cobra o envía correos, quiero saber cómo se revierte antes de encenderlo. No después. Un botón, un script, un procedimiento escrito, me da igual el formato. Lo que no vale es descubrir el camino de vuelta en mitad del incidente. ## Por qué esto no es perfeccionismo Lo digo porque me lo han dicho: que así todo tarda más. Sí, la entrega tarda más. Y el año siguiente cuesta mucho menos. Una incidencia prevenida cuesta unas horas de trabajo tranquilo. La misma incidencia en caliente cuesta esas horas más el coste de tenerte a ti apagando el fuego, más los clientes afectados, más las decisiones improvisadas a las once de la noche que luego hay que deshacer. Nadie contabiliza esa diferencia porque una de las dos facturas no llega nunca, pero está ahí. Y hay una parte menos medible que a mí me importa igual: poder dormir. Un sistema que puede fallar sin avisar te obliga a estar pendiente para siempre. Uno que avisa te devuelve la cabeza. ## El listón que uso No es "funciona". Es "sé por qué funciona y sé qué hace cuando deje de funcionar". Esa segunda mitad es la que separa un entregable de un sistema. Y no depende de la tecnología ni de si lo has escrito tú o lo ha generado una herramienta: depende de si alguien se ha sentado a pensar en el día malo antes de que llegue. Si estás a punto de aprobar algo, hazle las cuatro preguntas a quien te lo entrega. No hace falta que seas técnico para entender las respuestas. Y si alguna se responde con un "bueno, eso no debería pasar", ya sabes exactamente por dónde se va a romper. ## Preguntas frecuentes ### ¿Qué significa que una demo engaña? Significa que una demo se ejecuta en las mejores condiciones posibles: la hace quien construyó el sistema, con datos que conoce, en un orden que ha ensayado y sin nadie más usándolo a la vez. Producción es justo lo contrario, así que una demo perfecta solo demuestra que el camino feliz existe, no que el sistema aguante. ### ¿Qué preguntas hago antes de aprobar un desarrollo? Qué pasa si el servicio del que depende no responde, qué pasa si el mismo aviso llega dos veces, quién se entera si falla un domingo por la noche, y cómo se deshace si sale mal. Si alguna respuesta es un silencio, el trabajo no está terminado aunque la funcionalidad esté hecha. ### ¿Esto no encarece cada proyecto? Encarece la entrega y abarata el año siguiente. Las incidencias que se resuelven en caliente cuestan más que las que se previenen, porque llegan en el peor momento, con clientes mirando y con alguien improvisando. El listón alto no es perfeccionismo, es dónde eliges pagar. ## Servicios relacionados - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Agente de voz con IA: cuándo automatizar una llamada tiene sentido (y cuándo es humo) > Qué es un agente de voz con IA, cómo funciona por dentro y en qué llamadas compensa: latencia, interrupciones, traspaso a humano y qué no se delega al modelo. - URL: https://fcgsystems.es/blog/agente-de-voz-ia/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: IA aplicada · Formato: Opinión · Lectura: 7 min - Palabra clave: agente de voz ia (también: agentes de voz con ia, voz ia, ia que contesta llamadas, voicebot, agente de voz para empresas) Un agente de voz con IA es un sistema que mantiene una conversación telefónica hablada sin una persona al otro lado. Encadena tres piezas: reconocimiento de voz, un modelo que decide qué responder y consulta tus sistemas, y una voz sintética que lo dice. No es una locución con opciones: entiende frases libres y puede actuar. La tecnología ha mejorado lo suficiente como para que las demos impresionen. Ese es justo el problema: una demo son dos minutos con buena cobertura y una persona colaborando. Una operación real son mil llamadas con ruido, gente que interrumpe y casos que nadie previó. Este artículo va de dónde está hoy la línea entre lo que funciona y lo que es humo. ## ¿Cómo funciona por dentro? Cuatro eslabones, y la calidad final la marca el más débil: 1. **Reconocimiento de voz (STT).** Convierte lo que dice la persona en texto, en streaming, mientras habla. El audio telefónico está comprimido, así que aquí ya hay más errores que en una grabación de micrófono. El detalle de esta pieza lo desarrollo en [transcripción de audio a texto con IA](https://fcgsystems.es/blog/transcripcion-audio-texto-ia/). 2. **Decisión.** Un modelo de lenguaje con instrucciones, acceso a tus datos (agenda, CRM, estado de pedidos) y una lista cerrada de acciones que puede ejecutar. 3. **Síntesis de voz (TTS).** Convierte la respuesta en audio. La naturalidad ha dejado de ser el cuello de botella; el ritmo y las pausas, no tanto. 4. **Orquestación de la conversación.** Quién habla, qué pasa cuando los dos hablan a la vez, qué se hace con un silencio de cuatro segundos, cuándo se traspasa a una persona. Es la pieza menos vistosa y la que decide si la llamada es tolerable. Las plataformas del mercado empaquetan todo esto; sus propias documentaciones describen bien las piezas, por ejemplo la de [ElevenLabs sobre su plataforma de agentes](https://elevenlabs.io/docs/agents-platform/overview) (consultado en septiembre de 2026). Montarlo por piezas separadas solo compensa si necesitas control fino sobre alguna de ellas. ## Los cuatro límites que deciden si es usable ### 1. Latencia Es el criterio número uno y el que casi ninguna demo enseña honestamente. Por debajo de un segundo desde que la persona calla hasta que el agente arranca, la conversación se sostiene. Por encima, el silencio se nota: la gente repite la frase, se solapa o cuelga. Y la latencia es la del **recorrido completo**, no la del modelo. Si el agente tiene que consultar tu CRM y esa consulta tarda dos segundos, la conversación se rompe por mucho que el modelo responda en 300 milisegundos. Conclusión práctica: las consultas que el agente haga en mitad de la llamada tienen que responder en milisegundos o estar precargadas; si no, se sacan de la conversación. ### 2. Interrupciones Las personas interrumpen. Dicen "sí, sí" mientras el otro habla, cambian de idea a mitad de frase, contestan antes de que termine la pregunta. Un agente que no corta cuando le hablan encima resulta insoportable en treinta segundos. Uno que corta demasiado pronto, con cada "ajá", tampoco funciona. Esto se prueba con llamadas reales, no leyendo especificaciones. Llama tú mismo e interrumpe a propósito: a mitad de frase, con un "espera" y con un silencio largo. Si el agente aguanta las tres, algo hay. ### 3. Ruido y audio real Coche, calle, manos libres, cobertura irregular. La demo se graba en una habitación silenciosa; tus clientes llaman desde el supermercado. Prueba con audio malo antes de decidir nada. ### 4. Traspaso a humano Un agente de voz sin salida es una trampa para el que llama. Hacen falta tres cosas: - **Un disparador claro:** que la persona lo pida, que el agente no entienda dos veces seguidas, que detecte enfado o un tema fuera de alcance. - **Contexto que viaja.** La persona no puede repetir lo que acaba de contar. Quien recoge la llamada debe ver el resumen de lo hablado. - **Un plan cuando no hay nadie.** Fuera de horario, el agente toma el recado, lo deja en el CRM con su transcripción y promete una devolución de llamada con una franja concreta. Y esa devolución ocurre. ## ¿Cuándo compensa un agente de voz? Hay un patrón claro: conversaciones **repetitivas, cortas y con final definido**. | Compensa | Por qué | |---|---| | Confirmar, cambiar o recordar una cita | Objetivo único, datos acotados, error barato de corregir | | Filtrar el motivo de la llamada antes de pasarla | Sustituye a un menú de opciones y lo hace mejor | | Responder dudas frecuentes (horarios, estado de pedido, dirección) | La respuesta está en un sistema consultable | | Recoger datos de un formulario hablado | La persona habla, el agente estructura | | Recuperar llamadas perdidas fuera de horario | La alternativa es que nadie conteste | | No compensa | Por qué | |---|---| | Venta consultiva o high ticket | La confianza se construye con una persona; el matiz decide la venta | | Reclamaciones y clientes enfadados | La empatía simulada empeora un cliente cabreado | | Temas legales, sanitarios o financieros | El coste de un error es desproporcionado | | Cobros, descuentos o cambios de contrato | Decisiones irreversibles con dinero de por medio | | Volumen bajo de llamadas | El coste de montarlo y mantenerlo no lo recupera nadie | Una comprobación previa que ahorra proyectos enteros: **si el mismo trámite se puede resolver por WhatsApp o por un formulario, hazlo ahí antes.** Un canal escrito es más barato de montar, deja rastro, no tiene latencia y la gente cada vez lo prefiere más. Lo que se puede resolver por [WhatsApp Business API](https://fcgsystems.es/blog/whatsapp-business-api/) casi nunca necesita una llamada. ## Qué NO se delega al modelo Este es el criterio que separa un sistema de una demo. El modelo conversa e interpreta; las decisiones del negocio viven en código, con reglas escritas. - **Nada irreversible.** Cobrar, cancelar, aplicar un descuento, cambiar condiciones. El agente puede proponerlo; lo ejecuta una regla o una persona. - **Ninguna promesa.** Plazos, precios fuera de tarifa, excepciones. Si no está en una lista cerrada, el agente no lo dice. - **La identidad.** Un agente no valida que alguien es quien dice ser. Eso se resuelve con un factor comprobable, no con una conversación convincente. - **La clasificación que dispara procesos.** Si de la llamada sale "lead cualificado" o "urgente", el criterio va en código sobre los campos que el agente ha recogido, con umbrales escritos. Un modelo que decide etapas te las cambiará un martes sin que nadie sepa por qué. Es el mismo principio que aplico a cualquier agente, hable o escriba, y que desarrollo en [agentes de IA para negocios](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/): herramientas mínimas, permisos mínimos, condiciones de parada y aprobación humana para lo irreversible. ## Lo que casi nadie te cuenta antes de montarlo - **Hay que decir que es una IA.** Al inicio de la llamada, sin rodeos. Además de ser lo correcto, evita la escena incómoda del cliente que se siente engañado y lo cuenta en público. - **Las llamadas salientes tienen reglas propias.** Llamar a alguien que no te ha dado permiso no es un problema técnico, es un problema legal. Antes de montar nada de prospección telefónica automatizada, revisa la base jurídica con las guías de la [Agencia Española de Protección de Datos](https://www.aepd.es/). - **La grabación y la transcripción son datos personales.** Informar, limitar accesos y definir cuánto se conserva. No es opcional. - **El coste se mide por minuto y se acumula.** Reconocimiento, modelo, voz y telefonía. Consulta los precios en las páginas oficiales de cada proveedor y calcula con tus minutos reales, no con el ejemplo del comercial. - **Se degrada sin que te enteres.** Un cambio de modelo, una consulta que se ha vuelto lenta, un guion que se tocó. Hace falta escuchar una muestra de llamadas cada semana, con un criterio escrito de qué cuenta como llamada bien resuelta. Si no, tendrás el clásico de [una automatización que falla en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/), pero hablando con tus clientes. ## Cómo lo probaría antes de comprometerme 1. **Elige un solo tipo de llamada** con final claro (confirmación de cita, por ejemplo) y escribe el criterio de éxito: qué porcentaje debe terminar sin traspaso y sin que nadie tenga que arreglar nada después. 2. **Graba veinte llamadas reales** de ese tipo. Son tu banco de pruebas, con su ruido y sus interrupciones. 3. **Monta un piloto en horario acotado**, con traspaso a humano siempre disponible. 4. **Escucha las veinte primeras llamadas enteras.** Todas. Aquí es donde se aprende lo que ninguna métrica cuenta. 5. **Mide tres cosas:** llamadas resueltas sin intervención, tiempo medio y cuántas personas piden hablar con alguien. 6. **Decide con datos, no con la sensación de la demo.** Si el traspaso es la salida habitual, tienes un filtro de llamadas, no un agente. Lo cual puede estar bien, siempre que lo llames por su nombre. ## Por dónde empezar Mira el registro de llamadas del último mes y clasifícalas por motivo. Si el motivo más repetido ocupa más de un tercio y es un trámite con final claro, ahí hay un caso. Si la lista es larga y todo son casos distintos, lo que tienes es un problema de procesos, y una voz sintética no lo va a arreglar. En FCG Systems esto entra en [inteligencia artificial aplicada](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/) y, cuando hay que conectar centralita, CRM y avisos, en [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/). Si estás valorando si una IA puede coger tus llamadas, [cuéntame qué tipo de llamadas recibes](https://fcgsystems.es/contacto/) y te digo cuáles automatizaría y cuáles no tocaría. ## Preguntas frecuentes ### ¿Qué es un agente de voz con IA? Es un sistema que mantiene una conversación telefónica hablada sin una persona al otro lado. Encadena tres piezas: reconocimiento de voz que convierte lo que dices en texto, un modelo de lenguaje que decide qué responder y consulta sistemas, y una voz sintética que lo dice. A diferencia de una locución de opciones, entiende frases libres y puede actuar sobre tus herramientas. ### ¿En qué se diferencia de una centralita con opciones o un contestador? Una centralita con menú reproduce opciones fijas y te obliga a encajar tu problema en una de ellas. Un agente de voz entiende lo que dices con tus palabras, hace preguntas de seguimiento y puede consultar el CRM o la agenda durante la llamada. También puede equivocarse de formas que una locución no puede, y por eso necesita límites y traspaso a humano. ### ¿Cuál es la latencia aceptable en un agente de voz? Por debajo de un segundo desde que la persona deja de hablar hasta que el agente empieza a responder, la conversación se sostiene. A partir de ahí el silencio se nota, la gente repite la frase o cuelga. La latencia es la suma de todo el recorrido (reconocimiento, decisión, consulta a tus sistemas y síntesis de voz), así que una consulta lenta al CRM rompe la conversación aunque el modelo sea bueno. ### ¿En qué llamadas compensa un agente de voz con IA? En conversaciones repetitivas, cortas y con final claro: confirmar o cambiar una cita, recoger datos de un formulario hablado, filtrar el motivo de la llamada antes de pasarla, resolver dudas frecuentes sobre horarios o estado de un pedido. No compensa en ventas complejas, reclamaciones cargadas de emoción, temas legales o sanitarios, ni en llamadas donde el error cuesta dinero o confianza. ### ¿Qué decisiones no hay que delegar en un agente de voz? Nada irreversible ni con dinero de por medio: cobrar, aplicar descuentos, cancelar contratos, cambiar condiciones, dar por buena una identidad o prometer plazos. El agente recoge información y ejecuta acciones reversibles; lo que compromete al negocio pasa por una regla en código o por una persona. ## Servicios relacionados - [Sistemas de IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Agentes de IA para negocios: qué son, cuándo compensan y cómo se construyen sin perder el control > Qué es un agente de IA, en qué se diferencia de un chatbot o una automatización, cuándo compensa en un negocio digital y cómo crearlo paso a paso con control. - URL: https://fcgsystems.es/blog/agentes-de-ia-para-negocios/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: IA aplicada · Formato: Breakdown · Lectura: 10 min - Palabra clave: agente de ia (también: qué es un agente de ia, como crear un agente de ia, agentes de ia para empresas, para qué sirve un agente de ia, agentes de ia ejemplos) Un **agente de IA** es un sistema en el que un modelo de lenguaje decide por sí mismo qué pasos dar y qué herramientas usar para completar una tarea: consulta datos, actúa, mira el resultado y vuelve a decidir. A diferencia de una automatización, que sigue un camino fijo, el agente elige el camino. Compensa en tareas abiertas que combinan varias fuentes y decisiones; no compensa cuando la decisión cabe en una regla. La palabra "agente" se usa hoy para casi cualquier cosa con IA, desde un chatbot de preguntas frecuentes hasta un flujo de n8n con un nodo de lenguaje. Esa confusión cuesta dinero: se construyen agentes donde bastaba una regla, o se lanzan agentes con acceso a todo y sin límites. Esta guía explica qué es exactamente un agente, en qué se diferencia de lo que ya conoces, cuándo tiene sentido en un negocio digital y cómo se construye uno que se pueda operar. Si buscas casos concretos de IA dentro de procesos (clasificar, resumir, puntuar), están en [IA aplicada en negocios digitales](https://fcgsystems.es/blog/ia-aplicada-negocios-digitales/). ## ¿Qué es un agente de IA exactamente? Anthropic, en su guía [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) (consultado en septiembre de 2026), separa dos tipos de sistemas que combinan modelos de lenguaje y herramientas: - **Workflows:** el modelo y las herramientas se orquestan mediante rutas de código predefinidas. Quien diseña el sistema decide el orden. - **Agentes:** el modelo dirige dinámicamente su propio proceso y el uso de herramientas, y mantiene el control sobre cómo completa la tarea. La misma guía describe a los agentes, en la práctica, como modelos que usan herramientas en bucle según lo que les devuelve el entorno. La documentación de n8n lo explica de forma parecida ([qué hacen los agentes](https://docs.n8n.io/build/integrate-ai/understand-ai-components/what-agents-do/), consultado en septiembre de 2026): una cadena sigue una secuencia predeterminada de llamadas, mientras que un agente usa un modelo de lenguaje para decidir qué acciones tomar. Por eso, dentro de una misma ejecución, el agente se ejecuta varias veces: prepara, llama a una herramienta, evalúa la respuesta y contesta. La consecuencia práctica: un agente no es un modelo más listo, es un modelo con **capacidad de decidir y actuar**. Todo lo que puede hacer depende de las herramientas y permisos que le des. ## ¿En qué se diferencia de un chatbot o de una automatización? | | Chatbot de reglas | Automatización (workflow) | Workflow con IA | Agente de IA | |---|---|---|---|---| | Quién decide el siguiente paso | Un árbol de opciones fijo | El diseño del flujo | El diseño del flujo; la IA resuelve pasos concretos | El modelo, dentro de los límites que le pongas | | Previsibilidad | Total | Total | Alta en el recorrido, variable en la respuesta de la IA | La más baja: puede tomar caminos distintos ante casos parecidos | | Coste y latencia | Bajos | Bajos | Medios | Los más altos: varias llamadas al modelo por tarea | | Cuándo usarlo | Menús y respuestas cerradas | Reglas claras: si pasa X, haz Y | Pasos de juicio dentro de un proceso fijo (clasificar, resumir, extraer) | Tareas abiertas en las que el orden de los pasos depende de cada caso | Buena parte de lo que se vende como "agente" es en realidad un workflow con IA, y muchas veces eso es justo lo que conviene. La propia guía de Anthropic recomienda buscar la solución más simple posible, aumentar la complejidad solo cuando haga falta, y recuerda que los sistemas agénticos suelen cambiar latencia y coste por mejor rendimiento en la tarea. A veces la conclusión correcta es no construir un agente, y quedarse en la columna de la izquierda: [qué resuelve un chatbot y hasta dónde llega](https://fcgsystems.es/blog/que-es-un-chatbot/) está desarrollado aparte. ## ¿Cuándo compensa un agente de IA en un negocio digital? La pregunta que conviene hacerse es: **¿el orden de los pasos cambia en cada caso?** Si la respuesta es no, basta con una automatización, con o sin IA en algún paso. Si la respuesta es sí, un agente puede tener sentido. ### Cuándo sí - La tarea necesita consultar varias fuentes y el orden depende de lo que encuentre en cada una. - La petición llega en lenguaje natural y admite muchas variantes. - El coste de una respuesta imperfecta es asumible, o existe revisión humana antes de actuar. - El volumen justifica el esfuerzo de construirlo, evaluarlo y mantenerlo. ### Cuándo no - **La decisión cabe en una regla.** Asignar un lead por país, dar acceso cuando el pago está aprobado o deduplicar por email son lógica determinista: van en código o en una automatización, nunca delegados a un modelo. - **El error es caro e irreversible** y no hay forma de meter una aprobación humana. - **No hay datos fiables** de los que tirar: un agente sobre un CRM desordenado solo desordena más rápido. - **Nadie va a medir la calidad** una vez en producción. ### Tres escenarios típicos Estos son escenarios habituales en academias online e infoproductores, no casos de clientes: 1. **Soporte de alumnos con base de conocimiento.** El agente busca en la documentación del curso y en el estado del alumno (acceso, pagos) antes de responder, y deriva a una persona cuando la duda no está documentada o hay un cobro de por medio. 2. **Contexto para setters antes de una llamada.** El agente reúne lo que existe sobre el lead en el CRM, el formulario y las conversaciones previas y prepara un resumen; el setter decide, el agente no llama ni vende. 3. **Triaje de mensajes de WhatsApp.** El agente entiende qué pide cada mensaje, responde lo que está documentado y pasa a una persona lo comercial o lo delicado, con el contexto ya recogido. En los tres, el agente prepara o responde dentro de un perímetro. Las acciones con consecuencias (cobrar, dar de baja, prometer algo) siguen en manos de una persona o de una regla. ## ¿Cómo se crea un agente de IA paso a paso? ### 1. Define la tarea y el criterio de éxito Una tarea concreta, no "atender a los clientes". Por ejemplo: "resolver dudas sobre accesos y contenido del curso usando la documentación, y derivar el resto". Y cómo se medirá: qué parte de las respuestas se consideran correctas en una revisión, cuántas se derivan, cuánto tiempo ahorra al equipo. Sin criterio de éxito no hay forma de saber si funciona. ### 2. Dale las herramientas mínimas con los permisos mínimos Cada herramienta es algo que el agente puede hacer por su cuenta. Si solo necesita leer el estado de un alumno, no le des permiso para modificarlo. Documenta bien cada herramienta: la guía de Anthropic insiste en diseñar con cuidado las herramientas y su documentación, porque el agente decide a partir de ellas. Si vas a exponer esas herramientas de forma estándar en vez de a medida para cada modelo, el protocolo que se ha impuesto para eso es [MCP](https://fcgsystems.es/blog/que-es-mcp-model-context-protocol/). ### 3. Conecta fuentes de conocimiento fiables Documentación actualizada, políticas escritas y datos del CRM con una fuente de verdad clara. Si la información está repartida en tres sitios que no coinciden, arregla eso antes. Es el mismo principio de la guía de [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/). ### 4. Pon límites y condiciones de parada Un número máximo de iteraciones, un tiempo máximo y una salida clara cuando no sabe: "derivo a una persona". Anthropic recomienda condiciones de parada como un máximo de iteraciones, además de pruebas extensas en entornos aislados y guardarraíles adecuados. ### 5. Exige aprobación humana para lo irreversible Enviar un mensaje a un cliente, modificar un registro o borrar datos no deberían ocurrir sin revisión mientras el agente no haya demostrado su fiabilidad. En n8n, por ejemplo, se puede exigir [aprobación humana antes de que un agente use una herramienta](https://docs.n8n.io/build/integrate-ai/ai-examples/human-in-the-loop-for-tools/) (consultado en septiembre de 2026): el flujo se pausa y una persona aprueba o deniega la acción. La documentación lo recomienda para acciones irreversibles, requisitos de cumplimiento, decisiones de alto impacto y mientras se construye confianza en el sistema. ### 6. Registra todo y evalúa con casos reales Cada conversación o tarea deja rastro: qué pidió el usuario, qué herramientas usó el agente, qué respondió y si se derivó. Antes de producción, prueba con un conjunto de casos reales (incluidos los difíciles) y revisa las respuestas. Después, revisión periódica de una muestra. Un agente sin logs falla en silencio igual que cualquier automatización, como explico en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ### 7. Mide el coste por tarea Cada paso del agente es una llamada al modelo. Mide cuánto cuesta de media resolver una tarea y compáralo con lo que ahorra. Si una automatización con un paso de IA resuelve la mayoría de los casos con menos coste, quizá el agente sobra. ### ¿Con qué herramienta se construye? Depende del sistema, no al revés. Plataformas como n8n incluyen nodos de agente que se integran con el resto de tus flujos; para lógica más exigente, un servicio propio. Si estás decidiendo plataforma de automatización, lo comparo en [n8n vs Make](https://fcgsystems.es/blog/n8n-vs-make/). ## ¿Y un agente de voz o un agente en WhatsApp? Las mismas reglas, con dos matices: - **Agente de voz:** la conversación ocurre en tiempo real, así que la latencia pesa más y es más difícil meter una revisión humana antes de responder. Limita todavía más lo que puede prometer o ejecutar. - **Agente en WhatsApp:** además de todo lo anterior, depende de las reglas del canal (plantillas, ventana de atención de 24 horas, consentimiento). Lo explico en [WhatsApp Business API](https://fcgsystems.es/blog/whatsapp-business-api/). ## ¿Hay que avisar de que responde una IA? El [artículo 50 del Reglamento de IA de la UE](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50) (consultado en septiembre de 2026) establece que los proveedores deben diseñar los sistemas de IA que interactúan directamente con personas de forma que estas sepan que están interactuando con una IA, salvo que resulte obvio por el contexto. Según el [artículo 113](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113) (consultado en septiembre de 2026), el Reglamento se aplica con carácter general desde el 2 de agosto de 2026, con excepciones y plazos distintos para algunas partes. Esto no es asesoramiento legal: quién es proveedor y quién responsable del despliegue depende de cada caso, y conviene revisarlo con quien lleve vuestro cumplimiento normativo. A efectos prácticos, avisar de forma clara de que responde una IA y ofrecer siempre la opción de hablar con una persona es buena práctica en cualquier caso. ## Errores comunes al crear agentes de IA - **Un agente donde bastaba una regla.** Más caro, más lento y menos predecible que un `if`. - **Herramientas con demasiados permisos.** Si puede borrar, algún día borrará lo que no debía. - **Sin límite de iteraciones ni tiempo máximo.** Bucles que consumen sin llegar a ninguna parte. - **Sin evaluación antes de producción.** "En la demo funcionaba" no es un criterio de calidad. - **Sin traspaso a una persona.** El agente se inventa una respuesta en lugar de reconocer que no sabe. - **Datos personales sin revisar.** Qué datos ve el agente, a qué proveedor se envían y cuánto tiempo se guardan tiene que estar decidido antes de conectarlo. - **Sin dueño.** Nadie revisa las conversaciones ni ajusta el sistema cuando cambian los productos o las políticas. ## Checklist antes de poner un agente de IA en producción - La tarea está definida y tiene un criterio de éxito medible. - Se ha descartado que una regla o una automatización resuelva el caso. - Las herramientas son las mínimas y con los permisos mínimos. - Las fuentes de conocimiento están actualizadas y tienen dueño. - Hay límite de iteraciones, tiempo máximo y salida hacia una persona. - Las acciones irreversibles requieren aprobación humana. - Cada tarea queda registrada con las herramientas usadas y el resultado. - Se ha evaluado con casos reales, incluidos los difíciles. - El coste medio por tarea está medido y compensa. - El usuario sabe que habla con una IA y puede pedir una persona. - Está revisado qué datos personales ve el agente y a dónde se envían. - Hay un responsable que revisa una muestra de conversaciones periódicamente. ## ¿Cuándo conviene delegarlo? Probar un agente sencillo con una herramienta visual es razonable para aprender. Conviene hacerlo con alguien con criterio de sistema cuando el agente toca datos de clientes, pagos o accesos, cuando tiene que integrarse con el CRM y otras herramientas, o cuando va a atender a personas en nombre del negocio. Nuestra oferta de AI Workflow sigue siempre el mismo orden: definición del caso, arquitectura, modelos y prompts, integración, control de calidad, métricas y documentación. No se vende "IA": se vende una mejora concreta de tiempo, capacidad, calidad o coste. Lo tienes en la ficha de [agentes de IA para empresas y automatización con IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/), y los casos donde la IA ya ahorra trabajo, en el artículo de [IA aplicada en negocios digitales](https://fcgsystems.es/blog/ia-aplicada-negocios-digitales/). Si tienes una tarea en mente y no sabes si necesita un agente, una automatización o nada, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y te digo qué tiene sentido. ## Preguntas frecuentes ### ¿Qué es un agente de IA? Es un sistema en el que un modelo de lenguaje decide qué pasos dar y qué herramientas usar para completar una tarea, en lugar de seguir una secuencia fija. Consulta datos, llama a herramientas, evalúa el resultado y repite hasta terminar o hasta que salta una condición de parada. ### ¿Qué diferencia hay entre un agente de IA y un chatbot? Un chatbot de reglas responde siguiendo un árbol de opciones que alguien diseñó. Un agente de IA interpreta la petición y decide qué acciones tomar con las herramientas que tiene disponibles: buscar en una base de conocimiento, consultar el CRM o crear una tarea. Eso le da flexibilidad y también más riesgo, por eso necesita límites. ### ¿Cómo se crea un agente de IA para una empresa? Empezando por una tarea concreta con un criterio de éxito medible. Después se eligen las herramientas mínimas con los permisos mínimos, se conectan las fuentes de conocimiento, se fijan límites y condiciones de parada, se exige aprobación humana para acciones irreversibles y se evalúa con casos reales antes de ponerlo en producción. ### ¿Cuándo no conviene usar un agente de IA? Cuando el proceso es determinista: si la decisión se puede escribir como una regla (asignar un lead por país, dar acceso cuando el pago está aprobado), va en código o en una automatización. Un agente añade coste, latencia e imprevisibilidad donde no hacen falta. ### ¿Hay que avisar a los clientes de que hablan con un agente de IA? El artículo 50 del Reglamento de IA de la UE obliga a que los sistemas que interactúan con personas estén diseñados para que estas sepan que hablan con una IA, salvo que sea obvio por el contexto. Además de la obligación legal, avisar evita malentendidos. No es asesoramiento legal: revisa tu caso concreto. ## Servicios relacionados - [Sistemas de IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Automatización de marketing: qué se automatiza bien y qué se rompe cuando el dato está sucio > Qué se automatiza bien en marketing, qué se rompe cuando los datos del CRM están sucios y la higiene mínima que necesita un flujo antes de activarlo. - URL: https://fcgsystems.es/blog/automatizacion-de-marketing/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Automatización · Formato: Opinión · Lectura: 7 min - Palabra clave: automatización de marketing (también: marketing de automatizacion, marketing automation, herramientas de marketing automation, email marketing automatizado) **La automatización de marketing funciona bien cuando lo que la dispara es un hecho comprobable y falla cuando depende de un dato que nadie ha limpiado.** Entregar lo que alguien acaba de comprar, avisar al comercial de una señal de compra o recuperar un pago fallido son procesos automatizables con poco riesgo. Segmentar, personalizar o puntuar leads sobre una base con duplicados y orígenes perdidos produce campañas que parecen sofisticadas y no lo son. Casi todo el contenido sobre marketing automation habla de herramientas y de secuencias. Esta pieza va del otro lado: de lo que hay debajo, que es lo que decide si la automatización suma o hace daño. ## ¿Qué se automatiza bien en marketing? Lo que tiene un disparador que es un hecho, no una interpretación. | Proceso | Qué lo dispara | Por qué funciona bien | |---|---|---| | Entrega de lo comprado o descargado | Evento de pago o de registro | El disparador es un hecho verificable y el contenido no depende del contexto | | Secuencia de bienvenida o de activación | Alta confirmada, primer acceso | La misma secuencia sirve para todos los que están en ese punto | | Recordatorios por inactividad | Ausencia de una acción concreta en un plazo | La condición es objetiva y se comprueba en el sistema | | Aviso interno por señal de compra | Visita a precios, respuesta a un email, descarga concreta | El valor está en la velocidad, no en el mensaje | | Recuperación de pago fallido | Evento de la pasarela | Es el flujo con mejor retorno y el que menos gente monta | | Segmentación por datos duros | País, producto comprado, fecha de alta | El dato está estructurado y no se interpreta | Fíjate en el patrón: en todos los casos hay un evento del sistema detrás. Cuando el disparador es "parece interesado", empiezan los problemas. ## ¿Qué se rompe cuando el dato está sucio? Estas son las cinco averías que aparecen una y otra vez, por orden de frecuencia. ### 1. Duplicados que reciben todo dos veces La misma persona registrada con dos correos, o con el teléfono escrito de dos formas, entra dos veces en la secuencia. Recibe el mismo email duplicado, cuenta como dos leads en el informe y, si hay comerciales, la llaman dos personas distintas. La automatización amplifica el duplicado: sin ella, alguien lo habría visto al mirar la lista. La deduplicación tiene que ocurrir **antes** de que el contacto entre en cualquier flujo, con reglas propias y no solo por coincidencia exacta de email. Cómo se monta ese tramo está en [leads que se pierden entre el formulario y el comercial](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). ### 2. El origen que se sobrescribe Si el sistema guarda como origen el último formulario que alguien rellenó, el primer contacto desaparece. A partir de ahí, toda la segmentación por canal es ficción y las decisiones de inversión en captación se toman sobre números inventados sin querer. El origen se captura en el primer registro y no se toca. Los siguientes toques se guardan aparte. Por qué las cifras nunca cuadran entre plataformas y qué hacer al respecto está en [atribución rota](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/). ### 3. Campos vacíos que rompen la personalización Un "Hola ," a las nueve de la mañana no es un detalle estético: es la señal más clara que puede recibir alguien de que nadie está mirando. Pasa siempre por lo mismo: un campo obligatorio en un formulario y opcional en otro, un nombre completo metido en el campo de nombre de pila, un dato que llega de una importación antigua. La regla es tener un valor por defecto para cada campo que se use en un mensaje, y comprobar antes de enviar cuántos registros lo tienen vacío. ### 4. Estados desincronizados entre herramientas El caso clásico: alguien compra y sigue recibiendo la secuencia que le vende lo que ya ha comprado. O peor: recibe una oferta mejor que la que acaba de pagar. Ocurre cuando la herramienta de marketing y el CRM guardan cada una su versión del estado del contacto y la sincronización va en una sola dirección, o falla en silencio. Antes de conectar dos herramientas hay que decidir cuál manda en cada dato. Normalmente el CRM manda en la etapa comercial y la pasarela en el estado de pago. Y esa sincronización necesita registro: el fallo típico no es un error rojo, es que un cambio de estado no llegó y nadie se enteró en tres semanas. El patrón completo está en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ### 5. Scoring construido sobre interpretaciones Puntuar leads es útil cuando los puntos vienen de hechos: ha comprado antes, ha visitado la página de precios, ha pedido una llamada. Se vuelve ruido cuando se puntúan aperturas de correo y clics sin más contexto, porque esas señales son cada vez menos fiables y porque premian a quien lee mucho, no a quien compra. Si el scoring existe, que sea determinista y esté escrito: qué suma, cuánto y por qué. Un umbral que decide si un lead pasa a comercial es una regla de negocio, y las reglas de negocio se escriben en código o en condiciones explícitas, nunca se delegan a un modelo que un día puntuará distinto lo mismo. ## La higiene mínima antes de activar un flujo No hace falta un proyecto de calidad de datos. Hacen falta cinco comprobaciones: 1. **Duplicados.** Cuántos contactos comparten teléfono normalizado o dominio y nombre. Si es más de un puñado, hay que limpiar antes. 2. **Campos usados en mensajes.** Qué porcentaje está vacío o con basura. Cualquier campo que se imprima en un email necesita valor por defecto. 3. **Origen.** Cuántos registros del último mes tienen canal y campaña. Si falta en la mitad, la segmentación por canal no es utilizable. 4. **Estados.** Cuántos contactos están marcados como clientes en la pasarela y no en el CRM, o al revés. 5. **Consentimiento.** Qué registros tienen constancia de haber aceptado recibir comunicaciones, con fecha y origen. Esto es además un requisito legal: confirma con tu asesoría qué necesitáis registrar exactamente. Ese último punto es el único que no admite grados. El resto se puede ir mejorando; enviar a quien no ha consentido, no. ## ¿Qué sigue siendo manual, y debería seguir siéndolo? - **La respuesta a una objeción concreta.** Una plantilla genérica delante de una duda específica cierra la conversación en vez de abrirla. - **La negociación y las condiciones particulares.** En cuanto hay excepción, hay criterio. - **El primer contacto en venta de ticket alto.** Automatizar la cadencia de recordatorios, sí; automatizar el mensaje, no. - **La recuperación de un cliente enfadado.** Cualquier secuencia automática ahí empeora la situación. - **La decisión de qué se comunica.** La herramienta ejecuta; el criterio de qué contar y a quién no se delega. Automatizar no es enviar más. En la mayoría de operaciones que hemos visto, ordenar el dato y quitar dos secuencias redundantes hace más por el resultado que añadir cinco flujos nuevos. ## ¿Herramienta específica de marketing automation o el CRM que ya tenéis? Antes de contratar una plataforma nueva, la pregunta útil es qué hace la que ya pagáis. Muchos CRM incluyen secuencias por comportamiento y reglas de asignación suficientes para una operación de tamaño medio, y mantener el dato en un solo sitio evita de raíz el problema de los estados desincronizados. Una herramienta específica compensa cuando el volumen de envíos es alto, cuando hacen falta ramificaciones complejas o cuando el equipo de marketing necesita autonomía para montar flujos sin tocar el CRM. Pero entonces hay que asumir la parte que nadie cuenta: decidir quién manda en cada dato, montar la sincronización y vigilarla. Los criterios generales de elección de herramienta están en [herramientas de automatización](https://fcgsystems.es/blog/herramientas-de-automatizacion/), y los de CRM, en [CRM para pymes y negocios digitales](https://fcgsystems.es/blog/crm-para-pymes-saas-o-a-medida/). ## Errores comunes en automatización de marketing - **Automatizar antes de deduplicar.** El duplicado se multiplica por el número de flujos activos. - **Sobrescribir el origen en cada interacción.** Destruye la única información que permite decidir dónde invertir. - **Personalizar con campos que están vacíos en un tercio de la base.** Se nota y resta credibilidad. - **Sincronizar en las dos direcciones sin decidir quién manda.** Dos versiones del mismo contacto, discutiendo. - **Puntuar leads por aperturas.** Premia lectores, no compradores. - **Delegar a un modelo de IA la decisión de si un lead pasa a comercial.** Eso es una regla de negocio: va escrita y probada. - **No vigilar las secuencias activas.** Un flujo que dejó de dispararse hace un mes no avisa de su propio silencio. - **Medir solo aperturas y clics.** La métrica que importa es cuántas de esas personas acabaron comprando. ## Checklist antes de activar automatización de marketing - La base está deduplicada y hay reglas para que no vuelvan a entrar duplicados. - El origen se captura en el primer registro y no se sobrescribe. - Cada campo que aparece en un mensaje tiene valor por defecto. - Está decidido qué sistema manda en cada dato entre CRM, plataforma de envíos y pasarela. - Hay constancia del consentimiento, con fecha y origen, confirmada con la asesoría. - Las reglas de scoring, si existen, están escritas y son deterministas. - Cada flujo tiene una comprobación diaria que compara lo que entró con lo que salió. - Hay un responsable con nombre para cada alerta. - Sabéis medir cuántas ventas vienen de cada secuencia, no solo cuántas aperturas. ## ¿Por dónde empezar? Si tenéis flujos activos y la sensación de que no rinden, el orden que recomendamos es: primero mirar el dato, después quitar lo redundante y solo entonces añadir. Casi siempre aparecen duplicados, un origen sobrescrito y dos secuencias que se pisan. Cuando la automatización de marketing tiene que convivir con el CRM, la pasarela de pagos y la plataforma de formación, esto deja de ser una cuestión de secuencias y pasa a ser de arquitectura de datos: quién es dueño de qué y cómo viaja. Es el trabajo de [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/) junto con [datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/), para que las cifras con las que decidís sean las de verdad. Si ahora mismo no sabrías decir cuántos duplicados hay en vuestra base, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Qué es la automatización de marketing? Es ejecutar acciones de marketing sin intervención manual a partir de lo que hace o deja de hacer una persona: un email de bienvenida tras el registro, un recordatorio cuando no ha abierto el curso, un aviso al comercial cuando visita la página de precios. No es enviar más correos, es que cada acción dependa de un dato del sistema en lugar de la memoria de alguien. ### ¿Qué se puede automatizar en marketing y qué no? Se automatiza bien todo lo que se dispara con un evento claro y comprobable: entrega de lo prometido, secuencias por comportamiento, segmentación por datos que ya existen, avisos internos y recuperación de pagos fallidos. No se automatiza bien lo que exige criterio o contexto: la respuesta a una objeción concreta, la negociación de un caso particular o cualquier decisión que dependa de un dato que nadie ha comprobado que esté limpio. ### ¿Cuáles son los tipos de automatización en marketing? Cuatro, por lo que las dispara: por evento del sistema (un pago, un registro), por comportamiento de la persona (abrir, hacer clic, visitar), por tiempo (a los tres días, antes de que caduque) y por cambio de estado en el CRM (etapa, responsable, producto). Las de evento son las más fiables porque el disparador es un hecho, no una inferencia. ### ¿Qué diferencia hay entre marketing automation y un CRM? El CRM es la fuente de verdad del contacto y de la oportunidad; la herramienta de marketing automation ejecuta las comunicaciones. En la práctica se solapan, y ahí está el problema habitual: cuando las dos guardan su propia versión del contacto, acaban discrepando. Conviene decidir cuál manda en cada dato antes de conectarlas. ### ¿Por qué mis automatizaciones de marketing dan resultados peores de lo esperado? En la mayoría de casos que hemos visto, el problema no está en el copy ni en la secuencia, sino en el dato: contactos duplicados que reciben la misma secuencia dos veces, origen sobrescrito que arruina la segmentación, campos vacíos que rompen la personalización y estados desincronizados que envían promociones a quien ya compró. Antes de reescribir los emails, mira qué hay en la base. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Casos relacionados - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/): Formularios, tracking, CRM y agenda comercial conectados en un solo sistema, con el origen de cada lead a la vista. Las tres etapas del funnel mejoraron. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Automatizar sin vigilar es peor que no automatizar > Una automatización sin alertas y sin dueño no te ahorra trabajo: te lo esconde. Por qué el fallo silencioso hace más daño que el proceso manual que sustituye. - URL: https://fcgsystems.es/blog/automatizar-sin-vigilar-es-peor/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Automatización · Formato: Opinión · Lectura: 4 min - Palabra clave: automatizar sin vigilar (también: fallo silencioso automatización, monitorizar automatizaciones, dueño de una automatización) Un proceso manual tiene un testigo. Una automatización sin vigilancia, no. Esa es toda la diferencia, y es más grande de lo que parece. Piénsalo. Cuando una persona mete los leads a mano en el CRM, esa persona es, sin proponérselo, un sistema de monitorización bastante decente. Nota que hoy llegan menos. Nota que uno viene sin teléfono. Nota que el formulario del anuncio nuevo trae los campos cambiados. Es lento, es caro y no escala, pero *ve*. El día que automatizas ese proceso, ganas velocidad y pierdes al testigo. Si no pones nada en su lugar, no has automatizado: has apagado la luz. ## El fallo silencioso no es un fallo, es una hemorragia Una automatización que se rompe del todo es casi una buena noticia. Todo se para, alguien se queja en una hora, se arregla esa tarde. Molesta y ya está. La que hace daño de verdad es la que sigue ejecutándose y deja de hacer bien su trabajo. El flujo corre, la herramienta lo marca en verde, y por dentro mete el campo vacío, se salta un paso o duplica el envío. Desde el punto de vista del sistema no ha pasado nada raro. Desde el punto de vista del negocio llevas tres semanas perdiendo los leads de un canal. Y aquí está lo que más me revienta: casi siempre el que descubre el fallo es el cliente. Escribe alguien preguntando por qué no le ha llegado su acceso, o por qué le habéis cobrado dos veces, y en ese momento no estás arreglando un flujo. Estás gestionando una reclamación con toda la información en contra. El coste real de ese tipo de fallo tiene tres capas. Está lo que se pierde mientras dura. Está lo que cuesta reconstruirlo después, si es que se puede. Y está la tercera, la que nadie presupuesta: **la confianza**. Cuando el equipo descubre dos o tres veces que "la automatización no iba", empieza a comprobarlo todo a mano por su cuenta. En ese momento has pagado la automatización y sigues haciendo el trabajo manual. Enhorabuena, ahora tienes los dos costes. ## Por qué pasa: nadie construye para el día malo No pasa por dejadez. Pasa porque el incentivo, mientras montas, empuja justo en dirección contraria. Cuando estás construyendo un flujo, tu objetivo es que funcione. Lo pruebas con dos registros, sale bien, sientes el chute y pasas a lo siguiente. Pensar en el fallo es aburrido, alarga el trabajo y no se ve en la demo. Así que se deja "para después", y después es un sitio que no existe en la agenda de nadie. Hay algo más profundo. La monitorización tiene un problema de percepción: cuando funciona, no pasa nada. Nadie te felicita por la alerta que no saltó. Es el mismo motivo por el que los backups no se prueban y los seguros dan pereza. Solo se convierte en prioridad la semana siguiente al susto, y para entonces ya has pagado el susto. Y luego está la trampa de creerse cubierto. "Tenemos las notificaciones de error activadas." Vale. Eso te avisa de lo que la herramienta reconoce como error. Un formulario que cambia un campo, un webhook que nunca llega, un paso que se ejecuta a medias: nada de eso genera un error. No hay ejecución fallida que notificar. El silencio no es señal de que todo va bien; en la mayoría de los casos, el silencio no es ninguna señal. ## Qué exijo antes de dar por terminada una automatización Tengo una regla que no negocio con nadie: **un proceso crítico sin logs no está terminado**. Da igual que funcione en la demo. Si no puedo saber qué hizo ayer, no lo puedo operar, y si no lo puedo operar, no lo he entregado. Encima de eso, tres cosas más. La primera es una **alerta con dueño**. No una alerta a un canal genérico donde se mueren las notificaciones. Una persona con nombre que recibe el aviso y sabe que es suyo. Una alerta que no tiene dueño no es una alerta, es ruido que enseñas en una reunión para decir que hay monitorización. La segunda es una **comprobación de resultado, no de ejecución**. Es la que casi nadie pone y la que caza el 80% de los fallos silenciosos: contar lo que entra y contar lo que sale. Si ayer hubo 120 registros en el formulario y en el CRM hay 114, algo pasó, aunque las 120 ejecuciones estén en verde. La pregunta correcta no es "¿se ejecutó?", sino "¿está el resultado ahí?". La tercera es el **latido**: un aviso cuando un flujo lleva demasiado tiempo sin correr. Porque el fallo más silencioso de todos es el que no produce ninguna ejecución, y ahí no hay nada que se ponga rojo. Un flujo muerto es invisible por definición. El detalle técnico de cómo se monta todo esto —logs, reintentos seguros, idempotencia, reconciliación diaria— lo tienes en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). Aquí me interesa el criterio anterior a la implementación. ## La pregunta que hago antes de automatizar nada ¿Cuánto tardaríamos en enterarnos si esto dejara de funcionar hoy? Si la respuesta es "semanas", ese proceso no está listo para funcionar solo. No importa lo bien construido que esté el flujo. Y si la respuesta es "depende de si un cliente se queja", entonces tu sistema de monitorización son tus clientes, que es la forma más cara de monitorizar que existe. Automatizar un proceso no es delegarlo y olvidarlo. Es cambiar trabajo de ejecución por trabajo de supervisión. Ese cambio es un negocio buenísimo, pero solo si haces la segunda parte. Si te quedas con la primera, lo que has hecho no es ahorrar trabajo: es esconderlo hasta que el coste aparezca de golpe. Si algo se te escapa, es porque no lo sabes. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/): Servidores, despliegues, backups y alertas para que tu operación no se caiga y sea tuya. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Cerrar clientes sin audiencia: se vende por criterio, no por postureo > Se puede cerrar trabajo serio con una cuenta de tres cifras de seguidores. No es carisma ni volumen: es diagnosticar mejor que nadie y saber decir que no. - URL: https://fcgsystems.es/blog/cerrar-clientes-sin-audiencia/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Opinión · Lectura: 4 min - Palabra clave: cerrar clientes sin audiencia (también: vender servicios técnicos, captar clientes sin redes sociales, vender por criterio) He cerrado trabajo serio con una cuenta de redes de tres cifras de seguidores. Sin carrusel, sin hilo viral, sin marca personal montada. No lo cuento como mérito. Lo cuento porque desmonta una creencia bastante cara: que primero hay que construir audiencia y luego llega el negocio. Esa secuencia funciona para quien vende contenido. Si lo que vendes es criterio aplicado al negocio de otro, el mecanismo es distinto. ## Sin volumen, la precisión es obligatoria La cuenta es simple. Quien tiene cincuenta mil seguidores puede permitirse una tasa de acierto baja: con suficientes conversaciones, alguna cae. Sin audiencia no tienes ese colchón. Tendrás pocas conversaciones, así que cada una tiene que valer. Eso obliga a hacer dos cosas que la gente con volumen se puede saltar: elegir con quién hablas y llegar preparado. Elegir con quién hablas significa no perseguir a todo el mundo. Un negocio que no depende de su tecnología no te va a contratar por mucho que insistas, y hace bien. Un negocio que factura, tiene procesos a mano y no sabe qué pasa por dentro, ese sí tiene el problema que resuelves. La diferencia entre esas dos conversaciones no es tu discurso, es a quién se lo das. Llegar preparado significa algo muy concreto: saber cosas de su operación antes de que te las cuente. Se puede. Está su web, está su funnel, está el formulario que rellenas para ver qué email te llega y cuándo. En veinte minutos de mirar con atención sabes más de su máquina que la mayoría de proveedores que le escriben. ## La llamada no es una presentación, es un diagnóstico Aquí está el cambio que más resultado me ha dado, y llegué a él por necesidad, no por estrategia: cuando no tienes casos famosos que enseñar, lo único que puedes hacer es demostrar criterio en directo. Así que dejé de presentarme. La llamada va de su negocio desde el minuto uno. Qué proceso le está frenando. Qué se hace a mano. Qué depende de una sola persona. Qué pasa cuando algo falla y cómo se entera. Qué no puede hacer hoy que le gustaría hacer. Al terminar, el objetivo no es que le haya gustado la conversación. Es que entienda su problema mejor que cuando empezó. Que salga con una frase nueva en la cabeza del tipo "no sabía que eso se podía detectar solo" o "nunca había pensado que ahí se nos escapa dinero". Fíjate en lo que está pasando ahí. No has enseñado ningún logo. No has contado tu trayectoria. Y sin embargo ya has entregado valor, y el otro tiene una prueba de primera mano de cómo piensas. La confianza no viene de lo que dices que sabes, viene de lo que demuestras entendiendo. Esa capacidad, por cierto, no sale de la llamada. Sale de haber construido cosas y haber visto cómo se rompen. Vender por criterio exige tener criterio, y eso no se improvisa. ## Decir que no cierra más que decir que sí Esto suena a frase de LinkedIn y sin embargo es de las cosas más prácticas que he aprendido. Cuando alguien te plantea un proyecto que no le va a resolver el problema, tienes dos opciones. Cogerlo, cobrarlo y entregar algo correcto que no mueve su negocio. O decirle que eso no es lo que necesita y explicarle por qué. La segunda cuesta dinero a corto plazo y cambia por completo la relación. En el momento en el que alguien ve que le quitas trabajo de encima en vez de añadirlo, dejas de ser un proveedor con una propuesta y pasas a ser un criterio externo en el que puede apoyarse. Muchos de esos "no" vuelven meses después convertidos en el proyecto correcto, o en una recomendación a alguien que sí lo necesitaba. También te ahorra el peor tipo de cliente: el que compró algo que no le servía y con razón se acuerda de ti cuando no le funciona. ## Vender el resultado, no las horas La otra pieza es cómo se pone el precio, y es donde más gente técnica se pega un tiro en el pie. "Son cuarenta horas a equis euros la hora" convierte tu trabajo en una mercancía comparable. Invita a que te comparen con alguien que cobra menos por hora y a que discutan cada hora contigo. Y sobre todo, desplaza la conversación de lo que el cliente gana a lo que el cliente gasta. "Construimos el sistema de captación, asignación y seguimiento completo por equis" es otra conversación. Se habla de lo que va a existir cuando termine, no de cuánto tardas. Y si el precio le parece caro, la comparación correcta no es con otro presupuesto: es con lo que le cuesta hoy hacerlo a mano, con los errores, con el retraso y con la oportunidad que no está aprovechando. Eso solo se sostiene si el alcance está definido de verdad. Vender resultado con el alcance difuso es una forma elegante de arruinarte. ## Lo que sí hace falta Nada de esto significa que la visibilidad no sirva. Sirve, y bastante. Pero es un multiplicador, no el motor. El motor es esto: saber diagnosticar, tener criterio para decir que no, y poder defender delante de quien paga cada decisión que has tomado. Con eso cierras sin audiencia. Sin eso, la audiencia solo hace que más gente se entere de que no cumples. Osea, que la pregunta no es cuántos te siguen. Es si la próxima persona que hable contigo treinta minutos va a colgar entendiendo su negocio mejor que antes. Trabaja en eso y el resto llega mucho más tarde de lo que te gustaría, pero llega. ## Preguntas frecuentes ### ¿Se puede vender sin audiencia en redes? Sí, pero cambia el mecanismo. Sin audiencia no hay volumen de oportunidades, así que la tasa de acierto por conversación tiene que ser mucho más alta. Eso se consigue eligiendo bien con quién hablas y llegando a cada conversación con un diagnóstico que el otro no tiene, no con un discurso general sobre lo que haces. ### ¿Qué hago en una primera llamada si no tengo casos famosos que enseñar? Diagnosticar delante del cliente. Pregunta por el proceso que le está frenando, por lo que se hace a mano y por lo que depende de una sola persona. Si al terminar entiende su problema mejor que antes de la llamada, ya has demostrado criterio, y eso pesa más que un carrusel de logos. ### ¿Por qué decir que no ayuda a cerrar más? Porque es la única señal creíble de que no estás vendiendo por vender. Cuando alguien te dice que un proyecto no le encaja y te explica por qué, deja de ser un proveedor y pasa a ser un criterio externo. Ese es el momento en el que empieza a confiar de verdad. ## Servicios relacionados - [Partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/): Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Cómo funciona n8n: cuatro ejemplos reales de flujos para un negocio digital > Cómo funciona n8n explicado con cuatro ejemplos de negocio: leads al CRM, acceso tras el pago, conciliación nocturna y clasificación con IA, con sus fallos. - URL: https://fcgsystems.es/blog/como-funciona-n8n-ejemplos/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Automatización · Formato: Breakdown · Lectura: 7 min - Palabra clave: n8n ejemplo (también: n8n ejemplos, como funciona n8n, n8n tutorial, automatizaciones con n8n, n8n en local) **n8n funciona encadenando nodos: algo dispara el flujo (un webhook, una hora programada, un cambio en otra aplicación) y los datos pasan de un nodo al siguiente, que los lee, los transforma, decide o los escribe en otro sitio.** Lo que hace útil un flujo no son los nodos, sino las decisiones de negocio que hay dentro: qué se considera duplicado, quién recibe el lead, qué pasa si el pago falla. Casi todos los ejemplos de n8n que circulan son tutoriales de interfaz: arrastra este nodo, pega esta clave. Aquí van cuatro flujos que resuelven problemas reales de un negocio digital, con lo que suele romperse en cada uno. Doy por hecho el contexto previo; si te falta, está en [n8n explicado desde cero](https://fcgsystems.es/blog/que-es-n8n/). ## ¿Cómo funciona n8n por dentro? Tres conceptos y ya se entiende cualquier flujo: - **El disparador.** Un [webhook](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/) que recibe datos cuando algo ocurre, un [disparador programado](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger/) que corre a una hora fija, o un nodo que vigila cambios en otra aplicación (documentación consultada en septiembre de 2026). El webhook es casi siempre mejor: reacciona al momento y no consume cuando no hay nada nuevo. - **Los elementos.** Los datos viajan como una lista. Si entran cincuenta registros, los nodos siguientes se ejecutan una vez por cada uno sin que tengas que montar un bucle. - **La ejecución.** Cada vez que el flujo corre queda registrada, con lo que entró y salió de cada nodo. Ese registro es la herramienta de diagnóstico más útil que tiene n8n, y la que más se ignora. Con eso basta para leer los ejemplos que vienen. ## Ejemplo 1: del formulario al CRM, ya deduplicado y asignado El caso más común y el que antes devuelve el tiempo invertido. **Qué hace el flujo:** 1. Un webhook recibe el registro del formulario o de la plataforma de anuncios, con sus parámetros de campaña. 2. Normaliza los datos: teléfono con prefijo, email en minúsculas, nombre sin espacios sobrantes. 3. Busca en el CRM si ese contacto ya existe, por email y por teléfono. 4. Si existe, actualiza y añade una nota; si no, lo crea con su origen y su fecha de entrada. 5. Asigna responsable según la regla que uséis: reparto por turno, por producto o por idioma. 6. Avisa al comercial por el canal donde de verdad mira, y guarda un registro de la operación. **Lo que se rompe:** el paso 3. Si la búsqueda de duplicados solo mira el email, la misma persona que se registra dos veces con dos correos entra dos veces y dos comerciales la llaman. Y si el origen no se guarda en el primer registro, después no se puede reconstruir: el circuito completo y sus fugas están en [leads que se pierden](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). ## Ejemplo 2: acceso tras el pago (y retirada cuando deja de pagar) El flujo que evita las dos incidencias más caras de una academia o una membresía: gente dentro que no debería estar y gente fuera que sí pagó. **Qué hace el flujo:** 1. Un webhook recibe el evento de la pasarela: pago completado, suscripción renovada, pago fallido o baja. 2. Comprueba que el evento es legítimo y que no se ha procesado ya, usando el identificador único del evento. 3. Según el tipo, crea el usuario y le da acceso, lo mantiene, lo suspende o lo retira. 4. Actualiza el estado en el CRM para que el comercial sepa en qué situación está esa persona. 5. Envía el mensaje que corresponda y guarda el registro. **Lo que se rompe:** el paso 2. Las pasarelas reintentan los avisos, así que el mismo evento puede llegar varias veces; sin la comprobación de duplicados, el usuario recibe tres correos de bienvenida o se le cobra dos veces. Y los eventos de pago fallido casi nunca se tratan, que es justo por donde se escapa el dinero cada mes: el caso concreto está en [pagos fallidos de Stripe y acceso al curso](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/). ## Ejemplo 3: la conciliación nocturna que detecta lo que falla en silencio Este flujo no automatiza una tarea: vigila a los demás. Es el que más tranquilidad da y el que casi nadie monta. **Qué hace el flujo:** 1. A una hora fija, cuenta los registros de origen del día: formularios recibidos, pagos cobrados, pedidos creados. 2. Cuenta los equivalentes en destino: contactos en el CRM, accesos activados, facturas emitidas. 3. Compara. Si las cifras no cuadran, lista los identificadores que faltan. 4. Avisa a una persona concreta, con el detalle de qué falta y desde cuándo. 5. Guarda el resultado diario para poder mirar la serie, no solo el dato de hoy. **Lo que se rompe:** el avisar "al equipo". Una alerta sin responsable con nombre no la atiende nadie. Y si el propio flujo de vigilancia deja de ejecutarse, no avisa de su propio silencio: necesita un aviso por ausencia de señal. Todo el patrón está en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ## Ejemplo 4: clasificar con IA lo que llega en texto libre Aquí es donde encaja un modelo de lenguaje dentro de n8n, y donde conviene poner el límite claro. **Qué hace el flujo:** 1. Recibe una entrada no estructurada: un correo de soporte, la transcripción de una llamada, el campo libre de un formulario. 2. Un nodo de modelo extrae lo que interesa y devuelve una estructura fija: motivo, producto mencionado, urgencia percibida, resumen en dos líneas. 3. Una condición explícita, no el modelo, decide qué se hace con eso: a qué cola va, a quién se asigna, si se escala. 4. Escribe el resultado en el CRM o en el sistema de tickets, con el texto original enlazado. 5. Marca para revisión humana lo que el modelo no pudo clasificar con claridad. **Lo que se rompe:** el paso 3 cuando se le delega al modelo. Si el modelo decide si se aplica un descuento, si un cliente tiene derecho a reembolso o si un lead pasa a comercial, un día decidirá distinto con la misma entrada y nadie sabrá por qué. La lógica determinista va en condiciones y código; la IA interpreta, no decide. Cómo aplicamos esa frontera está en [IA aplicada a negocios digitales](https://fcgsystems.es/blog/ia-aplicada-negocios-digitales/). ## ¿Qué tienen en común los cuatro ejemplos? Ninguno es una lista de nodos. Los cuatro se sostienen sobre cuatro decisiones que hay que tomar antes de abrir la herramienta: | Decisión | Pregunta que hay que responder | |---|---| | Idempotencia | ¿Qué pasa si este flujo se ejecuta dos veces con el mismo dato? | | Fuente de verdad | ¿Qué sistema manda si el CRM y la plataforma de pagos discrepan? | | Registro | ¿Puedo saber mañana qué pasó exactamente con el registro de hoy? | | Responsable | ¿Quién recibe el aviso cuando esto falla, con nombre y apellidos? | Un flujo que no responde a esas cuatro funciona en la demo y se rompe en el lanzamiento. ## ¿Qué necesitas para empezar con n8n? - **Dónde ejecutarlo.** n8n Cloud o instalación propia. La edición Community autoalojada no tiene coste de licencia, pero sí servidor, actualizaciones y copias de seguridad; los planes de Cloud están en su [página de precios](https://n8n.io/pricing/) y las opciones de instalación, en su [documentación de alojamiento](https://docs.n8n.io/hosting/) (consultadas en septiembre de 2026). Los números y el coste real de cada opción están en [n8n precios: Cloud o self-hosted](https://fcgsystems.es/blog/n8n-precios-cloud-self-hosted/). - **Un proceso pequeño que hoy se haga a mano.** No empieces por el flujo crítico del lanzamiento. - **Datos de prueba feos.** Un email vacío, un teléfono sin prefijo, un nombre con un emoji. Si el flujo aguanta eso, aguanta producción. - **Un aviso de error configurado desde el primer día.** No viene puesto de serie. Si el webhook funciona al probarlo y no cuando lo lanza la plataforma de verdad, el diagnóstico paso a paso está en [webhook de n8n que no funciona](https://fcgsystems.es/blog/webhook-n8n-no-funciona/). ## Errores comunes con los primeros flujos de n8n - **Consultar una API cada minuto pudiendo recibir un webhook.** Consume ejecuciones sin que haya datos nuevos. - **Probar solo con el caso bueno.** El dato que rompe el flujo es siempre el raro. - **Dejar la lógica de negocio repartida en veinte nodos.** Si nadie sabe dónde está la regla, la regla no existe. - **No hacer los flujos idempotentes.** Un reintento vuelve a crear el contacto o a cobrar. - **Guardar credenciales en el propio flujo.** Van en el gestor de credenciales, siempre. - **Montarlo todo en una sola instancia sin copias de seguridad.** El día que el servidor falle, la operación entera se para. - **Elegir n8n antes de saber si encaja.** La comparación honesta con las alternativas está en [n8n vs Make](https://fcgsystems.es/blog/n8n-vs-make/). ## Checklist antes de poner un flujo de n8n en producción - El flujo se puede ejecutar dos veces con el mismo dato sin efectos duplicados. - Está probado con datos vacíos, duplicados y mal formateados. - Hay un flujo de error configurado que avisa a una persona concreta. - Queda registro de qué entró y qué salió en cada ejecución. - Está decidido qué sistema es la fuente de verdad de cada dato. - Las credenciales están en el gestor de credenciales, no dentro de los nodos. - Existe una comprobación diaria que compara origen y destino. - Si va autoalojado, hay copias de seguridad probadas y responsable del servidor. ## ¿Cuándo conviene delegarlo? Un flujo suelto lo monta cualquiera con ganas y una tarde. La cosa cambia cuando de esos flujos depende que entren leads, que la gente tenga acceso a lo que ha pagado o que la facturación cuadre: ahí lo que hace falta no es saber n8n, es diseñar el sistema y dejarlo observable. Es lo que hacemos en el servicio de [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/) y, cuando n8n va en servidor propio, con [infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/) para que la instancia no dependa de la suerte. Si quieres ver antes cómo encaja la automatización con el resto de piezas, empieza por [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/). Y si ya tienes flujos en n8n pero no sabrías decir cuáles fallaron la semana pasada, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Qué se puede hacer con n8n? Ejemplos reales En un negocio digital, los cuatro usos que más se repiten son: llevar cada lead del formulario o del anuncio al CRM ya deduplicado y asignado, dar o quitar el acceso a un curso o membresía según el estado del pago, conciliar cada noche dos fuentes de datos y avisar de las diferencias, y clasificar entradas de texto libre con IA para dejarlas ordenadas en el sistema. Todo lo demás suele ser una variante de estos cuatro. ### ¿Cómo funciona n8n exactamente? Un flujo de n8n arranca con un disparador (un webhook que recibe datos, una ejecución programada o un cambio en otra aplicación) y encadena nodos que leen, transforman, deciden y escriben. Los datos viajan de un nodo al siguiente como una lista de elementos, de modo que un mismo flujo puede procesar uno o cien registros con la misma estructura. ### ¿n8n es gratuito o se paga? La edición Community, que se instala en tu propio servidor, no tiene coste de licencia; los planes de n8n Cloud se pagan por ejecuciones y están publicados en su web. Gratuito no es lo mismo que sin coste: autoalojarlo implica servidor, actualizaciones, copias de seguridad y alguien que responda cuando falle. ### ¿Se puede automatizar con IA dentro de n8n? Sí, un nodo de modelo puede clasificar, resumir o extraer datos de texto libre dentro del flujo. La regla que aplicamos es sencilla: la IA se usa para interpretar lo que no está estructurado, nunca para decidir lo determinista. Umbrales, importes, permisos y reglas de negocio van en código o en condiciones explícitas, donde se pueden probar y auditar. ### ¿Cómo empiezo a aprender n8n sin romper nada? Elige un proceso pequeño que hoy se haga a mano, móntalo con datos de prueba y no lo conectes a producción hasta que hayas comprobado qué pasa cuando llega un dato vacío o duplicado. Añade desde el primer día un registro de cada ejecución y un aviso de error con responsable. Ese hábito enseña más que cualquier tutorial de nodos. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. - [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/): Servidores, despliegues, backups y alertas para que tu operación no se caiga y sea tuya. ## Casos relacionados - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/): Formularios, tracking, CRM y agenda comercial conectados en un solo sistema, con el origen de cada lead a la vista. Las tres etapas del funnel mejoraron. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # CRM para pymes y negocios digitales: para qué sirve, cómo elegirlo y cuándo compensa uno a medida > Para qué sirve un CRM en una pyme o negocio digital, qué exigirle antes de elegirlo y cuándo compensa un CRM SaaS, uno a medida o una combinación de ambos. - URL: https://fcgsystems.es/blog/crm-para-pymes-saas-o-a-medida/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Breakdown · Lectura: 13 min - Palabra clave: crm para pymes (también: crm para empresas, crm para pequeñas empresas, crm a medida, crm para whatsapp, mejor crm, mejor crm para pymes, cuanto cuesta un crm, precio crm) Un **CRM para pymes** sirve para que cada contacto y cada oportunidad de venta vivan en un solo sitio, con su origen, su responsable, su etapa y su historial. Elegirlo bien no depende de la lista de funciones, sino de que encaje con vuestro proceso comercial y se conecte con formularios, pagos y canales. Un SaaS bien configurado resuelve la mayoría de casos; uno a medida compensa cuando el proceso comercial es lo que diferencia al negocio. En una pyme o en un negocio digital, el CRM suele llegar tarde: primero hay un formulario, luego una hoja de cálculo, luego un grupo de WhatsApp del equipo comercial. Cuando por fin se contrata un CRM, se hace muchas veces por comparación de precios o recomendación, sin haber decidido qué tiene que resolver. Esta guía explica para qué sirve un CRM, qué necesita cada tipo de negocio digital, cómo elegirlo y cuándo tiene sentido construir uno propio. ## ¿Para qué sirve un CRM? Un CRM es la **fuente de verdad** de la relación comercial: el sistema que manda para contactos, leads y oportunidades. Es la misma idea que explico en la guía de [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/): cada dato crítico tiene que tener un único sitio donde se decide su valor. En la práctica, un CRM bien implantado resuelve seis cosas: | Función | Qué resuelve | Qué pasa sin ella | |---|---|---| | Registro único de contactos | Cada persona existe una vez, con sus datos normalizados | Duplicados y dos comerciales llamando al mismo lead | | Responsable por lead | Cada contacto tiene un propietario claro | Leads que nadie atiende porque todos creen que lo hace otro | | Etapas reales de venta | El pipeline refleja cómo se vende de verdad | Etapas genéricas que nadie actualiza | | Seguimiento | Tareas y recordatorios que no dependen de la memoria | Leads que se enfrían sin que nadie lo note | | Origen del lead | Se sabe qué canal o campaña trajo a cada contacto | Imposible saber qué inversión en captación funciona | | Reporting | Cifras de captación y ventas sin exportar datos a mano | Informes que llegan tarde y no cuadran | El origen merece atención aparte: si no se guarda en el primer registro y se conserva hasta la venta, ningún CRM puede reconstruirlo después. Por qué pasa y cómo evitarlo está en [por qué GA4, Meta y tu CRM nunca dan la misma cifra](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/). ## ¿Qué necesita del CRM una pyme o un negocio digital? No todos los negocios usan el CRM igual. Antes de comparar herramientas conviene identificar vuestro perfil: | Perfil | Cómo vende | Qué debe resolver el CRM | |---|---|---| | Equipo comercial con setters o closers | Leads que se cualifican y pasan a llamada | Asignación automática con propietario único, etapas de cualificación, agenda vinculada al lead, visibilidad por comercial | | Academia online o infoproductor por lanzamientos | Miles de registros en pocos días, venta en ventana corta | Deduplicación antes de asignar, origen por campaña, integración con formularios, pagos y accesos, reporting durante el lanzamiento | | Negocio con venta continua (evergreen, membresía) | Flujo constante de leads y renovaciones | Seguimiento automático, estado del cliente sincronizado con el pago, historial de compras | | Agencia | Proyectos para varios clientes | Separación de datos por cliente, permisos, oportunidades de proyecto y no solo de contacto | | Pyme de servicios con venta consultiva | Pocas oportunidades de más valor | Historial de conversaciones, presupuestos, tareas de seguimiento y previsión de ventas | Si tu negocio encaja en más de una fila, el CRM tiene que cubrir la más exigente. Y si los leads ya se están perdiendo entre formulario, WhatsApp y comercial, empieza por [leads que se pierden y Excel como CRM](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/), que explica ese tramo en detalle. ## ¿Cuál es el mejor CRM? No existe un mejor CRM en abstracto, y no es una respuesta evasiva: es que la pregunta se contesta con datos que solo tenéis vosotros. **El mejor CRM es el que encaja con vuestras etapas de venta, se conecta con lo que ya usáis y seguirá siendo asumible dentro de tres años.** Dos negocios del mismo tamaño y del mismo sector pueden necesitar herramientas distintas si uno vende por lanzamientos y el otro por venta consultiva. Cinco cosas deciden de verdad, y ninguna aparece en una comparativa de marcas: 1. **Cómo vendéis.** Si hay setters y closers, el CRM tiene que repartir leads con propietario único y capacidad por persona. Si la venta es consultiva y larga, lo que importa es el historial y la previsión. Son productos distintos. 2. **Con qué tiene que hablar.** Formularios, pasarela de pago, plataforma formativa, agenda y mensajería. Un CRM sin API ni webhooks os obliga a rellenar el hueco a mano para siempre. 3. **Qué pasa con vuestros datos.** Cómo se exportan, con qué historial y en qué formato. Es la pregunta que más incomoda a un comercial y la que mejor predice el dolor de dentro de dos años. 4. **Quién lo va a usar.** Un CRM que el equipo comercial no abre no es mejor ni peor: es un gasto. La adopción pesa más que cualquier función del catálogo. 5. **Cuánto costará con vuestro volumen futuro.** No con el de hoy. Ver el apartado siguiente. ### Por qué un ranking de marcas caduca Las listas del tipo "los 7 mejores CRM" envejecen mal, y no por pereza de quien las escribe: - **Los planes se reorganizan.** La función por la que elegisteis la herramienta sube un escalón de plan y el precio deja de parecerse al que comparasteis. - **Los precios cambian, y casi siempre en la misma dirección.** Una comparativa de precios con seis meses es ficción. - **El mercado se consolida.** Las compras entre fabricantes cambian hojas de ruta, integraciones y soporte sin avisar. - **Muchos rankings tienen dueño.** Buena parte de esos listados se financian con comisiones por alta, así que el orden responde a lo que paga mejor, no a lo que encaja mejor. Lo que no caduca son los criterios. Por eso aquí no hay ranking: hay preguntas que hacerle a cada proveedor con vuestro proceso delante. **La prueba que sí funciona:** coge dos o tres candidatos, mete en cada uno un proceso real vuestro de principio a fin (un lead entra, se deduplica, se asigna, avanza de etapa, se cierra) y dale dos semanas a un comercial de verdad. Esa comparación vale más que cualquier tabla de funciones. ## ¿Cómo elegir un CRM para una pyme? Por criterios, no por marcas. Estas son las preguntas que conviene responder antes de firmar, con cada proveedor delante: ### Datos - ¿Permite definir los campos que necesitáis, incluido el origen del lead y los parámetros de campaña? - ¿Cómo detecta y fusiona duplicados? ¿Por email, por teléfono, por reglas propias? - ¿Se pueden exportar todos los datos, con su historial, en un formato estándar y sin depender del proveedor? ### Integraciones - ¿Tiene API documentada para leer y escribir contactos y oportunidades? - ¿Envía webhooks cuando cambia algo (nuevo lead, cambio de etapa, venta cerrada)? - ¿Se conecta con vuestros formularios, pasarela de pago, plataforma formativa, agenda y canal de mensajería, de forma nativa o mediante automatización? ### Equipo y permisos - ¿Cada persona ve solo lo que le corresponde? - ¿Queda registro de quién cambió qué? - ¿El equipo comercial lo va a usar de verdad, o duplicará el trabajo en otra hoja? ### Coste - ¿El precio crece por usuario, por número de contactos, por funciones o por volumen de envíos? - ¿Cuánto costaría con el volumen y el equipo que esperáis dentro de dos o tres años, no con el de hoy? - ¿Qué funciones que necesitáis están en planes superiores? Una respuesta vaga a "¿cómo sacamos los datos si nos vamos?" es una señal de alerta, independientemente del precio. ## ¿Cuánto cuesta un CRM? Aquí no vais a encontrar cifras de marcas concretas, y es deliberado: los planes se reorganizan cada pocos meses y cualquier número que escriba hoy os llevaría a una conclusión equivocada mañana. Lo que sí se mantiene es **por qué eje os van a cobrar**, que es lo que determina si el precio crece con vosotros o se dispara. | Eje de cobro | Cómo escala | A quién le duele | |---|---|---| | Por usuario | Cada persona con acceso suma cuota, cada mes | Equipos que crecen, o donde marketing, soporte y dirección también necesitan entrar | | Por contactos almacenados | Se paga por el tamaño de la base, la trabajéis o no | Negocios con captación masiva: lanzamientos, leads magnets, listas antiguas | | Por funciones del plan | Lo que necesitáis vive dos escalones más arriba | Casi todos, en cuanto hacen falta permisos finos, automatizaciones o informes | | Por volumen de envíos o de API | Emails, mensajes o llamadas a la API por encima de un umbral | Operaciones automatizadas, que consumen API sin que nadie lo vea | Un CRM barato por usuario puede salir caro por contactos, y al revés. La combinación de ejes es lo que hay que simular, no la cuota de entrada. ### Lo que no aparece en la página de precios Estos cuatro conceptos suelen sumar más que la licencia del primer año: - **Implantación.** Definir etapas, campos, permisos y reglas de asignación. Es trabajo de diseño del proceso, no de configuración de una herramienta, y por eso no se puede saltar. - **Migración de datos.** Limpiar duplicados, normalizar teléfonos y decidir qué histórico entra. Importar la hoja tal cual mete el desorden dentro del CRM nuevo. - **Integraciones.** Cada conexión con formularios, pagos, agenda o mensajería es trabajo, y necesita logs y reintentos si no queréis descubrir los fallos por el hueco en la facturación. - **Mantenimiento.** Alguien con nombre revisa que las integraciones siguen vivas, que las reglas siguen teniendo sentido y que el equipo lo usa como se acordó. **La cifra que sirve para decidir** no es la cuota mensual: es el coste total a dos o tres años, con el número de usuarios y el volumen de contactos que esperáis tener entonces, sumando implantación, migración, integraciones y mantenimiento. Ese es el número que hay que poner al lado del presupuesto de un desarrollo propio, y no antes. ## ¿CRM SaaS o CRM a medida? Es la pregunta que más dinero mueve y la que más se responde por intuición. El criterio es el mismo que aplico en [de no-code a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/): se construye lo que diferencia al negocio y se contrata lo estándar. | | CRM SaaS | CRM a medida | |---|---|---| | Cuándo encaja | El proceso comercial es estándar y una herramienta existente lo cubre casi entero | El proceso comercial es vuestra forma de operar y ningún SaaS lo cubre sin parches | | Puesta en marcha | Rápida: configurar, integrar y formar | Más larga: diseñar, construir, probar y migrar | | Coste | Licencias que suelen crecer con usuarios, contactos o funciones | Desarrollo inicial y mantenimiento, con coste que no depende del número de usuarios | | Flexibilidad | La que permita la herramienta | Total, dentro de lo que se diseñe | | Mantenimiento | Lo asume el proveedor | Tiene que tener responsable: vuestro equipo o un partner | | Riesgo principal | Adaptar el negocio a la herramienta y quedar atado a sus límites | Construir sin diseño previo y sin plan de mantenimiento | Para decidir con números, calcula el **coste total con vuestro volumen y vuestros usuarios a varios años**: licencias o desarrollo, integraciones, horas manuales que se eliminan o se mantienen y coste de los errores actuales. Comparar la cuota mensual de un SaaS con el presupuesto de un desarrollo, sin más, lleva casi siempre a una conclusión equivocada en uno u otro sentido. ### El modelo que suele funcionar: híbrido En la mayoría de negocios digitales la respuesta no es una cosa u otra: - **SaaS para lo estándar:** email, agenda, pipeline comercial básico. - **Software propio para lo que diferencia:** la lógica de asignación de leads, la deduplicación, el control de accesos o un panel para setters con exactamente lo que necesitan. - **Automatizaciones con logs** que conectan ambas partes y respetan cuál es la fuente de verdad de cada dato. Si hoy el CRM es una base de Airtable o una colección de escenarios de automatización que ya no dan más de sí, las señales concretas para dar el salto están en el artículo sobre [pasar de no-code a software propio](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/). ## ¿Y el CRM con WhatsApp? En muchos negocios digitales la venta pasa por WhatsApp. Si las conversaciones ocurren en la app del móvil de cada comercial, el CRM nunca tendrá el historial completo por bueno que sea. Para que WhatsApp forme parte del CRM hace falta la API oficial y una integración que registre cada conversación en la ficha del contacto. Qué implica, cuánto cuesta y cuándo compensa está en [WhatsApp Business API: qué es, precio y cuándo usarla](https://fcgsystems.es/blog/whatsapp-business-api/). ## ¿Cómo se implanta un CRM sin parar las ventas? ### 1. Mapa de datos Qué datos de cada contacto necesitáis, de dónde vienen (formularios, pagos, agenda, mensajería) y qué herramienta manda para cada uno. ### 2. Etapas reales Las etapas del pipeline se escriben a partir de cómo vendéis hoy, no de la plantilla que trae la herramienta. Cada etapa tiene un criterio de entrada claro. ### 3. Deduplicación y asignación Reglas para detectar duplicados antes de asignar, y reglas de asignación con un único responsable por lead. En lanzamientos, la deduplicación va antes de la asignación, nunca después. ### 4. Migración en paralelo Los registros nuevos entran en el CRM mientras la hoja actual sigue viva unos días, se comparan ambas fuentes y el equipo cambia cuando el sistema ya ha demostrado que funciona. El paso a paso está en [cómo migrar de un Excel a un sistema sin parar las ventas](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). ### 5. Integraciones observables Cada integración que alimenta el CRM tiene logs, avisos y reintentos seguros. Si no, acabarás con [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/) y un CRM que parece completo pero no lo está. ### 6. Reporting desde el CRM Los informes de captación y ventas se generan desde el CRM, sin exportar a mano. Si el reporting sigue saliendo de una hoja, la fuente de verdad sigue siendo la hoja. ## ¿Qué cambia cuando el CRM está bien conectado? Un ejemplo publicado: en el [caso del sistema comercial de una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/) conectamos tracking de fuentes con GA4 y Google Tag Manager, formularios de Tally hacia una base común en Airtable, reservas de Calendly vinculadas al lead y dashboards por etapa y fuente. Durante el proyecto, con las campañas activas, el opt-in pasó del 70,81 % al 77,61 %, la preinscripción del 36,85 % al 44,72 % y las llamadas del 9,89 % al 16,22 %. Son mejoras del conjunto del sistema, no atribuibles a una sola pieza. Lo relevante para esta guía es que el CRM no se eligió aislado: se diseñó como parte del circuito completo. ## Errores comunes al elegir e implantar un CRM - **Elegir por la lista de funciones.** La mitad no se usará y la que falta es la integración que necesitabais. - **Copiar las etapas de la plantilla.** El pipeline deja de reflejar la venta real y nadie lo actualiza. - **No guardar el origen desde el primer registro.** Después no se puede reconstruir. - **Importar el histórico sin limpiar.** Los duplicados de la hoja pasan al CRM. - **Mantener la hoja editable "por si acaso".** Crea dos fuentes de verdad. - **Calcular el coste con el equipo de hoy.** El precio que importa es el de dentro de dos o tres años. - **No revisar cómo se exportan los datos.** Salir del proveedor se vuelve un proyecto en sí mismo. - **Construir un CRM a medida sin haber diseñado el proceso.** El desorden se muda de herramienta. ## Checklist antes de elegir CRM - Las etapas reales de venta están escritas, con criterio de entrada. - Sabemos qué datos necesitamos de cada contacto y de dónde vienen. - El origen del lead se captura en el primer registro. - Hay reglas de deduplicación y de asignación con un único responsable. - El CRM candidato tiene API y webhooks para las integraciones que necesitamos. - Hemos comprobado cómo se exportan todos los datos. - Los permisos permiten que cada persona vea lo que le corresponde. - Hemos calculado el coste total con el volumen y el equipo esperados a varios años. - Está decidido si WhatsApp entra en el CRM y cómo. - Las integraciones tendrán logs y avisos. - Hay un responsable con nombre del CRM y de su mantenimiento. ## ¿Cuándo conviene delegarlo? Si sois un equipo pequeño con un proceso comercial sencillo, esta guía y un par de semanas de pruebas con dos o tres candidatos pueden bastar. Conviene hacerlo con alguien que diseñe el sistema cuando el CRM tiene que conectarse con varios canales de captación, pagos, accesos y mensajería; cuando hay setters y closers con reglas de asignación; cuando vendéis por lanzamientos o cuando la duda real es si construir o contratar. Un **Systems Audit** de 5 a 10 días laborables documenta herramientas, flujos de datos y procesos, y termina en una arquitectura objetivo con roadmap de 90 días: es el trabajo de [arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/). Si la conclusión es construir, el CRM o la parte que os diferencia se aborda como un [CRM a medida](https://fcgsystems.es/servicios/software-a-medida/), y las integraciones con la [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/). Si estáis a punto de elegir CRM o el que tenéis ya no refleja cómo vendéis, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Para qué sirve un CRM en una pyme? Para tener un único sitio donde vive cada contacto y cada oportunidad de venta, con su origen, su responsable, su etapa y su historial. Sin eso, la información comercial se reparte entre hojas de cálculo, correos y móviles, y nadie puede decir con certeza cuántos leads hay, quién los atiende ni qué canal trae ventas. ### ¿Qué CRM es mejor para una pequeña empresa? El que encaja con cómo vendéis y se conecta con las herramientas que ya usáis, no el que más funciones anuncia. Antes de comparar marcas conviene escribir las etapas reales de la venta, qué datos necesitáis de cada lead, con qué formularios, pagos y canales tiene que integrarse y cuántos usuarios lo van a usar dentro de dos o tres años. ### ¿Cuándo compensa un CRM a medida frente a uno SaaS? Cuando el proceso comercial es la forma de operar del negocio y un SaaS obliga a vivir de parches, o cuando el coste de licencias crece más rápido que el valor que aporta. Para procesos estándar, un SaaS bien configurado suele ser la mejor opción. Lo habitual es combinar: SaaS para lo estándar y software propio para lo que os diferencia. ### ¿Un Excel puede servir como CRM? Al principio sí, con pocos leads y una sola persona que los gestiona. Deja de servir cuando entran contactos desde varios canales, hay más de un comercial o hace falta saber el origen de cada venta. En ese punto los duplicados, los leads sin responsable y el reporting manual cuestan más que implantar un CRM. ### ¿Se puede conectar el CRM con WhatsApp? Sí, pero depende de cómo uséis WhatsApp. Con la app de WhatsApp Business las conversaciones se quedan en el móvil y hay que registrarlas a mano. Con la API oficial de WhatsApp Business los mensajes pueden entrar y salir desde el CRM o desde una automatización conectada, con registro de cada conversación. ### ¿Cuál es el CRM más usado? Los más extendidos por cuota de mercado son las suites grandes del sector, pero eso dice poco sobre cuál os conviene: la cuota mide el tamaño de su fuerza comercial, no el encaje con vuestro proceso. Un CRM muy implantado en equipos de cien comerciales suele ser caro y pesado para una pyme de cinco, y al revés. Lo que decide es qué tipo de CRM necesitáis, y esos perfiles están en [los tipos de CRM y qué resuelve cada uno](/blog/tipos-de-crm/). ### ¿Cuánto cuesta un CRM? El precio de lista casi nunca es el coste real. Un CRM se factura por alguna combinación de cuatro ejes (usuarios, contactos almacenados, funciones del plan y volumen de envíos o llamadas a la API) y a eso hay que sumarle implantación, migración de datos, integraciones y el tiempo de quien lo mantiene. La cifra útil es el coste total a dos o tres años con el equipo y el volumen que esperáis, no la cuota del primer mes. ## Servicios relacionados - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Casos relacionados - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/): Formularios, tracking, CRM y agenda comercial conectados en un solo sistema, con el origen de cada lead a la vista. Las tres etapas del funnel mejoraron. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Dar permisos a un agente de IA es una decisión de riesgo, no una casilla de configuración > Qué no se delega nunca a un modelo: accesos, cobros, precios e identidad. Cómo decidir los permisos de un agente de IA con criterio de riesgo, no de setup. - URL: https://fcgsystems.es/blog/permisos-de-un-agente-decision-de-riesgo/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: IA aplicada · Formato: Opinión · Lectura: 4 min - Palabra clave: permisos de un agente de ia (también: seguridad de agentes de ia, qué no delegar a un modelo, agente ia accesos) El momento más peligroso de un proyecto de IA no es cuando eliges el modelo. Es cuando alguien marca una casilla que dice "permitir escribir". Pasa en treinta segundos y en mitad de otra tarea. Estás montando el agente, le has dado acceso de lectura al CRM, funciona bien, y entonces surge lo obvio: "ya que está, que actualice él la ficha". Un clic. Después "ya que está, que mande él el email". Otro clic. Y en algún punto de esa cadena de "ya que está", un sistema que solo leía ha pasado a poder cambiar el estado de un cliente, mover dinero o dar un acceso. Nadie tomó esa decisión. Se fue acumulando. ## Un permiso no es una funcionalidad: es una apuesta Cuando le das a un modelo la capacidad de ejecutar una acción, estás afirmando algo muy concreto: *si se equivoca en esa acción, puedo asumir la consecuencia*. Ese es el cálculo entero. Todo lo demás es ruido. Y conviene decirlo sin adornos: un modelo de lenguaje no falla como falla el software normal. El software roto falla igual siempre, y por eso lo cazas. Un modelo acierta el 98% de las veces y el 2% restante hace algo perfectamente razonable y perfectamente equivocado, con un tono impecable. No hay excepción, no hay stack trace, no hay alarma. Hay una acción bien redactada que no debería haber ocurrido. Con lectura, eso te da una respuesta mala. Con escritura, te da un problema con cliente delante. ## Lo que no delego nunca a un modelo Tengo una lista corta y no la negocio. Cuatro cosas las decide código determinista, siempre: **Accesos.** Quién entra en un producto, en una comunidad o en un panel. Un acceso mal dado no se deshace: la persona ya vio lo que hay dentro, ya descargó lo que quería. Y un acceso mal quitado es un cliente que pagó y está fuera, escribiendo enfadado. Ambos errores son caros y ninguno de los dos se recupera pidiendo perdón. La regla de acceso es una condición: pago activo, plan X, fecha dentro de rango. Eso es un `if`, no una inferencia. **Cobros.** Cualquier cosa que mueva dinero. Cobrar, reembolsar, aplicar un descuento, cambiar el importe de una suscripción. Aquí la asimetría es brutal: el beneficio de automatizarlo con un modelo es ahorrarte una condición en código, y el coste de un fallo es un cargo indebido y una disputa. No compensa ni de lejos. **Precios.** Ni fijarlos, ni negociarlos, ni "adaptarlos al perfil del cliente". El precio es una decisión de negocio con consecuencias legales y de marca. Un modelo que improvisa un descuento en un chat te acaba de crear un compromiso que tendrás que honrar. **Identidad.** Quién es alguien. La verificación de una persona nunca sale de una conversación, por convincente que suene. Sale de un token, de una sesión, de un dato comprobado contra tu base de datos. Lo que sí delego sin dramas: redactar, resumir, clasificar, proponer, extraer, traducir, priorizar. Todo lo que produce una recomendación que alguien (o algo determinista) valida después. La diferencia no es la dificultad de la tarea. Es si la salida es una **sugerencia** o un **hecho consumado**. ## Los dos permisos que la gente subestima Hay dos que se cuelan casi siempre porque no parecen peligrosos. El primero es **hablar en nombre de la empresa sin revisión**. Un agente que responde en el WhatsApp de atención al cliente no está "escribiendo texto": está creando compromisos. Si promete un plazo de entrega, ese es el plazo. Si dice que hay devolución a los 60 días, tu política acaba de cambiar por la cara. El daño no está en el sistema, está en lo que has prometido. El segundo es **buscar información fuera y actuar con ella**. Si un agente lee un correo, una web o un ticket y luego ejecuta acciones, cualquiera que pueda escribir en esa entrada puede intentar darle instrucciones. No hace falta ser un genio: basta con meter una frase dentro de un mensaje de soporte. El agente no distingue entre "esto son datos" y "esto son órdenes" salvo que tú lo separes explícitamente. Cuanto más permiso tenga, más interesante es como objetivo. ## Cómo lo decido en un proyecto No empiezo por la lista de herramientas que le doy al agente. Empiezo por una tabla de dos columnas: qué puede hacer y qué pasa si se equivoca haciéndolo. Luego aplico tres filtros. **¿Es reversible?** Si no puedo deshacerlo en un minuto y sin llamar a nadie, no lo ejecuta el modelo solo. **¿Alguien lo va a ver?** Una acción sin registro es una acción que nunca sabrás que ocurrió; todo lo que el agente haga deja rastro con su entrada, su salida y su hora. **¿Está acotado?** Acceso mínimo, no acceso cómodo: solo los registros de este cliente, solo este rango de importes, solo estas operaciones. La cuenta de administrador con la que probaste el lunes no es la cuenta con la que se despliega. Y para lo que no pasa los filtros, existe el mejor patrón de todos: **el agente prepara, el humano aprueba**. El modelo redacta el reembolso, monta la ficha, propone el descuento. Otro sistema o una persona pulsa. Sigue ahorrando casi todo el trabajo y no delega ninguna de las cuatro decisiones de la lista. Sobre cómo se estructura eso dentro de un proceso real escribí en [agentes de IA para negocios](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/), y sobre el caso concreto de accesos y cobros, en [pagos fallidos y acceso al producto](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/). El criterio que te llevas: los permisos de un agente no los decide quien lo configura, los decide quien asume la pérdida. Si esas dos personas no son la misma, tienes un problema de gobierno antes que un problema técnico. Y si alguna vez dudas, hazte la pregunta corta: ¿me vale que esto pase el 2% de las veces? ## Servicios relacionados - [Sistemas de IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. - [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/): Servidores, despliegues, backups y alertas para que tu operación no se caiga y sea tuya. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # De prototipo con IA a producción: lo que siempre falta cuando la demo ya funciona > Qué falta siempre para llevar a producción una app creada con IA: permisos, datos, pagos, límites, observabilidad, costes y propiedad. Con checklist accionable. - URL: https://fcgsystems.es/blog/de-prototipo-ia-a-produccion/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Software · Formato: Breakdown · Lectura: 9 min - Palabra clave: de prototipo a producción (también: poner en produccion una app hecha con ia, llevar prototipo a produccion, app con lovable a produccion, mvp a producto, prototipo ia produccion, vibe coding produccion) Entre una demo que funciona y un producto en producción hay siete bloques de trabajo que la IA no genera sola: **autenticación y permisos, datos y copias, pagos y accesos, límites y abuso, observabilidad, costes y propiedad del código**. En una app que toca dinero o datos personales, ese trabajo suele ser mayor que el de construir la demo. Y no es una mala noticia. Es la noticia que conviene tener antes de firmar el presupuesto, no después. Esta pieza es la continuación práctica de [qué es el vibe coding](https://fcgsystems.es/blog/que-es-vibe-coding/). Allí explico dónde está el límite; aquí, qué hay exactamente al otro lado. ## ¿Por qué una demo generada con IA parece más terminada de lo que está? Porque lo que se ve funciona. El diseño es correcto, la navegación responde, los formularios guardan, hay datos en las tablas. Todas las señales que un ser humano usa para juzgar si algo está acabado están en verde. Lo que falta es, por definición, invisible: lo que pasa cuando entra *otro* usuario, cuando el pago falla, cuando alguien manda mil peticiones seguidas, cuando el servicio de terceros devuelve un error, cuando hay que averiguar qué ocurrió hace tres días. Osea: la demo demuestra que el camino feliz existe. Producción es todo lo demás. Entender es el verdadero atajo, y aquí se nota: el equipo que sabe qué le falta negocia bien con su cliente. El que no lo sabe promete una fecha y se come el retraso. ## Los siete bloques que siempre faltan ### 1. Autenticación y permisos de verdad Una demo tiene una pantalla de login. Un producto tiene un modelo de permisos. La diferencia es dónde se decide quién puede hacer qué. Si la comprobación está en el navegador ("si el usuario no es admin, no muestro el botón"), no es seguridad: es decoración. Cualquiera puede llamar a la API igualmente. La verificación tiene que ocurrir en el servidor o en la base de datos, en cada petición. Esto es la categoría número uno del [OWASP Top 10:2025, control de acceso roto](https://top10.owasp.org/2025/A01_2025-Broken_Access_Control/) (consultado en septiembre de 2026). Es la primera por frecuencia y es exactamente el punto ciego de cualquier prototipo. Qué hay que tener resuelto: - Roles definidos con nombres del negocio, no genéricos: quién es cliente, quién es gestor de cuenta, quién es administrador. - Cada endpoint y cada tabla con una regla explícita de quién accede. - Reglas a nivel de fila cuando varios clientes comparten base de datos: el cliente A no puede ver los registros del cliente B ni cambiando un identificador en la URL. - Sesiones que caducan, cierre de sesión que invalida de verdad, y recuperación de contraseña que no sea un agujero (categoría [A07:2025, fallos de autenticación](https://top10.owasp.org/2025/A07_2025-Authentication_Failures/)). Si la app usa Supabase, esto pasa por Row Level Security, y la [documentación oficial](https://supabase.com/docs/guides/database/postgres/row-level-security) es tajante: *"una tabla en un esquema expuesto sin RLS es legible y escribible por cualquier rol que tenga permiso sobre ella"* (consultado en septiembre de 2026). No es opcional. ### 2. Datos, copias y recuperación Pregunta incómoda: si mañana se borra la base de datos por error, ¿cuánto se pierde y cuánto se tarda en volver? Si la respuesta es "no lo sé", no hay copias de seguridad; hay una esperanza. Lo mínimo para producción: - Copias automáticas con una frecuencia que encaje con cuánto dato se puede permitir perder. - **Una restauración probada al menos una vez.** Una copia que nunca se ha restaurado no es una copia, es un fichero. - Un esquema de datos con claves únicas y restricciones, para que los duplicados no entren. - Un plan de migraciones: cómo se cambia el esquema sin romper lo que ya hay dentro. - Saber dónde están alojados los datos y qué se guarda de cada persona, porque alguien te lo va a preguntar por escrito. ### 3. Pagos y accesos El bloque donde los errores cuestan dinero literal en vez de tiempo. Cobrar bien no es poner un botón de Stripe. Es que el estado del pago y el estado del acceso estén sincronizados siempre, en los dos sentidos: - **Webhooks verificados y idempotentes.** El proveedor puede reenviar el mismo evento; si tu código lo procesa dos veces, das dos accesos o cobras dos veces. La [documentación de webhooks de Stripe](https://docs.stripe.com/webhooks) explica la verificación de firma y el reintento de eventos (consultado en septiembre de 2026). - **El precio se calcula en el servidor.** Nunca en el navegador, nunca confiando en un valor que llega del cliente. - **Impagos y cancelaciones revocan el acceso** sin que nadie tenga que acordarse. Este flujo concreto, con sus estados intermedios, lo desgloso en [pagos fallidos en Stripe y control de accesos](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/). - **Reembolsos y cambios de plan** contemplados, no improvisados el día que pasan. ### 4. Límites y abuso Una demo la usan cinco personas amables. Producción la usa internet. - Límite de peticiones por usuario y por IP en los endpoints caros o sensibles. - Validación de todo lo que entra, en el servidor. Es la raíz de la categoría [A05:2025, inyección](https://top10.owasp.org/2025/A05_2025-Injection/). - Tamaño máximo de subidas y tipos de fichero permitidos. - Protección en formularios públicos, o el primer bot te llena la base de datos de basura. - Si hay llamadas a modelos de IA dentro del producto: tope de gasto por usuario. Sin eso, un abuso puntual se convierte en una factura. ### 5. Observabilidad El bloque que nadie presupuesta y todos echan de menos. - **Logs** de lo que pasa en los flujos críticos: quién hizo qué y cuándo. - **Alertas** cuando algo falla, que lleguen a un canal que alguien mira. Un error que nadie ve es un error que sigue ocurriendo. - **Captura de errores** en cliente y servidor, agrupada, con contexto suficiente para reproducir. - **Métricas mínimas**: peticiones, latencia, errores. No hace falta un panel bonito; hace falta poder responder "¿está bien ahora?" en diez segundos. El [OWASP Top 10:2025 incluye los fallos de registro y alerta](https://top10.owasp.org/2025/A09_2025-Security_Logging_and_Alerting_Failures/) como categoría propia. Y en la práctica, es la diferencia entre enterarte por tu monitorización o por un correo del cliente enfadado. Este es el mismo problema que describo en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/), pero aplicado a una aplicación en vez de a un flujo. ### 6. Costes previsibles Las plataformas de prototipado cobran por uso, y el uso durante el desarrollo no se parece al uso en producción. Bolt, por ejemplo, documenta que el consumo de tokens crece con el tamaño del proyecto: *"la mayor parte de tu uso de tokens viene de que Bolt lee, entiende y sincroniza los ficheros de tu proyecto, así que los proyectos más grandes usan más tokens por mensaje"* ([soporte de Bolt](https://support.bolt.new/account-and-subscription/tokens), consultado en septiembre de 2026). Y Figma limita Make a asientos completos de planes de pago ([centro de ayuda de Figma](https://help.figma.com/hc/en-us/articles/31304412302231-Explore-Figma-Make), consultado en septiembre de 2026). Antes de lanzar hay que tener una cuenta clara de: hosting, base de datos, envío de correo, pasarela de pago, modelos de IA si los hay, y el coste de la propia herramienta de construcción si se sigue usando para mantener. Un producto que cuesta más de operar que lo que ingresa no es un producto, es un hobby caro. ### 7. Propiedad del código y del stack La pregunta que hay que hacer el primer día: **cuando esto esté terminado, ¿a nombre de quién está todo?** - Repositorio de código, con su historial. - Base de datos y sus copias. - Dominio y DNS. - Cuentas de los servicios de terceros y sus claves. - Si el prototipo vive dentro de una plataforma cerrada, cómo se sale de ahí y qué se pierde por el camino. Esto no es desconfianza, es higiene. Y para una agencia es especialmente relevante: si el cliente final tiene que entrar en la cuenta de la agencia para ver su propia base de datos, eso es una conversación pendiente que va a llegar en el peor momento. ## Checklist de puesta en producción Imprimible, para ir marcando. Si no puedes marcar una casilla, eso no es una tarea pendiente: es un riesgo abierto. **Permisos** - [ ] Todas las comprobaciones de permisos ocurren en el servidor o en la base de datos. - [ ] Un usuario no puede acceder a datos de otro cambiando un identificador en la URL. - [ ] Los roles están definidos y documentados en términos del negocio. - [ ] Las sesiones caducan y el cierre de sesión invalida el token. **Secretos y configuración** - [ ] Ninguna clave de API ni credencial aparece en el código del navegador. - [ ] Las variables de entorno de producción son distintas a las de desarrollo. - [ ] Los mensajes de error no exponen trazas internas al usuario final. - [ ] Las dependencias están actualizadas y sin vulnerabilidades conocidas. **Datos** - [ ] Hay copias de seguridad automáticas. - [ ] Se ha restaurado una copia al menos una vez, de verdad. - [ ] El esquema tiene claves únicas y restricciones. - [ ] Está documentado qué datos personales se guardan y dónde. **Pagos y accesos** - [ ] Los webhooks verifican la firma del proveedor. - [ ] Procesar el mismo evento dos veces no duplica nada. - [ ] Los importes se calculan en el servidor. - [ ] Un impago o una cancelación revocan el acceso automáticamente. **Límites** - [ ] Hay límite de peticiones en los endpoints sensibles. - [ ] Toda entrada se valida en el servidor. - [ ] Las subidas tienen límite de tamaño y de tipo. - [ ] Hay tope de gasto en las llamadas a modelos de IA, si las hay. **Observabilidad** - [ ] Los flujos de dinero y accesos dejan registro. - [ ] Las alertas llegan a un canal que alguien mira. - [ ] Los errores se capturan con contexto suficiente para reproducirlos. - [ ] Alguien tiene asignado el papel de mirar esto. **Costes y propiedad** - [ ] Hay una estimación mensual de coste de operación. - [ ] Repositorio, base de datos, dominio y cuentas están a nombre de quien corresponde. - [ ] Existe un plan de mantenimiento con responsable y frecuencia. - [ ] Está escrito qué pasa si mañana cambia el proveedor técnico. ## ¿Se reescribe o se aprovecha? Casi siempre se aprovecha bastante más de lo que la gente teme. La interfaz, el flujo de pantallas y buena parte de los componentes suelen ser perfectamente válidos: es donde estas herramientas son realmente buenas. Lo que hay que rehacer es la capa que decide cosas: acceso a datos, permisos, lógica de negocio y todo lo que toque dinero. El orden que sigo: 1. **Revisar** el código existente y clasificar qué se queda, qué se refactoriza y qué se tira. Cómo hacer esa revisión está en [revisar código generado por IA](https://fcgsystems.es/blog/revisar-codigo-generado-por-ia/). 2. **Mover la fuente de verdad** a una base de datos con dueño, esquema y restricciones. 3. **Reconstruir permisos** en servidor, con pruebas que comprueben que un usuario no ve lo del otro. 4. **Cerrar el circuito de pagos y accesos** con webhooks idempotentes. 5. **Instrumentar**: logs, alertas, captura de errores. 6. **Endurecer**: límites, validación, secretos fuera del cliente. 7. **Documentar y entregar**: quién mantiene esto y cómo. Es el mismo patrón de migración por piezas que describo al pasar [de no-code a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/): nunca un apagón y encendido, siempre sustituir la pieza que más duele primero. ## Cómo encaja esto en el presupuesto de una agencia Una recomendación concreta, de las que ahorran discusiones: separad la propuesta en dos. **Fase 1 — Prototipo.** Corta, barata, con IA, sin promesas de producción. Su entregable es una demo funcional y una decisión: seguimos o no. **Fase 2 — Producto.** Con los siete bloques de arriba como alcance explícito. Si el cliente ve la lista, entiende por qué cuesta lo que cuesta. Si no la ve, solo compara el precio con el tiempo que tardasteis en enseñarle la demo, y siempre vais a parecer caros. Y la parte técnica de la fase 2 no tiene por qué ser vuestra. Trabajar con un socio en **white label** os permite vender el proyecto completo manteniendo la relación con el cliente, sin contratar un perfil técnico a jornada completa para un proyecto puntual. ## ¿Tienes una demo y no sabes qué le falta? Eso es literalmente el punto de partida con el que más trabajo: una app hecha con Lovable, Bolt, v0 o Figma Make que funciona, que el cliente ya ha visto, y que nadie se atreve a poner delante de usuarios reales. [Cuéntame qué has construido](https://fcgsystems.es/contacto/) y te devuelvo la lista concreta de lo que falta, con prioridades y con lo que se aprovecha. Si después hay que construir la versión sólida, eso es [software a medida](https://fcgsystems.es/servicios/software-a-medida/); si lo que necesitáis es tener un equipo técnico detrás de forma continuada y en white label, es [partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/). ## Preguntas frecuentes ### ¿Cuánto trabajo hay entre una demo hecha con IA y un producto en producción? Depende de qué toque la aplicación. Si no maneja dinero ni datos personales, puede ser poco. Si tiene usuarios, pagos o información sensible, lo habitual es que el trabajo restante sea mayor que el de la demo: permisos, datos, cobros, límites y observabilidad no se generan solos. ### ¿Hay que reescribir el prototipo desde cero? Casi nunca. Lo normal es conservar la interfaz y el flujo, que es donde la IA es realmente buena, y reconstruir la capa de datos, permisos y lógica de negocio. Se sustituye por piezas, empezando por la que toca dinero o accesos. ### ¿Puede una agencia sin perfil técnico llevar esto a producción? Puede coordinarlo, pero alguien tiene que responder técnicamente de permisos, pagos y datos. Esa responsabilidad se asigna antes de empezar, con nombre y apellidos, sea del equipo interno o de un socio técnico externo que trabaje en white label. ### ¿Qué es lo primero que hay que arreglar? El control de acceso. Es la primera categoría del OWASP Top 10:2025 y es lo que una demo nunca enseña, porque en la demo solo hay un usuario. Después, los secretos expuestos y el flujo de pagos y accesos. ### ¿De quién es el código y los datos al final del proceso? Debe quedar claro por escrito antes de empezar: repositorio, base de datos, dominio y credenciales a nombre de la empresa que va a explotar el producto. Si el prototipo vive dentro de una plataforma cerrada, esa migración forma parte del trabajo de puesta en producción. ## Servicios relacionados - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. - [Partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/): Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Diferencia entre CRM y ERP: qué resuelve cada uno y cuándo necesitas los dos > Qué diferencia hay entre un CRM y un ERP, qué procesos cubre cada uno, por dónde empezar en un negocio digital y cómo conectarlos sin duplicar datos. - URL: https://fcgsystems.es/blog/diferencia-crm-erp/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Breakdown · Lectura: 7 min - Palabra clave: diferencia entre crm y erp (también: diferencia entre erp y crm, crm vs erp, que es un erp, crm y erp ejemplos) **Un CRM gestiona la relación con clientes y posibles clientes; un ERP gestiona los recursos internos de la empresa.** El CRM responde a "¿cómo va la venta?" y el ERP a "¿cómo va el negocio por dentro?": facturación, contabilidad, compras, inventario. No son competidores. Son dos fuentes de verdad distintas que, cuando el negocio crece, tienen que hablarse. La confusión es razonable, porque los dos guardan clientes y los dos se venden como "el sistema central de tu empresa". La diferencia está en qué proceso soporta cada uno y, sobre todo, en qué dato es dueño cada uno. ## ¿Qué diferencia hay entre un CRM y un ERP? | Criterio | CRM | ERP | |---|---|---| | Pregunta que responde | ¿Cómo va la captación y la venta? | ¿Cómo va la operación y el dinero? | | Procesos que cubre | Contactos, oportunidades, etapas, seguimiento, previsión de ventas | Facturación, contabilidad, compras, inventario, tesorería y, según el caso, nóminas o producción | | Quién lo usa a diario | Marketing, comerciales, atención al cliente | Administración, finanzas, operaciones, compras | | Dato del que es dueño | El contacto y la oportunidad: origen, responsable, etapa | El cliente facturable, el documento contable y el stock | | Momento del ciclo | Antes de la venta y durante la relación | Desde que hay pedido, factura o coste | | Cuándo suele implantarse | En cuanto entran leads por varios canales | Cuando la administración deja de caber en herramientas sueltas | | Coste de equivocarse | Leads sin atender, origen perdido, previsión irreal | Facturación descuadrada, stock erróneo, cierres contables a mano | Dicho de otra forma: el CRM trabaja con lo que **todavía no es dinero**, y el ERP con lo que **ya lo es**. ## ¿Qué hace un CRM exactamente? Un CRM es la fuente de verdad de la relación comercial. Guarda cada contacto con su origen, su responsable, su etapa y su historial, y permite responder sin abrir una hoja de cálculo a preguntas como cuántas oportunidades hay abiertas, qué canal trae ventas o qué lead lleva diez días sin que nadie lo toque. La versión larga, con las funciones una por una, está en [para qué sirve un CRM](https://fcgsystems.es/blog/que-es-un-crm/). Lo que suele resolver en un negocio digital: - Recoger leads de formularios, anuncios, webinars o mensajería en un único sitio. - Deduplicar antes de asignar, para que dos comerciales no llamen al mismo contacto. - Registrar el origen desde el primer contacto, que es lo que después permite atribuir la venta. - Mover la oportunidad por etapas con criterios de entrada claros. Si esa parte todavía vive en un Excel compartido, el problema concreto está descrito en [leads que se pierden entre el formulario y el comercial](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). Y si la duda es qué clase de CRM encaja con tu operación, los cuatro perfiles están en [tipos de CRM](https://fcgsystems.es/blog/tipos-de-crm/). ## ¿Qué hace un ERP exactamente? Un ERP integra los procesos administrativos y financieros en una única base de datos: facturas emitidas y recibidas, asientos contables, proveedores, compras, inventario, cobros y pagos. Su valor no está en ningún módulo concreto, sino en que el mismo dato no se teclee tres veces en tres sitios. En una empresa con almacén o producción el ERP es casi obligatorio. En un negocio digital sin stock físico, muchas veces lo que existe no es un ERP completo, sino su equivalente por piezas: una pasarela de pagos, un software de facturación y una asesoría que recibe los datos cada mes. Eso es perfectamente válido hasta que deja de serlo. ## ¿Un negocio digital necesita las dos cosas? Casi siempre empieza por el CRM, y con motivo: el primer dolor real es comercial, no contable. Estas son las señales de que hace falta también la capa de gestión. **Señales de que necesitas CRM (o uno mejor):** - Entran leads por más de un canal y nadie sabe cuántos hay ni quién los atiende. - No puedes decir con datos qué campaña trajo las últimas diez ventas. - El seguimiento depende de la memoria de una persona. - Cada informe comercial se monta a mano. **Señales de que necesitas ERP (o una capa de gestión de verdad):** - Hay inventario, compras a proveedores o costes por unidad que cuadrar. - Facturas en varias sociedades, países o monedas. - La conciliación entre lo que cobra la pasarela y lo que dice la contabilidad se hace a mano cada mes. - Administración vive de exportar CSV de cinco herramientas distintas. **Señales de que necesitas los dos, conectados:** - El comercial cierra una venta y alguien la vuelve a teclear para facturar. - Existen clientes en el CRM que no existen en facturación, o al revés. - Nadie puede decir, sin cruzar hojas, cuánto se ha facturado de verdad a los clientes que entraron por un canal concreto. - Ventas promete condiciones que administración descubre al emitir la factura. ## ¿Por dónde se empieza: CRM o ERP? Por donde se esté perdiendo dinero ahora mismo. En la mayoría de negocios digitales el orden sensato es: 1. **CRM primero.** Es donde se pierden leads y donde el retorno se ve antes. 2. **Facturación y cobros conectados.** Pasarela, software de facturación y accesos sincronizados con el estado del pago. 3. **ERP o capa de gestión** cuando la administración deja de caber: inventario, varias sociedades, muchos proveedores. Implantar un ERP para ordenar un problema comercial es caro y lento, y suele terminar con un ERP infrautilizado. Al revés también falla: exigirle al CRM que lleve la contabilidad acaba en informes que no cuadran con los del asesor. ## ¿Cómo se conectan un CRM y un ERP sin duplicar datos? Esta es la parte que decide si tener los dos sistemas suma o resta. Tres decisiones, en este orden: **1. Quién manda en cada dato.** El CRM suele ser dueño del contacto comercial y de la oportunidad; el ERP, del cliente facturable, la factura y el cobro. Un dato con dos dueños termina con dos versiones distintas y una discusión. **2. Qué identificador los une.** Hace falta una clave común y estable: el identificador del cliente en el ERP guardado en la ficha del CRM, o al revés. El email no sirve como clave única, porque cambia y se comparte. **3. Qué dispara la sincronización y qué pasa si falla.** Lo normal es que la oportunidad ganada cree o actualice el cliente en el ERP, y que el estado de cobro vuelva al CRM. Ese puente puede ser una integración nativa, una automatización con n8n o Make, o código propio, pero necesita registro de cada operación y aviso cuando algo no pasa. Ese tercer punto es donde más veces revienta en la práctica. No con un error rojo, sino en silencio: un cliente que se crea duplicado cada vez que se reabre la oportunidad, una factura que no vuelve al CRM y un comercial que llama a alguien que ya pagó. El patrón y cómo detectarlo está en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ## Errores comunes al decidir entre CRM y ERP - **Elegir un sistema que "lo haga todo" sin mirar qué módulo cubre cada proceso.** La suite completa suele ser fuerte en una mitad y floja en la otra. - **Implantar ERP para resolver un desorden comercial.** El desorden se muda de herramienta, más caro. - **Sincronizar en las dos direcciones sin decidir quién manda.** Es la receta segura para los duplicados. - **Usar el email como identificador único de cliente.** Dos personas de la misma empresa, un cambio de dominio y el cruce deja de funcionar. - **Conectar ambos sistemas sin logs.** Cuando alguien pregunte por qué falta una factura, no habrá forma de reconstruirlo. - **Dejar la decisión en manos del proveedor que te vende la licencia.** Cada uno dibujará el mapa con su producto en el centro. ## Checklist antes de decidir - Está escrito qué procesos son comerciales y cuáles administrativos, sin mezclarlos. - Sabemos qué sistema será dueño del contacto y cuál del cliente facturable. - Existe un identificador común y estable entre ambos. - Sabemos qué pasa cuando se gana una oportunidad: qué se crea, dónde y con qué datos. - Están definidas las reglas de deduplicación en los dos sistemas. - La integración tendrá registro de operaciones y aviso con responsable si falla. - Hemos calculado el coste con el volumen y el equipo de dentro de dos o tres años. - Hemos confirmado con la asesoría los requisitos legales del software que emite las facturas. ## ¿Cuándo conviene delegar esta decisión? Si el negocio es pequeño y la duda es solo qué CRM contratar, se resuelve con criterio propio: los criterios de elección están en [CRM para pymes y negocios digitales](https://fcgsystems.es/blog/crm-para-pymes-saas-o-a-medida/). Cuando ya hay dos o tres sistemas conviviendo, datos que no cuadran entre ventas y administración y una integración que nadie se atreve a tocar, esto deja de ser una compra de software y pasa a ser una decisión de arquitectura: qué sistema es dueño de qué dato y cómo viaja entre ellos. Es el trabajo de [arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/), y la parte del puente entre ambos suele resolverse con [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/) o, cuando la lógica es propia del negocio, con [software a medida](https://fcgsystems.es/servicios/software-a-medida/). Para ver cómo encaja esto con el resto de capas de la operación, empieza por [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/). Y si ahora mismo tenéis clientes en dos sitios y ninguna cifra que cuadre, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Qué son un ERP y un CRM, con ejemplos? El CRM gestiona la relación comercial: contactos, oportunidades, etapas de venta y seguimiento. El ERP gestiona los recursos de la empresa: facturación, contabilidad, compras, inventario y, según el caso, nóminas o producción. Un ejemplo: el CRM sabe que una academia tiene 300 oportunidades abiertas; el ERP sabe cuánto se facturó el mes pasado y qué facturas siguen sin cobrar. ### ¿Es SAP un CRM o un ERP? SAP es un fabricante de software empresarial conocido sobre todo por su ERP, y comercializa además productos del ámbito CRM. Pasa lo mismo con otros grandes proveedores: no hay que fijarse en la marca, sino en qué módulo concreto se contrata y qué procesos cubre. La pregunta útil no es si una marca es CRM o ERP, sino qué sistema va a ser la fuente de verdad de cada dato. ### ¿Necesito un ERP si ya tengo un CRM? No por defecto. Un negocio digital pequeño suele funcionar bien con CRM, una pasarela de pagos y un software de facturación conectado a la asesoría. El ERP empieza a tener sentido cuando hay inventario, compras, varias sociedades o líneas de negocio, o cuando la contabilidad y la facturación ya no caben en herramientas sueltas. ### ¿Puede un CRM hacer facturas? Muchos CRM permiten emitir presupuestos y facturas o integrarse con un software que lo haga. Eso cubre casos sencillos, pero no sustituye a la contabilidad ni a las obligaciones de registro de facturación. Antes de decidirlo conviene confirmar con tu asesoría qué requisitos legales debe cumplir el software que emite tus facturas. ### ¿Cómo se conectan un CRM y un ERP? Por API o por una automatización intermedia, decidiendo antes qué sistema manda en cada dato: normalmente el CRM en el contacto comercial y el ERP en el cliente facturable. Hace falta un identificador común, reglas de deduplicación y un registro de qué se sincronizó, porque el error típico no es que la integración se caiga, sino que duplique clientes sin que nadie lo vea. ## Servicios relacionados - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # El caos técnico no aparece en la cuenta de resultados hasta que ya es tarde > El desorden técnico no tiene una línea propia en tus cuentas: se reparte en cobros que fallan, accesos mal dados y horas a mano. Cómo ponerle número. - URL: https://fcgsystems.es/blog/caos-tecnico-coste-invisible/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Opinión · Lectura: 4 min - Palabra clave: coste del caos técnico (también: deuda técnica en negocios digitales, dinero que se pierde por procesos manuales, cobros fallidos sin detectar) Nadie ha puesto nunca una línea llamada "desorden técnico" en una cuenta de resultados. Por eso se paga durante años sin verla. Un negocio digital con caos por dentro no da señales de alarma contables. Factura. Los clientes entran. El equipo trabaja. Los números del mes se parecen a los del mes anterior. Y mientras tanto hay dinero saliendo por sitios que nadie mira, porque ese dinero no sale: simplemente nunca llega. Esa es la trampa. Un gasto se ve. Un ingreso que no ocurrió no se ve. ## Las fugas no hacen ruido Piensa en las tres más comunes en negocios de suscripción, membresía o formación online. **Los cobros que fallan.** Una tarjeta caduca, un banco rechaza una renovación, el proveedor de pago reintenta un par de veces y se rinde. El cliente no se entera de nada. Tú tampoco. Ese cliente sigue con acceso, sigue consumiendo soporte y ha dejado de pagar. La contabilidad lo registra como un cliente menos, no como un problema técnico. Lo he visto en varios sitios y siempre con el mismo gesto de sorpresa cuando lo pones en una tabla. Si quieres el detalle técnico de ese caso concreto, lo desarrollo en [pagos fallidos y acceso a cursos](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/). **Los accesos que nadie revoca.** Gente dentro que ya no debería estar. Antiguos alumnos, cuentas de prueba, colaboradores de un lanzamiento de hace dos años. Si el acceso se concede a mano, se revoca a mano, y lo que se hace a mano se olvida. Aquí la pérdida es doble: consumo de plataforma que pagas y producto que regalas. **El trabajo manual que ya está pagado.** Alguien de tu equipo copia registros de un formulario a una hoja, de la hoja al CRM y del CRM a la plataforma de email. Esa persona cobra igual haga eso o haga algo que genere dinero. No hay ninguna factura que diga "4 horas semanales de copiar y pegar". Hay un coste de oportunidad silencioso que no aparece en ningún sitio. El caso de los leads que se quedan en una hoja lo cuento en [leads perdidos en Excel](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). Ninguna de las tres dispara una alerta. Ninguna de las tres tiene un responsable claro. Y las tres crecen exactamente al mismo ritmo que el negocio. ## Por qué se descubre tarde Porque el caos técnico escala mejor que el orden. Suena raro, pero es así. Cuando facturas poco, el desorden se compensa con atención. Tú mismo miras los pagos, tú mismo das los accesos, tú te acuerdas de quién es quién. Funciona. El problema es que ese método no se rompe de golpe: se degrada. Cada mes se te escapa un poco más, y como el mes anterior también se te escapó un poco, no notas la diferencia. El día que lo ves suele ser un día malo. Un cierre de cuentas que no cuadra. Un cliente enfadado porque lleva medio año pagando algo a lo que perdió el acceso. Una migración de plataforma en la que descubres que nadie sabe cuál de las tres listas de clientes es la buena. Ahí es cuando el coste aparece entero y de golpe. Y lo que estás pagando ese día no es el problema de ese día: es la factura acumulada de dos años de no mirar. ## Ponerle número no es difícil No hace falta una auditoría de tres semanas para saber si tienes esto. Hacen falta tres preguntas que puedes responder esta tarde. - **¿Cuántos cobros fallaron el mes pasado y cuántos recuperaste?** Si no puedes responder con un número, ya tienes la respuesta. - **¿Cuántos accesos se conceden o se quitan a mano cada semana?** Multiplica por las semanas del año y mira el número resultante sin apartar la vista. - **¿Cuántas horas del equipo se van en mover datos de una herramienta a otra?** No preguntes por herramientas, pregunta por tareas. Eso no es una métrica fina y no pretende serlo. Es un orden de magnitud. Y un orden de magnitud basta para decidir si esto merece una semana de trabajo o no. ## Lo que se arregla primero Mi orden, y lo digo desde haber cambiado de opinión un par de veces: primero ver, después automatizar. Antes de montar nada, escribe el inventario. Qué sistema cobra. Qué sistema da acceso. Qué sistema guarda al cliente. Dónde vive el dato bueno de cada cosa. Suena a deberes aburridos y es el paso que más problemas resuelve, porque la mayoría de las fugas no vienen de una herramienta mala, vienen de que nadie sabe cuál manda. Después, alertas. Un cobro que falla tiene que avisar a una persona. Un acceso que caduca tiene que avisar a un sistema. Si algo importante puede fallar sin que nadie se entere, no tienes un proceso: tienes una apuesta. Cómo se construye esa vigilancia lo explico en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). Y solo entonces, automatizar. Automatizar un proceso que no entiendes multiplica el desorden en vez de eliminarlo, y encima lo hace más rápido. ## El punto incómodo El caos técnico no es un problema de tecnología. Es un problema de visibilidad. Un negocio que no puede responder "¿qué está pasando ahora mismo por dentro?" no está tomando decisiones: está reaccionando a las que ya se tomaron solas. Y cuando por fin llega la factura, no llega en forma de incidencia. Llega en forma de mes malo que nadie sabe explicar. Si algo se te escapa, es porque no lo sabes. Arreglar eso es más barato hoy que el año que viene, y mucho más barato que el día que se rompa. ## Preguntas frecuentes ### ¿Cómo puedo estimar lo que me cuesta el desorden técnico? Coge tres números que ya tienes: cuántas suscripciones fallan al mes y cuántas se recuperan, cuántos accesos concedes o revocas a mano, y cuántas horas dedica tu equipo a mover datos entre herramientas. No necesitas una auditoría para ver el orden de magnitud, necesitas mirar esos tres sitios. ### ¿Por qué el caos técnico no se ve en la contabilidad? Porque no genera una factura. Un cobro que falla y nadie reclama no aparece como pérdida, aparece como ingreso que nunca existió. Una hora de trabajo manual está ya pagada dentro de una nómina. El desorden no encarece tus gastos, adelgaza tus ingresos, y eso es mucho más difícil de notar. ### ¿Por dónde empiezo si sospecho que tengo este problema? Por el inventario, no por la herramienta. Escribe qué sistemas cobran, qué sistemas dan acceso y qué sistemas guardan clientes, y marca dónde vive el dato bueno de cada cosa. La mitad de los problemas se explican solos cuando ves ese mapa escrito por primera vez. ## Servicios relacionados - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # El piloto de IA que nunca llega a producción: por qué la demo funciona y el sistema no existe > Por qué tantas pruebas de IA se quedan en demo eterna, qué separa un piloto de un sistema en producción y qué exijo antes de dar por buena una prueba. - URL: https://fcgsystems.es/blog/el-piloto-de-ia-que-nunca-llega-a-produccion/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: IA aplicada · Formato: Opinión · Lectura: 5 min - Palabra clave: piloto de ia en producción (también: prueba de concepto ia, ia en producción, por qué fallan los proyectos de ia) La prueba de IA funcionó. Por eso lleva siete meses siendo una prueba. He visto la misma escena lo suficiente como para reconocerla por el olor. Alguien del equipo monta en dos tardes algo que clasifica los correos de soporte, o que resume las llamadas de ventas, o que redacta el primer borrador de una respuesta. Lo enseña en una reunión. Todo el mundo asiente. Se aprueba seguir. Y medio año después eso sigue siendo exactamente lo mismo: un script que una persona ejecuta a mano los martes, con un archivo que se pasa por WhatsApp. Nadie lo llama fracaso. Y ese es el problema, porque un fracaso se entierra y se aprende. Una demo eterna se mantiene con vida, consume atención cada trimestre y ocupa el hueco del proyecto que sí habría cambiado algo. ## Una demo y un sistema no se parecen en nada Una demo tiene que funcionar una vez, delante de gente, con datos que eliges tú. Un sistema tiene que funcionar todos los días, sin que nadie mire, con los datos que le lleguen. Son dos problemas distintos, y el segundo no es "el primero pero más grande". La demo se construye eligiendo veinte casos que representan bien el problema. Producción no elige: te manda el correo reenviado tres veces con una firma corporativa de cuarenta líneas, el PDF escaneado torcido, el cliente que escribe en tres idiomas en el mismo párrafo y el registro que viene con el campo de teléfono vacío porque alguien renombró el formulario el jueves. Ahí es donde revienta. No por el modelo. Por todo lo de alrededor. Lo que separa una cosa de la otra casi nunca es la parte de IA: - **Dónde entran los datos y dónde salen.** Un piloto vive de copiar y pegar. Un sistema necesita que el dato entre solo y aterrice en el sitio donde el equipo ya trabaja: el CRM, el ticket, la ficha del cliente. Si el resultado acaba en un documento que hay que abrir aparte, no lo abrirá nadie. - **Qué pasa cuando falla.** Y va a fallar. La API caerá, el modelo devolverá algo raro, el documento vendrá vacío. Un piloto se queda colgado y ya. Un sistema reintenta, registra y avisa a alguien con nombre y apellidos. - **Cómo sabes que sigue acertando.** Un piloto se valida a ojo la semana que se construye. Un sistema necesita una medida: sobre una muestra fija, cuántas veces acierta y cuántas no. Sin eso no puedes saber si ha empeorado. - **Quién es el dueño.** El piloto lo lleva el que lo montó, en sus ratos. Producción necesita a alguien responsable de que funcione, con tiempo asignado para ello. - **Qué decide el modelo y qué no.** Esto es lo que más se salta. Un piloto puede permitirse que el modelo "decida" porque hay un humano revisando cada salida. En producción, cualquier cosa que toque accesos, cobros o precios tiene que decidirla código determinista. Hablo de eso largo y tendido en [cómo se construyen agentes sin perder el control](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/). Ninguno de esos cinco puntos es "más inteligencia". Son fontanería, contabilidad y responsabilidad. Aburrido. Por eso no sale en las demos. ## Por qué pasa: el piloto se diseñó para convencer, no para funcionar Esta es la parte incómoda. Muchos pilotos de IA no se montan para resolver un proceso. Se montan para conseguir un sí en una reunión. Y cuando el objetivo es convencer, tomas decisiones distintas sin darte cuenta: eliges el caso de uso que mejor se ve, no el que más duele; trabajas con datos limpios, no con los reales; enseñas el resultado, no la tasa de acierto. Todo eso es legítimo para explorar. El error es creer que lo que has construido es un principio de sistema, cuando en realidad es una maqueta que se ha quedado sin camino por delante. Hay un segundo motivo, más prosaico. Casi nadie pone en el presupuesto inicial lo que cuesta llevar algo a producción. Se aprueba el piloto porque es barato. Y cuando llega la factura de verdad (integraciones, permisos, logs, alertas, el proceso de revisión, el dueño), el proyecto se compara con su propia versión barata y parece caro. Así que se queda donde está, en la demo, que al menos ya está pagada. ## Qué hago yo en su lugar Antes de tocar nada, pongo por escrito una frase: **qué proceso deja de hacerse a mano si esto funciona**. Una frase, con un nombre de proceso real y una persona que hoy lo hace. Si no soy capaz de escribirla, el piloto no es un piloto, es una curiosidad. Y las curiosidades se hacen un viernes, no con presupuesto. Después, el piloto se prueba contra los datos feos. Los de verdad, los del mes pasado, con las firmas, los reenvíos y los campos vacíos. Si la tasa de acierto sobre una muestra real no te vale, mejor saberlo la primera semana que después de firmar tres meses de desarrollo. Y en el diseño, los caminos de vuelta antes que el camino de ida. Qué pasa si el modelo no responde. Qué pasa si responde una cosa que no encaja en el formato esperado. Quién recibe el aviso. Esto es lo mismo que exijo a cualquier automatización, con IA o sin ella: [un proceso que puede fallar en silencio no está terminado](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). Lo que queda casi siempre es más pequeño de lo que se aprobó en la reunión. Un trozo del proceso, no el proceso entero. Pero ese trozo sí entra en producción, sí se mide y sí se puede ampliar. Un sistema pequeño funcionando le gana a un sistema grande imaginado, todos los días de la semana. El criterio que te llevas es este: un piloto no se evalúa por lo bien que sale en la demo, sino por lo cerca que está de aguantar un martes cualquiera sin que nadie lo mire. Si nadie ha respondido a "quién lo arregla cuando falla", todavía no estás construyendo. Y construir sin entender es fracaso con buena pinta. ## Servicios relacionados - [Sistemas de IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Facturación electrónica obligatoria: qué sistemas tuyos tienen que hablar entre sí > Qué es la facturación electrónica obligatoria en España, qué plazos marca el Real Decreto 238/2026 y cómo integrarla con tu CRM, tus pagos y tus altas. - URL: https://fcgsystems.es/blog/facturacion-electronica-integracion/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Automatización · Formato: Arquitectura · Lectura: 8 min - Palabra clave: facturacion electronica (también: que es facturacion electronica, facturacion electronica obligatoria, facturas verifactu, factura electrónica B2B, Real Decreto 238/2026) La facturación electrónica obligatoria es la exigencia de que las facturas entre empresas y profesionales se emitan, se envíen y se reciban en un formato estructurado que las máquinas puedan leer, a través de plataformas que cumplen unos requisitos técnicos. No es enviar un PDF por email: es que la factura viaje como dato, con su ciclo de vida registrado. Y ese matiz es todo el problema. Porque si la factura deja de ser un documento que alguien redacta y pasa a ser un dato que circula, la pregunta deja de ser "¿qué programa de facturas compro?" y pasa a ser **"¿qué sistemas míos tienen que hablar entre sí para que la factura salga sola y con los datos correctos?"**. Esa es la parte de la que casi nadie habla, y es la que te va a costar dinero si la dejas para el final. Este artículo va de eso. **No es asesoramiento fiscal**: en FCG Systems integramos sistemas, no llevamos tu contabilidad. Para saber qué te obliga y desde cuándo, tu asesor. ## Las dos obligaciones que se están mezclando Antes de tocar nada conviene separar dos cosas que circulan juntas y no lo son: | | Verifactu (RRSIF) | Factura electrónica B2B | |---|---|---| | **Qué regula** | Cómo se comporta el software que emite la factura | En qué formato viaja la factura hasta el destinatario | | **Norma** | Real Decreto 1007/2023 y Orden HAC/1177/2024 | Ley 18/2022 (art. 12) y Real Decreto 238/2026 | | **Exige** | Registro de facturación, huella encadenada, firma o envío a la AEAT, log de eventos, QR | Sintaxis estructurada, plataforma de intercambio, comunicación de estados | | **Fechas** | 1 de enero de 2027 (Sociedades) · 1 de julio de 2027 (resto) | 12 y 24 meses desde la orden ministerial de la solución pública | Son obligaciones acumulativas. Cumplir una no te libra de la otra. Si lo que te interesa ahora es la primera, la tienes desarrollada en [qué es Verifactu y qué tiene que hacer tu software](https://fcgsystems.es/blog/verifactu-que-es/). ## Qué dice la norma de la factura electrónica, con fuentes El punto de partida es el artículo 12 de la **Ley 18/2022, de 28 de septiembre**, la llamada "Crea y Crece", que extendió a todas las relaciones entre empresas y profesionales la obligación de factura electrónica que hasta entonces solo existía frente a la Administración. Su desarrollo reglamentario es el **[Real Decreto 238/2026, de 25 de marzo](https://www.boe.es/buscar/act.php?id=BOE-A-2026-7295)**, publicado en el BOE el 31 de marzo de 2026. La Agencia Tributaria lo resume en su ficha de [novedades de normativa](https://sede.agenciatributaria.gob.es/Sede/iva/novedades-iva/novedades-normativa-2026/real-decreto-238-2026-25-marzo.html) (consultado en septiembre de 2026). Lo que fija, en lo que nos afecta: - **Plazos.** Doce meses para empresarios y profesionales cuyo volumen de operaciones haya excedido de 8 millones de euros, y veinticuatro meses para el resto. Ambos se cuentan **desde la entrada en vigor de la orden ministerial que desarrolle la solución pública de facturación electrónica**, no desde la publicación del real decreto. - **Sintaxis admitidas.** CII, UBL, EDIFACT y Facturae. Los mensajes Peppol BIS se consideran válidos porque emplean UBL, que además es la sintaxis de referencia de la solución pública. - **Estados obligatorios.** El destinatario debe informar de la aceptación o rechazo comercial de la factura y del pago efectivo completo, con sus fechas, en un plazo máximo de cuatro días naturales, excluyendo sábados, domingos y festivos. El pago efectivo completo se comunica siempre a la solución pública, uses la plataforma que uses. - **Solución pública.** La AEAT pondrá a disposición una herramienta gratuita para emitir facturas electrónicas y comunicar estados, disponible antes de la aplicación efectiva. A septiembre de 2026 la orden ministerial que dispara el cómputo sigue siendo el hito a vigilar. Conviene comprobarlo en la sede de la AEAT antes de fijar ninguna fecha interna: esto es normativa en curso y se ha movido más de una vez. ## Lo que la norma te obliga a tener, dicho en arquitectura Traduce los cuatro puntos anteriores a requisitos de sistema y aparece esto: 1. **Un emisor único de facturas fiscales.** Un sistema, no tres. 2. **Datos maestros de cliente fiables.** NIF correcto, razón social, dirección y, ahora, la dirección electrónica a la que se le entrega la factura. 3. **Una conexión con una plataforma de intercambio** (o con la solución pública) capaz de emitir en una de las sintaxis admitidas. 4. **Un canal de vuelta.** Los estados no son informativos: hay que capturarlos, guardarlos y responder en plazo. Esto es lo que rompe el modelo de "facturo y me olvido". 5. **Trazabilidad.** Qué se emitió, cuándo, en qué estado está y quién lo cambió. El punto 4 es el que cambia la naturaleza del problema. Hasta ahora una factura era un documento que salía. Ahora es un **objeto con ciclo de vida** que recibe eventos externos con plazo de respuesta. Eso es, literalmente, una integración con webhooks y cola de trabajo, no una plantilla de Word. ## Dónde se rompe esto en un negocio real Si tu negocio vende online, las facturas no nacen en el programa de facturación. Nacen mucho antes, en sitios distintos: - **En la pasarela de pago**, cuando alguien compra con tarjeta. - **En la plataforma de suscripciones**, cada renovación mensual. - **En el CRM**, cuando el equipo comercial cierra una venta y se factura por transferencia. - **En la plataforma de cursos o membresía**, con altas, bajas y cambios de plan. - **A mano**, en los casos raros que siempre existen. Y aquí es donde aparecen los fallos que ya he visto varias veces: - **Numeración duplicada.** Dos sistemas emitiendo con la misma serie porque nadie decidió cuál manda. - **Cliente sin NIF.** La compra online se hace con un email y el NIF se pide después, o no se pide. Cuando llega el momento de emitir la factura estructurada, falta un dato obligatorio y el proceso se para. - **El mismo cliente dos veces.** Identificado por email en un sistema y por NIF en otro. Cuando el email cambia, aparece un cliente nuevo. - **La baja que no llega.** El cliente cancela en la plataforma, pero la suscripción sigue viva en la pasarela y se factura un mes más. Devolución, rectificativa y una conversación incómoda. - **El estado que nadie escucha.** El destinatario rechaza la factura, el webhook llega, nadie lo procesa y el plazo pasa. Ninguno de estos es un problema de normativa. Son problemas de integración que la normativa convierte en visibles y con plazo. Es el patrón de siempre: los errores que [fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/) dejan de ser silenciosos cuando alguien externo empieza a mirar. ## Cómo se monta para que la factura salga sola El diseño que aplico, y que no depende de qué herramientas uses: ### 1. Decide la fuente de verdad de cada cosa Tres fuentes, tres dueños: | Dato | Fuente de verdad | |---|---| | Estado del cobro | La pasarela de pago | | Identidad fiscal del cliente | El CRM o el ERP | | Factura y su numeración | El software de facturación | Si dos sistemas se disputan un dato, ya tienes el bug. Es la misma regla que aplico a los accesos por suscripción en [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/): quien manda sobre un dato es uno solo, el resto lo reflejan. ### 2. Captura la identidad fiscal en el momento de la compra, no después Si vendes a empresas, el NIF y la razón social son campos del checkout, no un email de seguimiento tres días después. Cualquier dato fiscal que se pida a posteriori se convierte en trabajo manual para alguien. ### 3. Relaciona los sistemas por identificador, nunca por email Guarda el identificador de cliente de la pasarela en la ficha del CRM y en la del software de facturación desde la primera compra. El email cambia, se escribe distinto o se usa uno para pagar y otro para acceder. Un identificador estable es lo único que aguanta. ### 4. Dispara la factura con un evento, no con una persona El cobro confirmado genera un evento; ese evento crea la factura. Con tres reglas que evitan la mayoría de los desastres: - **Idempotencia.** El mismo evento dos veces no puede generar dos facturas. Guarda el identificador del evento procesado. - **Sin depender del orden.** Ante cualquier evento, consulta el estado actual en la fuente de verdad y decide con ese dato. - **Cola con reintentos.** Si el software de facturación no responde, el evento se reintenta; no se pierde. ### 5. Escucha los estados y responde en plazo Los estados que vuelven (aceptado, rechazado, pagado) entran por el mismo tipo de canal y con la misma disciplina: verificación, idempotencia, registro y, cuando hace falta, aviso a un responsable con nombre. Cuatro días hábiles no dan para descubrir el lunes que el viernes llegó un rechazo. ### 6. Reconcilia todos los días Una vez al día, compara cobros confirmados con facturas emitidas y facturas emitidas con estados recibidos. Cualquier diferencia es un fallo, aunque ninguna herramienta haya marcado error. Es la comprobación que más problemas destapa, y la que casi nadie monta. ### 7. Deja traza de todo Qué evento entró, qué factura se generó, qué estado se comunicó y cuándo. Sin log no hay forma de responder a "¿por qué a este cliente se le facturó dos veces en marzo?". ## Checklist antes de que empiecen a correr los plazos - Inventario de todos los sistemas desde los que hoy sale una factura. - Decidido cuál es el emisor único de facturas fiscales. - Declaración responsable del proveedor de ese software (requisito de Verifactu). - Plataforma de intercambio elegida, o solución pública, con la sintaxis que vas a emitir. - NIF y razón social capturados en el checkout para las ventas B2B. - Identificador de cliente compartido entre pasarela, CRM y facturación. - Emisión disparada por evento, idempotente y con reintentos. - Estados entrantes procesados y respondidos dentro del plazo. - Reconciliación diaria entre cobros, facturas y estados. - Log por factura y un responsable que recibe los avisos. - Fechas confirmadas en la sede de la AEAT, no en un artículo de blog (este incluido). ## Dónde acaba el asesor y empieza el sistema Tu asesor decide si te aplica, desde cuándo y con qué implicaciones fiscales. Ese reparto no lo discuto. Lo que ninguna asesoría te va a montar es que tu pasarela, tu CRM, tu plataforma y tu software de facturación intercambien datos sin que nadie copie nada a mano. Eso es integración, y es donde está el trabajo real: eventos, identificadores estables, idempotencia, reintentos, reconciliación y trazas. Es un proyecto típico de [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/), con diseño, integración, pruebas y documentación; y cuando lo que tienes no encaja con ninguna herramienta del mercado, de [software a medida](https://fcgsystems.es/servicios/software-a-medida/). Si no sabes con certeza desde cuántos sitios salen hoy tus facturas ni con qué datos, [cuéntame cómo está montada tu operativa](https://fcgsystems.es/contacto/) y lo revisamos. ## Preguntas frecuentes ### ¿Qué es la facturación electrónica obligatoria? Es la obligación de emitir y recibir las facturas entre empresas y profesionales en un formato estructurado que las máquinas puedan leer, intercambiado a través de plataformas que cumplen unos requisitos técnicos. Nace del artículo 12 de la Ley 18/2022 y se desarrolla en el Real Decreto 238/2026. Un PDF enviado por email no es una factura electrónica a estos efectos. ### ¿Cuándo entra en vigor la factura electrónica obligatoria entre empresas? El Real Decreto 238/2026 fija doce meses para empresarios y profesionales con volumen de operaciones superior a 8 millones de euros y veinticuatro meses para el resto, contados desde la entrada en vigor de la orden ministerial que desarrolle la solución pública de facturación electrónica. A septiembre de 2026 esa orden marca el inicio del cómputo, así que las fechas concretas dependen de su publicación. ### ¿Es lo mismo la factura electrónica que Verifactu? No. Verifactu regula cómo tiene que comportarse el software que emite tus facturas: registro inmutable, huella encadenada y envío a la Agencia Tributaria. La factura electrónica obligatoria regula el formato estructurado en el que la factura viaja hasta tu cliente y los estados que hay que comunicar. Son dos obligaciones distintas y hay que cumplir las dos. ### ¿Qué formatos de factura electrónica se admiten? El Real Decreto 238/2026 admite cuatro sintaxis: CII, UBL, EDIFACT y Facturae. Los mensajes en formato Peppol BIS se consideran válidos en la medida en que emplean la sintaxis UBL. La sintaxis de referencia para la solución pública es UBL. ### ¿Qué tengo que comunicar además de la factura? El Real Decreto 238/2026 obliga al destinatario a informar de la aceptación o rechazo comercial de la factura y de su pago efectivo completo, con sus fechas, en un plazo máximo de cuatro días naturales excluyendo sábados, domingos y festivos. El pago efectivo completo hay que comunicarlo siempre a la solución pública, sea cual sea la plataforma que uses. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Funnel de ventas: las etapas y las piezas técnicas que lo hacen medible > Qué es un funnel de ventas, cuáles son sus etapas y qué pieza técnica necesita cada una para que el embudo se pueda medir y operar sin cifras inventadas. - URL: https://fcgsystems.es/blog/funnel-de-ventas-sistema/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Arquitectura · Lectura: 13 min - Palabra clave: funnel de ventas (también: embudo de ventas, etapas del embudo de ventas, embudo de ventas ejemplo) Un **funnel de ventas** es el recorrido de una persona desde que conoce tu negocio hasta que compra, dividido en etapas medibles. Funnel y **embudo de ventas** son la misma cosa: funnel es simplemente la palabra inglesa para embudo. Lo que separa un embudo útil de un dibujo bonito no es el número de etapas, sino que cada una tenga un criterio de entrada claro y una pieza técnica que permita contar cuántas personas la cruzan. Casi todo lo que se publica sobre el tema se queda en el diagrama: cuatro etapas, unos iconos y la recomendación de "optimizar cada fase". El problema que veo en los negocios con los que trabajo no es que desconozcan las etapas. Es que no pueden medirlas. El funnel existe en una diapositiva y las cifras salen de tres herramientas que no se ponen de acuerdo. Este artículo cubre las etapas, porque hacen falta, pero dedica el peso a la parte que nadie explica: qué tiene que existir en vuestros sistemas para que el embudo se pueda medir y operar. ## ¿Qué es un funnel de ventas y por qué se dibuja como un embudo? Se dibuja como un embudo por una razón geométrica: entran muchas personas por arriba y solo una parte llega abajo. En cada paso se pierde gente, y esa pérdida es normal. El embudo no es un objetivo de diseño, es una constatación. La utilidad del modelo es diagnóstica. Si solo miras las ventas del mes, cuando bajan no sabes por qué. Si mides cada etapa, puedes ver que el tráfico es el mismo, que los registros son los mismos y que lo que cayó fue la asistencia a la sesión. Eso ya es una hipótesis accionable. Verás también los términos embudo de conversión, embudo comercial o pipeline. Hay matices entre ellos (el pipeline suele referirse a la parte que gestiona el equipo comercial, no al tráfico frío), pero en la práctica se usan de forma intercambiable. No merece la pena discutir el vocabulario: merece la pena acordar qué etapas usa vuestro equipo y qué significa cada una. ## ¿Cuáles son las etapas del embudo de ventas? Lo primero, con honestidad: el número de etapas es una convención, no una ley. La versión de cuatro etapas viene del modelo AIDA, formulado a finales del siglo XIX para describir la publicidad impresa. La de cinco suele añadir fidelización al final. Hay quien usa siete. Ninguna es más correcta que otra. | Modelo | Etapas | De dónde viene | |---|---|---| | Cuatro etapas (AIDA) | Atención, interés, deseo, acción | Modelo publicitario clásico, el más citado | | Tres bloques (TOFU, MOFU, BOFU) | Parte alta, media y baja del embudo | Vocabulario de marketing de contenidos | | Cinco etapas | Las cuatro anteriores más fidelización o recompra | Añade el ciclo de vida posterior a la venta | | Etapas operativas | Las que usa vuestro equipo comercial de verdad | Se escriben a partir de cómo vendéis | La única columna que importa para operar es la última. Un criterio práctico: **una etapa merece existir si cambia lo que hace alguien del equipo y si se puede contar cuántas personas entran en ella**. Si nadie actúa distinto cuando un lead pasa de "interés" a "deseo", y nadie sabe decir cuántos hay en cada una, esas dos etapas son una sola. En un negocio digital, unas etapas operativas típicas serían: visita, registro, asistencia a la sesión, llamada agendada, llamada realizada, venta. Se parecen poco a AIDA y sirven mucho más, porque cada una tiene un hecho verificable detrás. ## Qué pieza técnica necesita cada etapa para ser medible Aquí está el fondo del asunto. Un embudo se mide cuando cada etapa deja un registro que se puede contar y cruzar con las demás. Esta es la correspondencia que uso al diseñar un sistema comercial: | Etapa | Qué se mide | Qué pieza lo hace posible | |---|---|---| | Visita / tráfico | Sesiones por fuente y campaña | Convención de UTMs escrita y analítica configurada, con los parámetros intactos tras cada redirección | | Registro | Leads nuevos por origen | Formulario con campos ocultos de fuente, medio, campaña y página de entrada | | Lead único | Personas reales, no filas | Deduplicación por email y teléfono normalizados, **antes** de asignar | | Lead asignado | Cuántos tienen dueño y cuándo lo tuvieron | Regla de asignación en el CRM con propietario único y marca de tiempo | | Contacto / cualificación | Intentos, respuestas y descartes con motivo | Estados en el CRM con un responsable y un motivo de descarte cerrado, no texto libre | | Reunión o llamada | Agendadas frente a realizadas | Agenda vinculada al lead existente, no a un contacto nuevo | | Venta | Ingresos atribuibles a su origen | Pago cruzado con el lead por email normalizado o por un identificador propio | | Conjunto | Que las cifras cuadren entre sí | Un evento por etapa con el mismo nombre en analítica y en CRM, y una conciliación periódica | Cada fila es un punto donde el dato se rompe con frecuencia. Vamos por las cuatro que más problemas dan. ### El origen se captura en el formulario, no después Es el fallo más caro y el más barato de arreglar. El formulario guarda nombre, email y teléfono, pero no guarda de dónde viene la persona. La analítica sabe que alguien llegó de una campaña; el CRM tiene a la persona sin origen. Los dos datos ya no se vuelven a juntar. La solución son campos ocultos que se rellenan al cargar la página con los parámetros de la URL, y que se conservan durante la visita porque casi nadie se registra en la primera página que ve. Ese valor viaja con el lead hasta la venta. Si no se captura ahí, ningún informe posterior lo puede reconstruir. El recorrido completo de esa pérdida, paso a paso, está en [por qué GA4, Meta y tu CRM nunca dan la misma cifra](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/). ### La deduplicación va antes de la asignación Una persona que se registra dos veces son dos filas y, si el reparto ya ha ocurrido, dos comerciales llamando a la misma persona. Además, el embudo cuenta dos registros donde hay uno, con lo que la tasa de paso a la siguiente etapa sale peor de lo que es. Deduplicar significa decidir tres cosas y escribirlas: cómo se normaliza el email (minúsculas, sin alias), cómo se normaliza el teléfono (prefijo internacional, sin espacios ni guiones) y qué gana cuando hay conflicto. Sobre el origen, mi recomendación es conservar el primero y añadir el último en un campo aparte, nunca sobrescribir. ### Cada lead tiene un dueño y una marca de tiempo Sin propietario, una etapa no se puede operar: nadie sabe de quién es la responsabilidad. Sin marca de tiempo, no se puede medir lo único que casi siempre mueve la aguja en la parte baja del embudo, que es cuánto tarda el equipo en contactar. Esto vive en el CRM, no en una hoja de cálculo compartida. El motivo no es esnobismo de herramientas: una hoja no impone propiedad ni deja historial de quién cambió qué. Cuándo deja de servir y cómo se hace el cambio sin parar las ventas está en [leads que se pierden entre el formulario y el comercial](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/), y qué exigirle al CRM antes de elegirlo, en [CRM para pymes y negocios digitales](https://fcgsystems.es/blog/crm-para-pymes-saas-o-a-medida/). Cuando entran más leads de los que el equipo puede atender bien, a la propiedad y a la marca de tiempo se les suma una tercera decisión: el orden. Eso ya es priorización, y cómo se monta sin inventarse una puntuación lo cuento en [lead scoring con reglas o con IA](https://fcgsystems.es/blog/lead-scoring-reglas-o-ia/). ### Los motivos de descarte son una lista cerrada Si el campo "por qué no compró" es texto libre, en seis meses tendréis doscientas respuestas distintas y ningún informe. Con una lista cerrada de cinco o seis motivos (precio, momento, no cualifica, no contesta, competencia, otro) el embudo empieza a explicar sus propias fugas. Es una decisión de diez minutos que cambia la calidad del análisis durante años. ## ¿Por qué las cifras de cada etapa no cuadran entre herramientas? Porque cada herramienta cuenta cosas distintas con reglas distintas. La analítica web cuenta sesiones que ha podido medir. La plataforma de anuncios cuenta conversiones que se atribuye según sus propias ventanas. El CRM cuenta personas. Que difieran es lo normal. Lo que no es normal es no saber cuál manda. Para decidir presupuesto, la fuente de verdad es el CRM o la base de datos donde vive el lead, porque es la única que une quién es la persona, de dónde vino y si compró. La analítica sigue siendo útil para entender el comportamiento en la web, y la plataforma de anuncios para optimizar dentro de sí misma. Son trabajos distintos y no conviene mezclarlos. Cuadrar al 100 % no es un objetivo realista. Sí lo es esto: que cada mes alguien compare el recuento de registros del CRM con el de la analítica y sepa explicar la diferencia. Cuando esa diferencia cambia de golpe, normalmente se ha roto una integración. ## ¿Cómo se define un evento por etapa? Un evento es el registro de que algo ocurrió. Para que el embudo sea medible de punta a punta, cada etapa necesita el suyo, y todos deben cumplir cuatro condiciones. **Un nombre único y compartido.** El mismo identificador en la analítica y en el CRM. Si en GA4 el evento se llama `lead_registrado` y en el CRM la etapa es "Registro", nadie podrá cruzarlos sin una tabla de traducción que alguien mantendrá mal. Google publica su lista de [eventos recomendados en GA4](https://support.google.com/analytics/answer/9267735) (consultado en septiembre de 2026); usarla cuando encaja ahorra discusiones. **Un identificador de persona.** El evento tiene que llevar consigo el email normalizado o un identificador propio del lead. Sin eso, tienes un contador, no un embudo: sabes cuántos eventos hubo, pero no puedes seguir a la misma persona de una etapa a la siguiente. **Un momento de emisión definido.** ¿"Llamada agendada" se emite cuando la persona reserva o cuando la reserva se confirma? Las dos opciones son defendibles. Lo que no es defendible es que cada herramienta use una distinta. **Idempotencia.** Si el mismo evento se envía dos veces (un reintento, un usuario que recarga la página), no debe contarse dos veces. Esto se resuelve con un identificador de evento estable, derivado del recurso y no generado al azar en cada clic. Las etapas que ocurren fuera del navegador (un pago confirmado, una llamada marcada como realizada, una devolución) no se pueden medir desde el front. Ahí entran los eventos de servidor: el [Measurement Protocol de GA4](https://developers.google.com/analytics/devguides/collection/protocol/ga4) o la [API de conversiones de Meta](https://developers.facebook.com/docs/marketing-api/conversions-api) (ambas consultadas en septiembre de 2026). Ojo con enviar lo mismo desde el navegador y desde el servidor sin coordinarlo: es la causa habitual de contar cada conversión dos veces, y lo trato en [píxel de Meta y API de conversiones sin duplicados](https://fcgsystems.es/blog/pixel-meta-api-conversiones-duplicados/). ## ¿Qué se rompe primero cuando sube el volumen? Un embudo que funciona con cincuenta registros al mes puede dejar de funcionar con cinco mil en una semana de lanzamiento. Por orden de aparición: 1. **La deduplicación.** Con poco volumen los duplicados se ven a ojo. Con mucho, no. Y si la asignación va por delante, el error se multiplica. 2. **El reparto.** Una regla por turnos reparte bien hasta que alguien está de baja o un canal trae el triple de lo previsto. Sin capacidad por persona, la mitad de los leads se quedan sin trabajar. 3. **Las integraciones sin reintentos.** Un formulario que envía al CRM por webhook y falla en un pico pierde registros en silencio. Con volumen bajo se nota; con volumen alto se camufla. 4. **Los informes manuales.** La exportación del lunes deja de ser viable, y con ella desaparece la única foto que tenía el equipo. 5. **La conciliación.** Cuando entran miles de registros, la diferencia entre herramientas deja de ser explicable a mano y hace falta un cruce automático. La regla que aplico: **si un paso del embudo depende de que una persona se acuerde de hacer algo, ese es el que se rompe primero.** El trabajo de convertirlo en un proceso con logs y reintentos es lo que hacemos desde [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/). ## Errores comunes al montar un funnel de ventas - **Copiar las etapas de una plantilla.** El embudo deja de reflejar la venta real y el equipo no lo actualiza. - **Medir solo la primera y la última etapa.** Ves que entran muchos y compran pocos, pero no dónde se caen. - **No guardar el origen en el primer registro.** Después no se puede reconstruir, por mucho presupuesto que le pongas al análisis. - **Asignar antes de deduplicar.** Dos comerciales, un mismo lead y una tasa de conversión que sale peor de lo que es. - **Motivos de descarte en texto libre.** El embudo no puede explicar sus fugas. - **Un evento con nombre distinto en cada herramienta.** Cada informe cuenta una cosa y nadie sabe cuál usar. - **Perseguir que las cifras cuadren al 100 %.** Se gastan semanas en un objetivo imposible en vez de decidir cuál manda. - **Añadir etapas que nadie opera.** Más filas en el informe, la misma ignorancia. - **Optimizar la etapa equivocada.** Se invierte en creatividades cuando la fuga está en que el comercial tarda dos días en llamar. ## Ejemplo de funnel de ventas: una academia online Un ejemplo aterrizado, describiendo el flujo y sin cifras. Una academia que vende un programa formativo con llamada de venta tendría estas etapas y estas piezas: 1. **Anuncio o contenido.** El enlace lleva UTMs según una convención escrita. Ningún acortador ni redirección los elimina, y se comprueba haciendo clic en el enlace real publicado. 2. **Registro a una clase gratuita.** Formulario con campos ocultos de fuente, medio, campaña y página de entrada. El registro entra en la base de datos común, no en la herramienta del formulario. 3. **Lead único.** Se deduplica por email y teléfono normalizados. Si la persona ya existía, se conserva su primer origen y se añade el nuevo como último origen. 4. **Asistencia a la sesión.** Evento emitido por la plataforma de vídeo o por el sistema de acceso, vinculado al lead por su identificador. Sin esta etapa no se puede distinguir entre "no le interesó el programa" y "no llegó a verlo". 5. **Llamada agendada.** La agenda recibe el identificador del lead y actualiza su etapa, en lugar de crear un contacto nuevo. Es el punto donde más historial se pierde en los sistemas que reviso. 6. **Llamada realizada.** El comercial marca el resultado con un motivo de una lista cerrada. Queda registrado quién la hizo y cuándo. 7. **Matrícula.** El pago se cruza con el lead por email normalizado o por el identificador. Si no se cruza, la venta existe en la contabilidad pero no en el embudo. Con esas siete etapas y sus piezas, el negocio puede responder a preguntas que antes se contestaban por intuición: qué canal trae registros que además asisten, cuánto se tarda en llamar, qué motivo de descarte se repite. Una agencia de servicios tendría otras etapas (formulario, reunión de diagnóstico, propuesta enviada, propuesta aceptada), pero exactamente las mismas piezas debajo. ## Checklist del funnel de ventas - Las etapas están escritas, con un criterio de entrada verificable para cada una. - Cada etapa cambia lo que hace alguien del equipo; ninguna existe solo para el informe. - Hay una convención de UTMs escrita y todos los enlaces publicados la siguen. - Cada formulario guarda fuente, medio, campaña y página de entrada en campos ocultos. - La deduplicación ocurre antes de la asignación, con email y teléfono normalizados. - Cada lead tiene un único responsable y una marca de tiempo de asignación. - Los motivos de descarte son una lista cerrada, no texto libre. - Cada etapa tiene un evento con el mismo nombre en analítica y en CRM. - Los eventos llevan un identificador de persona y son idempotentes. - Las etapas que ocurren fuera del navegador se emiten desde servidor. - Las ventas se cruzan con el lead por email normalizado o por identificador propio. - Está decidido qué herramienta manda para cada pregunta, y el equipo lo sabe. - Existe un dashboard que lee de la fuente de verdad, sin exportaciones manuales. - Alguien concreto revisa cada mes la diferencia entre el recuento del CRM y el de la analítica. Si tachas menos de la mitad, el problema no es el embudo: es la capa de datos que hay debajo. Y si tenéis un lanzamiento cerca, conviene repasar antes el [checklist técnico antes de abrir registros](https://fcgsystems.es/blog/checklist-tecnico-lanzamiento/). ## ¿Por dónde empezar? No empieces rediseñando el diagrama. Coge una venta real de este mes y reconstrúyela hacia atrás: del pago al lead, del lead al formulario, del formulario al anuncio. Anota cada punto donde el rastro se corta o donde alguien tuvo que recordar algo a mano. Esa lista, ordenada por lo que cuesta cada corte, es vuestro plan de trabajo. En FCG Systems esto encaja en [tracking y atribución hasta el CRM](https://fcgsystems.es/servicios/datos-tracking-analitica/) cuando el problema es de medición, en [arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/) cuando es de cómo encajan las herramientas y en [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/) cuando hay pasos manuales que se rompen con el volumen. Si vuestro embudo se explica bien en una diapositiva pero no se puede medir en la práctica, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Qué hace un funnel de ventas? Ordena el recorrido de una persona desde que conoce el negocio hasta que compra, dividido en etapas con un criterio de entrada claro. Su utilidad real es diagnóstica: permite ver en qué punto concreto se queda la gente, en lugar de mirar solo el número de ventas del mes y adivinar qué lo está frenando. ### ¿Qué quiere decir funnel? Funnel es la palabra inglesa para embudo, así que funnel de ventas y embudo de ventas son exactamente lo mismo. La metáfora viene de la forma: entran muchas personas por arriba y solo una parte llega abajo, a la compra. Verás también embudo de conversión o embudo comercial para referirse a la misma idea. ### ¿Cuáles son las 4 etapas del embudo de ventas? La versión clásica, heredada del modelo AIDA, son atención, interés, deseo y acción. Es una convención útil para explicar la idea, no una ley: lo que importa es que las etapas que uséis reflejen cómo se vende de verdad en vuestro negocio y que cada una tenga un criterio de entrada verificable. ### ¿Cuáles son las 5 etapas del funnel de ventas? La variante de cinco etapas suele añadir la fidelización o la recompra al final, o partir la cualificación en dos pasos. Que sean cuatro, cinco o siete importa mucho menos que el criterio: una etapa solo merece existir si cambia lo que hace el equipo y si se puede medir cuántas personas entran en ella. ### ¿Cómo se hace un funnel de ventas? Escribiendo primero las etapas reales de vuestra venta con su criterio de entrada, y montando después la pieza técnica que hace medible cada una: captura de origen en el formulario, deduplicación antes de asignar, un responsable por lead en el CRM y un evento por etapa con el mismo nombre en todas las herramientas. ### ¿Puedes darme un ejemplo de un funnel de ventas? Una academia online: anuncio, registro a una clase gratuita, asistencia, reserva de llamada, llamada realizada y matrícula. Cada paso es una etapa con criterio de entrada, y cada uno necesita su pieza técnica: campos ocultos con el origen, deduplicación por email y teléfono, agenda vinculada al lead y pago cruzado con el registro. ## Servicios relacionados - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Herramientas de automatización: qué categorías hay y cuándo cada una se queda corta > Panorama de las herramientas de automatización por categorías, con los criterios que deciden la elección y las señales de que la tuya se ha quedado corta. - URL: https://fcgsystems.es/blog/herramientas-de-automatizacion/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Automatización · Formato: Breakdown · Lectura: 8 min - Palabra clave: herramientas de automatizacion (también: herramienta de automatizacion, mejores herramientas de automatizacion, software de automatizacion, plataforma de automatizacion) **Las herramientas de automatización no se eligen por la lista de integraciones, sino por la forma de tus flujos y por quién los va a mantener.** En un negocio digital hay cinco categorías con propósitos distintos, y la mayoría de operaciones acaba combinando dos o tres. Lo que decide la elección es el volumen, el número de pasos, dónde deben vivir los datos y qué ocurre cuando algo falla. Casi todos los listados del sector son rankings de veinticinco marcas que caducan en seis meses. Aquí no hay ranking: hay categorías, criterios y las señales concretas de que la herramienta que usas se te ha quedado corta. La pregunta previa, qué merece la pena automatizar y qué no, la contesto en [automatización de procesos: qué es y qué no lo es](https://fcgsystems.es/blog/que-es-automatizacion-de-procesos/). ## ¿Qué categorías de herramientas de automatización existen? | Categoría | Para qué sirve | Encaja cuando | Se queda corta cuando | |---|---|---|---| | Conectores entre aplicaciones (n8n, Make, Zapier) | Mover y transformar datos entre herramientas que ya usas | Los procesos cruzan varias plataformas y cambian a menudo | La lógica de negocio crece dentro del flujo y nadie la documenta | | Automatización nativa del CRM, el email o la plataforma de pagos | Reglas y secuencias dentro de una sola herramienta | El proceso empieza y acaba en esa herramienta | Necesitas cruzar datos de otra o cambiar de proveedor | | Tareas programadas y código propio | Procesos periódicos, cálculos, conciliaciones, migraciones | La lógica es estable, crítica o debe estar versionada | No hay quién lo mantenga ni dónde ejecutarlo con garantías | | RPA (robots sobre la interfaz) | Operar aplicaciones sin API imitando clics de una persona | El proveedor no ofrece API y el proceso es repetitivo | La interfaz cambia y el robot se rompe sin avisar | | IA dentro del flujo | Clasificar, resumir, extraer datos de texto libre | La entrada no es estructurada y la salida admite revisión | Se le delega lógica determinista: umbrales, reglas, importes | Esa última fila es la que más problemas causa últimamente. Clasificar el asunto de un correo es un buen trabajo para un modelo; decidir si un cliente tiene derecho a un reembolso, no. Las reglas de negocio se escriben en código, donde se pueden probar y auditar. ## Conectores entre aplicaciones: el caballo de batalla Es la categoría por la que casi todo el mundo entra, y con razón: resuelven lo más común en un negocio digital (formulario a CRM, pago a acceso, venta a aviso interno) sin escribir código. La más extendida en este lado del mercado es n8n, y [cómo está montada por dentro](https://fcgsystems.es/blog/que-es-n8n/) explica bastante de por qué se comporta como se comporta. Las tres opciones habituales se diferencian en tres cosas, y ninguna tiene que ver con cuántas integraciones anuncian: - **Cómo cobran.** Unas cuentan cada operación de cada paso y otras cuentan la ejecución completa del flujo. Con flujos largos, esa diferencia multiplica la factura. Los precios de cada plan están en la web de cada fabricante ([n8n](https://n8n.io/pricing/) y [Zapier](https://zapier.com/pricing), consultadas en septiembre de 2026); la comparación con aritmética real está en [n8n vs Make](https://fcgsystems.es/blog/n8n-vs-make/). - **Dónde se ejecutan.** Algunas solo funcionan en la nube del proveedor; n8n además puede instalarse en tu propio servidor, con lo que eso implica de control y de responsabilidad. El coste real de esa opción está en [n8n precios: Cloud o self-hosted](https://fcgsystems.es/blog/n8n-precios-cloud-self-hosted/). - **Qué hacen cuando algo falla.** n8n permite definir un [flujo de error](https://docs.n8n.io/build/flow-logic/handle-errors-gracefully/) que se dispara cuando otro falla, y Make guarda las [ejecuciones incompletas](https://help.make.com/incomplete-executions) para recuperarlas después (ambas consultadas en septiembre de 2026). En los dos casos hay que configurarlo: no viene resuelto de serie. Nota sobre precios: los planes de Make no se han podido consultar en su web oficial al redactar este artículo, así que aquí no aparece ninguna cifra suya. Compara siempre con tu volumen real, en el mes de más carga y con la forma que tienen tus flujos. ## La automatización que ya tienes contratada Antes de sumar una plataforma nueva, mira lo que ya pagas. El CRM tiene reglas de asignación y secuencias, la herramienta de email tiene flujos por comportamiento, la pasarela de pagos dispara eventos, la plataforma de cursos da o quita accesos según el estado del pago. Automatizar dentro de la herramienta que ya usas tiene una ventaja que no es menor: el dato no viaja. Menos puntos de fallo, menos latencia, menos cosas que vigilar. El límite aparece pronto: en cuanto el proceso cruza dos herramientas, la automatización nativa de cada una solo ve su mitad. Y si algún día cambias de proveedor, esa lógica no se puede exportar; hay que reescribirla. ## Tareas programadas y código propio La categoría menos glamurosa y la que mejor envejece. Un proceso que corre cada noche, lee dos fuentes, compara y avisa de las diferencias no necesita una plataforma visual: necesita estar versionado, probado y monitorizado. Encaja especialmente bien en: - Conciliaciones: comparar lo que cobró la pasarela con lo que registró el sistema. - Cálculos con reglas propias: comisiones, scoring, tramos de precio. - Migraciones y limpiezas de datos puntuales. - Cualquier lógica que tenga que sobrevivir a que se vaya la persona que la montó. En la práctica lo habitual es híbrido: el conector orquesta las integraciones y llama a un servicio propio cuando toca decidir algo. Cuándo dar ese paso y cómo hacerlo por piezas, sin parar la operación, está en [de no-code a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/). ## RPA: el último recurso, no el primero Un robot que abre una aplicación y hace clic donde haría clic una persona resuelve un caso concreto: proveedores sin API, sistemas antiguos, portales que no dejan integrarse de otra forma. El precio que pagas es la fragilidad. El día que el proveedor mueve un botón, el robot deja de funcionar, y muchas veces no lanza ningún error: simplemente no hace nada. Si hay API, aunque sea incómoda, la API gana siempre. ## Cinco criterios que deciden de verdad Cuando alguien pregunta cuál es la mejor herramienta, casi siempre le falta responder antes a esto: 1. **Volumen real y de pico.** Cuántas veces al mes corre cada flujo crítico, y cuánto sube eso en la semana de un lanzamiento. 2. **Forma de los flujos.** Pocos flujos largos o muchos flujos cortos. Cambia el coste según el modelo de cobro. 3. **Quién mantiene.** Una persona sin perfil técnico necesita un editor visual y una curva suave; un equipo cómodo con APIs y JSON puede permitirse más control y más responsabilidad. 4. **Dónde pueden vivir los datos.** Si hay información que por contrato o por criterio no debe pasar por una nube de terceros, eso descarta opciones antes que cualquier comparación de precio. 5. **Qué pasa cuando falla.** Si no puedes responder "esta semana fallaron doce registros y estos son", la herramienta no es el problema principal. Ese quinto punto es el que más dinero cuesta y el que menos aparece en las comparativas. Una automatización que se rompe del todo se arregla en una hora. La que falla a medias durante tres semanas hace mucho más daño: el patrón completo está en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ## ¿Cuándo una herramienta de automatización se ha quedado corta? Señales concretas, no sensaciones: - Hay más de quince o veinte flujos activos y nadie sabe decir qué hace cada uno. - El mismo dato se guarda en tres sitios y no está claro cuál manda. - Cada cambio da miedo porque no se sabe qué va a romper. - La factura sube por encima del volumen de negocio. - Necesitáis una pantalla propia para un rol concreto y la herramienta no la da. - Cuando alguien pregunta por un pedido concreto, hay que abrir la plataforma y buscar la ejecución a mano. Ninguna de esas se arregla cambiando de plataforma. Cambiar de herramienta sin arreglar la falta de registro y de gestión de errores muda el problema de sitio. ## Errores comunes al elegir herramienta de automatización - **Decidir por el precio del plan de entrada.** Lo que importa es el consumo con tu volumen y la forma de tus flujos. - **Elegir por número de integraciones.** Todas cubren de sobra lo habitual; la diferencia está en el coste, el control de errores y quién mantiene. - **Consultar una API cada minuto pudiendo usar webhooks.** Consume aunque no haya datos nuevos. - **No activar la gestión de errores.** No viene activada por defecto en las opciones más habituales. - **Delegar lógica determinista a un modelo de IA.** Umbrales, importes y reglas van en código, donde se pueden probar. - **Acumular plataformas sin criterio.** Tres herramientas conviviendo sin territorio definido es más frágil que una sola bien usada. - **Automatizar un proceso que nadie ha ordenado antes.** Automatizar el caos solo produce caos a mayor escala. ## Checklist antes de elegir - Están escritos los tres o cuatro procesos críticos, con lo que entra y lo que debe salir. - Sabemos cuántas veces se ejecuta cada uno al mes y en el pico. - Está decidido quién mantiene los flujos, con nombre. - Sabemos qué datos no pueden salir a una nube de terceros. - Cada flujo crítico tiene definido qué hacer cuando falla y a quién avisa. - Hay una forma de comparar lo que entró con lo que salió, sin abrir la herramienta. - El coste está calculado con el volumen del mes de más carga. - Ninguna decisión de negocio determinista está delegada a un modelo de IA. ## ¿Por dónde empezar? Si estás eligiendo la primera herramienta, empieza por un solo proceso: el que más veces se hace a mano o el que más caro sale cuando falla. Montarlo bien, con registro y avisos, enseña más sobre qué herramienta necesitáis que cualquier comparativa. Cuando ya hay decenas de flujos repartidos, procesos críticos que dependen de ellos y la duda es consolidar, migrar o reforzar, la decisión es de arquitectura: qué proceso vive dónde y quién es dueño de cada dato. Eso es lo que hacemos en [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/) y, cuando hay servidor propio de por medio, con [infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/). Para ver cómo encaja la automatización con el resto de capas de la operación, empieza por [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/). Y si tienes flujos funcionando pero no sabrías decir cuáles fallaron la semana pasada, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Cuál es la mejor herramienta de automatización? No existe una mejor en abstracto, y desconfía de quien te dé un nombre sin preguntarte nada antes. La elección depende de cuántos pasos tienen tus flujos, cuántas veces se ejecutan al mes, quién los va a mantener, si los datos pueden salir a una nube de terceros y qué pasa cuando algo falla. Con esas cinco respuestas, la lista de candidatos se reduce sola. ### ¿Cuáles son los tipos de herramientas de automatización? En un negocio digital se usan cinco categorías: los conectores entre aplicaciones (tipo n8n, Make o Zapier), la automatización nativa que ya incluyen el CRM o la plataforma de email, las tareas programadas y el código propio, los robots que imitan a una persona en una interfaz (RPA) y los pasos con IA dentro de un flujo. La mayoría de operaciones acaba combinando varias. ### ¿Hace falta saber programar para automatizar procesos? Para flujos estándar, no: los conectores visuales cubren la mayoría de integraciones habituales sin escribir código. Hace falta criterio técnico en cuanto aparecen reintentos, deduplicación, control de errores o datos que no pueden salir a un tercero. La frontera no es saber teclear código, es saber qué pasa cuando el flujo falla a medias. ### ¿Cuándo una herramienta de automatización se queda corta? Cuando la lógica de negocio ya vive repartida en veinte escenarios que nadie documenta, cuando el coste por ejecución crece por encima del valor que aporta, cuando hace falta una interfaz propia para un rol concreto o cuando cada cambio da miedo porque no se sabe qué va a romper. En ese punto la conversación deja de ser de herramienta y pasa a ser de arquitectura. ### ¿Se pueden combinar varias herramientas de automatización? Sí, y es lo habitual, pero que sea por diseño y no por acumulación. Tener flujos críticos repartidos entre tres plataformas sin documentación multiplica los puntos de fallo y hace imposible saber dónde se perdió un dato. Si conviven, conviene que cada una tenga un territorio claro y un responsable con nombre. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. - [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/): Servidores, despliegues, backups y alertas para que tu operación no se caiga y sea tuya. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # KPI: qué es, cuáles mirar de verdad en un negocio digital y de dónde sale cada número > Qué es un KPI, en qué se diferencia de una métrica y qué indicadores mirar en un negocio digital: CAC, LTV, conversión por etapa y de dónde sale cada dato. - URL: https://fcgsystems.es/blog/kpis-negocio-digital/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Breakdown · Lectura: 8 min - Palabra clave: kpi que es (también: que es un kpi, kpis de ventas, que son los kpi, kpis de un negocio digital, indicadores clave de rendimiento) Un KPI (key performance indicator, o indicador clave de rendimiento) es una medida que refleja si el negocio avanza hacia un objetivo concreto y sobre la que alguien puede actuar. Se diferencia de una métrica cualquiera en dos cosas: está atada a un objetivo y tiene un responsable que hace algo cuando se mueve. Esa es la definición. El problema real de la mayoría de negocios digitales no es no saber qué es un KPI: es tener veinte y no poder decidir con ninguno. Este artículo va de eso, de qué mirar y, sobre todo, de dónde tiene que salir cada número para que te lo puedas creer. ## ¿Qué diferencia hay entre una métrica y un KPI? Las visitas a tu web son una métrica. También lo son los seguidores, las aperturas de email o el número de automatizaciones que tienes montadas. Describen algo que ocurre. Un KPI es la métrica que has elegido como clave porque cumple tres condiciones: - **Está atada a un objetivo del periodo.** Si el objetivo es captar leads cualificados, el KPI no son las visitas: es la conversión de visita a registro y el coste por lead cualificado. - **Alguien es responsable de moverla.** Un número sin dueño es un adorno del panel. - **Se puede actuar sobre ella.** Si sube o baja y nadie sabe qué haría distinto, no decide nada. Hay una prueba que uso en las reuniones de arranque: pregunto por cada número del panel "si mañana esto cae un 20 %, ¿qué harías?". Los indicadores que se quedan sin respuesta no son KPIs. Son contexto, y el contexto va en un anexo, no en la portada. ## ¿Cuáles son los KPIs que de verdad hay que mirar? Depende del modelo de negocio, pero en negocios digitales que venden con registros, llamadas o suscripción se repiten los mismos. Los agrupo en cuatro bloques, con la fuente de la que debe salir cada uno. ### 1. Captación: ¿cuánto cuesta traer a alguien? | KPI | Qué responde | Fuente del dato | |---|---|---| | Coste por lead (CPL) | Cuánto cuesta un registro por canal | Plataforma de anuncios + CRM (por origen) | | Coste de adquisición de cliente (CAC) | Cuánto cuesta un cliente que paga | Inversión total ÷ clientes nuevos del CRM o la pasarela | | Conversión de visita a registro | Si la landing y la oferta funcionan | Analítica web + registros del CRM | | Leads cualificados sobre el total | Si estás comprando volumen o gente que compra | CRM, con un criterio de cualificación escrito | El CAC honesto incluye lo que casi nadie mete: publicidad, sí, pero también herramientas y el coste del equipo comercial. Si solo cuentas la inversión en anuncios, tu CAC es una cifra de escaparate. ### 2. Conversión: ¿dónde se cae la gente? Aquí el KPI útil no es "la conversión", en singular, sino la conversión **por etapa**. Registro, preinscripción, llamada agendada, llamada realizada, venta. Una conversión global del 2 % no te dice nada; saber que agendas el 16 % de las llamadas pero solo se presenta la mitad, sí. En el [caso del funnel, tracking y CRM de una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/) fue exactamente eso: hasta que no medimos cada etapa por separado, cualquier discusión sobre qué mejorar era una opinión. Lo que no se mide por etapa no se optimiza; se debate. ### 3. Valor: ¿cuánto deja cada cliente? - **LTV (valor de vida del cliente):** el margen medio que deja un cliente durante toda su relación con el negocio. Con un producto único y pago único es el margen de la venta. Con recurrencia, entra la permanencia. - **Relación LTV/CAC:** el número que decide si puedes escalar la inversión o si estás comprando facturación con pérdidas. - **Ticket medio y margen por producto:** dos productos con la misma facturación pueden dejar márgenes opuestos si uno consume soporte y el otro no. - **Churn o bajas** en recurrencia, y su hermano feo: los **impagos**. Una cuota que falla y nadie ve es dinero que se escapa con toda la operación funcionando aparentemente bien. ### 4. Operación: ¿qué se está rompiendo por dentro? Estos casi nunca aparecen en los artículos de KPIs y son los que más dinero recuperan: - **Tiempo de primera respuesta a un lead**, medido desde que entra el registro. - **Leads sin asignar o sin tocar** después de 24 horas. - **Pagos fallidos y su recuperación.** Si vendes por suscripción, mira cuántos cobros fallan y cuántos se recuperan; lo desarrollo en [pagos fallidos que dejan a un alumno sin acceso](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/). - **Errores de las automatizaciones.** Un flujo que falla en silencio no aparece en ningún KPI de marketing, pero está tirando leads a la basura: lo cuento en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ## ¿De dónde sale cada número? (la parte que nadie mira) Aquí está el motivo por el que la mitad de los paneles no se usan: los números no cuadran entre herramientas y, cuando alguien lo señala en una reunión, el panel pierde autoridad para siempre. La regla es una sola: **cada KPI sale de la fuente que registra el hecho, no de la que lo estima.** - **Ingresos, cobros, impagos y reembolsos** → pasarela de pago o facturación. No la plataforma de anuncios. - **Leads, etapas y ventas por origen** → CRM. Es el único sistema que une quién es la persona, de dónde vino y si compró. - **Comportamiento en la web** → analítica. Sirve para detectar fugas en la landing, no para contar ventas. - **Inversión publicitaria** → plataforma de anuncios, que para eso es su dato de primera mano. Que el informe de Meta, el de GA4 y el del CRM no coincidan es normal, porque cada uno cuenta cosas distintas con reglas distintas. Lo que no es normal es no saber cuál usar para decidir. Lo desmonto paso a paso en [por qué GA4, Meta y tu CRM nunca dan la misma cifra](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/), y el trasfondo conceptual está en [qué es la atribución de marketing](https://fcgsystems.es/blog/que-es-la-atribucion/). Un detalle pequeño con consecuencias grandes: si tus enlaces no llevan una nomenclatura de campañas coherente, ningún KPI por canal es fiable, por bonito que sea el gráfico. Antes de discutir indicadores, fija la convención de [parámetros UTM](https://fcgsystems.es/blog/que-es-utm/). ## ¿Cómo se automatiza el cálculo de los KPIs? Si alguien de tu equipo dedica los lunes a exportar CSVs y pegarlos en una hoja, no tienes un sistema de KPIs: tienes un ritual. Y el ritual se rompe cuando esa persona está de vacaciones. La arquitectura mínima tiene cuatro piezas, y ninguna es exótica: 1. **Fuentes de verdad definidas por dominio.** Un documento de una página que diga qué sistema manda para cada cosa: ventas, leads, tráfico, inversión. Sin esto, todo lo demás mide con precisión un dato ambiguo. 2. **Identificadores que viajan.** El email normalizado o un ID propio que acompaña a la persona desde el formulario hasta la pasarela de pago. Es lo que permite cruzar una venta con el canal que la trajo. 3. **Definiciones escritas de cada KPI.** Qué entra y qué no entra en el CAC, qué cuenta como lead cualificado, qué periodo se usa. Dos personas calculando el mismo KPI con criterios distintos producen dos verdades y ninguna decisión. 4. **Un panel que lee de las fuentes, sin pasos manuales.** Con actualización automática y la fecha del último refresco visible. Si no sabes de cuándo es el dato, no puedes usarlo para decidir. Sobre el cuarto punto: existe una diferencia enorme entre [un panel bonito y uno que sirve para decidir](https://fcgsystems.es/blog/que-es-un-dashboard/). La [infraestructura para lanzamientos con miles de registros](https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/) tenía dashboards de registros, asignaciones y ventas por fuente actualizados mientras la campaña estaba en marcha. Esa es la utilidad real: mirar un número el martes y cambiar algo el miércoles, no leer un informe del trimestre pasado. ## Errores habituales al montar KPIs - **Confundir volumen con resultado.** Seguidores, impresiones y visitas suben con presupuesto. El margen, no. - **Medir solo lo que la herramienta trae de serie.** Los indicadores por defecto describen la herramienta, no tu negocio. - **Cambiar la definición sin avisar.** Si en marzo el CAC incluía el equipo comercial y en abril no, la serie histórica es basura. - **Objetivos sin umbral.** "Subir la conversión" no es un objetivo. "Pasar del 9 % al 13 % de llamadas agendadas antes de diciembre" sí, porque se puede fallar. - **Un panel para todo el mundo.** Dirección, marketing y soporte no necesitan los mismos números. Un panel único acaba siendo el de nadie. ## Checklist: ¿tus KPIs sirven para decidir? - Cada KPI del panel tiene un objetivo asociado con un umbral y una fecha. - Cada KPI tiene una persona responsable, con nombre. - Está escrito qué entra y qué no entra en cada cálculo, y la definición no ha cambiado a mitad de año. - Cada número sale de la fuente que registra el hecho, no de una estimación de otra herramienta. - Ningún KPI depende de que alguien exporte y pegue datos a mano. - El panel muestra la fecha del último refresco. - Hay al menos dos indicadores de operación (respuesta a leads, impagos o errores) y no solo de marketing. - Si un número se mueve, el equipo sabe qué revisar en la hora siguiente. Si te fallan más de la mitad, el problema no es de analítica: es de arquitectura de datos. Es la misma capa que describo en [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/) y que se rompe antes de lo que parece cuando el CRM es una hoja de cálculo, como cuento en [leads que se pierden entre el formulario y el comercial](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). ## Por dónde empezar Coge el número que más se repite en tus reuniones. Sigue su rastro hacia atrás hasta el sistema que lo genera y anota cuántas manos humanas lo tocan por el camino. Ese recorrido es tu primer arreglo, y casi siempre termina en un formulario que no guarda el origen o en una hoja que alguien rellena a mano. En FCG Systems esto encaja en [datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/) y, cuando el lío viene de cómo están conectadas las herramientas, en [arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/). Si tu equipo discute cifras en vez de decisiones, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y te digo por dónde miraría primero. ## Preguntas frecuentes ### ¿Qué es un KPI y qué ejemplos hay? Un KPI (indicador clave de rendimiento) es una medida que refleja si el negocio avanza hacia un objetivo concreto y que sirve para tomar una decisión. Ejemplos habituales en un negocio digital: coste de adquisición de cliente, valor de vida del cliente, conversión de lead a venta, tasa de impagos y margen por producto. ### ¿Qué diferencia hay entre una métrica y un KPI? Toda métrica es un número que describe algo que ocurre; un KPI es la métrica que has elegido como clave porque está atada a un objetivo y alguien actúa cuando se mueve. Las visitas a la web son una métrica. Si tu objetivo del trimestre es captar leads, el KPI es la conversión de visita a registro, y las visitas pasan a ser contexto. ### ¿Cuántos KPIs debería tener un negocio digital? Pocos: entre cinco y ocho para el panel de dirección, y uno o dos por equipo. Un panel con treinta indicadores no se mira; se abre el primer lunes y se abandona. La prueba es sencilla: si un número se mueve y nadie sabe qué haría al respecto, no es un KPI, es contexto. ### ¿Cómo se calcula el CAC y el LTV? El CAC se calcula dividiendo todo lo invertido en captar clientes en un periodo (publicidad, herramientas y el coste del equipo comercial) entre los clientes nuevos de ese mismo periodo. El LTV es el margen medio que deja un cliente durante toda su relación con el negocio. Ambos solo tienen sentido con el mismo criterio de periodo y con las ventas reales del CRM o de la pasarela de pago. ### ¿De dónde deberían salir los datos de un KPI? De la fuente que registra el hecho, no de la que lo estima. Las ventas y los ingresos salen de la pasarela de pago o de la facturación; los leads y su origen, del CRM; el comportamiento en la web, de la analítica. Si un KPI se calcula copiando cifras a mano entre herramientas, tarde o temprano se calcula mal. ## Servicios relacionados - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Casos relacionados - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/): Formularios, tracking, CRM y agenda comercial conectados en un solo sistema, con el origen de cada lead a la vista. Las tres etapas del funnel mejoraron. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # La IA no elimina la revisión del código: la convierte en el cuello de botella real > Generar código dejó de ser el límite. Ahora lo es el criterio para revisarlo. Por qué el volumen de código generado por IA hace la revisión más necesaria. - URL: https://fcgsystems.es/blog/la-ia-no-elimina-la-revision/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Software · Formato: Opinión · Lectura: 4 min - Palabra clave: revisar código generado por ia (también: código generado por ia, riesgos de la ia en desarrollo, revisión de código) Escribir código dejó de ser el cuello de botella hace un par de años. Lo que nadie dice en voz alta es que el cuello de botella no desapareció: se movió. Y se movió a un sitio donde casi nadie ha puesto capacidad. La escena la conoces. Un equipo que antes producía tres cambios a la semana ahora produce quince. La misma gente. Y todo el mundo lo celebra, porque lo que se mide es lo que sale, no lo que se ha mirado de verdad antes de salir. El problema es de cuentas. La capacidad de generar se ha multiplicado. La capacidad de juzgar sigue siendo la misma, porque depende de cuántas personas con criterio tienes y de cuántas horas de atención les caben en el día. Cuando una de las dos se dispara y la otra no, la diferencia no se evapora: se acumula en producción, en forma de cosas que nadie leyó con atención. ## El código generado falla de otra manera Y esto es lo que más me interesa. No es que la IA escriba peor. En muchos casos escribe mejor que la media, y desde luego más ordenado. El asunto es *cómo* falla. El código malo de un humano cansado suele tener mala pinta. Está desordenado, tiene nombres raros, se nota el parche. Tu instinto de revisor se enciende solo: cuando algo se lee mal, lo miras con lupa. El código generado se lee estupendamente. Nombres coherentes, estructura limpia, comentarios en su sitio. Todo pide a gritos que le des al aprobar. Y dentro puede haber una comprobación de permisos que da por hecho un rol que en tu sistema no significa lo mismo, una consulta que funciona con cien registros y muere con cien mil, o una gestión de errores que se traga la excepción y sigue como si nada. La superficie no te avisa. La IA escribe código inseguro igual de rápido que el seguro, y con la misma cara de seguridad. Hay un segundo efecto, más silencioso. Cuando el código lo has escrito tú, lo entiendes por el camino: has dudado, has probado, has descartado dos opciones. Ese proceso deja un mapa mental. Cuando lo genera un modelo, el mapa no existe salvo que lo construyas a propósito leyendo. Y el mapa es justo lo que necesitas seis meses después, a las once de la noche, cuando algo se ha roto y hay que decidir rápido. Lo que te faltará no serán líneas de código: será saber por qué está puesto así. ## La revisión de verdad no es leer el diff Aquí es donde la mayoría de equipos se engaña. Se abre el cambio, se echa un vistazo de treinta segundos, se aprueba. Eso no es revisar. Con quince cambios a la semana, eso es una firma. Revisar de verdad es hacer cuatro preguntas que ningún vistazo responde. **¿Resuelve el problema que teníamos, o uno parecido?** Es el fallo más común y el menos buscado. El código funciona, pasa los tests, hace algo razonable. Y no es lo que hacía falta. Cuando pides poco contexto, recibes una solución para el problema que describiste, no para el que tienes. **¿Qué rompe?** Tu sistema tiene invariantes que no están escritos en ningún sitio: ese campo nunca es nulo, ese proceso corre siempre después de aquel, ese identificador se usa en otros tres lados. Un modelo no los conoce. Tú sí, y eres el único que puede verlos. **¿Qué pasa en el caso feo?** El dato vacío, el usuario sin permisos, el reintento, los dos procesos a la vez. Lo generado cubre el camino feliz con una consistencia admirable. **¿Puedo mantener esto?** Si dentro de seis meses nadie sabe por qué está ahí, ya es deuda. Aunque funcione perfecto hoy. Lo determinista merece un párrafo aparte, porque es donde más veo colarse cosas: cualquier lógica de clasificación, umbral o mapeo que decide algo importante tiene que estar en código legible y probable, nunca escondida dentro de un prompt. Un umbral que vive en una frase de un prompt no se puede testear ni auditar. Es la misma regla que aplico al decidir [qué permisos tiene un agente](https://fcgsystems.es/blog/permisos-de-un-agente-decision-de-riesgo/). ## Qué hago yo Reviso todo lo que genero antes de fiarme. No por desconfianza ceremonial, sino porque "funciona" no es el listón; hay que adelantarse al fallo. En la práctica, tres cosas. Primero: **pedir en trozos pequeños**. Un cambio grande generado de golpe es un cambio que no se revisa, se hojea. Si no cabe en tu cabeza, no lo has revisado. Segundo: **poner señal externa antes que opinión**. Tipos, tests, linters, el build. Todo lo que una máquina pueda comprobar por ti libera tu atención para lo que solo tú puedes juzgar, que es si la solución tiene sentido en tu negocio. Tercero: **dar el contexto antes, no corregir después**. La mayoría de revisiones dolorosas se evitan explicando bien las restricciones al principio. Y una cuarta, la más incómoda: si no entiendo un trozo, no entra. Punto. Entender es tener el control, y aceptar código que no entiendes es firmar una hipoteca en un idioma que no lees. ## El criterio que te llevas La IA no ha eliminado el trabajo de ingeniería. Ha eliminado la parte que menos valor tenía, que era teclear, y ha dejado al descubierto la que siempre fue el trabajo de verdad: decidir qué hay que construir, verificar que lo construido aguanta y saber por qué está hecho así. Si tu equipo genera cinco veces más y revisa igual, no has ganado velocidad. Has ganado velocidad de emisión y has creado una cola invisible. La pregunta útil para medir si vas bien no es cuántos cambios salen a la semana, sino cuántos de ellos alguien podría defender delante de un cliente si mañana fallan. Tu curro no es teclear menos, es juzgar mejor. ## Servicios relacionados - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Sistemas de IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Lead scoring con reglas o con IA: qué necesitas antes de puntuar y qué hacer con el score > Qué es el lead scoring, qué datos necesitas antes de puntuar, cómo se calcula con reglas, cuándo aporta la IA y qué hacer con el score en el reparto comercial. - URL: https://fcgsystems.es/blog/lead-scoring-reglas-o-ia/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Automatización · Formato: Breakdown · Lectura: 10 min - Palabra clave: lead scoring (también: que es lead scoring, calificación de leads, como calcular lead score, lead scoring ejemplos) El **lead scoring** es asignar una puntuación a cada contacto para decidir a quién atiende antes el equipo comercial. Combina quién es esa persona (lo que ha declarado) con lo que ha hecho (su comportamiento), y produce un número que ordena la cola de trabajo. No adivina quién va a comprar: ordena el tiempo de quien vende, que es un recurso finito. Casi todo lo que se escribe sobre lead scoring empieza por la tabla de puntos. Es empezar por el final. La tabla es la parte sencilla; lo que decide si el scoring sirve para algo es lo que hay antes (si conserváis el origen del lead y registráis los resultados) y lo que hay después (qué pasa exactamente cuando un contacto supera el umbral). Este artículo va por ese orden. Y se moja en la pregunta que la mayoría esquiva: cuándo bastan unas reglas y cuándo aporta algo un modelo. ## ¿Para qué sirve de verdad el lead scoring? Para una sola cosa: **priorizar**. Si vuestro equipo comercial puede atender cuarenta contactos al día y entran cuarenta, no necesitáis scoring, necesitáis atenderlos a todos. El scoring aparece cuando entran más de los que se pueden atender bien, y alguien tiene que decidir el orden. De ahí se derivan dos consecuencias que conviene aceptar pronto: - **El scoring no crea demanda.** Si los leads son malos, el scoring os dirá con más precisión cuáles son los menos malos. - **Un score que nadie usa es peor que no tener score.** Consume mantenimiento, da una falsa sensación de control y nadie cambia su comportamiento por él. Si al final el comercial llama por orden de llegada, el proyecto ha fracasado aunque el número se calcule perfecto. ## ¿Qué necesitas antes de puntuar nada? Tres cosas. Sin ellas no hay scoring, hay decoración. **1. El origen del lead, conservado de extremo a extremo.** De qué campaña, anuncio o contenido viene cada contacto, guardado en el CRM y no solo en la analítica. Es el dato que más peso suele tener y el primero que se pierde por el camino: formularios que no propagan las UTM, redirecciones que las borran, integraciones que solo pasan nombre y email. Si os suena, el problema está descrito entero en [atribución rota: por qué GA4, Meta y tu CRM nunca dan la misma cifra](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/). Si os falta esa trazabilidad, el problema no es el scoring: es el embudo. Qué pieza técnica necesita cada etapa para que las cifras cuadren está en [funnel de ventas: etapas y piezas técnicas](https://fcgsystems.es/blog/funnel-de-ventas-sistema/). **2. Estados del CRM con un significado acordado.** Qué quiere decir "contactado", "cualificado" o "perdido", y quién los cambia. Si cada comercial los usa a su manera, el histórico no sirve para calibrar nada. **3. El resultado registrado.** Quién compró, quién no y por qué. Sin esto no podéis saber si vuestras reglas aciertan, porque no hay contra qué comparar. Es la diferencia entre puntuar con criterio y puntuar con opinión. Si los contactos todavía viven en una hoja de cálculo y se reparten a mano, el orden correcto es primero el sistema y después la puntuación: eso lo cuento en [leads que se pierden](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/) y en [CRM para pymes y negocios digitales](https://fcgsystems.es/blog/crm-para-pymes-saas-o-a-medida/). ## Scoring explícito e implícito: qué es cada uno Se puntúan dos familias de señales, y mezclarlas sin distinguirlas es la causa habitual de que un scoring no funcione. - **Explícito (quién es):** lo que el contacto ha declarado. Tipo de negocio, facturación aproximada, número de empleados, cargo, país, presupuesto. Dice si **encaja** con lo que vendéis. - **Implícito (qué hace):** su comportamiento. Ha pedido precio, ha visto la página de contratación dos veces, ha abierto el correo de la demo, ha reservado una llamada. Dice si **tiene intención ahora**. La distinción importa porque las dos señales se degradan de forma distinta. El encaje es bastante estable: quien es una academia online lo seguirá siendo el mes que viene. La intención caduca deprisa: alguien que pidió precio hace tres meses y no respondió ya no está en el mismo momento. Un scoring que suma los dos en un único número y nunca lo envejece acaba llenando la cola de contactos que encajan muy bien y no piensan comprar. De ahí sale una recomendación práctica: **que la parte de comportamiento pierda puntos con el tiempo**. ## ¿Cómo se construye una tabla de puntos con reglas? Se mira hacia atrás. Coged los últimos cierres reales y los últimos "no" y buscad qué atributos aparecen en unos y no en otros. Eso os da los candidatos. Después se les pone un valor, se suman y se fija el umbral. El ejemplo que viene a continuación es **ilustrativo**: enseña la forma de una tabla, no un baremo válido para vuestro negocio. Los puntos salen de vuestros datos o no salen de ningún sitio. | Señal | Tipo | Puntos (ejemplo ilustrativo) | Por qué | |---|---|---|---| | Encaja con el perfil de cliente declarado | Explícita | +20 | Es el filtro más barato y el más estable | | Indica un volumen de operación acorde | Explícita | +15 | Separa quien puede contratar de quien no | | Pide precio o presupuesto | Implícita | +25 | La intención más clara que existe | | Reserva una llamada | Implícita | +30 | Compromete tiempo propio | | Visita la página de servicio más de una vez | Implícita | +10 | Interés sostenido, no un clic suelto | | Viene de una campaña con histórico de cierres | Explícita | +10 | El origen predice mejor que casi nada | | Correo personal en una venta a empresas | Explícita | −10 | Señal débil de proyecto real | | País o idioma fuera de lo que atendéis | Explícita | −40 | Descarta, no pospone | | Sin actividad en 30 días | Implícita | −15 | La intención caduca | Tres reglas sobre la tabla: - **Pocos criterios y que se entiendan.** Ocho o diez bien elegidos superan a treinta que nadie sabe explicar. Si un comercial no puede entender por qué un lead tiene 70, no se fiará del 70. - **Los puntos negativos hacen más trabajo que los positivos.** Descartar lo que claramente no encaja limpia la cola más que afinar entre los buenos. - **Cuidado con un único número si vendéis cosas distintas.** Un negocio con un curso de 300 € y un servicio de 15.000 € necesita dos scorings. Las señales que predicen uno no predicen el otro. Y una señal que conviene mirar con desconfianza: **la apertura de correos**. Con la protección de privacidad en los clientes de correo, una apertura registrada puede no ser una persona leyendo. Si pesa mucho en vuestra tabla, estáis puntuando ruido. ## ¿Cuándo aporta algo la IA y qué le pides exactamente? Un modelo puede aportar dos cosas reales: - **Leer lo que no es un campo.** El texto libre de un formulario, la transcripción de una llamada o un mensaje de WhatsApp contienen información que ninguna regla captura: qué problema describe, qué urgencia tiene, si menciona presupuesto. Convertir eso en una señal estructurada es un buen uso, y es uno de los casos que ya describo en [IA aplicada en negocios digitales](https://fcgsystems.es/blog/ia-aplicada-negocios-digitales/). - **Encontrar combinaciones que no habíais visto.** Con suficiente histórico, un modelo predictivo puede detectar que cierta combinación de origen y comportamiento cierra mejor de lo que suponíais. Ahora las condiciones, que es donde se cae la mayoría: - **Hace falta histórico de resultados, no de contactos.** Un modelo aprende de cierres y de rechazos etiquetados. Unos pocos cientos de contactos sin resultado registrado no dan para nada. - **Hace falta volumen sostenido.** Si entran quince leads a la semana, una persona con criterio los ordena mejor que cualquier modelo, y gratis. - **Hace falta poder explicar la puntuación.** Un comercial que no entiende por qué un lead está arriba deja de usar el sistema. Por eso, en la práctica, la combinación que funciona es **la IA aporta señales y las reglas deciden**. El modelo devuelve "intención detectada: alta" o "problema mencionado: integración con CRM", y esa señal entra en la tabla de puntos como una más. El umbral a partir del cual se llama a alguien sigue siendo una regla escrita. Esto no es prudencia decorativa. La lógica determinista (umbrales, mapeos, a quién se asigna, qué SLA aplica) tiene que ser **predecible, auditable y fácil de cambiar**. Si mañana el equipo crece y queréis bajar el umbral, eso es una línea de configuración, no reentrenar nada. Y cuando un cliente pregunta por qué nadie le llamó, tenéis una respuesta. ## Lo que casi nadie cuenta: qué haces con el score Aquí se decide si el proyecto sirve. Un número no cambia nada; lo que cambia las cosas es la acción asociada a cada tramo. Conviene escribirlo así de explícito: | Tramo | Qué pasa | Quién | En cuánto tiempo | |---|---|---|---| | Alto | Se asigna a comercial y se contacta | Comercial de guardia | Menos de una hora en horario laboral | | Medio | Entra en cola normal y recibe secuencia de nutrición | Comercial asignado | Mismo día | | Bajo | No se contacta; se queda en nutrición automática | Nadie, hasta que suba | — | | Descartado | Se marca y se saca de la cola | Automático, con motivo registrado | — | Cuatro detalles que marcan la diferencia: 1. **El reparto también es una regla.** Por producto, por idioma, por carga de trabajo de cada comercial. El score dice el orden; el reparto dice quién. Son dos decisiones distintas y conviene no mezclarlas. 2. **Los tramos bajos necesitan un destino.** Si no lo tienen, se convierten en un cementerio de contactos que pagasteis por conseguir. Ese destino suele ser una secuencia automática, y qué conviene disparar así y qué no lo reviso en [automatización de marketing](https://fcgsystems.es/blog/automatizacion-de-marketing/). 3. **Un lead puede subir de tramo.** Alguien con 40 puntos que reserva una llamada pasa a alto. El sistema tiene que reaccionar a eso, no calcular el score una sola vez en la entrada. 4. **El SLA importa más que el score.** Ordenar bien la cola y luego tardar dos días en llamar no arregla nada. ## ¿Cómo se revisa un scoring que se ha quedado viejo? Un scoring envejece porque el negocio cambia: producto nuevo, canal nuevo, precio distinto. Revisarlo es sencillo si registrasteis los resultados. - **Cada mes:** mirad qué porcentaje de los contactos de tramo alto acabó en venta y qué porcentaje de las ventas venía de tramo bajo. La segunda cifra es la interesante: si vendéis mucho a gente que el sistema puntuaba bajo, la tabla está equivocada. - **Cada trimestre:** revisad los criterios uno a uno y quitad los que no separan. Un criterio que tienen casi todos no aporta información. - **Siempre que entre un canal nuevo:** dadle tiempo antes de puntuarlo alto. Un origen sin histórico no merece confianza todavía. - **Cuando cambie el umbral:** anotad la fecha. Si no, dentro de tres meses nadie sabrá por qué las cifras cambiaron. Y guardad el score con su fecha y sus componentes, no solo el número final. Cuando queráis entender por qué un contacto puntuó lo que puntuó, lo agradeceréis. ## Errores comunes con el lead scoring - **Empezar por la tabla.** Sin origen conservado ni resultados registrados, la tabla es una opinión con decimales. - **Puntuar aperturas de correo** como si fueran intención. - **Un único score para productos muy distintos.** - **Nunca envejecer la parte de comportamiento,** así que la cola se llena de interés caducado. - **Un score que nadie mira.** Si el comercial llama por orden de llegada, no hay sistema. - **Delegar el umbral al modelo.** La decisión tiene que ser explícita y revisable. - **Demasiados criterios.** Nadie los mantiene y nadie los entiende. - **Calcularlo solo al entrar el lead** y no recalcularlo cuando pasa algo nuevo. - **Sin responsable.** Nadie revisa si sigue acertando cuando cambia el producto. ## Checklist antes de montar un lead scoring - El origen del lead llega íntegro al CRM y no se pierde por el camino. - Los estados del CRM tienen un significado acordado por escrito. - Los resultados de venta están registrados y son consultables. - Está definido por escrito qué es un lead válido para vuestro negocio. - Los criterios salen de mirar vuestros cierres, no de una plantilla genérica. - Hay menos de diez criterios y un comercial puede explicarlos. - Los criterios negativos descartan de verdad lo que no encaja. - La parte de comportamiento pierde peso con el tiempo. - Cada tramo tiene una acción, un responsable y un plazo. - El reparto entre comerciales es una regla aparte del score. - El score se recalcula cuando el contacto hace algo nuevo. - Se guarda el score con su fecha y sus componentes. - Hay una revisión periódica con una métrica clara. - Hay una persona responsable del sistema. ## ¿Por dónde empezar? Si todavía no tenéis nada, empezad por la versión aburrida: tres o cuatro criterios, dos tramos y una regla de reparto. Funcionando en el CRM, con los resultados registrados. En dos meses tendréis datos para afinar, que es exactamente lo que hoy no tenéis. Si ya tenéis un scoring y no os fiáis de él, el diagnóstico casi siempre está antes de la tabla: origen que se pierde, estados ambiguos o resultados sin registrar. Eso es trabajo de [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/) y de [datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/), y solo cuando está resuelto tiene sentido plantear la capa de [IA aplicada](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/). Si tenéis más leads de los que podéis atender y no sabéis por dónde cortar, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y te digo si lo vuestro es un scoring o es otra cosa. ## Preguntas frecuentes ### ¿Qué significa lead scoring? Lead scoring es asignar una puntuación a cada contacto para ordenar a quién atiende antes el equipo comercial. La puntuación combina quién es el contacto (datos declarados) y qué ha hecho (comportamiento). No predice quién va a comprar: ordena una cola de trabajo con la información disponible. ### ¿Qué es la calificación de leads? Es el proceso completo de decidir si un contacto merece tiempo comercial y cuándo. El scoring es la parte numérica; la calificación incluye además el criterio de qué es un lead válido, quién lo revisa y qué se hace con los que no llegan al umbral. Un número sin ese proceso detrás no cambia nada. ### ¿Cómo se calcula un lead score? Se listan los atributos que en vuestro negocio se asocian a ventas cerradas, se les asigna un valor positivo o negativo, se suman y se define un umbral a partir del cual el contacto pasa a comercial. Los puntos salen de mirar vuestros propios cierres, no de una plantilla genérica de internet. ### ¿Qué se entiende por lead? Un contacto que ha dejado sus datos y ha mostrado algún interés en lo que vendéis. Conviene definirlo por escrito, porque marketing y ventas suelen entender cosas distintas: si para uno es cualquier descarga y para otro solo quien pide precio, las cifras nunca cuadrarán. ### ¿Qué relación hay entre leads y CRM? El CRM es donde vive el lead y su historia: origen, estado, responsable y resultado. El scoring se calcula con esos datos y se escribe de vuelta en el CRM. Sin un CRM con estados y resultados registrados, no hay con qué puntuar ni forma de saber si la puntuación acierta. ### ¿Conviene usar IA para puntuar leads? Solo cuando hay volumen y un histórico de resultados reales, y siempre como señal que se suma a las reglas, no como sustituto. La decisión de a partir de qué puntuación se llama a alguien debe seguir siendo una regla explícita: tiene que ser predecible, auditable y fácil de cambiar. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Sistemas de IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Lovable vs Bolt vs v0: comparativa honesta por criterios de uso real > Lovable vs Bolt vs v0: para qué sirve cada una, qué código genera, qué control te deja, qué pasa al exportar y cuándo ninguna de las tres es la respuesta. - URL: https://fcgsystems.es/blog/lovable-vs-bolt-vs-v0/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Software · Formato: Breakdown · Lectura: 10 min - Palabra clave: lovable vs bolt vs v0 (también: lovable vs bolt, bolt.new, v0 vercel, figma make, replit agent, alternativas a lovable, herramientas para prototipos con ia) **Lovable, Bolt y v0 hacen lo mismo de cerca y cosas distintas de lejos: las tres convierten instrucciones escritas en una aplicación web que funciona.** La diferencia que importa no es cuál genera pantallas más bonitas, sino qué control te deja sobre el código, qué backend trae puesto y qué pasa el día que tu equipo tiene que seguir trabajando fuera de la herramienta. Esta comparativa está hecha desde ese ángulo. No hay ganadora. Hay tres herramientas buenas para escenarios distintos, y un cuarto escenario donde ninguna es la respuesta. ## Tabla comparativa | Criterio | Lovable | Bolt | v0 | |---|---|---|---| | Qué es, según su documentación | Plataforma de desarrollo full-stack con IA, con código editable | "Una herramienta de IA que convierte tus ideas en webs y aplicaciones reales" | "Un agente de IA que ayuda a cualquiera a crear código real y aplicaciones full-stack" | | Qué genera | Proyectos estándar de Vite y React | Proyecto de ficheros con frontend y backend en JavaScript | Código con Next.js, Tailwind y componentes shadcn/ui | | Backend incluido | Sí: base de datos, autenticación, almacenamiento, tiempo real y funciones | Sí, con base de datos propia; también conecta con Supabase | Conecta con sistemas externos para aplicaciones con datos | | Lenguajes de backend | Sobre base open source de Supabase | Solo JavaScript: PHP o Python no son compatibles | Ecosistema Next.js | | Control sobre el código | Editor integrado; de solo lectura en el plan gratuito | Trabajo directo sobre los ficheros del proyecto | Código generado, con revisión por pull request | | Sincronización con Git | Dos direcciones, una rama cada vez | Commit automático por cada cambio que no rompe el proyecto; comprueba GitHub cada 30 segundos | Despliegue directo o pull request para revisar | | Ramas | Una rama sincronizada a la vez | Sí, con memoria propia por rama; las fusiones se hacen en GitHub | Flujo de pull request | | Publicación | URL propia; dominio personalizado en planes de pago | Publicación y conexión de dominios de terceros | Despliegue en la infraestructura de Vercel | | Modelo de cobro | Créditos, con plan gratuito limitado por día y por mes | Tokens, con tope diario y mensual en el plan gratuito | Créditos incluidos por plan | | Dónde brilla | Aplicación completa con usuarios y datos desde el chat | Control fino del proyecto y trabajo con ramas | Producto que va a vivir en Next.js y Vercel | Todas las filas salen de la documentación oficial de cada herramienta, enlazada más abajo, consultada en septiembre de 2026. Los precios cambian a menudo: aquí se describe el modelo de cobro, no la tarifa del mes. ## Lovable: la aplicación entera desde la conversación Su [documentación](https://docs.lovable.dev/introduction) (consultada en septiembre de 2026) la define como una plataforma de desarrollo full-stack con IA para construir, iterar y desplegar aplicaciones web en lenguaje natural, con código real detrás. Genera frontend, backend, base de datos, autenticación e integraciones en el mismo sitio. **Qué genera.** Proyectos estándar de Vite y React. Lo dice su [guía de despliegue y propiedad del código](https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership) (consultada en septiembre de 2026), que además afirma "You own your code" y que puedes clonar el repositorio, modificarlo fuera y desplegarlo en tu infraestructura o autoalojarlo sin restricciones. **Qué control te deja.** Bastante, con un matiz de plan: según su [documentación del editor de código](https://docs.lovable.dev/features/code-mode) (consultada en septiembre de 2026), editar código está disponible en los planes de pago y en el plan gratuito el editor es de solo lectura. La sincronización con Git es bidireccional pero de una rama cada vez, según su [integración con GitHub](https://docs.lovable.dev/integrations/github) (consultada en septiembre de 2026). **Qué pasa al exportar.** Sales con un proyecto que cualquier equipo de frontend reconoce. Eso es mucho. Lo que no sale revisado son los permisos: su propia [documentación de Supabase](https://docs.lovable.dev/integrations/supabase) (consultada en septiembre de 2026) avisa de que la falta de políticas de Row Level Security es la forma más habitual de exponer los datos de una aplicación, y pide verificarlas a mano antes de publicar. **Para quién.** Quien quiere una aplicación con usuarios, datos y login sin montar un backend, y quiere poder llevársela después. El detalle completo, en [qué es Lovable y hasta dónde llega](https://fcgsystems.es/blog/lovable-que-es-y-hasta-donde-llega/). ## Bolt: el proyecto de ficheros, con ramas Su [centro de ayuda](https://support.bolt.new/get-started/intro-bolt) (consultado en septiembre de 2026) lo presenta como una herramienta de IA que convierte ideas en webs y aplicaciones reales, y menciona webs de marketing, portfolios, tiendas, paneles, herramientas internas y presentaciones. **Qué genera.** Aquí hay una restricción que conviene conocer antes de empezar, no después. Su página de [tecnologías soportadas](https://support.bolt.new/concepts/supported-technologies) (consultada en septiembre de 2026) dice que Bolt se centra en tecnologías web basadas en JavaScript, con Node.js en el backend, y que "Bolt solo admite backends en JavaScript, así que lenguajes como PHP o Python no son compatibles". Si tu equipo trabaja en Python o si el proyecto va a tirar de librerías que no existen en Node, Bolt queda fuera por diseño. **Qué control te deja.** Es donde mejor está. Según su [integración con GitHub](https://support.bolt.new/integrations/git) (consultada en septiembre de 2026), Bolt crea un commit cada vez que haces un cambio que no rompe el proyecto y comprueba GitHub cada 30 segundos para traerse lo que se haya hecho fuera. Admite ramas, cada una con su propia memoria. Dos avisos de la misma página: las fusiones de ramas hay que hacerlas en GitHub, no dentro de Bolt, y si hay cambios simultáneos, Bolt conserva los suyos y sobrescribe la versión de GitHub. Esa última línea merece un subrayado si vais a ser dos personas tocando lo mismo. **Qué pasa al exportar.** Como hay repositorio desde el minuto uno, no hay momento de exportación: hay un repositorio que ya existe. Es el flujo más cómodo de los tres para un equipo técnico que entra a mitad. **El coste.** Bolt cobra por tokens, y según su [documentación de tokens](https://support.bolt.new/account-and-subscription/tokens) (consultada en septiembre de 2026) la mayor parte del consumo viene de que Bolt lea, entienda y sincronice los ficheros de tu proyecto, así que los proyectos grandes consumen más por mensaje. El plan gratuito incluye un millón de tokens al mes con un tope diario de 300.000 que no se acumula. Traducido a decisiones: un proyecto que crece consume más por cada cosa que le pides, aunque le pidas lo mismo. ## v0: el camino corto hacia Next.js y Vercel Su [documentación](https://v0.app/docs/introduction) (consultada en septiembre de 2026) lo describe como un agente de IA que ayuda a crear código real y aplicaciones full-stack, y menciona Next.js, Tailwind y componentes shadcn/ui. **Qué genera.** Código dentro del ecosistema de Vercel. Si tu producto va a vivir ahí, eso no es una limitación: es que ya estás en casa. **Qué control te deja.** La misma documentación señala que puedes desplegar a producción de inmediato o abrir una pull request para revisión. Esa segunda opción es la interesante: mete lo generado en un flujo de revisión normal, con alguien mirando el diff antes de que llegue a producción. Es la forma sana de trabajar con código generado, y viene de serie. **Qué pasa al exportar.** Poco drama, porque el destino es un stack muy estándar. El riesgo aquí no es técnico, es de encaje: si el cliente tiene su infraestructura en otro sitio, empezar por v0 orienta el proyecto hacia Vercel desde el primer día. **El coste.** Funciona por créditos incluidos según plan, con un nivel gratuito. Las cifras exactas cambian con frecuencia y conviene mirarlas en su [página de precios](https://v0.app/pricing) antes de comprometer un presupuesto; no las reproducimos aquí para no dar un número caducado. ## El resto del mapa: Figma Make, Replit Agent y Cursor No son las mismas herramientas, pero salen en la misma conversación. **Figma Make.** Su [página oficial](https://www.figma.com/make/) (consultada en septiembre de 2026) lo resume como "prompt to code": lo que construyes está respaldado por código y es editable visualmente, y puedes saltar entre código y lienzo. Se apoya en tu contexto de diseño, con "Make kits" que sincronizan paquetes npm, estilos de librería y guías con Figma. Encaja cuando el equipo de diseño ya vive en Figma y el prototipo tiene que respetar un sistema de diseño existente. Ojo: la propia página marca como "coming soon" el uso local sobre cualquier base de código, así que conviene comprobar el estado de esa pieza antes de planificar con ella. **Replit Agent.** Según su [documentación](https://docs.replit.com/replitai/agent) (consultada en septiembre de 2026), convierte descripciones en lenguaje natural en aplicaciones funcionales, cubre planificación, desarrollo, pruebas y despliegue, y mantiene puntos de control para volver a un estado anterior. Construye y despliega dentro de Replit. Encaja cuando quieres que el entorno de desarrollo y el de ejecución sean el mismo sitio y no quieres tocar infraestructura. **Cursor.** Aquí hay un malentendido frecuente. Su [documentación](https://cursor.com/docs) (consultada en septiembre de 2026) lo define como un agente de programación para construir software ambicioso, que sirve para entender un repositorio, planificar y construir funcionalidades, corregir errores y revisar cambios. No es un generador de aplicaciones desde un prompt en blanco: es la herramienta con la que se trabaja sobre un repositorio que ya existe. Por eso no está en la tabla. En un proyecto real, las dos fases conviven: una de estas plataformas para la primera versión, y un entorno como Cursor para el trabajo posterior. Esa forma de trabajar tiene nombre propio y su propio manual de instrucciones: está en [qué es el vibe coding](https://fcgsystems.es/blog/que-es-vibe-coding/). ## Cuándo ninguna de las tres es la respuesta Hay cuatro situaciones en las que empezar por aquí es empezar torcido: - **Hay dinero de por medio con reglas propias.** Comisiones, prorrateos, descuentos por tramos, recobros. La lógica determinista se escribe, se prueba y se audita. Un modelo que "casi siempre" calcula bien una comisión no es una implementación, es un riesgo con interfaz. - **Hay datos personales sensibles o requisitos de cumplimiento.** Salud, menores, datos financieros. Aquí la primera pregunta no es qué herramienta, sino quién puede ver qué y qué se registra. - **El sistema tiene que integrarse con lo que ya existe.** Un ERP, un CRM con años de datos, una pasarela con su propia lógica de suscripciones. El prototipo no conoce esas reglas y el coste está justo ahí. - **El backend no puede ser JavaScript.** Con Bolt es una incompatibilidad declarada. Con las otras, es una fricción que aparece más tarde. En esos casos el prototipo sigue siendo útil, pero para otra cosa: para acordar la interfaz y el recorrido del usuario. El motor se construye aparte. Las señales de cuándo toca ese salto están en [de no-code a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/). ## Errores comunes al elegir - **Elegir por la demo de la web.** Todas enseñan el caso que mejor les sale. Prueba tu caso, con tus datos y tus integraciones, antes de decidir. - **No mirar dónde acaba el proyecto.** La pregunta buena es dónde vivirá dentro de un año y quién lo mantendrá. Eso descarta o confirma más que cualquier tabla. - **Ignorar el modelo de cobro.** Créditos y tokens no se consumen construyendo bien: se consumen sobre todo iterando. Cuanto más crece el proyecto, más cuesta cada petición. - **Confundir "el código es tuyo" con "el código está listo".** Sacarlo es un derecho, no una revisión. Lo que hay que mirar está en [revisar código generado por IA](https://fcgsystems.es/blog/revisar-codigo-generado-por-ia/). - **Mezclar dos herramientas en el mismo proyecto sin criterio.** Cada una impone su estructura. Convivir es posible; hacerlo sin decidirlo, no. - **Publicar sin revisar permisos.** Aplica a las tres, aunque solo una lo avise de forma tan explícita en su documentación. ## Checklist para decidir en diez minutos - ¿El backend puede ser JavaScript? Si no, Bolt queda fuera por su propia documentación. - ¿Dónde se va a desplegar esto en producción y quién lo va a mantener? - ¿Va a tocar código alguien más que tú? Si sí, mira primero cómo funciona la integración con Git de cada una. - ¿El proyecto tiene que respetar un sistema de diseño ya existente? Ahí Figma Make parte con ventaja. - ¿Cuánto vas a iterar? Multiplica por dos y mira el modelo de cobro con ese número. - ¿Hay datos personales o dinero? Entonces la decisión no es de herramienta, es de arquitectura. - ¿Podrías llevarte el proyecto mañana a otro sitio? Comprueba la vía de salida antes de empezar, no cuando la necesites. ## Y después de elegir, lo de siempre La elección de herramienta ocupa una tarde. Lo que ocupa el resto es lo mismo con las tres: modelo de datos que aguante, permisos verificados, pagos conciliados, copias de seguridad probadas y alguien que se entere cuando algo se rompe. Esa parte no la decide la comparativa. En FCG Systems cogemos ese prototipo, venga de donde venga, y lo convertimos en un sistema que se puede cobrar y mantener: [software a medida](https://fcgsystems.es/servicios/software-a-medida/) cuando es un proyecto cerrado, y [partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/) cuando lo que hace falta es alguien detrás mes a mes. Para agencias, también en marca blanca. El recorrido completo del prototipo a producción está en [de prototipo con IA a producción](https://fcgsystems.es/blog/de-prototipo-ia-a-produccion/), y la forma de trabajar con esto delante de un cliente, en [prototipos con IA para clientes de agencia](https://fcgsystems.es/blog/prototipo-con-ia-para-clientes-de-agencia/). Si ya has elegido y quieres una segunda opinión antes de comprometer un presupuesto, [cuéntame el caso](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Cuál es mejor: Lovable, Bolt o v0? Ninguna es mejor en abstracto. Lovable encaja cuando quieres una aplicación completa con base de datos y autenticación desde el chat. Bolt encaja cuando quieres control fino sobre los ficheros del proyecto y trabajar con ramas. v0 encaja cuando el destino es un proyecto Next.js desplegado en Vercel. Elige por dónde va a vivir el proyecto dentro de un año. ### ¿Qué diferencia hay entre Lovable y Bolt? Lovable genera un proyecto estándar de Vite y React con un backend incluido y sincronización con GitHub de una rama cada vez. Bolt trabaja sobre el proyecto de ficheros, crea un commit por cada cambio que no rompe el proyecto, sincroniza con GitHub y admite ramas, aunque las fusiones hay que hacerlas en GitHub. Bolt, además, solo admite backends en JavaScript. ### ¿Puedo exportar el código de estas herramientas y seguir en mi equipo? Sí, las tres dejan salida. Lovable afirma en su documentación que el código es tuyo y que puedes clonarlo y desplegarlo donde quieras. Bolt sincroniza con GitHub y crea commits automáticos. v0 permite desplegar a producción o abrir una pull request para revisión. Exportar es el principio del trabajo, no el final. ### ¿Y Figma Make, Replit Agent o Cursor? Figma Make genera prototipos respaldados por código desde el contexto de diseño, y encaja cuando el equipo ya vive en Figma. Replit Agent construye y despliega dentro de Replit, con puntos de control para volver atrás. Cursor es otra categoría: su documentación lo define como un agente de programación para entender un repositorio, planificar y construir funcionalidades y revisar cambios. No compite con las otras tres, se usa después. ### ¿Cuándo no hay que usar ninguna de estas herramientas? Cuando lo que hay que construir es lógica de negocio con reglas precisas, dinero de por medio o datos personales sensibles. Un cálculo de comisiones, una conciliación de pagos o un control de accesos no se prototipan: se especifican, se programan y se prueban. Ahí el prototipo sirve para la interfaz, no para el motor. ## Servicios relacionados - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/): Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Lovable: qué es, qué resuelve de verdad y hasta dónde llega antes de ser un producto > Qué es Lovable, qué construye realmente con IA y dónde está su límite: datos, permisos, pagos, dominio, copias y costes antes de llamarlo producto. - URL: https://fcgsystems.es/blog/lovable-que-es-y-hasta-donde-llega/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Software · Formato: Breakdown · Lectura: 10 min - Palabra clave: lovable que es (también: que es lovable, lovable español, para que sirve lovable, como funciona lovable, lovable opiniones, lovable es gratis, lovable ai) **Lovable es una plataforma que construye aplicaciones web a partir de instrucciones escritas en lenguaje natural.** Su propia documentación la describe como una plataforma de desarrollo full-stack con IA que genera frontend, backend, base de datos, autenticación e integraciones, con código editable detrás. Sirve para tener una primera versión funcionando en horas. No sirve, por sí sola, para tener un producto. Esa distinción es todo el artículo. Lovable hace muy bien una parte del trabajo, y esa parte antes costaba semanas. El problema aparece cuando se confunde "ya se ve y se puede pinchar" con "ya se puede cobrar por esto". Aquí va qué es, qué genera por debajo, dónde está su techo y qué hay que montar después para que aquello sea un producto y no una demo con dominio propio. ## ¿Qué es Lovable y cómo funciona? Escribes lo que quieres. Lovable genera la aplicación, la enseña en una vista previa y la itera contigo en el mismo chat. Según su [documentación de introducción](https://docs.lovable.dev/introduction) (consultada en septiembre de 2026), cada proyecto "produce un código que se puede sincronizar con GitHub, GitLab o Bitbucket" y se puede publicar en una URL. Tres piezas conviene entender desde el principio, porque son las que marcan hasta dónde llega: - **El código es real y es tuyo.** La documentación sobre [despliegue, hosting y propiedad del código](https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership) (consultada en septiembre de 2026) lo dice sin rodeos: "You own your code". Las aplicaciones son proyectos estándar de Vite y React que puedes clonar, modificar fuera de la plataforma y desplegar en AWS, GCP, Azure, Netlify, Cloudflare Pages, Vercel o tu propio servidor. - **Hay un backend incluido.** Lo llaman [Cloud](https://docs.lovable.dev/features/cloud) (consultada en septiembre de 2026): base de datos, almacenamiento, autenticación, tiempo real y funciones, sin montar infraestructura. Está construido sobre la base open source de Supabase, y quien ya tenía su propio proyecto de Supabase conectado puede seguir usándolo. - **Se sincroniza con Git en las dos direcciones.** Según su [integración con GitHub](https://docs.lovable.dev/integrations/github) (consultada en septiembre de 2026), lo que cambias en Lovable llega al repositorio y lo que empujas a la rama sincronizada vuelve a Lovable. El repositorio es privado por defecto y sigue siendo tuyo aunque desconectes la integración. Un detalle importante: Lovable sincroniza una sola rama a la vez. Esa última pieza es la que más se ignora y la que más cambia el escenario. Significa que un equipo técnico puede entrar a trabajar sobre lo generado sin empezar de cero. Es un buen diseño, y hay que decirlo. ## ¿Para qué sirve Lovable de verdad? Sin humo, esto es lo que resuelve bien: - **La primera versión.** Pasar de una idea a algo que se ve, se navega y se enseña. Eso antes se pagaba en semanas de maquetación y ahora sale en una tarde. - **La conversación con un cliente o un socio.** Enseñar una pantalla real cambia una reunión entera. La gente opina sobre lo que ve, no sobre lo que imagina. - **El descarte barato.** Tres ideas prototipadas y dos muertas en una semana es una buena semana. Ahí Lovable gana solo. - **Herramientas internas de bajo riesgo.** Un panel para el equipo, un formulario con lógica, una calculadora de presupuestos. Poco dato sensible, poco tráfico, poco que perder. - **El arranque de un proyecto que luego seguirá un equipo técnico.** Gracias a la sincronización con Git, lo generado es un punto de partida, no un callejón. El resto de este artículo no va contra Lovable. Va contra la idea de que con eso ya está. ## ¿Qué hay que montar después para que sea un producto? Aquí está la parte que ningún generador resuelve por ti, porque no son pantallas: son decisiones con consecuencias. ### 1. Los datos Una aplicación generada crea tablas a partir de tu descripción. Funciona en la demo porque los datos son tres filas que has metido tú. Con datos reales aparece lo de siempre: el mismo cliente dado de alta dos veces con dos correos distintos, un pedido sin cliente asociado, un campo de texto libre donde debería haber una lista cerrada. Lo que hay que resolver antes de que entre gente de verdad: claves únicas donde toca, relaciones con integridad, qué pasa cuando se borra algo que otra tabla usa, y qué dato es el bueno cuando dos sistemas discrepan. Esto es diseño de modelo de datos, y arreglarlo con la base ya llena cuesta mucho más que hacerlo antes. ### 2. Los permisos Este es el punto de fallo número uno, y no lo decimos nosotros. La [documentación de la integración con Supabase](https://docs.lovable.dev/integrations/supabase) (consultada en septiembre de 2026) avisa: antes de publicar, asegúrate de que cada tabla tiene políticas de Row Level Security que restrinjan quién lee y quién escribe cada fila, y verifícalas tú en el panel de Supabase, porque "la falta de políticas RLS es la forma más habitual de que los datos de una aplicación queden expuestos". Su [página de seguridad](https://docs.lovable.dev/features/security) (consultada en septiembre de 2026) es igual de clara sobre el escaneo automático que incluye la plataforma: ayuda a detectar problemas comunes, pero "no puede garantizar una seguridad completa" y "no sustituye una revisión de seguridad a fondo". Y remata: eres tú el responsable de que tu aplicación cumpla los requisitos de seguridad que le correspondan. Traducido: la herramienta te avisa, pero la responsabilidad no se delega. Un panel donde cualquier usuario autenticado puede consultar las filas de todos los demás es un incidente esperando fecha. Cómo se revisa esto está en la guía sobre [revisar código generado por IA](https://fcgsystems.es/blog/revisar-codigo-generado-por-ia/). ### 3. Los pagos Cobrar no es poner un botón. Es qué ocurre cuando la tarjeta se rechaza al tercer mes, cuando el webhook llega dos veces, cuando llega tarde, cuando no llega, cuando el usuario paga y el acceso no se activa, y cuando alguien pide la baja. Nada de eso se ve en una demo, porque en una demo el pago siempre sale bien. Ese es exactamente el agujero que describimos en [pagos fallidos de Stripe y accesos que no se cortan](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/): dinero que se escapa cada mes sin que nadie lo vea. Hace falta conciliación entre lo que dice la pasarela y lo que dice tu base de datos, y una alerta con responsable cuando no cuadran. ### 4. El dominio y la publicación Publicar en Lovable es inmediato, pero el dominio propio tiene condiciones. Según su [documentación de dominios personalizados](https://docs.lovable.dev/features/custom-domain) (consultada en septiembre de 2026), los dominios propios están disponibles en los planes de pago, la plataforma registra el dominio, configura los DNS y el SSL por ti, y el dominio no sirve contenido hasta que publicas el proyecto. La pregunta que hay que hacerse no es si se puede conectar el dominio. Es dónde quieres que viva esto dentro de un año: en la plataforma, o en tu propia infraestructura con tu propio despliegue. Las dos opciones son legítimas. La mala es no haberla decidido. ### 5. Las copias de seguridad y la vuelta atrás Lovable guarda historial de versiones del proyecto. Eso te cubre el código. No te cubre los datos de tus clientes. Preguntas que conviene poder responder antes de tener usuarios: ¿dónde está la copia de la base de datos de ayer?, ¿cuánto se tarda en restaurarla?, ¿alguien ha probado a restaurarla alguna vez? Una copia que nunca se ha restaurado no es una copia, es una carpeta. Y si la aplicación acaba viviendo fuera de la plataforma, esto pasa a ser tuyo entero. ### 6. Los costes Aquí hay que mirar el modelo de cobro, no el precio de entrada. Según la [documentación de planes de Lovable](https://docs.lovable.dev/introduction/subscription-plans) (consultada en septiembre de 2026): - El plan **Free** da 5 créditos de construcción al día con un tope de 30 al mes, más 20 créditos de Cloud mensuales. El editor de código es de solo lectura en este plan, según su [documentación del editor](https://docs.lovable.dev/features/code-mode) (consultada en septiembre de 2026). - El plan **Pro** arranca en 25 dólares al mes por 100 créditos y escala por tramos según los créditos que necesites. - El plan **Business** arranca en 50 dólares al mes por 100 créditos, con sus propios tramos. Los créditos se gastan construyendo, y construir incluye equivocarse. Cada iteración para arreglar algo que salió torcido consume. Por eso el coste real no se estima con el precio del plan, sino con cuántas vueltas vas a dar. Y ojo con el otro coste: el backend incluido tiene su propio consumo, y una aplicación con tráfico real no consume como una demo. ## Qué te da Lovable y qué tienes que montar tú | Pieza | Lovable | Lo que sigue siendo tuyo | |---|---|---| | Interfaz y navegación | La genera completa y editable | Accesibilidad, estados de error, comportamiento en móvil real | | Base de datos | Crea tablas y relaciones desde una descripción | Modelo correcto, claves únicas, integridad, migraciones con datos vivos | | Autenticación | Registro y login conectados | Roles, qué ve cada perfil, recuperación de cuenta | | Permisos de datos | Avisa y hace linting de políticas RLS | Definir y verificar cada política antes de publicar | | Pagos | Integra la pasarela | Webhooks idempotentes, conciliación, impagos, bajas | | Publicación | URL y dominio propio en planes de pago | Decidir dónde vive el sistema a medio plazo | | Código | Vite + React, sincronizado con Git | Revisión, pruebas de lo crítico, despliegue reproducible | | Copias de seguridad | Historial de versiones del código | Copias de datos, restauración probada | | Fallos | Corrige errores que detecta al construir | Saber qué se rompió en producción y avisar a alguien | La columna de la derecha no es un reproche a la herramienta. Es el trabajo que siempre ha existido y que ninguna herramienta de generación ha prometido nunca hacer. ## Errores comunes con Lovable - **Confundir la demo con el producto.** El demo funciona con tres filas y un usuario: tú. Producción son datos sucios, usuarios con prisa y fallos de red. - **Publicar sin revisar las políticas de permisos.** Lo avisa la propia documentación. Se sigue haciendo. - **Meter claves de API en el chat o en el código.** Lovable detecta claves pegadas en el chat y te guía para guardarlas en su almacén de credenciales ("Secrets"), según su página de seguridad. Aprovéchalo en vez de esquivarlo. - **No mirar el consumo hasta que llega la factura.** El coste no está en el plan, está en las iteraciones y en el tráfico real. - **Seguir pidiendo cambios cuando el problema es de arquitectura.** Si llevas quince vueltas sobre lo mismo, no necesitas otro prompt: necesitas decidir cómo debería estar montado. - **No sincronizar con Git desde el principio.** Es la vía de salida y el punto de entrada de cualquiera que venga a ayudarte. Conectarla tarde cuesta trabajo. - **Prometerle a un cliente una fecha basándose en lo que tardó el prototipo.** Ese error cuesta dinero y reputación; lo desarrollamos en [prototipos con IA para clientes de agencia](https://fcgsystems.es/blog/prototipo-con-ia-para-clientes-de-agencia/). ## Checklist antes de llamarlo producto - ¿Cada tabla tiene políticas de permisos y las has verificado tú, una a una? - ¿Hay claves únicas que impidan duplicar clientes, pedidos o inscripciones? - ¿Qué pasa si el mismo webhook de pago llega dos veces? - ¿Sabrías decir hoy qué pagos de este mes no cuadran con los accesos concedidos? - ¿Dónde está la copia de la base de datos y quién la ha restaurado alguna vez? - ¿Si algo se rompe un domingo, quién se entera y cómo? - ¿Hay datos personales? ¿Quién puede verlos y con qué base legal? - ¿El proyecto está en un repositorio propio al que tiene acceso alguien más que tú? - ¿Sabes cuánto costará esto al mes con diez veces el tráfico de hoy? Si hay más de tres noes, todavía no es un producto. Es un prototipo con buena pinta, que ya es mucho, pero no es lo mismo. ## ¿Entonces Lovable sirve o no? Sirve, y bastante. Para validar una idea, para enseñar algo tangible, para herramientas internas y para arrancar un proyecto que después seguirá un equipo. Y el hecho de que el código salga en un repositorio estándar de Vite y React lo separa de las herramientas que te encierran dentro. Lo que no hace es tomar las decisiones que convierten un programa en un negocio: qué dato es la verdad, quién puede ver qué, qué ocurre cuando falla el cobro, qué se hace cuando el servidor se cae un domingo. Eso no es un fallo de la herramienta. Es que ese trabajo nunca fue el de escribir pantallas. Construir sin entender es fracaso con buena pinta. Y la parte que hay que entender es justo la que no se ve en la vista previa. Si lo que quieres es entender la categoría entera antes que la herramienta, empieza por [qué es el vibe coding](https://fcgsystems.es/blog/que-es-vibe-coding/). Si quieres la comparación con las otras opciones, está en [Lovable vs Bolt vs v0](https://fcgsystems.es/blog/lovable-vs-bolt-vs-v0/). Si lo que tienes ya es un prototipo y la pregunta es cómo llevarlo a producción, el recorrido completo está en [de prototipo con IA a producción](https://fcgsystems.es/blog/de-prototipo-ia-a-produccion/). Y si vienes del no-code, las señales de cuándo toca dar el salto están en [de no-code a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/). ## Qué hacemos nosotros con esto En FCG Systems no venimos a decirte que tires el prototipo. Al revés: si ya tienes algo hecho en Lovable, tienes recorrido ganado y decisiones tomadas. Lo que hacemos es coger ese proyecto, revisar permisos y modelo de datos, montar el backend que aguante, cerrar los pagos y dejarlo desplegado con copias, alertas y quien responda cuando falla. Es el servicio de [software a medida](https://fcgsystems.es/servicios/software-a-medida/), y cuando el acompañamiento es continuo, el de [partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/). Para agencias lo hacemos también en marca blanca. Si tienes un prototipo y no sabes qué le falta para poder cobrarlo, [cuéntamelo](https://fcgsystems.es/contacto/) y te digo qué hay que tocar y en qué orden. ## Preguntas frecuentes ### ¿Qué es Lovable exactamente? Lovable es una plataforma que construye aplicaciones web a partir de instrucciones escritas en lenguaje natural. Su documentación la define como una plataforma de desarrollo full-stack con IA que genera frontend, backend, base de datos, autenticación e integraciones, todo respaldado por código editable. No es un maquetador de pantallas: produce un proyecto de código real. ### ¿Lovable es gratis? Hay un plan gratuito, pero está pensado para probar. Según su documentación de planes (consultada en septiembre de 2026), el plan Free da 5 créditos de construcción al día con un tope de 30 al mes, el editor de código es de solo lectura y los dominios propios están reservados a los planes de pago. Para sostener un proyecto en marcha hay que pasar a un plan de pago. ### ¿Puedo sacar el código que genera Lovable? Sí. Su documentación afirma literalmente "You own your code" y que los proyectos se pueden sincronizar con un repositorio de Git, clonar, modificar fuera de Lovable y desplegar en tu propia infraestructura. Las aplicaciones son proyectos estándar de Vite y React. Que puedas sacarlo no significa que esté listo para producción: eso lo decide una revisión, no la exportación. ### ¿Se puede lanzar un negocio real con una aplicación hecha en Lovable? Depende de qué maneje. Si es una herramienta interna, una lista de espera o un panel sin datos sensibles, puede aguantar. Si cobra dinero, guarda datos personales o da acceso a un contenido pagado, antes hay que resolver permisos a nivel de base de datos, conciliación de pagos, copias de seguridad y alertas cuando algo falla. ### ¿Qué es lo que más se rompe al llevar un proyecto de Lovable a producción? Los permisos de base de datos. La propia documentación de Lovable avisa de que las políticas de Row Level Security mal configuradas son la causa más habitual de fuga de datos y pide verificarlas en el panel de Supabase antes de publicar. Después vienen los pagos sin conciliar y la ausencia de alertas: el sistema falla y nadie se entera. ## Servicios relacionados - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/): Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Modelos de atribución: último clic, lineal, basado en datos y por qué ninguno te va a cuadrar solo > Qué son los modelos de atribución, cómo reparte el crédito cada uno, qué sesgo tiene y por qué un negocio digital necesita su propia atribución en el CRM. - URL: https://fcgsystems.es/blog/modelos-de-atribucion/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Breakdown · Lectura: 6 min - Palabra clave: modelos de atribución (también: modelo de atribucion, modelos de atribucion marketing, atribucion last click, atribucion basada en datos, modelo de atribucion ga4) Un modelo de atribución es la regla con la que repartes el crédito de una conversión entre los puntos de contacto que intervinieron antes de ella. No es un dato objetivo que venga en el informe: es un criterio que eliges, y cambiarlo cambia qué canal parece rentable sin que el negocio haya cambiado nada. Si has llegado aquí buscando cuál elegir, el resumen honesto es que ninguno te va a cuadrar solo. Los modelos estándar responden preguntas parciales; la decisión de presupuesto necesita además algo que solo está en tu CRM. Vamos por partes. ## ¿Cuáles son los modelos de atribución y cómo reparten el crédito? Tomemos un recorrido real: la persona ve un anuncio en Instagram, días después lee un email, luego busca tu marca en Google y compra. Cuatro toques, una venta. Así la reparte cada modelo: | Modelo | Cómo reparte | Qué favorece | Buena pregunta que responde | |---|---|---|---| | **Último clic** | 100 % al último toque (la búsqueda de marca) | Marca, remarketing, email de cierre | ¿Qué cierra la venta? | | **Primer clic** | 100 % al primer toque (el anuncio) | Contenido, campañas de descubrimiento | ¿Qué trae gente nueva? | | **Lineal** | 25 % a cada toque | Reparto neutro entre canales | ¿Qué canales participan? | | **Decaimiento temporal** | Más peso cuanto más cerca de la compra | Canales del final del recorrido | ¿Qué empuja en la recta final? | | **Basado en posición (en U)** | 40 % al primero, 40 % al último, 20 % al resto | Descubrimiento y cierre a la vez | ¿Quién abre y quién cierra? | | **Basado en datos** | Lo calcula la plataforma comparando recorridos que convirtieron con los que no | Depende de sus datos | ¿Qué correlaciona con convertir, según lo que esa plataforma ve? | Un apunte de realidad: Google ha ido retirando varios modelos basados en reglas de sus informes y hoy trabaja sobre todo con atribución basada en datos y último clic, como documenta en su [visión general de los modelos de atribución](https://support.google.com/analytics/answer/10596866) y en la [atribución en Google Ads](https://support.google.com/google-ads/answer/6259715) (consultado en septiembre de 2026). Así que la elección práctica es más estrecha de lo que sugieren los artículos con seis gráficos de colores. ## El sesgo de cada modelo, en una frase - **Último clic:** hace parecer geniales a la búsqueda de marca y al remarketing. Recortas lo que llenaba el embudo y las ventas caen un mes después, sin que el panel te avise. - **Primer clic:** ignora todo el trabajo de cierre. Con ciclos de venta largos, premia al anuncio que alguien vio hace cinco semanas y olvidó. - **Lineal:** suena justo y esconde las diferencias. Si un toque vale diez veces más que otro, el modelo los iguala. - **Decaimiento temporal:** razonable cuando la decisión es corta; injusto con lo que genera demanda a meses vista. - **En U:** el más equilibrado de los basados en reglas, y aun así, arbitrario: los porcentajes son una convención, no una medición. - **Basado en datos:** aprovecha información que tú no tienes, pero solo ve lo que esa plataforma puede medir y no se puede auditar desde fuera. Es una respuesta útil que no puedes reproducir ni explicar en una reunión. Hay un patrón debajo de todo esto: cada plataforma modela el mundo que ve, y el mundo que ve termina en su propio borde. Ninguna incluye la llamada comercial, la conversación de WhatsApp ni el pódcast donde te escucharon. ## Por qué ningún modelo te va a cuadrar solo Tres razones estructurales, ninguna arreglable con configuración: 1. **Universos distintos.** La plataforma de anuncios solo ve sus impactos; la analítica, las sesiones que el navegador le dejó medir; el CRM, a las personas. Aplicar un modelo sobre datos incompletos no los completa. 2. **Ventanas distintas.** Cada plataforma se apunta las conversiones dentro de su propio plazo tras un clic o una visualización. Los mismos hechos, con ventanas distintas, dan cifras distintas. 3. **Créditos que se solapan.** Si tres sistemas se atribuyen la misma venta, la suma supera a las ventas reales. No hay engaño; hay tres respuestas a la vez. El desarrollo completo de por qué las cifras no coinciden está en [qué es la atribución en marketing](https://fcgsystems.es/blog/que-es-la-atribucion/), y el recorrido paso a paso de dónde se pierde el dato, en [atribución rota: GA4, Meta y tu CRM](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/). ## La atribución que sí decide: la de tu CRM Para repartir presupuesto no necesitas el modelo perfecto. Necesitas dos campos en cada contacto del CRM: - **Primer origen:** fuente, medio y campaña con los que esa persona apareció por primera vez. - **Último origen:** los del contacto que precedió al registro o a la venta, sin sobrescribir el primero. Con eso, y con las ventas reales cruzadas por email o por un identificador propio, puedes construir dos informes que valen más que cualquier modelo de plataforma: - **Ventas por primer origen:** qué canal descubre clientes que acaban pagando. - **Ventas por último origen:** qué canal cierra. Cuando los dos informes coinciden, la decisión es evidente. Cuando divergen (mucho descubrimiento por contenido, mucho cierre por marca), ya sabes que recortar lo primero te va a costar lo segundo. Eso es lo que un modelo único nunca te enseña. Para que esos campos existan hace falta lo de siempre, y no es glamuroso: una convención de [parámetros UTM](https://fcgsystems.es/blog/que-es-utm/) que todo el mundo respete y campos ocultos en cada formulario. Sin eso, discutir modelos es decorar un dato ausente. ## ¿Qué modelo uso para cada decisión? Mi criterio práctico, por si te sirve de atajo: | Decisión | Dónde miro | |---|---| | Repartir presupuesto entre canales | Ventas por primer y último origen en el CRM | | Optimizar creatividades dentro de Meta o Google | El modelo propio de cada plataforma, sin comparar entre ellas | | Justificar inversión en contenido o marca | Primer origen y volumen de tráfico directo o de marca | | Ver si el ciclo de venta se alarga | Días entre primer contacto y venta, en el CRM | | Evaluar un lanzamiento concreto | Registros, llamadas y ventas por campaña, en el CRM | La regla que hay debajo: **cada herramienta responde a las preguntas de su propio ámbito.** Comparar el número de conversiones de Meta con las ventas del CRM no es rigor, es mezclar unidades. Y ese mismo principio es el que sostiene [los KPIs que de verdad hay que mirar](https://fcgsystems.es/blog/kpis-negocio-digital/). ## Errores habituales al elegir modelo - **Cambiar de modelo a mitad de trimestre** y comparar con el periodo anterior. La serie deja de ser comparable y nadie se acuerda de por qué. - **Sumar conversiones de varias plataformas.** Se solapan por diseño. - **Aplicar un modelo multitoque sin tener los toques.** Si el 40 % de los leads llega al CRM sin origen, cualquier reparto es una ficción bien formateada. - **Discutir modelos antes de arreglar la captura.** El orden correcto es: capturar el origen, cruzarlo con la venta y solo entonces elegir cómo repartir el crédito. - **Enviar eventos duplicados a las plataformas** y creer que la culpa es del modelo. Revisa primero la deduplicación: [píxel de Meta y API de conversiones](https://fcgsystems.es/blog/pixel-meta-api-conversiones-duplicados/). ## Por dónde empezar Exporta los leads del último trimestre y cuenta qué porcentaje llega sin origen. Si supera el 20 %, el trabajo no es elegir modelo: es capturar el dato. Si está por debajo, monta los dos informes (ventas por primer origen y por último origen) y compáralos antes de tocar un euro de presupuesto. En FCG Systems esto entra en [datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): captura del origen, atribución hasta el CRM y paneles que leen de la fuente correcta. Si estáis decidiendo inversión con informes que no cuadran, [cuéntame cómo lo medís ahora](https://fcgsystems.es/contacto/) y te digo por dónde miraría primero. ## Preguntas frecuentes ### ¿Qué es un modelo de atribución? Es la regla con la que se reparte el crédito de una conversión entre los puntos de contacto que intervinieron antes de ella. Si alguien ve un anuncio, abre un email y luego compra tras una búsqueda de marca, el modelo decide qué parte de esa venta se apunta cada canal. No es un dato objetivo: es un criterio que eliges. ### ¿Qué modelos de atribución existen? Los clásicos son último clic, primer clic, lineal, con decaimiento temporal, en forma de U (posición) y el basado en datos que calculan las propias plataformas. Google Analytics 4 y Google Ads trabajan hoy con atribución basada en datos y con último clic, tras retirar varios de los modelos basados en reglas de sus informes. ### ¿Cuál es el mejor modelo de atribución? No hay uno mejor para todo, porque cada modelo responde a una pregunta distinta. El primer clic dice qué canal descubre audiencia; el último clic, qué canal cierra. Lo práctico en un negocio digital es guardar el primer origen y el último origen de cada lead en el CRM y mirar los dos, en lugar de buscar un único reparto perfecto. ### ¿Qué problema tiene la atribución de último clic? Que premia al final del recorrido y castiga a lo que genera demanda. Con último clic, la búsqueda de marca y el remarketing parecen los canales más rentables, porque aparecen justo antes de la compra, mientras que el contenido o la campaña que hizo que alguien buscara tu marca no reciben nada. Se recorta el presupuesto de lo que llenaba el embudo y las ventas caen un mes después. ### ¿Qué es la atribución basada en datos? Es un modelo en el que la plataforma reparte el crédito según sus propios cálculos, comparando recorridos que convirtieron con recorridos que no. Aprovecha datos que tú no tienes, pero solo ve los puntos de contacto que esa plataforma puede medir y no se puede auditar desde fuera: es una respuesta útil que no puedes reproducir. ## Servicios relacionados - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Casos relacionados - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/): Formularios, tracking, CRM y agenda comercial conectados en un solo sistema, con el origen de cada lead a la vista. Las tres etapas del funnel mejoraron. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Prototipos con IA para clientes de agencia: vender y validar sin prometer lo que no se sostiene > Cómo usar Lovable, Bolt o v0 para vender y validar con tu cliente sin prometer de más, qué entregar al equipo técnico, qué preguntar y qué no firmar. - URL: https://fcgsystems.es/blog/prototipo-con-ia-para-clientes-de-agencia/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Software · Formato: Opinión · Lectura: 9 min - Palabra clave: prototipo con ia para clientes (también: prototipo con ia, lovable para agencias, vender proyectos de software con ia, mvp con ia para clientes, white label desarrollo agencia) **Un prototipo hecho con IA vende mejor que una propuesta en PDF, y ese es justo el riesgo.** El cliente ve pantallas que funcionan y asume que el trabajo está casi hecho. Si tu agencia no encuadra esa reunión, acabará firmando una fecha y un precio calculados sobre una demo que no guarda datos, no cobra dinero y no aguanta a diez personas dentro. Este artículo va de cómo usar estas herramientas a favor: para vender mejor, para validar antes y para llegar al equipo técnico con algo aprovechable. Y de las tres o cuatro frases que no hay que decir nunca en esa reunión. ## Qué cambia un prototipo en una venta de agencia Cambia bastante, y para bien: - **Acorta la discusión sobre el alcance.** La gente opina mucho mejor sobre lo que ve. Dos rondas de comentarios sobre un prototipo valen más que seis reuniones sobre un documento. - **Saca a la luz los requisitos escondidos.** El cliente ve la pantalla de alta de usuario y suelta: "aquí también hay que poder importar los de la base antigua". Eso, en un PDF, no sale hasta el mes tres. - **Reduce el coste de decir que no.** Prototipar tres ideas y descartar dos es una semana bien invertida. Descartarlas después de firmar cuesta el proyecto. - **Te posiciona distinto.** Llegas con algo hecho a una reunión donde el resto lleva diapositivas. Lo que no cambia es el trabajo que hay debajo. La velocidad que has ganado es la de la primera versión de la interfaz. El modelo de datos, los permisos, las integraciones y la operación siguen costando lo mismo que costaban. ## Lo que el prototipo demuestra y lo que no Esta tabla es, literalmente, la que conviene tener delante en la reunión. | Lo que el prototipo sí demuestra | Lo que no demuestra | |---|---| | Qué pantallas hay y cómo se navega entre ellas | Que el sistema aguante mil usuarios a la vez | | Qué información ve el usuario en cada paso | Que cada usuario vea solo lo suyo | | Si el recorrido tiene sentido para quien lo va a usar | Que los datos sobrevivan a un error, un borrado o una migración | | Cómo se siente la herramienta al usarla | Que el cobro se registre bien cuando la pasarela falla o repite el aviso | | Que la idea se entiende y se puede explicar | Que se pueda integrar con el ERP, el CRM o la plataforma que el cliente ya usa | | El tono visual y el encaje con la marca | Cuánto costará mantenerlo cada mes | La columna de la izquierda es mucho. Es, de hecho, lo que antes costaba semanas. Pero si el cliente sale de la reunión creyendo que también ha visto la de la derecha, el problema es de la agencia, no del cliente. ## Cómo encuadrar la reunión sin bajar el nivel de la venta No hace falta rebajar nada. Hace falta ser preciso. Tres frases concretas, para decirlas tal cual: > "Esto es un prototipo funcional. Sirve para que acordemos las pantallas y el recorrido antes de construir. No guarda datos reales y no es la versión que se entrega." > "Lo que ves aquí se ha hecho en dos días. Lo que hay detrás (permisos, integraciones, pagos y puesta en producción) es la mayor parte del proyecto y lo presupuestamos aparte." > "Antes de darte una fecha necesito saber con qué sistemas tiene que hablar esto y quién tiene que poder ver qué. Eso es lo que mueve el plazo." Fíjate en lo que hacen esas tres frases a la vez: no le quitan mérito a lo que has enseñado, dejan claro que queda trabajo y convierten la siguiente conversación en una de requisitos, no de descuento. Un cliente serio agradece esto. Los que no lo agradecen suelen ser los que luego discuten cada factura. Y una frase que no hay que decir nunca: "esto ya está prácticamente hecho". Aunque lo parezca. Sobre todo si lo parece. ## Las promesas que no se sostienen Cuatro, por orden de frecuencia: 1. **La fecha calculada sobre el prototipo.** "Si esto ha salido en dos días, en tres semanas lo tenemos." No. El prototipo no tenía que conciliar pagos, ni migrar 12.000 contactos, ni cumplir con lo que exige el departamento legal del cliente. 2. **El precio cerrado antes de conocer las integraciones.** La integración con el sistema que el cliente lleva usando ocho años es casi siempre la partida más cara, y casi nunca se ve en el prototipo. 3. **"El cliente podrá seguir editándolo él mismo desde el chat."** Es verdad mientras el proyecto viva dentro de la herramienta. En cuanto el equipo técnico se lleva el repositorio y añade su propia lógica, seguir pidiendo cambios por chat es la vía directa a romper lo que funcionaba. Si prometes esa autonomía, prométela para el contenido, no para el sistema. 4. **"Funciona igual con datos reales."** El prototipo funciona con tres filas metidas por ti. Producción son datos duplicados, campos vacíos, nombres con acentos raros y gente pulsando dos veces el botón de pagar. Hay una que además es técnica y conviene conocer antes de comprometerse: si el proyecto necesita un backend que no sea JavaScript, algunas de estas herramientas lo descartan por diseño. La documentación de [tecnologías soportadas de Bolt](https://support.bolt.new/concepts/supported-technologies) (consultada en septiembre de 2026), por ejemplo, dice que solo admite backends en JavaScript y que PHP o Python no son compatibles. Prometer una integración con el sistema en PHP del cliente sobre un prototipo hecho ahí es prometerse un rehacer. ## Qué validar de verdad con el prototipo Si vas a invertir dos días en esto, que sirvan para reducir riesgo, no solo para impresionar: - **Lleva el prototipo a quien lo va a usar, no solo a quien lo paga.** Las personas de atención al cliente, de almacén o de administración desmontan en quince minutos supuestos que el director daba por buenos. - **Fuerza los casos feos delante del cliente.** ¿Qué pasa si este campo llega vacío? ¿Y si el mismo cliente aparece dos veces? Sus respuestas son requisitos, y salen gratis en esta fase. - **Pregunta por el dato, no por la pantalla.** "¿De dónde sale este listado hoy?" suele destapar una hoja de cálculo que alguien mantiene a mano y que es, en realidad, el sistema que hay que sustituir. - **Mide algo.** Si el prototipo se enseña a usuarios, apunta cuántos completan el recorrido sin ayuda. Eso es validación; lo demás es opinión. ## El paso al equipo técnico Aquí se pierde la mitad del valor del prototipo, casi siempre por lo mismo: se entrega el enlace y nada más. Esto es lo que hay que entregar. ### Qué entregar - **El repositorio, con acceso.** No una URL de vista previa. El código, en un repositorio al que el equipo técnico pueda entrar. Si la herramienta sincroniza con Git, conéctalo desde el primer día y no el día de la entrega. - **La lista de lo que el prototipo dio por supuesto.** Cada pantalla tomó decisiones que nadie discutió: qué campos son obligatorios, qué pasa al borrar, qué ve cada perfil. Escríbelas. Son el núcleo de la especificación. - **El modelo de datos real, con volúmenes.** Cuántos registros hay hoy, cuántos entrarán al mes, de dónde vienen y en qué estado. La diferencia entre 200 y 200.000 filas cambia la arquitectura, no el precio. - **Los sistemas con los que hay que integrarse**, con documentación y credenciales de pruebas. Si no hay entorno de pruebas, eso ya es un riesgo del proyecto y hay que decirlo antes de firmar. - **Los perfiles de usuario y qué puede ver y hacer cada uno.** Esta es la pieza que más se olvida y la que más incidentes provoca. La documentación de [la integración de Lovable con Supabase](https://docs.lovable.dev/integrations/supabase) (consultada en septiembre de 2026) lo dice de forma directa: la falta de políticas de permisos a nivel de fila es la forma más habitual de que los datos de una aplicación queden expuestos, y hay que verificarlas a mano antes de publicar. - **El criterio de éxito del cliente.** Qué tiene que pasar para que considere que el proyecto ha ido bien. Si no está escrito, se redefine cada mes. ### Qué preguntar antes de presupuestar - ¿Con qué sistemas tiene que hablar esto y quién los administra hoy? - ¿Hay datos personales? ¿De qué tipo y quién debe poder verlos? - ¿Se cobra dinero dentro? ¿Con qué pasarela y qué pasa cuando un pago falla? - ¿Cuántos usuarios y cuántos registros, hoy y dentro de un año? - ¿Qué hay que migrar y desde dónde? ¿Quién valida que la migración es correcta? - ¿Quién mantendrá esto después de la entrega? ¿Vosotros, ellos, nadie? - ¿Qué pasa si el sistema se cae un domingo? ¿Hay compromiso de disponibilidad? - ¿Hay alguna decisión ya tomada que no se puede cambiar? Proveedor de infraestructura, idioma, normativa del sector. Las respuestas a estas ocho preguntas son el presupuesto. El prototipo es la portada. ### Qué no firmar - **Fecha cerrada calculada sobre el tiempo del prototipo.** Si el cliente necesita una fecha, dale la de una primera fase acotada, no la del sistema entero. - **Precio cerrado sin conocer las integraciones.** O se investigan antes (y eso también se cobra), o el precio es por fases. - **Mantenimiento incluido "por si acaso", sin definir.** Mantener no es corregir errores gratis para siempre. Define qué entra, cuántas horas y con qué tiempo de respuesta. - **Penalizaciones por caídas sin monitorización acordada.** Si te comprometes a disponibilidad, tiene que haber alertas, guardias y alguien que responda. Si no lo hay, no firmes el compromiso. - **Propiedad del código sin decir de qué código.** Aclara qué se entrega, en qué repositorio y con qué licencias de terceros. También quién paga las cuentas de las plataformas: las suscripciones de la herramienta, del hosting y de la base de datos tienen dueño y hay que nombrarlo. - **Depender de una sola persona sin contrato que lo cubra.** Si todo el proyecto vive en la cabeza de un freelance, el riesgo es tuyo ante el cliente. Ese patrón lo desarrollamos en [cuando todo depende de una sola persona](https://fcgsystems.es/blog/dependencia-de-una-persona-capacidad-tecnica/). ## Errores comunes de agencia con esto - **Enseñar el prototipo sin encuadre y corregir después.** El encuadre cuesta treinta segundos al principio y una renegociación al final. - **Tratar el prototipo como entregable.** Es una herramienta de conversación. Si se entrega, se entrega con lo de arriba. - **Iterar el prototipo hasta el infinito.** Llega un punto en que cada cambio cuesta más que hacerlo bien. Suele coincidir con la primera vez que dices "es que no consigo que haga justo esto". - **Firmar y buscar después quién lo construye.** El orden correcto es al revés: alcance cerrado con el socio técnico y entonces se firma. - **No revisar el código generado antes de basar un presupuesto en él.** Lo que hay que mirar está en [revisar código generado por IA](https://fcgsystems.es/blog/revisar-codigo-generado-por-ia/). - **Olvidar la operación.** Copias de seguridad, alertas, accesos, soporte. Lo que hay que tener resuelto antes de abrir al público está en el [checklist técnico de lanzamiento](https://fcgsystems.es/blog/checklist-tecnico-lanzamiento/). ## Cómo se hace el paso bien, en resumen El prototipo abre la puerta y acorta el alcance. El encuadre protege el presupuesto. Las ocho preguntas convierten una demo en un proyecto presupuestable. Y la entrega al equipo técnico no es un enlace: es repositorio, supuestos escritos, modelo de datos, integraciones, permisos y criterio de éxito. Hecho así, estas herramientas son un buen negocio para una agencia. Hecho de la otra forma, son la mejor máquina de firmar proyectos que se entregan tarde y con pérdidas. ## Dónde encajamos nosotros En FCG Systems trabajamos con agencias en las dos modalidades. Podemos entrar antes de firmar, para cerrar el alcance técnico y que el presupuesto refleje el trabajo real. Y podemos entrar después, para construir el backend, asegurarlo y mantenerlo mientras la relación con el cliente sigue siendo vuestra: eso es lo que hacemos en marca blanca, dentro del servicio de [partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/), o como proyecto cerrado en [software a medida](https://fcgsystems.es/servicios/software-a-medida/). Si quieres el contexto de las herramientas antes de elegir, empieza por [Lovable vs Bolt vs v0](https://fcgsystems.es/blog/lovable-vs-bolt-vs-v0/) y por [qué es Lovable y hasta dónde llega](https://fcgsystems.es/blog/lovable-que-es-y-hasta-donde-llega/). El recorrido técnico completo está en [de prototipo con IA a producción](https://fcgsystems.es/blog/de-prototipo-ia-a-produccion/), y el marco general de trabajar así, en [qué es el vibe coding](https://fcgsystems.es/blog/que-es-vibe-coding/). Si tienes un prototipo encima de la mesa y una propuesta a punto de salir, [cuéntamelo antes de enviarla](https://fcgsystems.es/contacto/) y te digo qué falta por cerrar. ## Preguntas frecuentes ### ¿Puedo enseñarle a un cliente un prototipo hecho con IA? Sí, y suele mejorar la conversación. Lo que no se puede es enseñarlo sin encuadre. Di desde el primer minuto que es un prototipo para acordar el alcance y el recorrido del usuario, que no guarda datos reales y que no es la versión que se entrega. Si el cliente se lleva otra idea de la reunión, el problema aparece al firmar. ### ¿Cómo presupuesto un proyecto a partir de un prototipo? No presupuestes sobre lo que se ve, presupuesta sobre lo que hay debajo. El prototipo cubre pantallas y recorrido; el presupuesto tiene que cubrir modelo de datos, permisos, integraciones con lo que el cliente ya usa, pagos, despliegue, copias y soporte. Presupuestar la interfaz y regalar el motor es el error clásico. ### ¿Qué tengo que entregarle al equipo técnico además del prototipo? El repositorio con acceso, la lista de decisiones que el prototipo dio por supuestas, el modelo de datos real con volúmenes esperados, los sistemas con los que hay que integrarse y sus credenciales de prueba, los perfiles de usuario con qué puede ver cada uno, y el criterio de éxito del cliente. Sin eso, el equipo técnico reconstruye a ciegas. ### ¿Qué cláusulas conviene no firmar? Fecha de entrega cerrada calculada sobre el tiempo que costó el prototipo. Precio cerrado antes de conocer las integraciones reales. Compromiso de que el cliente podrá seguir editando la aplicación desde el chat de la herramienta una vez pase a producción. Y penalizaciones por caídas sin un acuerdo de soporte y monitorización que las respalde. ### ¿Y si la agencia no tiene equipo técnico propio? Entonces el prototipo es media venta y el riesgo es entero. La salida sana es cerrar el alcance con un socio técnico antes de firmar, no después, y decidir si ese socio aparece ante el cliente o trabaja en marca blanca bajo tu marca. Lo que no funciona es firmar y buscar después a quién se lo encargas. ## Servicios relacionados - [Partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/): Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Qué es el vibe coding: de dónde viene, dónde funciona de verdad y dónde te la juegas > Qué es el vibe coding, quién acuñó el término y en qué casos funciona: prototipos e internas sí, dinero, datos y accesos no. Con el límite explicado sin humo. - URL: https://fcgsystems.es/blog/que-es-vibe-coding/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Software · Formato: Opinión · Lectura: 9 min - Palabra clave: que es vibe coding (también: vibe coding, vibe coding que es, que es el vibe coding, vibe coding en español, crear app con ia, vibe coding riesgos) El **vibe coding** es construir software describiendo en lenguaje natural lo que quieres y aceptando el código que genera la IA sin revisarlo a fondo. Sirve para llegar a algo que funciona en horas. Deja de servir en el momento en que ese algo toca dinero, datos personales o accesos de usuarios reales. Esa es la respuesta corta. La larga tiene matices, porque el término se ha convertido en trinchera: o eres un creyente que enseña capturas de una app montada en un fin de semana, o eres el que dice que todo esto es un desastre. Ninguna de las dos posturas es útil si tu trabajo consiste en entregarle algo a un cliente. ## ¿De dónde viene el término "vibe coding"? Lo acuñó Andrej Karpathy en febrero de 2025 en un mensaje en X. Su descripción era deliberadamente provocadora: dejarse llevar por las vibraciones, abrazar las exponenciales y "olvidar que el código siquiera existe". Hablaba de proyectos de fin de semana, de cosas desechables, de no leer los diffs. La recopilación de fuentes y coberturas del término está en la [entrada de Wikipedia sobre vibe coding](https://en.wikipedia.org/wiki/Vibe_coding) (consultada en septiembre de 2026). El matiz que se perdió por el camino es importante: Karpathy describía una forma de trabajar para cosas que no importan si se rompen. Un año y medio después, "vibe coding" se usa para describir la construcción de productos que sí importan. Ahí es donde empieza el problema. Y ojo, el término se ha institucionalizado rápido: diccionarios lo han recogido como palabra del año. Eso dice mucho de la velocidad de adopción y nada de la calidad del resultado. ## ¿Qué herramientas se usan para hacer vibe coding? Conviene separarlas, porque no hacen lo mismo y las agencias las mezclan en la misma frase. | Herramienta | Qué es, según su documentación oficial | Dónde encaja | |---|---|---| | **Lovable** | Entorno que genera una app completa y la publica en una URL en vivo, con integración de base de datos y escáneres de seguridad integrados | Demo funcional con backend real | | **Bolt.new** | "Una herramienta de IA que convierte tus ideas en webs y apps reales", con base de datos y publicación propias | Demo funcional, iteración rápida | | **v0** (Vercel) | "Un agente de IA que ayuda a cualquiera a crear código real y apps full-stack", con Next.js, Tailwind y shadcn/ui | Interfaces y prototipos que luego entran en un repo | | **Figma Make** | "Herramienta de prompt-a-app impulsada por IA" que convierte ideas y diseños de Figma en prototipos funcionales publicables | Prototipo de diseño con comportamiento real | | **Cursor** | Editor con agente para "construir software ambicioso", con revisión de diffs y ejecución de comprobaciones | Trabajo continuado sobre un repositorio | (Fuentes: [documentación de Lovable](https://docs.lovable.dev/features/publish), [soporte de Bolt](https://support.bolt.new/cloud/hosting/publish), [documentación de v0](https://v0.app/docs/introduction), [centro de ayuda de Figma](https://help.figma.com/hc/en-us/articles/31304412302231-Explore-Figma-Make) y [documentación de Cursor](https://cursor.com/docs/get-started/concepts), todas consultadas en septiembre de 2026.) Fíjate en la línea que separa la tabla por la mitad: las cuatro primeras te llevan de cero a una demo desplegada. La última asume que ya hay un proyecto y te ayuda a trabajar dentro de él. Son fases distintas del mismo problema, y confundirlas es la causa del 80% de los atascos que veo. ## ¿Por qué el vibe coding funciona tan bien al principio? Porque la primera versión de cualquier software es, en su mayor parte, trabajo repetitivo. Formularios, tablas, rutas, estilos, un CRUD, una pantalla de login que *parece* una pantalla de login. Todo eso está escrito millones de veces en internet y un modelo lo reproduce con una fidelidad altísima. Así que sí: en una tarde tienes una app con su navegación, su diseño decente y sus datos de prueba. Para una agencia esto es un cambio enorme. Puedes enseñarle al cliente algo que se toca en vez de un Figma estático, y puedes hacerlo dentro del presupuesto de la fase de propuesta. Eso es valor real, no humo. El problema es que ese 80% visible es el 20% del trabajo. Lo que queda fuera de la demo es precisamente lo que hace que un software sea un producto: quién puede ver qué, qué pasa cuando el pago falla, dónde están los datos, quién se entera cuando algo se rompe a las tres de la mañana. ## ¿Dónde brilla el vibe coding? Estos son los casos donde lo usaría sin dudarlo, y donde de hecho tiene todo el sentido del mundo para un equipo creativo: - **Prototipos para vender**. Enseñar el flujo real en una reunión en vez de describirlo. Convierte muchísimo mejor que un PDF. - **Validar una idea antes de presupuestarla**. Si el flujo no se sostiene ni en una demo, no se va a sostener en un proyecto de seis semanas. - **Herramientas internas de un solo uso**. Un panel para que el equipo revise entregas, un conversor, un visor de datos que solo usáis vosotros y que no contiene nada sensible. - **Explorar una interfaz**. Cinco variantes de una pantalla en el tiempo que antes costaba maquetar una. - **Aprender el terreno**. Ver cómo se estructura una app de verdad es una forma rapidísima de entender de qué se habla en las reuniones técnicas. En todos estos casos el coste de que el resultado esté mal por dentro es cero, porque nada depende de que esté bien. ## ¿Dónde te la juegas? Aquí es donde toca ser claro, sin dramatizar. El riesgo no está repartido por igual: se concentra en cuatro sitios. ### 1. Permisos y control de acceso Es el punto número uno. El **control de acceso roto** es la primera categoría del [OWASP Top 10:2025](https://top10.owasp.org/2025/A01_2025-Broken_Access_Control/) (consultado en septiembre de 2026), y es exactamente lo que una demo no puede enseñarte: en la demo tú eres el único usuario, así que todo lo que ves es lo que deberías ver. Cuando la app usa una base de datos accesible desde el navegador, el modelo por defecto es peligroso. La propia [documentación de Supabase sobre Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security) lo dice sin rodeos: *"una tabla en un esquema expuesto sin RLS es legible y escribible por cualquier rol que tenga permiso sobre ella"* (consultado en septiembre de 2026). Traducido: si nadie activó y escribió las políticas, cualquiera con la clave pública de tu app puede leer la tabla de clientes entera. ### 2. Secretos y configuración Claves de API en el código del navegador, variables de entorno que acaban en el bundle, configuraciones de desarrollo publicadas tal cual. Es la segunda categoría del Top 10:2025, [configuración de seguridad incorrecta](https://top10.owasp.org/2025/A02_2025-Security_Misconfiguration/). Una demo no falla por esto. Una app publicada, sí. ### 3. Dinero Cobrar es la parte del software donde los errores no se pueden deshacer con un despliegue. Un webhook de pago que se procesa dos veces, un acceso que no se revoca cuando la suscripción caduca, un precio que se calcula en el navegador en vez de en el servidor. Nada de eso se ve en una demo porque en una demo nadie paga. ### 4. Lo que no existe hasta que se rompe Logs, alertas, copias de seguridad, límites de uso. El [fallo en el registro y las alertas de seguridad](https://top10.owasp.org/2025/A09_2025-Security_Logging_and_Alerting_Failures/) está en el Top 10:2025 por una razón: sin eso, no es que no puedas arreglar el problema, es que no te enteras de que existe. ## ¿Las propias herramientas no resuelven esto? En parte, y hay que reconocérselo: lo están trabajando en serio. Lovable, por ejemplo, incluye escaneos que revisan políticas de RLS, el esquema de base de datos, dependencias con vulnerabilidades conocidas, secretos expuestos y control de acceso. Pero su propia documentación pone el límite con una honestidad que agradezco: *"estas herramientas ayudan a identificar problemas de seguridad comunes, pero no pueden garantizar una seguridad completa"* y *"no sustituyen una revisión de seguridad exhaustiva"*. Y añade la frase que debería estar enmarcada en toda agencia: *"eres responsable de asegurar que tu app cumple los requisitos de seguridad apropiados para su caso de uso"* ([documentación de seguridad de Lovable](https://docs.lovable.dev/features/security), consultada en septiembre de 2026). Eso no es letra pequeña defensiva. Es una descripción exacta de dónde acaba la herramienta y dónde empieza el criterio. Un escáner estático encuentra lo que ya sabe buscar; no sabe que en tu modelo de negocio un usuario del plan básico no debería poder descargar el informe completo. ## Vibe coding con criterio de ingeniero La postura que defiendo no es "no uses IA". Es la contraria: úsala a fondo, y cambia dónde pones tu atención. Construir sin entender es fracaso con buena pinta. Una app generada que funciona en la demo y se cae en el primer cliente real no es un ahorro de tiempo, es una deuda con intereses y con tu nombre encima. Y si la agencia es la cara ante el cliente final, la factura emocional la pagas tú, no el modelo. Lo que cambia con la IA no es que trabajes menos. Es qué parte del trabajo es tuya: - **Antes**: escribir el código era el cuello de botella; revisar era barato en comparación. - **Ahora**: generar es casi gratis; **juzgar** es el cuello de botella. Decidir qué está bien, qué falta y qué no puede salir así. Esto no es una metáfora bonita. Es un cambio de reparto de horas en un presupuesto. Si vendes un proyecto asumiendo que la IA te ahorra el 70% del tiempo y no reservas horas para revisión, arquitectura y puesta en producción, ese proyecto va a perder dinero. ## ¿Qué hago con la demo que ya tengo? Si has llegado hasta aquí probablemente ya tienes una app generada, funciona, y la pregunta no es filosófica sino práctica: qué le falta. La lista corta, que desarrollo entera en [de prototipo con IA a producción](https://fcgsystems.es/blog/de-prototipo-ia-a-produccion/): 1. Autenticación y permisos de verdad, verificados en el servidor. 2. Una base de datos con dueño, copias de seguridad y una restauración probada. 3. Pagos y accesos que se sincronizan solos, incluidos los fallos. 4. Límites de uso y protección contra abuso. 5. Logs y alertas en todo lo que toque dinero o datos. 6. Costes previsibles. 7. Propiedad del código y del stack a nombre de quien corresponde. Y antes de nada, una revisión del código que ya existe: qué mirar y en qué orden está en [cómo revisar el código generado por IA](https://fcgsystems.es/blog/revisar-codigo-generado-por-ia/). Si lo que descubres al revisar es que el prototipo no aguanta y hay que reconstruir la parte crítica, ese camino tiene su propio recorrido, muy parecido al de pasar [de no-code a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/): no se tira todo, se sustituye la pieza que ya no aguanta. ## Lo que le diría a una agencia que acaba de descubrir esto Tres cosas. **Una**: seguid usándolo. Es la mejor herramienta de venta y de validación que habéis tenido nunca. Un prototipo que se toca cierra proyectos. **Dos**: no vendáis la demo como producto. Vended la demo como demo y el producto como producto, con dos presupuestos, dos plazos y dos alcances. La conversación honesta con el cliente es más fácil de tener antes que después. **Tres**: decidid quién hace la parte que la demo no cubre. Puede ser alguien de vuestro equipo, puede ser un socio técnico. Lo que no puede es no estar decidido, porque el día que el cliente pregunte "¿esto está listo para lanzar?" alguien va a tener que responder. ## ¿Te has quedado atascado en la demo? Si tienes un prototipo hecho con Lovable, Bolt, v0 o Figma Make que funciona y no sabes qué le falta para poder facturarlo, eso es exactamente el trabajo que hago: coger lo que ya existe, decirte qué se aprovecha y qué no, y llevarlo a producción con permisos, pagos, datos y observabilidad de verdad. También en **white label**, de forma que la agencia sigue siendo la cara ante su cliente. [Cuéntame en qué punto está tu prototipo](https://fcgsystems.es/contacto/) y te digo sin rodeos qué falta. Si lo que buscas es que alguien construya la versión sólida, está en [software a medida](https://fcgsystems.es/servicios/software-a-medida/); si lo que necesitáis es un equipo técnico detrás de forma continuada, en [partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/). ## Preguntas frecuentes ### ¿Qué significa vibe coding exactamente? Describir en lenguaje natural lo que quieres que haga un programa y dejar que un modelo de IA escriba el código, aceptándolo sin revisarlo línea a línea. El término lo acuñó Andrej Karpathy en febrero de 2025 y describe una actitud ante el código, no una herramienta concreta. ### ¿El vibe coding sirve para producción? Sirve para llegar a algo que funciona muy rápido. No sirve, por sí solo, para sostenerlo cuando toca dinero, datos personales o accesos. Ahí hacen falta permisos reales, control de errores, observabilidad y alguien que entienda por qué funciona lo que se ha generado. ### ¿Lovable, Bolt, v0, Figma Make y Cursor son lo mismo? No. Lovable, Bolt, v0 y Figma Make son entornos de prompt-a-app que generan y alojan una aplicación completa; Cursor es un editor de código con agente, pensado para trabajar sobre un repositorio existente. Los primeros te llevan a la demo; el segundo te acompaña en el mantenimiento. ### ¿Es peligroso publicar una app hecha con vibe coding? Depende de qué toque. Una landing o una demo interna, no. Una app con login, base de datos o pagos publicada sin revisar permisos y secretos sí es un riesgo real: la propia documentación de estas herramientas avisa de que sus escaneos automáticos no sustituyen una revisión de seguridad. ### ¿Entonces no hay que usar estas herramientas? Al contrario. Son excelentes para lo que son: explorar una idea, validar un flujo con un cliente o enseñar algo tangible en una reunión. El error no es usarlas, es confundir la demo que producen con un producto listo para facturar. ## Servicios relacionados - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Sistemas de IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. - [Partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/): Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Qué es la atribución en marketing (y por qué nunca cuadra entre canales) > Qué es la atribución en marketing, qué significa atribuir una venta a un canal, por qué las cifras no coinciden entre herramientas y qué mirar para decidir. - URL: https://fcgsystems.es/blog/que-es-la-atribucion/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Breakdown · Lectura: 6 min - Palabra clave: atribución (también: atribucion marketing, atribucion significado, que es atribucion, atribucion de conversiones, atribucion multicanal) En marketing digital, la atribución es el proceso de asignar a cada lead y a cada venta el canal, la campaña y el punto de contacto que los originaron. Responde a una sola pregunta: qué trajo de verdad a este cliente. Aquí hablo de ese sentido, el comercial, no del jurídico ni del fiscal. Conviene aclararlo porque la palabra se usa en varios sitios: en derecho, las "atribuciones" son las competencias de un cargo; en psicología social, la teoría de la atribución estudia a qué causas achaca una persona lo que le ocurre; y en fiscalidad española existe el régimen de atribución de rentas. Nada de eso aparece en este artículo. ## ¿Por qué la atribución es un problema y no un informe? Porque el recorrido real de un cliente no se parece al gráfico del embudo. Un caso típico, y aburridamente habitual: 1. Ve un anuncio en Instagram el martes por la noche. No hace clic. 2. El jueves busca tu marca en Google y entra en la web. 3. Se registra a una clase gratuita desde el móvil. 4. Recibe tres emails y entra en un grupo de WhatsApp. 5. Reserva una llamada y compra el lunes siguiente desde el portátil del trabajo. ¿Esa venta es del anuncio, de la búsqueda, del email o de la llamada comercial? Cada herramienta responderá una cosa distinta, y todas tendrán parte de razón. Atribuir es decidir con qué criterio repartes ese crédito, y ese criterio lo eliges tú: no es un dato que venga en ninguna caja. ## ¿Por qué cada herramienta da una cifra distinta? Esta es la parte que genera más reuniones inútiles. No es un error de configuración: es que cada sistema mide un universo diferente. | Herramienta | Qué cuenta | Qué no ve | |---|---|---| | Plataformas de anuncios (Meta, Google) | Conversiones que atribuyen a sus anuncios según sus propias ventanas, que pueden incluir visualizaciones | Todo lo que ocurre fuera de sus señales | | Analítica web (GA4) | Sesiones y eventos que ha podido medir, repartidos según su modelo | Visitas sin consentimiento o con bloqueadores, conversaciones de WhatsApp, llamadas | | CRM | Personas, etapas y ventas reales | El origen, si nadie lo guardó en el primer contacto | Hay tres causas concretas detrás de la descuadre: - **Ventanas de atribución distintas.** Una ventana es el plazo durante el que una plataforma se apunta una conversión tras un clic o una visualización. Si una cuenta siete días tras el clic y otra treinta, los mismos hechos producen cifras distintas. - **Universos distintos.** Meta solo ve a quien pasó por Meta. La analítica solo ve lo que el navegador le dejó medir. El CRM ve a todo el mundo, pero solo sabe de dónde vino si alguien guardó el dato. - **Sumas que se solapan.** Si tres plataformas se atribuyen la misma venta, la suma de conversiones "atribuidas" supera a las ventas reales. No hay fraude: hay tres sistemas contestando a la vez sin hablar entre ellos. Por eso cuadrar al 100 % no es un objetivo realista ni útil. El objetivo es tener **una fuente de verdad para decidir** y saber explicar por qué las demás difieren. ## ¿Qué hace falta para que la atribución funcione? Tres condiciones. Si falla una, lo demás da igual. ### 1. Capturar el origen en el primer contacto El origen viaja en la URL en forma de [parámetros UTM](https://fcgsystems.es/blog/que-es-utm/), y la URL desaparece en cuanto la persona rellena un formulario. Si esos valores no se guardan en campos ocultos y no llegan al CRM con el registro, el dato se ha perdido para siempre. Ninguna herramienta lo reconstruye después. ### 2. Conservarlo mientras la persona avanza Guardando el **primer origen** (cómo descubrió el negocio) y el **último origen** (qué le hizo volver), sin que el segundo pise al primero. Con esos dos campos ya puedes responder a las dos preguntas que importan: qué canal descubre audiencia y qué canal cierra registros. ### 3. Un identificador que aguante el cambio de dispositivo El email normalizado o un ID propio que acompañe a la persona del formulario a la agenda, del WhatsApp a la pasarela de pago. Vio el anuncio en el móvil y compró desde el portátil: para la analítica son dos personas; para el CRM, con el mismo email, es una. Ese es el mejor argumento para que la fuente de verdad de la venta sea el CRM. El recorrido completo, con los siete puntos exactos donde se pierde el origen, está en [atribución rota: por qué GA4, Meta y tu CRM nunca dan la misma cifra](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/). ## Atribución de primer clic, último clic y todo lo demás Una vez tienes el dato, queda decidir cómo repartes el crédito. Los modelos habituales: - **Último clic:** todo el mérito al último punto de contacto. Es el de serie casi en todas partes y favorece a la marca y al remarketing. - **Primer clic:** todo al primero. Favorece a lo que genera descubrimiento. - **Lineal:** reparto igual entre todos los toques. - **Con decaimiento temporal:** más peso a lo más cercano a la venta. - **Basado en datos:** la propia plataforma reparte según sus modelos, como explica Google en su documentación de [modelos de atribución](https://support.google.com/analytics/answer/10596866). Ninguno es "el correcto", porque cada uno responde a una pregunta distinta. Lo desarrollo, con cuándo usar cada uno y por qué ninguno te va a cuadrar solo, en [modelos de atribución](https://fcgsystems.es/blog/modelos-de-atribucion/). ## Atribución y envío de conversiones no son lo mismo Se confunden constantemente y conviene separarlo: - **Atribución** es cómo **tú** repartes el crédito para decidir dónde inviertes. - **Envío de conversiones** es qué señales mandas a las plataformas para que **ellas** optimicen sus campañas. Puedes tener un envío de eventos impecable y una atribución inservible, y al revés. Si además envías el mismo evento por el navegador y por servidor, entra en juego la deduplicación: lo explico en [píxel de Meta y API de conversiones sin contar cada conversión dos veces](https://fcgsystems.es/blog/pixel-meta-api-conversiones-duplicados/). ## Qué mirar cuando la atribución no cuadra En vez de perseguir el cuadre perfecto, contesta estas cinco preguntas con tu equipo: 1. **¿Qué sistema manda para decir "esto es una venta"?** Casi siempre la pasarela de pago o la facturación. 2. **¿Qué sistema manda para decir "este lead viene de aquí"?** El CRM, si el origen se guarda en el formulario. 3. **¿Qué ventana de atribución usa cada plataforma?** Escríbelo al lado de cada cifra del informe. 4. **¿Cuánto tráfico cae en "directo"?** Suele ser la medida de cuántos enlaces salen sin etiquetar. 5. **¿Cuántos leads llegan al CRM sin origen?** Ese porcentaje es el techo real de precisión de todos tus informes. Lo que sale de ahí no es un número más bonito: es saber qué herramienta responde a cada pregunta, que es justo lo que separa [un cuadro de mando que se usa de uno que se ignora](https://fcgsystems.es/blog/que-es-un-dashboard/). Es la misma lógica con la que elijo [los KPIs que de verdad hay que mirar](https://fcgsystems.es/blog/kpis-negocio-digital/). ## Por dónde empezar Coge un cliente que compró esta semana y reconstruye su recorrido hacia atrás: de la venta al lead del CRM, del lead al formulario, del formulario a la landing, de la landing al enlace. Anota en qué paso desaparece el origen. Casi siempre es el formulario, y casi siempre se arregla en una tarde. En FCG Systems esto es [datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): captura del origen, atribución hasta el CRM y paneles que leen de la fuente correcta. Si tus reuniones se van en discutir qué cifra es la buena, [cuéntame cómo tenéis montado el circuito](https://fcgsystems.es/contacto/) y te digo por dónde miraría primero. ## Preguntas frecuentes ### ¿Qué es la atribución en marketing? Es el proceso de asignar a cada lead y a cada venta el canal, la campaña y el punto de contacto que los originaron. Responde a la pregunta de qué trajo realmente a un cliente cuando esa persona vio un anuncio, leyó un email, buscó la marca en Google y compró días después. ### ¿La atribución es lo mismo en marketing que en derecho o en psicología? No. El término se usa en varios campos: en derecho, las atribuciones son las competencias de un cargo; en psicología, la teoría de la atribución estudia a qué causas achaca una persona lo que ocurre; y en fiscalidad española existe la atribución de rentas. En marketing digital significa repartir el crédito de una conversión entre los canales que intervinieron. ### ¿Por qué las cifras de atribución no coinciden entre herramientas? Porque cada herramienta mide un universo distinto con reglas distintas. Las plataformas de anuncios atribuyen conversiones con sus propias ventanas, que pueden incluir visualizaciones; la analítica web solo ve las sesiones que ha podido medir; y el CRM registra personas y ventas reales, pero solo conoce el origen si alguien lo guardó. Que difieran es normal; lo anómalo es no saber cuál usar para decidir. ### ¿Qué es una ventana de atribución? Es el plazo durante el que una plataforma se apunta una conversión después de un clic o una visualización. Si la ventana es de siete días tras el clic, una compra del octavo día no se le atribuye a ese anuncio. Dos plataformas con ventanas distintas darán cifras distintas sobre exactamente los mismos hechos. ### ¿Qué herramienta debería ser la fuente de verdad de la atribución? Para decisiones de negocio, el CRM o la base de datos donde vive el lead, porque es la única que conecta a la persona con la venta real. La analítica y las plataformas de anuncios siguen siendo útiles para optimizar campañas y estudiar el comportamiento en la web, pero no para contar cuántas ventas trajo cada canal. ## Servicios relacionados - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Casos relacionados - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/): Formularios, tracking, CRM y agenda comercial conectados en un solo sistema, con el origen de cada lead a la vista. Las tres etapas del funnel mejoraron. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Qué es la automatización de procesos (y qué no lo es) > Qué es la automatización de procesos, para qué sirve, qué tipos hay y cuándo no compensa automatizar. Explicado desde quien construye y opera los sistemas. - URL: https://fcgsystems.es/blog/que-es-automatizacion-de-procesos/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Automatización · Formato: Breakdown · Lectura: 5 min - Palabra clave: automatizacion de procesos (también: qué es la automatización, automatización de procesos que es, para qué sirve automatizar procesos, automatización de procesos de negocio, tipos de automatización) **La automatización de procesos consiste en que un sistema ejecute solo los pasos repetitivos de un proceso de negocio, a partir de un disparador definido y con reglas explícitas.** Un formulario llega, los datos se normalizan, el contacto se crea en el CRM, se asigna un responsable y se avisa a quien corresponde. Nadie copia, nadie pega, nadie se acuerda. Esa es la definición. La parte interesante viene después: qué no es automatizar, qué se rompe cuando se hace mal y cuándo la respuesta correcta es no automatizar nada. ## ¿Qué no es la automatización de procesos? La palabra se usa hoy para cosas muy distintas, y esa confusión cuesta dinero. - **No es digitalizar.** Pasar un proceso de papel a una hoja de cálculo es digitalizarlo. Si alguien sigue rellenando la hoja a mano, el proceso no está automatizado. - **No es un bot que hace tu trabajo.** Un sistema automatizado ejecuta los pasos que alguien ha decidido antes, en el orden que alguien ha decidido antes. La decisión sigue siendo humana; lo que se delega es la ejecución. - **No es inteligencia artificial.** La mayoría de los procesos que más tiempo consumen en un negocio digital son deterministas: si el pago está confirmado, se da el acceso. Eso es una regla, no un modelo. - **No es un proyecto que se termina.** Una automatización vive conectada a APIs, formularios y herramientas que cambian sin avisar. Lo que no se vigila, se degrada. Y hay una confusión más cara que todas las anteriores: creer que automatizar un proceso desordenado lo arregla. No lo arregla. Lo ejecuta más veces por minuto. ## ¿Para qué sirve automatizar un proceso? El argumento habitual es el ahorro de horas. Es cierto, pero es el más débil, porque las horas ahorradas son difíciles de ver. Los tres motivos que de verdad sostienen la inversión son otros. **Consistencia.** Un proceso a mano tiene tantas versiones como personas lo ejecutan, y todas cambian un martes a las siete de la tarde. Un proceso automatizado se ejecuta igual la primera vez y la número diez mil. **Disponibilidad.** El formulario se envía a las 23:40 de un sábado. Si el lead entra en el CRM y recibe respuesta en ese momento, el proceso trabaja cuando la empresa no. **Trazabilidad.** Esta es la que casi nadie menciona y la que más vale. Un proceso automatizado bien construido deja registro: qué entró, qué se hizo, qué salió y qué falló. Un proceso manual no deja nada, salvo la memoria de quien lo hizo. ## ¿Qué tipos de automatización de procesos hay? En la práctica de un negocio digital, las etiquetas del sector se reducen a tres niveles. | Nivel | Qué hace | Cuándo encaja | |---|---|---| | Automatización de tareas | Conecta dos herramientas y mueve un dato: del formulario al CRM, del pago a la plataforma de cursos | Pasos sueltos, pocas condiciones, volumen moderado | | Automatización de procesos de negocio (BPA) | Encadena varios pasos con reglas, bifurcaciones, esperas y responsables: todo el recorrido de un lead o de una alta | El proceso completo cruza tres o más herramientas | | Software propio | La lógica vive en código, con su base de datos y su interfaz | La lógica es el núcleo del negocio o ya no cabe en una herramienta de terceros | No son escalones obligatorios. Un negocio puede tener los tres a la vez, y de hecho suele ser lo sano: tareas sueltas en una herramienta visual, procesos críticos orquestados, y en software propio solo lo que lo justifica. Las señales de que un no-code se ha quedado corto están en [cuándo dejar el no-code y pasar a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/). ## ¿Qué procesos se automatizan primero? El orden importa más que la herramienta. Un criterio que funciona: empieza por el proceso que, si falla, cuesta dinero el mismo día. En un negocio digital suelen ser estos: 1. **Captación de leads.** Del formulario al CRM, con normalización, deduplicación y asignación. Es el proceso donde más se pierde y donde antes se nota. Lo contamos en detalle en [leads que se pierden entre el formulario y el comercial](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). 2. **Cobros y accesos.** Pago confirmado, acceso concedido; pago fallido, aviso y reintento. Aquí un error se convierte en un cliente enfadado en cuestión de minutos. 3. **Onboarding y comunicaciones.** Secuencias que dependen de lo que hace el cliente, no de la fecha. 4. **Reconciliación de datos.** Cuadrar cada noche lo que dice la pasarela de pago con lo que dice el CRM. Aburrido, invisible y el que más disgustos evita. 5. **Informes internos.** Lo último, no lo primero. Un informe automático sobre datos que no cuadran solo automatiza la confusión. ## ¿Qué hace falta para que una automatización aguante? Aquí es donde se separa una automatización que funciona en la demo de una que aguanta un lanzamiento. Estos cuatro elementos no vienen activados por defecto en ninguna herramienta. - **Idempotencia.** Si el mismo evento llega dos veces (y llegará: los webhooks reintentan), el sistema no puede crear dos contactos ni cobrar dos veces. Se resuelve con una clave única por evento. - **Reintentos con criterio.** Un fallo temporal de una API se reintenta con espera creciente. Un dato mal formado no se reintenta nunca: se aparta y se avisa. - **Registros propios.** No basta con el historial de ejecuciones de la herramienta. Hace falta saber, meses después, qué entró y qué se hizo con ello. - **Alertas con responsable.** Una alerta que no llega a una persona concreta no es una alerta. Es un registro más. Sin estas cuatro cosas, lo que se construye no falla: falla en silencio, que es peor. Ese patrón, y cómo detectarlo, está en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ## ¿Cuándo no compensa automatizar? Decir que no a tiempo ahorra más que cualquier flujo. No automatices cuando: - **El proceso todavía cambia cada semana.** Automatizar congela una forma de trabajar. Si esa forma aún se está buscando, estás construyendo sobre arena. - **Ocurre cinco veces al mes y lleva dos minutos.** Diez minutos mensuales no pagan el mantenimiento de un flujo, ni el rato de averiguar por qué dejó de funcionar. - **Nadie sabe describir el proceso completo.** Si al preguntar "¿y qué pasa si el pago se rechaza?" no hay una respuesta clara, todavía no hay proceso que automatizar. - **La causa real es un dato sucio.** Automatizar encima de duplicados y campos vacíos multiplica el problema. - **No hay quién lo mantenga.** Un flujo sin responsable es una deuda con fecha de vencimiento desconocida. ## Cómo se aborda en FCG Systems Primero se entiende la operación; el código llega después. Mapeamos el proceso tal y como ocurre hoy, con sus excepciones, señalamos qué debe ser determinista y qué no merece automatizarse, y construimos solo lo que aguanta volumen: con registros, reintentos y una persona que recibe el aviso cuando algo se rompe. La herramienta se elige según el sistema, nunca al revés. Si tienes un proceso que ya no escala a mano, puedes ver cómo trabajamos en [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/) o [contarnos qué proceso os está frenando](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Qué es la automatización de procesos? Es sustituir los pasos manuales y repetitivos de un proceso de negocio por un sistema que los ejecuta solo a partir de un disparador: un formulario enviado, un pago confirmado, una fecha. El proceso no cambia de objetivo; cambia quién lo ejecuta y cuántas veces puede ejecutarse sin que nadie esté delante. ### ¿Cuáles son los tipos de automatización de procesos? En un negocio digital conviven tres. La automatización de tareas conecta dos herramientas y mueve un dato de una a otra. La automatización de procesos de negocio (BPA) encadena varios pasos con reglas, condiciones y responsables. Y la automatización con software propio, cuando la lógica es tan específica que no cabe en una herramienta de terceros. ### ¿Para qué sirve automatizar procesos? Sirve para tres cosas concretas: que un proceso se ejecute igual siempre, que se ejecute a cualquier hora y que no dependa de que una persona se acuerde. El ahorro de tiempo es la consecuencia, no el objetivo. El objetivo real suele ser la fiabilidad: que ningún lead, pago o acceso se quede por el camino. ### ¿Cuál es la mejor plataforma para automatizar procesos? No hay una mejor en abstracto. La elección depende de cuántos pasos tienen tus flujos, cuántas veces se ejecutan al mes, quién los va a mantener y si los datos pueden salir de tu infraestructura. Herramientas como n8n, Make o Zapier cubren lo habitual; cuando la lógica es el núcleo del negocio, suele acabar en software propio. ### ¿La inteligencia artificial automatiza procesos por sí sola? No. La IA aporta las partes que no se pueden escribir como regla: clasificar un texto, resumir una conversación, extraer datos de un documento. El esqueleto del proceso (el disparador, el orden de los pasos, los reintentos, los registros) sigue siendo determinista. Si una regla simple resuelve el problema, no hace falta un modelo. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Qué es MCP (Model Context Protocol) y qué cambia para un negocio que ya tiene sus sistemas > Qué es el Model Context Protocol, en qué se diferencia de una API, cuándo compensa montar un servidor MCP propio y qué permisos no deberías exponer nunca. - URL: https://fcgsystems.es/blog/que-es-mcp-model-context-protocol/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: IA aplicada · Formato: Breakdown · Lectura: 10 min - Palabra clave: model context protocol (también: que es mcp, que es un mcp, mcp server, mcp vs api, mcp inteligencia artificial) **MCP (Model Context Protocol)** es un estándar abierto para conectar aplicaciones de IA con sistemas externos: bases de datos, herramientas y procesos. En vez de programar una integración distinta para cada asistente, expones una vez tus datos y tus acciones, y cualquier cliente compatible puede usarlos. La propia documentación lo compara con un puerto USB-C para aplicaciones de IA. Para un negocio que ya tiene CRM, facturación y automatizaciones, la pregunta útil no es qué es MCP, sino qué cambia. Y lo que cambia es concreto: deja de tener sentido construir una integración a medida cada vez que aparece un asistente nuevo, y empieza a tener sentido decidir con cuidado qué parte de tu operación queda al alcance de un modelo. Este artículo explica el protocolo en términos de negocio, lo compara con una API normal, y se detiene donde casi nadie se detiene: en los permisos. Si lo que buscas es qué es un agente y cuándo compensa, está en [agentes de IA para negocios](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/). > Aviso de caducidad: MCP se versiona por fecha y cambia rápido. Todo lo técnico de este artículo está contrastado con la [documentación oficial](https://modelcontextprotocol.io/docs/getting-started/intro) y la [especificación](https://modelcontextprotocol.io/specification/latest), consultadas en septiembre de 2026, sobre la versión de protocolo `2026-07-28`. Antes de construir nada, comprueba la versión vigente. ## ¿Qué problema resuelve MCP? El problema es de multiplicación. Si tienes cuatro sistemas que un asistente debería consultar (el CRM, la plataforma de cursos, la facturación y la base de conocimiento) y usas tres aplicaciones de IA distintas, alguien tiene que mantener doce integraciones. Cada una con su autenticación, su formato y su mantenimiento. Cuando cambia un campo del CRM, cambian tres sitios. MCP invierte el planteamiento. Expones cada sistema **una vez** como servidor, y cada aplicación de IA se conecta a él con el mismo protocolo. Cuatro servidores en lugar de doce integraciones. Es el mismo argumento que justifica cualquier estándar: no es que haga algo imposible antes, es que deja de haber una traducción distinta por cada par. La definición oficial lo dice sin adornos: MCP es un estándar de código abierto para conectar aplicaciones de IA a sistemas externos. Lo anunció y liberó [Anthropic el 25 de noviembre de 2024](https://www.anthropic.com/news/model-context-protocol) (consultado en septiembre de 2026), con la especificación, los SDK y un repositorio abierto de servidores de referencia. Hoy lo soportan clientes como Claude, ChatGPT, Visual Studio Code o Cursor. ## ¿Quién es quién: host, cliente y servidor? Tres piezas, y conviene no confundirlas porque los tres nombres se usan mal continuamente. - **MCP Host:** la aplicación de IA que coordina uno o varios clientes. Es el programa con el que habla la persona. - **MCP Client:** el componente que mantiene la conexión con un servidor y le lleva el contexto al host. El host crea un cliente por cada servidor al que se conecta. - **MCP Server:** el programa que proporciona el contexto. Es la pieza que tú construyes o instalas. Cuando alguien dice "he montado un MCP", casi siempre quiere decir que ha montado un **servidor**. El servidor puede ejecutarse en la misma máquina que el host, con transporte **stdio**, o en remoto, con transporte **Streamable HTTP** y autenticación HTTP estándar. Para los tokens, la especificación recomienda OAuth. Por debajo hay dos capas: la **capa de datos**, que es un protocolo basado en JSON-RPC 2.0, y la **capa de transporte**, que se ocupa de la conexión y la autenticación. No necesitas saber más para decidir, pero sí para entender una cosa: MCP define cómo se intercambia el contexto, y nada más. No dice cómo debe usarlo el modelo ni qué debe hacer con él. Esa parte sigue siendo tuya. ## ¿Qué expone un servidor MCP? Tres primitivas. Traducidas a lo que significan en una operación real: - **Tools (herramientas):** funciones ejecutables que la aplicación de IA puede invocar. En un negocio digital: consultar el estado de un pedido, buscar al alumno por email, crear una tarea en el CRM, comprobar si una factura está pagada. - **Resources (recursos):** fuentes de datos que aportan contexto. El catálogo de productos, las políticas de devolución, el esquema de una base de datos. - **Prompts:** plantillas reutilizables de interacción. Por ejemplo, la forma estándar de preparar el resumen de un lead antes de una llamada. La diferencia práctica entre una herramienta y un recurso es quién actúa. Un recurso se lee. Una herramienta **hace algo**, y ahí es donde empieza el riesgo. Del lado del cliente, la primitiva vigente es **elicitation**: el servidor puede pedirle información o una confirmación a la persona antes de seguir. Es el mecanismo natural para meter una aprobación humana. Conviene saber que en la versión `2026-07-28` quedaron **obsoletas** *sampling* y *logging*; si te encuentras un tutorial que se apoya en ellas, está desactualizado. ## MCP frente a una API normal Es la pregunta que más se repite, y la respuesta corta es que no compiten. | | API tradicional | Servidor MCP | |---|---|---| | Quién la consume | Código que alguien escribió | Una aplicación de IA, en nombre de una persona | | Quién sabe qué hay disponible | Quien programa, leyendo la documentación | El propio cliente: el servidor publica sus herramientas con su esquema | | Quién decide cuándo llamar | El código, en un punto fijo | El modelo, en función de lo que le piden | | Contrato | Estable y versionado por ti | Estable y versionado por ti, más la versión del protocolo | | Qué pasa si falla | Lo gestiona tu código | Lo interpreta un modelo, que puede reintentar o rendirse | | Dónde vive el riesgo | En los permisos del token | En los permisos del token y en que el modelo decide | Lo importante de la tabla está en la última fila. Con una API, el alcance de lo que puede pasar lo fija tu código. Con MCP, el alcance lo fija lo que hayas expuesto, porque el orden de las llamadas ya no lo decides tú. Y una aclaración que ahorra discusiones: **MCP no sustituye a tu API**. Lo normal es que el servidor MCP se apoye en la API que ya tienes y le ponga delante una capa pensada para que la consuma un modelo: nombres explícitos, descripciones útiles y esquemas de entrada estrictos. ## ¿Qué cambia esto para un negocio que ya tiene sus sistemas? Tres cosas, por orden de impacto. **Primera: el coste de conectar una IA nueva baja.** Si mañana el equipo quiere probar otro asistente, no se rehace la integración. Esto solo es una ventaja si ya tienes varios sistemas y algo parecido a una fuente de verdad. Si tus datos están repartidos entre tres herramientas que no coinciden, MCP no lo arregla; lo hace accesible más deprisa, que no es lo mismo. Ese trabajo previo es el de [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/). **Segunda: la superficie de acceso se vuelve explícita.** Hasta ahora, lo que un asistente podía tocar estaba implícito en el código de cada integración. Con un servidor MCP, queda escrito en una lista de herramientas. Eso es bueno: se puede revisar. También significa que alguien tiene que revisarlo. **Tercera: aparece una decisión de producto.** Qué parte de tu operación quieres que sea conversacional. No todo gana por serlo. ## ¿Cuándo compensa montar un servidor MCP propio? ### Cuándo sí - Tenéis un sistema propio, un backoffice o un CRM a medida que ninguna integración estándar cubre, y varias personas quieren consultarlo desde una aplicación de IA. - Las consultas son variadas y en lenguaje natural: "¿cuántos alumnos del lanzamiento de marzo siguen sin acceder?" no cabe en un informe fijo. - Ya existe una API interna estable, así que el servidor es una capa fina encima y no un proyecto nuevo. - Hay alguien que va a mantenerlo cuando cambie el esquema de datos o la versión del protocolo. ### Cuándo no - **Cuando la consulta es siempre la misma.** Un informe programado cuesta menos y no se equivoca. - **Cuando no hay API ni modelo de datos claro.** Primero el sistema, después la conexión. - **Cuando lo que se quiere automatizar es determinista.** Dar acceso al aprobarse un pago, asignar un lead por país o deduplicar por email son reglas: van en código o en una automatización, como explico en [IA aplicada en negocios digitales](https://fcgsystems.es/blog/ia-aplicada-negocios-digitales/). - **Cuando ya existe un servidor oficial** para esa herramienta y cubre lo que necesitáis. - **Cuando nadie va a revisar los logs.** Un servidor MCP sin registro falla en silencio igual que cualquier automatización, y eso lo cuento en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ## Permisos y riesgo: la parte que no se cuenta Aquí es donde se rompen los proyectos, y casi nunca por el protocolo. **El fallo grave es el token con demasiado alcance.** Expones una herramienta que se llama `consultar_alumno`, pero la credencial que usa por debajo tiene permiso de escritura sobre toda la base. El día que el modelo interprete mal una petición, el límite no será el nombre de la herramienta: será el permiso real. El nombre es una etiqueta; el token es la frontera. Reglas que aplicamos siempre: - **Empezar en solo lectura.** Se abre escritura herramienta a herramienta, cuando hay un motivo. - **Una credencial por servidor**, con el alcance mínimo. Nunca la clave de administración que ya teníais por ahí. - **Las decisiones que mueven dinero o accesos no pasan por el modelo.** Cobrar, dar de baja, cambiar un precio o conceder acceso a un curso son lógica determinista. Van en código, son auditables y se pueden revisar. Un modelo acierta estadísticamente; eso no es suficiente cuando la consecuencia es que alguien pierde el acceso que pagó. - **Aprobación humana para lo irreversible**, usando *elicitation* o un paso previo en vuestro propio flujo. - **Registro de cada llamada:** qué herramienta, con qué argumentos, qué devolvió y en nombre de quién. Sin esto no hay forma de reconstruir un incidente. - **Datos personales decididos antes de conectar,** no después: qué ve el servidor, a qué proveedor viaja y cuánto se guarda. Hay un riesgo más, propio de este modelo de trabajo: el servidor describe sus herramientas con texto, y ese texto entra en el contexto del modelo. Si instaláis un servidor de terceros, estáis confiando en lo que ese servidor dice de sí mismo. Trátalo como tratarías a una dependencia con permisos sobre vuestros datos, porque es exactamente eso. ## Errores comunes con MCP - **Exponer la base de datos entera** en vez de un conjunto corto de herramientas con un propósito claro. - **Herramientas mal descritas.** El modelo elige a partir de la descripción; una descripción vaga produce llamadas equivocadas. - **Esquemas de entrada laxos.** Si el parámetro admite cualquier cadena, alguna vez recibirá cualquier cosa. - **Confundir el servidor con el producto.** MCP conecta; el valor sigue estando en que los datos sean correctos. - **Copiar tutoriales de versiones antiguas.** El protocolo cambia y hay primitivas ya obsoletas. - **Montarlo sobre un sistema que todavía no existe.** Si el proceso vive en hojas de cálculo, lo que toca es lo que cuento en [software a medida o no-code](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/). - **Sin dueño.** Nadie actualiza el servidor cuando cambia el esquema, y las respuestas empiezan a mentir. ## Checklist antes de conectar un servidor MCP a vuestros sistemas - El caso de uso está escrito y no se resuelve con un informe fijo. - Existe una fuente de verdad para los datos que va a consultar. - La lista de herramientas es corta y cada una tiene un propósito claro. - Cada herramienta tiene esquema de entrada estricto y descripción precisa. - Las credenciales son específicas del servidor y con el alcance mínimo. - Todo empieza en solo lectura; la escritura se abre caso a caso. - Las acciones irreversibles exigen confirmación de una persona. - Cobros, accesos y precios se deciden en código, no en el modelo. - Cada llamada queda registrada con argumentos, resultado y responsable. - Está decidido qué datos personales quedan expuestos y a dónde viajan. - La versión de protocolo está anotada y hay alguien que revisa los cambios. - Hay un responsable del servidor cuando cambie el esquema de datos. ## Por dónde empezar Si la idea os interesa pero no tenéis claro el caso, el primer paso barato es instalar un servidor oficial de una herramienta que ya uséis, en solo lectura, y ver qué preguntas hace la gente de verdad. Esas preguntas os dirán qué merece un servidor propio y qué no. Cuando el caso toca datos de clientes, pagos o accesos, o cuando hay que integrarlo con el CRM y el resto de la operación, conviene hacerlo con criterio de sistema: herramientas mínimas, permisos mínimos, logs y un responsable. Es el mismo orden que seguimos en cualquier trabajo de [IA aplicada y agentes](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/), y cuando hace falta una capa propia por debajo, en [software a medida](https://fcgsystems.es/servicios/software-a-medida/). Si tenéis un sistema interno que os gustaría poder consultar en lenguaje natural y no sabéis si eso es un servidor MCP, un informe o nada, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y te digo qué tiene sentido. ## Preguntas frecuentes ### ¿Qué significa MCP? MCP son las siglas de Model Context Protocol. Es un estándar abierto para conectar aplicaciones de IA con sistemas externos: datos, herramientas y plantillas de interacción. Lo publicó Anthropic el 25 de noviembre de 2024 junto con la especificación, los SDK y un repositorio de servidores de referencia. ### ¿Qué es un MCP en IA? Es la capa de conexión entre una aplicación de IA y tus sistemas. En lugar de programar una integración distinta para cada asistente, expones una vez tus datos y acciones como servidor MCP y cualquier cliente compatible puede usarlos. La documentación oficial lo compara con un puerto USB-C para aplicaciones de IA. ### ¿Cuáles son las diferencias entre una API y un MCP? Una API la consume código que alguien escribió sabiendo de antemano qué llamar y cuándo. Un servidor MCP se anuncia a sí mismo: publica qué herramientas y datos ofrece, con su esquema de entrada, y es el modelo quien decide cuál usar en cada momento. MCP no sustituye a tu API: normalmente se apoya en ella y le pone delante una capa pensada para que la consuma una IA. ### ¿Qué es un MCP server y cómo se crea? Un servidor MCP es el programa que proporciona el contexto: expone herramientas ejecutables, fuentes de datos y plantillas. Se construye con uno de los SDK oficiales y se despliega local, con transporte stdio, o remoto, con transporte Streamable HTTP y autenticación. La decisión difícil no es programarlo, sino elegir qué expone y con qué permisos. ### ¿Qué son los agentes de IA con MCP? Un agente decide por sí mismo qué pasos dar y qué herramientas usar. MCP es una de las formas de darle esas herramientas de manera estandarizada. El agente es quien decide; MCP es el cable. Siguen haciendo falta límites, condiciones de parada y aprobación humana para lo irreversible. ### ¿Es seguro conectar mi CRM por MCP? Depende de los permisos que le des, no del protocolo. El fallo grave no suele ser el transporte, sino un token con más alcance del necesario: una herramienta de solo lectura que en realidad puede modificar registros. Empieza en solo lectura, separa credenciales por servidor y registra cada llamada. ## Servicios relacionados - [Sistemas de IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Qué es n8n y para qué sirve: la guía para un negocio que ya factura, no un tutorial de instalación > Qué es n8n y para qué sirve en un negocio que ya factura: qué procesos resuelve, qué cuesta operarlo, qué dice su licencia y cuándo no es la respuesta. - URL: https://fcgsystems.es/blog/que-es-n8n/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Automatización · Formato: Breakdown · Lectura: 10 min - Palabra clave: n8n que es (también: que es n8n y para que sirve, n8n para que sirve, n8n español, para qué se utiliza n8n, n8n qué es) **n8n** es una herramienta de automatización que conecta las aplicaciones que ya usáis y ejecuta procesos completos sin que nadie los dispare a mano: un formulario que acaba en el CRM con su origen, un pago fallido que corta el acceso, un aviso que llega a la persona correcta. Se puede usar como servicio gestionado (n8n Cloud) o instalar en vuestra propia infraestructura. Para un negocio que ya factura, la pregunta útil no es qué es n8n, sino qué procesos deja de sostener una persona y qué responsabilidad asumís a cambio. Casi todo lo que se publica sobre n8n explica cómo instalarlo o cómo arrastrar el primer nodo. Esta guía va por otro sitio: qué resuelve de verdad en una operación con clientes, qué implica su licencia, cuánto cuesta mantenerlo y en qué casos no es la respuesta. ## ¿Qué es n8n exactamente? n8n es una plataforma de automatización de flujos de trabajo. Se construyen flujos conectando bloques en un editor visual, y cada bloque hace una cosa: recibir un webhook, leer una fila, crear un contacto, enviar un mensaje, decidir por dónde sigue el proceso. La [documentación oficial](https://docs.n8n.io/key-concept-glossary/) (consultada en septiembre de 2026) lo define con tres piezas que conviene tener claras antes de seguir: | Concepto | Qué es, en cristiano | |---|---| | Nodo | Un componente individual que se compone con otros para crear flujos. Es cada paso del proceso | | Flujo (workflow) | Una colección de nodos que automatizan un proceso completo | | Nodo trigger | El nodo especial que arranca el flujo cuando se cumple una condición: llega un webhook, pasa una hora, cambia un registro | | Credencial | La información de autenticación que guarda n8n para conectarse a cada aplicación | | Ejecución | Cada vez que el flujo corre de principio a fin. Es también la unidad con la que n8n cobra en sus planes | Esa última fila importa más de lo que parece. En n8n, una ejecución es una ejecución completa del flujo, tenga dos pasos o veinte. Por eso un flujo largo no encarece la factura y uno que se dispara muchas veces sí. Ese detalle cambia la comparación con otras herramientas y lo desarrollamos en [n8n vs Make y alternativas a n8n](https://fcgsystems.es/blog/n8n-vs-make/). ## ¿Para qué sirve n8n en un negocio que ya factura? La respuesta genérica —"conectar aplicaciones"— no ayuda a decidir. Estos son los procesos donde n8n aporta algo medible en un negocio digital con volumen: - **Captación de leads.** El registro de un formulario entra en el CRM con su origen, su campaña y su responsable, ya normalizado y sin duplicados. Si el origen no se guarda en el primer registro, después no hay forma de reconstruirlo. - **Altas y bajas de acceso.** Una compra da acceso a la plataforma formativa o al área privada; una baja o un impago lo retira. Sin esto, alguien revisa listas a mano y siempre queda algún alumno con acceso que ya no le corresponde. - **Cobros fallidos.** Cuando una suscripción falla, el flujo avisa al cliente, marca el estado en el CRM y programa la retirada de acceso si no se resuelve. Ese circuito completo lo detallamos en [pagos fallidos de Stripe y acceso al curso](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/). - **Avisos internos con responsable.** Un lead de alto valor que llega fuera de horario, un formulario que deja de recibir registros, un stock que baja de un umbral. El aviso llega a una persona concreta, no a un canal que nadie mira. - **Informes recurrentes.** Cifras de captación, ventas y consumo consolidadas cada lunes desde varias fuentes, sin que nadie exporte hojas de cálculo. - **Enriquecimiento y clasificación.** Consultar una API externa, completar datos de un contacto o etiquetar registros según reglas escritas en el propio flujo. - **Pasos con IA dentro de un proceso con reglas.** n8n permite incorporar agentes de IA, que su glosario define como sistemas capaces de responder a peticiones, tomar decisiones y ejecutar tareas. Funciona bien cuando el modelo redacta o resume y la lógica que decide —umbrales, asignaciones, identificadores— sigue en el flujo. Cuándo delegar en un modelo y cuándo no, en [agentes de IA para negocios](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/). El patrón común: n8n sirve para que un proceso ocurra siempre igual, quede registrado y avise cuando no ocurre. No para ahorrar clics sueltos. Cuatro de estos casos, desmontados nodo a nodo y con lo que suele romperse en cada uno, están en [ejemplos de flujos de n8n](https://fcgsystems.es/blog/como-funciona-n8n-ejemplos/). ## ¿Qué resuelve n8n y qué no resuelve? Media hora de honestidad aquí ahorra meses de desilusión. | Qué resuelve n8n | Qué no resuelve n8n | |---|---| | Mover datos entre herramientas con reglas escritas y repetibles | Un proceso que nadie ha definido: automatiza el desorden más deprisa | | Ejecutar un proceso siempre igual, sin depender de que alguien se acuerde | Datos sucios de origen. Si entran duplicados, salen duplicados | | Reaccionar a eventos (webhook, pago, formulario) en segundos | Sustituir un CRM, una pasarela de pago o una base de datos | | Orquestar llamadas a APIs y a modelos de lenguaje | Lógica de negocio compleja que ya es el núcleo del producto | | Dejar traza de cada ejecución para auditar qué pasó | Enterarse solo de los fallos silenciosos: eso hay que diseñarlo aparte | | Quitar trabajo manual repetitivo a un equipo pequeño | La ausencia de alguien que mantenga los flujos cuando cambien las APIs | La fila de los fallos silenciosos es la que más caro sale. Un webhook que deja de dispararse o un campo que llega vacío no generan error: el flujo termina en verde y el dato nunca llega. Por eso la automatización útil incluye logs propios, reconciliación y alertas con destinatario, como explicamos en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ## ¿n8n Cloud o n8n autoalojado? n8n ofrece [dos formas de uso](https://docs.n8n.io/choose-how-to-use-n8n/) (consultada en septiembre de 2026): el servicio gestionado, donde ellos operan la instalación, y la instalación en vuestra propia infraestructura, donde tenéis control total y también toda la responsabilidad. | | n8n Cloud | Self-hosted | |---|---|---| | En una línea | Pagáis cuota y ejecuciones, y no tocáis servidores | No pagáis licencia en la edición Community, pero operáis la infraestructura | | Encaja cuando | Nadie del equipo puede mantener un servidor, o queréis validar flujos antes de invertir | Los datos no deben salir de vuestra infraestructura, o el volumen desborda la cuota de Cloud | | Requisito real | Presupuesto y vigilar el consumo de ejecuciones | Alguien con nombre y apellidos responsable de backups, actualizaciones y caídas | La decisión rara vez es ideológica. Es una pregunta operativa: si el servidor falla un domingo por la tarde, ¿quién lo restaura y en cuánto tiempo? El desglose de importes vigentes, qué cuenta como ejecución y qué necesita una instancia en producción está en [n8n precios: Cloud o self-hosted](https://fcgsystems.es/blog/n8n-precios-cloud-self-hosted/). ## ¿Es n8n gratuito? Qué dice su licencia Aquí hay una confusión extendida que conviene deshacer antes de tomar decisiones de producto. **n8n no es open source en sentido estricto.** Se distribuye bajo la [Sustainable Use License v1.0](https://github.com/n8n-io/n8n/blob/master/LICENSE.md) (consultada en septiembre de 2026), cuyo texto dice literalmente: *"You may use or modify the software only for your own internal business purposes or for non-commercial or personal use."* Traducido a decisiones: - **Podéis** instalarlo y modificarlo para automatizar vuestros propios procesos internos. Ese es el caso de uso de la inmensa mayoría de negocios. - **No podéis** revenderlo ni ofrecerlo como servicio a terceros. Si vuestro plan era montar instancias de n8n para clientes y facturar por ello, esa es exactamente la línea que la licencia marca. - Además, los ficheros del repositorio con `.ee.` en el nombre corresponden a funciones que requieren licencia Enterprise. El coste de licencia de la edición Community es cero. El coste de operarla no. Confundir ambas cosas es el error económico más común con n8n autoalojado. ## ¿Qué responsabilidad asumís al autoalojar n8n? Cuando n8n sostiene captación, pagos o accesos, deja de ser una herramienta y pasa a ser infraestructura crítica. Esto es lo que alguien tiene que asumir, con nombre: - **Disponibilidad.** Si la instancia se cae, los webhooks que lleguen mientras tanto se pierden. No hay bandeja de entrada que los guarde. - **Backups con restauración probada.** No solo la base de datos: también la clave de cifrado con la que n8n protege las credenciales. Una base restaurada sin su clave no devuelve credenciales utilizables. - **Actualizaciones controladas.** Versión fijada, notas de versión leídas y prueba en una copia antes de tocar producción. Nunca en mitad de una campaña. - **Seguridad.** HTTPS, cuentas individuales con segundo factor, cortafuegos y solo los puertos necesarios expuestos. El editor de n8n guarda las llaves de todas vuestras aplicaciones. - **Vigilancia.** Que alguien se entere de una caída antes que un cliente, y de un flujo crítico fallido antes que el cliente afectado. n8n permite definir un [flujo de error](https://docs.n8n.io/build/flow-logic/handle-errors-gracefully/) (consultada en septiembre de 2026) que se ejecuta cuando otro falla; hay que configurarlo en cada flujo crítico, uno a uno. - **Documentación.** Cómo está montado, cómo se vuelve a la versión anterior y quién más sabe hacerlo. Si solo lo sabe una persona, tenéis un problema distinto, el que tratamos en [cuando todo depende de una persona](https://fcgsystems.es/blog/dependencia-de-una-persona-capacidad-tecnica/). Nada de esto es exótico. Es el trabajo de [infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/) que casi nunca aparece en el presupuesto inicial y que decide si la automatización aguanta un lanzamiento. ## ¿Cuándo n8n no es la respuesta? - **El proceso no está definido.** Si nadie sabe decir qué pasa con un lead paso a paso, automatizarlo solo acelera el desorden. Primero se escribe el proceso, después se automatiza. - **Es un proceso puntual.** Una migración que se hace una vez no necesita un flujo mantenido; necesita ejecutarse bien una vez. - **La lógica ya es el producto.** Cuando las reglas de negocio viven repartidas en veinte flujos con condiciones anidadas, el mantenimiento se vuelve el cuello de botella. Ese es el momento de pasar el núcleo a código y dejar n8n para orquestar, como explicamos en [de no-code a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/). - **Nadie va a mantenerlo.** Los flujos se rompen cuando cambia una API, caduca un token o una herramienta actualiza su formato. Sin responsable, la automatización dura hasta el primer cambio externo. - **La herramienta destino ya lo hace nativamente.** Si vuestro CRM y vuestra pasarela tienen integración oficial que cubre el caso, añadir un flujo en medio suma un punto de fallo sin aportar nada. ## Errores comunes al empezar con n8n - **Empezar por el flujo más vistoso** en vez de por el que más duele. El primer flujo debería quitar trabajo real o cerrar un agujero conocido. - **No guardar logs propios.** El historial de ejecuciones de n8n se poda y tiene límites de retención. Si necesitáis saber qué pasó con un registro dentro de seis meses, guardadlo en vuestra propia tabla. - **Dejar la gestión de errores para después.** El flujo de error no viene configurado: hay que activarlo en cada flujo crítico. - **Consultar APIs cada minuto sin necesidad.** Un trigger que pregunta periódicamente consume ejecuciones aunque no haya datos nuevos. Si el servicio de origen admite webhooks, usadlos. - **Credenciales compartidas en una cuenta común.** Cuando alguien sale del equipo, no hay forma limpia de revocar sus accesos. - **Webhooks que no llegan por configuración de red.** Es el problema más frecuente en instalaciones nuevas detrás de un proxy; las causas y el orden para diagnosticarlas están en [webhooks de n8n que no funcionan](https://fcgsystems.es/blog/webhook-n8n-no-funciona/). - **Un único flujo gigante** que hace todo. Cuando falla, nadie sabe por dónde iba. Flujos pequeños, con una responsabilidad cada uno. ## Por dónde empezar Si estáis valorando n8n para vuestra operación, este es un orden que funciona: 1. **Escribid el proceso que más duele**, paso a paso, con quién lo hace hoy y cuánto tiempo cuesta a la semana. 2. **Decidid cuál es la fuente de verdad de cada dato**: qué herramienta manda para los contactos, para los pagos y para los accesos. Sin esa decisión, la automatización crea dos versiones del mismo dato. 3. **Probad con n8n Cloud** ese primer proceso antes de montar infraestructura. Autoalojar es una decisión posterior, no el punto de partida. 4. **Añadid logs y avisos desde el primer flujo**, no cuando algo falle. Es más barato ahora. 5. **Poned un responsable con nombre** de los flujos y de la instancia, con alguien más que sepa tocarla. Con un proceso claro y un equipo con algo de soltura técnica, ese recorrido es perfectamente abordable en casa. Cuando n8n pasa a sostener la captación, los cobros o los accesos de varios miles de clientes, la conversación deja de ser de herramienta y pasa a ser de arquitectura: qué proceso vive en qué sitio, con qué garantías y quién responde. Es el trabajo que hacemos en [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/), y cuando la instancia va autoalojada, junto con [infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/). Si ya tenéis n8n en marcha y la duda es si aguantaría el próximo lanzamiento, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y lo revisamos. ## Preguntas frecuentes ### ¿Es n8n gratuito? La edición Community, que se instala en tu propia infraestructura, no tiene coste de licencia. Pero n8n no es open source en sentido estricto: se distribuye bajo la Sustainable Use License, que permite usarlo y modificarlo solo para fines internos de tu negocio o para uso personal y no comercial. Y aunque la licencia sea gratuita, operarlo no lo es: servidor, backups, actualizaciones y el tiempo de quien lo mantiene. ### ¿Qué puedo hacer con n8n? Conectar entre sí las aplicaciones que ya usáis y ejecutar procesos sin que nadie los dispare a mano: registrar un lead en el CRM con su origen, dar o quitar accesos cuando cambia el estado de un pago, avisar a una persona concreta cuando algo falla, preparar informes recurrentes o llamar a un modelo de lenguaje dentro de un flujo con reglas deterministas alrededor. ### ¿Cuánto cuesta n8n? Depende de si usas n8n Cloud, con cuota mensual y una cuota de ejecuciones por plan, o self-hosted, donde la licencia Community no cuesta pero pagas servidor y mantenimiento. Los importes vigentes están en la página de precios de n8n y el desglose con el coste real de operarlo, en nuestra guía de precios de n8n. ### ¿Qué es mejor, n8n o Make? Ninguno es mejor en abstracto. n8n cobra por ejecución completa del flujo y puede autoalojarse, lo que encaja con flujos de muchos pasos, volumen alto o datos que no deben salir de vuestra infraestructura. Make cobra por operación de módulo y no exige mantener servidores, lo que suele encajar mejor en equipos sin perfil técnico con flujos cortos. ### ¿Para qué se utiliza n8n en una empresa? Para sostener los procesos que unen herramientas distintas y que hoy dependen de que alguien se acuerde: captación, altas y bajas de acceso, cobros, avisos internos y reporting. El valor no está en ahorrar clics, sino en que un proceso ocurra siempre igual, quede registrado y avise cuando no ocurre. ### ¿Hace falta saber programar para usar n8n? No para los flujos básicos, que se montan conectando nodos en un editor visual. Sí ayuda tener soltura con APIs, JSON y algo de código cuando el proceso tiene condiciones, transformaciones de datos o servicios sin integración oficial. La parte que de verdad exige perfil técnico es operar la instancia si la autoalojáis. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/): Servidores, despliegues, backups y alertas para que tu operación no se caiga y sea tuya. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Qué es Stripe y cómo se integra con tus accesos, tu CRM y tu embudo de venta > Qué es Stripe, en qué se diferencian Link y los enlaces de pago, qué comisiones cobra en España y cómo conectarlo con tu CRM, tus accesos y tu facturación. - URL: https://fcgsystems.es/blog/que-es-stripe/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Infraestructura · Formato: Breakdown · Lectura: 8 min - Palabra clave: que es stripe (también: stripe link que es, stripe api, api stripe, enlaces de pago stripe, comisiones stripe españa) Stripe es una plataforma de infraestructura de pagos: permite cobrar por internet con tarjeta y otros métodos, gestionar suscripciones y recurrencias, y consultar o mover todo eso por API. Lo que la diferencia de una pasarela clásica es que cada cambio relevante (un cobro, una renovación, una baja) se notifica como un evento al que otros sistemas pueden reaccionar. Esa última frase es la que importa y la que casi ningún artículo de "qué es Stripe" menciona. Para un negocio online, Stripe no es un botón de pagar: es el sistema que decide **quién ha pagado y en qué estado está**. Y si ese dato no llega automáticamente a tu plataforma de cursos, a tu CRM y a tu facturación, tienes a alguien copiando datos a mano y clientes con el acceso equivocado. Este artículo explica qué es Stripe desde ahí: desde la óptica de quien tiene que conectar los pagos con el resto del negocio. ## Qué es Stripe, en concreto Stripe cobra por internet, sí. Pero lo que se contrata en la práctica es un conjunto de piezas que puedes usar por separado: | Pieza | Qué hace | Cuándo la necesitas | |---|---|---| | **Payments / Checkout** | Cobra pagos únicos con una página de pago alojada por Stripe | Casi siempre | | **Payment Links** | Una URL para vender un producto o una suscripción sin escribir código | Ventas puntuales, cierres por WhatsApp o email | | **Billing** | Suscripciones, ciclos, prorrateos, reintentos de cobro | Membresías, SaaS, cuotas | | **Invoicing** | Emite y envía documentos de cobro | Ventas B2B o cobros a plazos | | **Tax** | Calcula impuestos según el país del comprador | Venta internacional | | **Radar** | Reglas y puntuación antifraude | Volumen alto o producto con riesgo | | **API y webhooks** | Consultar, crear y reaccionar a lo que pasa | Siempre que haya otro sistema implicado | Lo relevante no es la lista, es que **todo lo anterior está expuesto por API y todo genera eventos**. Ese es el motivo por el que Stripe encaja bien en un sistema montado por piezas: puedes construir lógica encima sin pedirle permiso a nadie. ## Link y "enlace de pago": dos cosas distintas con el mismo nombre Esta confusión está en todas partes, incluida la primera página de Google, así que vale la pena zanjarla: - **Link** es la cartera digital de Stripe. Guarda de forma segura los datos de pago y la dirección del comprador y los autorrellena en su siguiente compra, con un código de un solo uso al email o al teléfono. Funciona con Checkout, Payment Links, Elements e Invoicing, según la [documentación de Link](https://docs.stripe.com/payments/link) (consultado en septiembre de 2026). Cuando a tu cliente le aparece un cargo de "Link" o le piden un código, es esto. - **Payment Links** (enlaces de pago) son URLs que tú creas desde el Dashboard o por API para vender un producto o una suscripción sin programar, compartibles por email, redes o un código QR, según la [documentación de Payment Links](https://docs.stripe.com/payments/payment-links) (consultado en septiembre de 2026). Uno es del comprador. El otro es tuyo. No tienen nada que ver más allá del nombre. Un apunte de criterio sobre los enlaces de pago: son una manera excelente de empezar a cobrar en una tarde, y una manera excelente de acabar con veinte enlaces sueltos que nadie sabe a qué producto corresponden. Si vas a usarlos, trátalos como un catálogo: nombres consistentes, productos creados una vez y parámetros en la URL para saber de dónde viene cada venta. ## Cuánto cuesta Stripe en España Las cifras vigentes en la [página de precios de Stripe para España](https://stripe.com/es/pricing) (consultado en septiembre de 2026): | Concepto | Comisión | |---|---| | Tarjetas estándar del EEE | 1,5 % + 0,25 € | | Tarjetas prémium del EEE | 2,8 % + 0,25 € | | Tarjetas internacionales | 3,15 % + 0,25 € | | Conversión de divisa | +2 % | | Invoicing | 0,4 % del total, con un tope por factura | | Billing (pago por consumo) | 0,7 % del volumen facturado | Dos avisos. El primero: los precios cambian, así que comprueba la página oficial antes de meter estos números en una hoja de cálculo. El segundo, más importante para el margen: **el coste real no es la comisión del cobro, es la suma de las capas**. Un negocio de suscripción que usa Payments más Billing más Tax paga tres cosas, no una. Haz el cálculo sobre tu ticket medio y tu recurrencia antes de decidir. Sobre cuándo ves el dinero: según la [documentación de transferencias](https://docs.stripe.com/payouts) (consultado en septiembre de 2026), la primera tarda entre 7 y 14 días desde el primer cobro y luego se aplica el calendario de tu cuenta, con un plazo estándar en la eurozona de 3 días hábiles desde la captura. Si estás planificando un lanzamiento con gasto en publicidad, ese desfase entra en la previsión de caja. ## La parte que decide si Stripe te sirve: los eventos Aquí está el núcleo. Stripe notifica lo que ocurre mediante **webhooks**: envía un evento a una URL tuya cada vez que pasa algo relevante. Ese mecanismo es lo que permite que el resto de tu negocio reaccione solo. El circuito mínimo de un negocio digital: 1. El cliente paga en Checkout o con un enlace de pago. 2. Stripe confirma el cobro y emite un evento. 3. Tu sistema lo recibe, verifica la firma y comprueba que no lo había procesado ya. 4. Consulta el estado actual en Stripe (no se fía del contenido del evento ni del orden en que llegan). 5. Da el acceso en la plataforma, crea o actualiza la ficha en el CRM y dispara la factura. 6. Registra qué hizo, con qué evento y con qué resultado. Los tres detalles que separan un circuito que aguanta de uno que da problemas cada pocas semanas son siempre los mismos: **verificar la firma**, **descartar eventos duplicados por su identificador** y **no depender del orden de llegada**. Los he desarrollado con casos concretos en [pagos fallidos en Stripe y control de accesos](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/), que es el problema más caro de esta familia: alumnos dentro sin pagar y alumnos pagando sin acceso. Y uno más, de datos: **relaciona al cliente por el identificador de Stripe, nunca por el email**. Guarda ese ID en la ficha del CRM y en la de la plataforma desde la primera compra. El email cambia, se escribe con mayúsculas distintas o se usa uno para pagar y otro para acceder al curso. Un identificador estable es lo único que aguanta el tiempo. ## Cómo encaja Stripe en un embudo de venta Puesto en el mapa de un lanzamiento o de una venta recurrente, Stripe ocupa un sitio muy concreto: | Capa | Quién manda | |---|---| | Captación y anuncios | Tus plataformas de publicidad | | Página de venta | Tu web | | Cobro y estado de la suscripción | **Stripe** | | Acceso al producto | Tu plataforma de cursos o membresía | | Relación con el cliente | Tu CRM | | Factura fiscal | Tu software de facturación | La regla que evita la mayoría de los líos: **el pago manda y el acceso obedece**. Stripe es la fuente de verdad del estado del cobro; la plataforma y el CRM reflejan ese estado, no lo deciden. En cuanto alguien empieza a dar accesos a mano "porque este cliente es de confianza", la fuente de verdad se rompe y ya nadie sabe quién debería estar dentro. Si estás montando esto para una campaña concreta, el [checklist técnico de un lanzamiento](https://fcgsystems.es/blog/checklist-tecnico-lanzamiento/) recorre el resto de capas con el mismo criterio: probar con volumen antes de abrir registros, no después. ## Stripe y la factura: cuidado con darlo por hecho Stripe Invoicing genera documentos de cobro perfectamente útiles para el cliente. Cosa distinta es que esos documentos cumplan los requisitos que el reglamento español exige al software que emite facturas: registro de facturación, huella encadenada, registro de eventos, QR y una declaración responsable del fabricante. Lo he desarrollado en [qué es Verifactu y qué tiene que hacer tu software](https://fcgsystems.es/blog/verifactu-que-es/). El patrón que veo funcionar es separar responsabilidades: Stripe cobra y notifica, y un software de facturación que sí declara cumplir emite la factura fiscal a partir de esos datos. Qué te aplica a ti y desde cuándo es una pregunta para tu asesor fiscal; **FCG Systems no da asesoramiento fiscal**, se ocupa de que los datos viajen bien entre ambos sistemas. ## Cuándo Stripe no es la respuesta Por honestidad, porque no todo encaja: - **Si vendes solo en España a consumidor y con ticket bajo**, comprueba si una pasarela local o un TPV virtual de tu banco te sale más barato en comisiones. El valor de Stripe está en la API y en los eventos; si no vas a usarlos, pagas por algo que no aprovechas. - **Si tu plataforma de cursos ya trae su propia pasarela integrada** y tu política de accesos es simple, añadir Stripe por separado puede complicar más de lo que resuelve. - **Si tu negocio necesita métodos de pago locales muy concretos** que Stripe no cubre en tu mercado, la decisión la marca la disponibilidad, no la tecnología. ## Checklist de una integración de Stripe que aguanta - Productos y precios creados una vez en Stripe, no duplicados por campaña. - Identificador de cliente de Stripe guardado en el CRM y en la plataforma. - Endpoint de webhooks con verificación de firma. - Eventos duplicados descartados por su identificador. - La lógica consulta el estado actual y no depende del orden de los eventos. - Acciones de dar y quitar acceso idempotentes. - Reintentos de cobro y emails de pago fallido configurados en el Dashboard. - Emisión de la factura fiscal delegada en un sistema que declare cumplir la normativa. - Reconciliación diaria entre cobros en Stripe, accesos activos y facturas emitidas. - Log de cada decisión y un responsable que recibe los avisos de fallo. - Claves en un gestor de secretos, nunca en el código ni en un flujo compartido. ## Cuándo conviene que lo monte alguien de sistemas Si vendes un producto, con un precio y una plataforma que trae integración nativa con Stripe, configúralo tú y dedica el tiempo a vender. Cuando tiene sentido delegarlo es cuando el cobro toca más de dos sistemas, cuando hay varios productos o planes, cuando ya has encontrado a alguien con acceso sin pagar o cuando el lanzamiento concentra en pocas horas lo que el negocio factura en meses. Ahí la integración de pagos, accesos y datos es exactamente el trabajo del servicio de [infraestructura de lanzamientos](https://fcgsystems.es/servicios/infraestructura-de-lanzamientos/): diseño, integración, pruebas con volumen, logs y documentación. Si tus cobros y tus accesos no cuadran, o no sabes si cuadran, [cuéntame cómo está montado tu embudo](https://fcgsystems.es/contacto/) y lo revisamos. ## Preguntas frecuentes ### ¿Qué es Stripe y para qué sirve? Stripe es una plataforma de infraestructura de pagos que permite a un negocio cobrar por internet con tarjeta y otros métodos, gestionar suscripciones y emitir documentos de cobro. Su diferencia con una pasarela clásica es que todo lo que hace está expuesto por API y notifica cada cambio con eventos, así que otros sistemas pueden reaccionar automáticamente. ### ¿Qué diferencia hay entre Link de Stripe y un enlace de pago de Stripe? Son cosas distintas con nombres parecidos. Link es la cartera digital de Stripe: guarda de forma segura los datos de pago del comprador y los autorrellena en su siguiente compra, y funciona con Checkout, Payment Links, Elements e Invoicing. Un Payment Link o enlace de pago es una URL que tú creas para vender un producto o una suscripción sin escribir código. ### ¿Cuánto cobra Stripe por cada cobro en España? Según la página de precios de Stripe para España consultada en septiembre de 2026, las tarjetas estándar del Espacio Económico Europeo son 1,5 % + 0,25 €, las tarjetas prémium del EEE 2,8 % + 0,25 € y las tarjetas internacionales 3,15 % + 0,25 €, con un 2 % adicional cuando hace falta conversión de divisa. Los productos como Billing o Invoicing se facturan aparte. Comprueba siempre la página oficial antes de hacer números. ### ¿Cuándo llega a mi banco el dinero cobrado con Stripe? Según la documentación de Stripe, la primera transferencia tarda entre 7 y 14 días desde el primer cobro, y a partir de ahí se aplica el calendario de transferencias de tu cuenta con un plazo estándar en la eurozona de 3 días hábiles desde la captura del pago. El calendario se configura en el Dashboard. ### ¿Las facturas de Stripe me valen para cumplir la normativa española? Los documentos que genera Stripe Invoicing son útiles para el cliente, pero el Reglamento español exige que el sistema que emite tus facturas cumpla unos requisitos concretos y venga acompañado de una declaración responsable del fabricante. Pregunta a tu proveedor de software de facturación qué declara para España y consulta a tu asesor fiscal: FCG Systems integra sistemas, no da asesoramiento fiscal. ## Servicios relacionados - [Infraestructura de lanzamientos](https://fcgsystems.es/servicios/infraestructura-de-lanzamientos/): Captación, tracking, reparto a tu equipo comercial y WhatsApp listos para miles de registros. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Qué es un chatbot (y en qué se diferencia de un agente de IA) > Qué es un chatbot, cómo funciona, qué tipos hay y en qué se diferencia de ChatGPT o de un agente de IA. Con las desventajas reales y cuándo no hace falta. - URL: https://fcgsystems.es/blog/que-es-un-chatbot/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: IA aplicada · Formato: Breakdown · Lectura: 5 min - Palabra clave: qué es un chatbot (también: que es chatbot, chatbot ia, chatbot que es, tipos de chatbot, chatbot en español) **Un chatbot es un programa que conversa con una persona por texto o voz y responde en su lugar a preguntas o peticiones previstas.** Puede vivir en una web, en WhatsApp o en un teléfono, y puede funcionar con un árbol de reglas fijo o con un modelo de lenguaje. En español se le llama bot conversacional o asistente conversacional. La definición es sencilla. Lo confuso es todo lo que hoy se llama chatbot: desde un formulario con forma de burbuja hasta un agente con acceso al CRM. Y esa distinción determina el coste, el riesgo y quién tiene que mantenerlo. ## ¿Cómo funciona un chatbot? Por dentro siempre son los mismos tres pasos, independientemente de la tecnología: 1. **Entrada.** Llega un mensaje por un canal (widget web, WhatsApp, o [voz transcrita en tiempo real](https://fcgsystems.es/blog/agente-de-voz-ia/)). 2. **Decisión.** El sistema determina qué responder. Aquí es donde se diferencian unos de otros. 3. **Salida.** Devuelve la respuesta por el mismo canal y, si hace falta, ejecuta una acción: crear un ticket, consultar un pedido, agendar una cita. Todo lo demás (memoria de la conversación, derivación a un humano, registros) se construye alrededor de esos tres pasos. ## ¿Qué tipos de chatbot hay? Conviven tres generaciones, y la más nueva no sustituye siempre a las anteriores. | Tipo | Cómo decide la respuesta | Punto fuerte | Punto débil | |---|---|---|---| | De reglas | Árbol de opciones y botones definido por una persona | Predecible al cien por cien, barato | Se rompe en cuanto el usuario se sale del guion | | De intenciones | Clasifica el mensaje entre un conjunto cerrado de casos previstos | Admite lenguaje libre en casos conocidos | Hay que entrenar y mantener cada intención | | Con modelo de lenguaje | Genera la respuesta a partir de tu documentación | Cubre preguntas que nadie previó | Puede responder de forma incorrecta con tono seguro | En la práctica, lo que mejor funciona en un negocio suele ser híbrido: reglas deterministas para lo crítico (comprobar un pedido, dar un acceso, cobrar) y modelo de lenguaje solo para responder preguntas. La lógica que decide algo va en código; la que redacta, en el modelo. ## Chatbot, asistente y agente de IA: no son lo mismo Las tres palabras se usan como sinónimos y no lo son. La diferencia está en **cuánta autonomía tiene el sistema para actuar**. - **Chatbot.** Responde. Puede consultar datos, pero no toma decisiones fuera de lo previsto. - **Asistente.** Responde y ejecuta un conjunto cerrado de acciones concretas que alguien ha definido. - **Agente de IA.** Decide por sí mismo qué pasos dar y qué herramientas usar para completar una tarea, y repite hasta terminar. La diferencia importa porque el riesgo crece con la autonomía. Un chatbot que se equivoca da una respuesta mala; un agente que se equivoca puede ejecutar una acción mala. Qué es exactamente un agente, cuándo compensa y cómo ponerle límites está en [agentes de IA para negocios](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/). ## ¿Y ChatGPT? ¿Es un chatbot? Sí: ChatGPT es un chatbot construido sobre un modelo de lenguaje de propósito general. La diferencia con un chatbot de empresa es el alcance. ChatGPT responde sobre casi cualquier cosa y no sabe nada de tu negocio. Un chatbot de empresa está limitado a un dominio, conectado a tus sistemas y sujeto a reglas sobre lo que puede prometer. Por eso un modelo potente no basta. Lo que hace útil a un chatbot de empresa es lo que hay alrededor: a qué documentación accede, qué puede consultar, qué tiene prohibido decir y cuándo debe pasar la conversación a una persona. ## El chatbot de WhatsApp, que es el caso real de casi todo el mundo Cuando una empresa española pide "un chatbot", normalmente quiere uno en WhatsApp, porque es donde ya le escriben los clientes. Eso no es un chatbot cualquiera: exige la WhatsApp Business Platform, con un número verificado y una aplicación conectada a la API de Meta, según su [documentación oficial](https://developers.facebook.com/docs/whatsapp/cloud-api) (consultada en septiembre de 2026). Las consecuencias prácticas que más sorprenden son tres: los mensajes que inicia la empresa requieren plantillas aprobadas, hay ventanas de tiempo para responder fuera de las cuales cambian las reglas, y el envío tiene coste por conversación. Todo eso está desarrollado en la guía de [WhatsApp Business API](https://fcgsystems.es/blog/whatsapp-business-api/). ## ¿Cuáles son las desventajas reales de un chatbot? Ninguna de estas es motivo para descartarlo, pero todas hay que aceptarlas antes de empezar: - **Responde mal con tono seguro.** Un modelo sin límites bien puestos inventa condiciones, plazos o precios. Se mitiga acotando las fuentes y prohibiendo temas. - **Atrapa al usuario.** Un chatbot sin salida hacia una persona convierte una duda en una queja. La derivación se diseña el primer día, no cuando llegan las reclamaciones. - **Envejece.** Bebe de una documentación que cambia. Si nadie la actualiza, empieza a dar respuestas correctas sobre condiciones que ya no existen. - **Añade un punto de fallo.** Es una integración más que puede caerse un domingo. Necesita registros y alertas como cualquier otra pieza del sistema. - **No se mide solo.** Saber si funciona exige leer conversaciones reales y contar cuántas se resolvieron y cuántas acabaron en una persona. ## ¿Cuándo no hace falta un chatbot? Casi siempre por una de estas cuatro razones: - **Recibes pocas consultas.** Con veinte mensajes a la semana, una persona responde mejor y sale más barato. - **Todas las preguntas son distintas.** Un chatbot rinde cuando hay repetición. Sin patrón, no hay nada que automatizar. - **La respuesta ya está en la web, pero nadie la encuentra.** Entonces el problema es de navegación o de contenido, no de conversación. - **Lo que quieres es ejecutar algo, no conversar.** Si el cliente necesita recuperar su acceso o ver su factura, un enlace directo y una automatización son mejores que una charla. ## Cómo lo abordamos en FCG Systems Empezamos por las conversaciones reales de los últimos meses: qué se pregunta, cuántas veces y qué hace falta para responder. Lo que se puede resolver con una regla o un enlace no va al modelo. Lo que queda se construye con fuentes acotadas, derivación a una persona desde el primer día y registros para saber qué contesta de verdad. Si una regla simple resuelve el problema, no hace falta un modelo. Puedes ver cómo trabajamos en [inteligencia artificial aplicada](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/) o [contarnos qué consultas os están comiendo el día](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Qué es un chatbot y cómo funciona? Un chatbot es un programa que mantiene una conversación por texto o voz con una persona. Funciona en tres pasos: recibe el mensaje, decide qué responder (siguiendo un árbol de reglas o generando la respuesta con un modelo de lenguaje) y devuelve el resultado por el canal correspondiente, ya sea la web, WhatsApp o un teléfono. ### ¿Qué diferencia hay entre ChatGPT y un chatbot? ChatGPT es un chatbot concreto, construido sobre un modelo de lenguaje de propósito general y sin acceso a los datos de tu negocio. Un chatbot de empresa es un sistema propio con un alcance limitado, conectado a tus sistemas y con reglas sobre lo que puede y no puede hacer o decir. ### ¿Qué tipos de chatbot existen? Tres generaciones que hoy conviven. Los de reglas siguen un árbol de opciones fijo. Los de intenciones clasifican lo que pide el usuario entre un conjunto cerrado de casos previstos. Y los de modelo de lenguaje generan la respuesta a partir de tu documentación. Se pueden combinar en un mismo flujo. ### ¿Cómo funciona un chatbot de WhatsApp? Necesita la WhatsApp Business Platform: un número verificado y una aplicación conectada a la API de Meta. Cuando alguien escribe, Meta envía el mensaje a tu sistema mediante un webhook, tu sistema decide la respuesta y la devuelve por la API. Hay reglas de plantillas y ventanas de tiempo para escribir el primero. ### ¿Cuáles son las desventajas de un chatbot? Cinco habituales: puede dar respuestas incorrectas con tono seguro, frustra cuando no sabe derivar a una persona, exige mantener actualizada la documentación de la que bebe, añade un punto de fallo más en la atención al cliente y obliga a revisar conversaciones reales para saber si funciona. Ninguna se resuelve sola. ### ¿Hay que avisar de que se está hablando con un chatbot? El Reglamento europeo de IA incluye obligaciones de transparencia para los sistemas que interactúan directamente con personas: deben estar diseñados para que el usuario sepa que habla con una IA, salvo que resulte evidente. Más allá de la norma, avisar reduce las quejas. No es asesoramiento legal: revisa tu caso concreto. ## Servicios relacionados - [Sistemas de IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Qué es un CRM (y qué es en realidad para un negocio digital) > Qué es un CRM, para qué sirve en una empresa, qué tipos hay y en qué se diferencia de un ERP. Con el criterio de cuándo un Excel deja de ser suficiente. - URL: https://fcgsystems.es/blog/que-es-un-crm/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Breakdown · Lectura: 5 min - Palabra clave: qué es un crm (también: crm que es, para qué sirve un crm, qué es un crm en una empresa, crm significado, crm en español) **Un CRM (Customer Relationship Management) es el sistema donde vive todo lo que tu empresa sabe de cada cliente y cliente potencial: quién es, de dónde vino, qué se le ha dicho y en qué punto está la relación.** Su función no es guardar contactos, sino sostener el proceso comercial: qué estados existen, quién es responsable de cada uno y qué pasa cuando algo cambia. Esa última parte es la que separa un CRM que sirve de una agenda cara. Aquí va la definición completa, la diferencia con un ERP y el criterio para saber cuándo hace falta. ## ¿Para qué sirve un CRM en una empresa? Un CRM resuelve cuatro problemas concretos. Si tu negocio no tiene ninguno de ellos, probablemente aún no lo necesites. - **Una sola versión de cada cliente.** Sin CRM, la información está repartida entre la bandeja de entrada de una persona, una hoja de cálculo y la memoria de un comercial. Con CRM, hay un registro y una historia. - **Un proceso explícito.** Los estados por los que pasa una venta dejan de ser una convención tácita y pasan a estar escritos: qué es un lead, cuándo se convierte en oportunidad, cuándo se da por perdida. - **Seguimiento que no depende de acordarse.** Tareas, avisos y plazos asociados al registro, no a la agenda de alguien. - **Medición honesta.** Cuántas oportunidades hay, de qué origen vienen y dónde se caen. Esto solo funciona si la definición de cada estado es la misma para todos. Lo que un CRM **no** hace: vender por ti, arreglar un proceso comercial que nadie ha definido, ni limpiar unos datos que entran sucios. Un CRM amplifica el proceso que ya tienes. Si el proceso es confuso, el CRM lo hace confuso más deprisa. ## ¿Qué tipos de CRM hay? La clasificación clásica distingue tres funciones, que en los productos reales vienen mezcladas (cada una, con sus señales de que se te ha quedado corta, en [los tipos de CRM al detalle](https://fcgsystems.es/blog/tipos-de-crm/)): | Tipo | Qué resuelve | Señal de que lo necesitas | |---|---|---| | Operativo | El día a día: contactos, oportunidades, tareas, seguimiento | Se te escapan seguimientos o no sabes quién lleva cada cliente | | Analítico | Explotar los datos: conversión por origen, ciclos, previsión | Inviertes en campañas sin saber cuáles acaban en venta | | Colaborativo | Compartir el contexto del cliente entre ventas, marketing y soporte | El cliente repite su historia en cada conversación | Hay una segunda distinción, más práctica para decidir: **CRM de catálogo o CRM a medida**. Los productos del mercado cubren el 90 % de los casos y salen mucho más baratos. El software propio compensa cuando el proceso comercial es el producto, o cuando el CRM tiene que ser el centro de un sistema que ya incluye pagos, accesos y entregas. Ese análisis, con el criterio de coste, está en [CRM para pymes: de catálogo o a medida](https://fcgsystems.es/blog/crm-para-pymes-saas-o-a-medida/). ## ¿Qué diferencia hay entre un CRM y un ERP? Es la confusión más repetida, y tiene una respuesta corta: **el CRM mira hacia fuera, el ERP mira hacia dentro.** - El **CRM** gestiona la relación antes y durante la venta: contactos, oportunidades, comunicaciones, previsión. - El **ERP** gestiona los recursos que permiten cumplir: facturación, inventario, compras, contabilidad. Se tocan en un punto: el pedido. Ahí es donde hay que decidir cuál de los dos es la fuente de verdad de cada dato, porque si ambos lo son, los números dejan de cuadrar y alguien acaba corrigiéndolos a mano cada mes. La comparación completa, campo por campo y con cuándo hace falta cada uno, está en [CRM y ERP: qué gestiona cada uno](https://fcgsystems.es/blog/diferencia-crm-erp/). ## Cuándo un Excel deja de servir Casi todos los negocios empiezan con una hoja de cálculo, y durante un tiempo es la decisión correcta. Estas son las señales de que dejó de serlo: 1. **Dos personas editan a la vez** y la última en guardar gana. 2. **El mismo cliente aparece dos veces**, con un correo distinto en cada fila. 3. **Alguien copia datos a mano** entre el formulario, la hoja y la herramienta de correo. 4. **Nadie sabe cuál es la versión buena**, porque hay tres archivos con sufijos de fecha. 5. **La cifra del mes depende de quién la calcule.** Cuando aparecen tres de las cinco, el problema ya no es la herramienta: es que no hay una fuente de verdad. Cómo se ve eso en el recorrido de un lead está en [leads que se pierden](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). ## El CRM que nadie actualiza El fallo más caro de un CRM no es elegir el producto equivocado. Es implantar uno que el equipo no usa. Ocurre casi siempre por las mismas razones: - **Pide datos que a nadie le sirven.** Doce campos obligatorios para crear un contacto garantizan que se creen fuera del CRM. - **Obliga a trabajar de otra forma sin motivo.** Si el proceso real tiene cinco estados y el CRM impone ocho, alguien empezará a saltárselos. - **La entrada de datos es manual.** Si los leads no entran solos desde el formulario, entrarán tarde o no entrarán. - **Nadie mira lo que sale.** Un CRM que no se usa para decidir nada se convierte en un trámite. La prueba honesta es sencilla: si mañana el CRM dejara de existir, ¿alguien lo notaría antes de una semana? Si la respuesta es no, tienes una base de datos, no un sistema. ## Qué hay que definir antes de elegir uno Antes de comparar productos, conviene tener escritas estas cinco cosas. Son las que determinan si la implantación funcionará, mucho más que la lista de funciones: - Los **estados** por los que pasa una venta, con el criterio exacto para cambiar de uno a otro. - La **definición de lead** que el sistema puede comprobar por sí mismo. La desarrollamos en [qué es un lead](https://fcgsystems.es/blog/que-es-un-lead/). - Cómo entran los datos: **qué formularios y qué integraciones**, y qué pasa cuando una falla. - Qué campos son **obligatorios de verdad** (cuantos menos, mejor). - Qué **sistema manda** sobre cada dato que también existe en otra herramienta. ## Cómo lo abordamos en FCG Systems No empezamos por el producto. Mapeamos el proceso comercial tal y como ocurre, definimos los estados y la fuente de verdad de cada dato, y después decidimos si lo correcto es un CRM de catálogo bien integrado o un sistema propio. En los dos casos, la entrada de datos se automatiza: un CRM que hay que rellenar a mano se queda vacío. Puedes ver cómo trabajamos en [software a medida](https://fcgsystems.es/servicios/software-a-medida/) o [contarnos cómo lleváis hoy vuestros clientes](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Qué es un CRM y para qué sirve? CRM son las siglas de Customer Relationship Management: un sistema que centraliza todo lo que tu empresa sabe de cada cliente y cada cliente potencial, y el estado en que está su relación con vosotros. Sirve para que el proceso comercial sea el mismo para todos, no dependa de la memoria de nadie y se pueda medir. ### ¿Cuáles son los tipos de CRM? Se suelen distinguir tres. El operativo gestiona el día a día comercial: contactos, oportunidades, tareas. El analítico explota los datos para entender qué funciona. Y el colaborativo comparte la información del cliente entre ventas, marketing y soporte. La mayoría de los productos del mercado combinan los tres en distinto grado. ### ¿Qué diferencia hay entre un CRM y un ERP? El CRM gestiona la relación con el cliente antes y durante la venta: quién es, qué le habéis dicho y en qué punto está. El ERP gestiona los recursos internos que hacen posible entregar: facturación, inventario, contabilidad, compras. Se solapan en el pedido, y por eso deben hablarse en lugar de duplicar datos. ### ¿Es SAP un CRM o un ERP? SAP es un fabricante que vende ambas cosas: productos de ERP para la gestión interna y productos de CRM para la parte comercial. Lo mismo ocurre con otros grandes proveedores. La pregunta útil no es qué marca es cuál, sino qué sistema es la fuente de verdad de cada dato en tu operación. ### ¿Cuál es el mejor CRM para una empresa? El que tu equipo actualice de verdad. Los más extendidos (Salesforce, HubSpot, Zoho, Pipedrive y similares) cubren de sobra lo habitual; la diferencia rara vez está en las funciones y casi siempre en si el CRM refleja vuestro proceso real. Un CRM que obliga a trabajar de otra manera acaba vacío. ### ¿Cuándo deja de servir un Excel como CRM? Cuando más de una persona lo edita a la vez, cuando el mismo cliente aparece dos veces, cuando nadie sabe cuál es la última versión o cuando hay que copiar datos a mano entre el formulario, la hoja y el correo. En ese punto el problema ya no es la herramienta: es que no hay una única fuente de verdad. ## Servicios relacionados - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Qué es un dashboard (y por qué el tuyo no sirve para decidir) > Qué es un dashboard, qué significa en español, qué debe tener y en qué se diferencia de un informe. Y por qué muchos paneles no sirven para decidir nada. - URL: https://fcgsystems.es/blog/que-es-un-dashboard/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Breakdown · Lectura: 5 min - Palabra clave: qué es un dashboard (también: dashboard que es, dashboard en español, qué es el dashboard, dashboard significado, cuadro de mando) **Un dashboard es una pantalla que reúne los indicadores clave de un negocio o de un proceso y los muestra actualizados en un solo sitio.** En español se le llama panel de control o cuadro de mando. Su propósito no es enseñar datos, sino responder en segundos a una pregunta concreta: cómo va el mes, qué campaña trae clientes, dónde se está cayendo el embudo. La mayoría de los paneles que vemos cumplen la primera parte y no la segunda. Están llenos de gráficos y no ayudan a decidir nada. Esa diferencia casi nunca está en la herramienta; está en lo que hay detrás. ## ¿Para qué sirve un dashboard? Para tres cosas, y ninguna de ellas es "tener los datos a mano": - **Detectar un cambio a tiempo.** Las ventas caen un 30 % un martes. Si te enteras el día 5 del mes siguiente, la información ya no sirve para actuar. - **Resolver una discusión con un dato.** Cuando marketing y ventas dan cifras distintas, el panel debe zanjar la duda, no añadir una tercera versión. - **Ver el efecto de lo que hicisteis.** Cambiasteis el formulario hace dos semanas: ¿entran más leads o entran peor cualificados? Si un panel no hace ninguna de las tres, es decoración. Cara, porque alguien lo mantiene. ## ¿Qué diferencia hay entre un dashboard, un informe y una hoja de cálculo? | | Qué responde | Cuándo se mira | Quién lo actualiza | |---|---|---|---| | Hoja de cálculo | Lo que alguien decidió calcular ese día | Cuando hace falta | Una persona, a mano | | Informe | Qué pasó en un periodo cerrado | Una vez, al cerrarlo | Automático o manual | | Dashboard | Cómo va ahora y qué se sale de lo normal | De forma recurrente | El sistema, solo | La prueba práctica: si para que el panel esté al día alguien tiene que exportar un CSV y pegarlo, no es un dashboard. Es un informe con un paso manual escondido, y ese paso se saltará el día que más falta haga. ## Por qué muchos dashboards no sirven para decidir Casi siempre por una de estas cinco razones. Las cuatro primeras son de diseño; la quinta es la grave. 1. **Responde a demasiadas preguntas a la vez.** Veinte widgets que mezclan tráfico, ventas, soporte y finanzas no responden a ninguna. Un panel, una audiencia, una pregunta. 2. **Las cifras no tienen contexto.** "1.240 visitas" no dice nada. "1.240 visitas, un 18 % menos que la semana anterior" ya es una señal. 3. **Mide lo que es fácil de medir.** Impresiones y clics se recogen solos. Lo que decide el negocio (leads cualificados, margen, recurrencia) exige cruzar fuentes, y por eso se queda fuera. 4. **Nadie es responsable de ninguna cifra.** Un indicador sin dueño no provoca acciones, solo comentarios en una reunión. 5. **Las cifras no se creen.** En cuanto alguien encuentra un número que no cuadra con su herramienta, el panel entero pierde autoridad. Y no vuelve a recuperarla. ## El problema real está debajo del panel Ese quinto punto es el que hunde la mayoría de los proyectos de datos, y no se arregla cambiando de herramienta. Cuando GA4 dice una cosa, la plataforma de anuncios otra y el CRM una tercera, es casi siempre porque: - **Cada sistema atribuye distinto.** El último clic, el primero, con o sin ventana de conversión: [asignar una venta a un canal](https://fcgsystems.es/blog/que-es-la-atribucion/) admite más de una respuesta válida y cada herramienta elige la suya. - **Las ventanas y las zonas horarias no coinciden.** Un día no empieza a la misma hora en todas las herramientas. - **Los duplicados se cuentan.** El mismo lead entra dos veces y el panel suma dos. - **Las devoluciones y los impagos no se restan.** Los ingresos del panel no son los ingresos que cobras. Por qué esas cifras nunca coinciden, y qué hacer al respecto, está en [atribución rota: GA4, Meta y tu CRM](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/). Y si el desajuste viene de contar dos veces la misma conversión, el caso concreto del [píxel de Meta y la API de conversiones](https://fcgsystems.es/blog/pixel-meta-api-conversiones-duplicados/) lo explica paso a paso. La conclusión es incómoda pero ahorra meses: **un dashboard no arregla unos datos que no cuadran. Los publica.** ## Qué necesita un dashboard para ser fiable Antes de elegir entre Looker Studio, Metabase, Power BI o un panel propio, hace falta tener resueltas estas cuatro cosas. - **Una fuente de verdad por dato.** Qué sistema manda sobre los ingresos, cuál sobre los leads, cuál sobre el gasto. Si dos sistemas mandan sobre lo mismo, el conflicto es cuestión de tiempo. - **Definiciones escritas.** Qué cuenta exactamente como "lead", como "venta" o como "cliente activo". Sin esto, cada persona lee el mismo gráfico de forma distinta. Conviene fijar antes [qué es un lead](https://fcgsystems.es/blog/que-es-un-lead/) en vuestro sistema. - **Un identificador que cruce sistemas.** Algo que permita seguir a la misma persona del anuncio al pago. Suele ser lo que falta. - **Frescura visible.** La fecha y hora de la última actualización, en el propio panel. Un dato de hace tres días sin avisar es peor que no tener dato. Las herramientas ayudan y están bien documentadas: [Looker Studio](https://support.google.com/looker-studio/answer/6283323) permite construir paneles sobre varias fuentes, y [GA4](https://developers.google.com/analytics/devguides/collection/ga4) admite eventos propios para medir lo que de verdad importa en tu negocio (ambas consultadas en septiembre de 2026). Pero ninguna resuelve las cuatro condiciones de arriba: eso es trabajo de diseño del sistema. ## Cómo diseñar uno que sí se use Un método corto que funciona: 1. **Escribe la pregunta.** Una sola, en una frase: "¿de qué canal vienen los clientes que más facturan?". 2. **Decide qué acción cambia la respuesta.** Si ninguna, no hace falta el panel. 3. **Elige entre tres y siete indicadores.** Con su definición y su dueño. 4. **Añade contexto a cada cifra.** Periodo anterior u objetivo. 5. **Comprueba el dato contra el sistema de origen.** Una vez, a mano, antes de publicarlo. Si no cuadra, arregla la fuente, no el panel. 6. **Fija quién lo mira y cuándo.** Un panel sin un momento de lectura acaba olvidado. ## Cómo lo abordamos en FCG Systems Empezamos por las decisiones, no por los gráficos: qué vais a decidir con cada cifra y quién responde de ella. Después se arregla lo de abajo (medición, identificadores, duplicados, fuente de verdad) y solo al final se pinta el panel. Es menos vistoso y evita el resultado habitual: un cuadro de mando precioso que nadie se cree. Puedes ver cómo trabajamos en [datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/) o [contarnos qué decisión no podéis tomar hoy por falta de datos](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Qué es un dashboard y para qué sirve? Un dashboard es una pantalla que reúne los indicadores clave de una actividad y los muestra actualizados en un solo sitio. Sirve para responder en segundos a una pregunta concreta de negocio (cómo va el mes, dónde se está cayendo el embudo) sin tener que abrir cuatro herramientas y cuadrar cifras a mano. ### ¿Qué significa dashboard en español? Se traduce como panel de control o cuadro de mando. El término viene del salpicadero de un coche, y la analogía explica bien su función: mostrar pocas cifras, las que de verdad indican si hay que hacer algo, y mostrarlas mientras aún se puede reaccionar. ### ¿Qué diferencia hay entre un dashboard y un informe? Un informe cuenta lo que pasó en un periodo cerrado y se lee una vez. Un dashboard muestra el estado actual y se consulta de forma recurrente para decidir. Si nadie lo abre entre dos reuniones, lo que tienes no es un dashboard: es un informe con gráficos. ### ¿Qué debe tener un buen dashboard? Cuatro cosas: una pregunta clara a la que responde, pocos indicadores (entre tres y siete), una comparación que dé contexto a cada cifra (periodo anterior u objetivo) y la fuente y fecha de actualización a la vista. Si un número no cambia ninguna decisión, sobra en el panel. ### ¿Por qué las cifras del dashboard no coinciden con las de otras herramientas? Casi siempre porque cada herramienta mide cosas distintas con nombres parecidos: distintos criterios de atribución, distintas ventanas de conversión, distintas zonas horarias y distinto tratamiento de duplicados o devoluciones. La solución no es elegir la cifra que más gusta, sino definir cuál es la fuente de verdad de cada dato. ## Servicios relacionados - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Qué es un infoproducto y qué infraestructura necesita por debajo para funcionar > Qué es un infoproducto, qué tipos hay y qué necesita cada uno por debajo: pagos, accesos, entregas y datos. La parte técnica que decide si aguanta o no. - URL: https://fcgsystems.es/blog/infoproductos-que-son/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Infraestructura · Formato: Breakdown · Lectura: 7 min - Palabra clave: infoproductos (también: infoproductos que es, que son los infoproductos, tipos de infoproductos, ejemplos de infoproductos, infraestructura para infoproductos) Un infoproducto es un producto digital cuyo valor está en el conocimiento que transmite: un curso online, una membresía, una plantilla, un ebook o una mentoría. Se vende y se entrega por internet, sin soporte físico, y una vez construido el coste de entregar una unidad más es mínimo. De ahí viene su atractivo y también su fama. Hasta aquí la definición que encontrarás en cualquier sitio. Lo que casi nadie cuenta es la otra mitad: **un infoproducto no es un PDF, es un sistema**. Detrás de "comprar y acceder" hay un cobro, un estado de suscripción, un acceso que se concede, una entrega, un email que sale y un dato que debería acabar en algún sitio. Cuando esa cadena no está montada, el producto puede ser excelente y el negocio ir mal igualmente: gente que paga y no entra, gente que dejó de pagar y sigue dentro, y alguien del equipo haciendo de pegamento a mano. Este artículo va de esa mitad. ## Tipos de infoproducto, ordenados por lo que exigen por debajo La clasificación habitual (curso, ebook, membresía) es poco útil para decidir qué construir. Esta otra sí, porque agrupa por **modo de entrega**, que es lo que determina la infraestructura: | Tipo | Ejemplos | Qué exige por debajo | |---|---|---| | **Descarga directa** | Ebook, plantilla, preset, checklist | Cobro, entrega del archivo con enlace controlado, email | | **Contenido alojado** | Curso grabado, biblioteca de vídeos | Cobro, alta de usuario, alojamiento de vídeo, seguimiento de progreso | | **Acceso recurrente** | Membresía, comunidad, newsletter de pago | Suscripciones, estados de pago, alta y **baja** automáticas, control de accesos | | **Directo y cohortes** | Taller, formación por cohortes, mentoría | Cupo, calendario, recordatorios, grabaciones, acceso temporal | | **Servicio productizado** | Auditoría con entregable fijo | Formulario de entrada, gestión de expedientes, entrega y facturación | La fila que cambia el juego es la tercera. **En cuanto hay recurrencia, el sistema deja de ser una entrega y pasa a ser un estado que hay que mantener sincronizado.** Un ebook se entrega una vez y se acabó. Una membresía tiene que saber, cada día, quién sigue pagando. Ese salto es donde la mayoría de los montajes caseros empiezan a perder dinero sin que nadie lo vea. ## Las seis capas que tiene todo infoproducto que funciona Da igual la plataforma que uses. Estas capas existen siempre; la única decisión es si están montadas a propósito o improvisadas. ### 1. Captación De dónde viene la gente y con qué origen registrado. Si un lead entra sin saber de qué canal viene, no vas a poder decidir dónde invertir. Aquí se pierde más dinero por datos mal guardados que por malas campañas. ### 2. Cobro La pasarela y, si hay recurrencia, la gestión de suscripciones: ciclos, reintentos de cobro fallido, cambios de plan, cancelaciones y reembolsos. Es la capa que tiene que ser la **fuente de verdad del estado del cliente**. Si quieres el detalle de cómo funciona una pasarela moderna por dentro, lo tienes en [qué es Stripe y cómo se integra](https://fcgsystems.es/blog/que-es-stripe/). ### 3. Acceso Quién puede entrar y hasta cuándo. La regla, escrita una vez y aplicada por el sistema: **el pago manda y el acceso obedece**. El acceso no se da porque alguien vuelva de la página de pago, se da porque el estado del cobro dice que puede darse. Y se quita solo cuando ese estado lo indica. Este es el punto donde más dinero se escapa. Los síntomas siempre son los mismos: clientes cancelados que siguen dentro, clientes que pagaron y escriben porque no pueden entrar, y una lista de impagos que alguien revisa a mano cada lunes. Lo he desarrollado entero, con los estados concretos de una suscripción, en [pagos fallidos y control de accesos](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/). ### 4. Entrega Dónde vive el contenido y cómo llega. Un vídeo en un alojamiento sin control de acceso es un vídeo que acabará circulando. Un PDF con enlace permanente es un PDF que se reenvía. No hablo de perseguir a nadie: hablo de que la entrega sea coherente con lo que has vendido. ### 5. Relación El CRM y el email. Aquí vive quién es cada persona, qué compró, en qué estado está y qué se le ha dicho. Cuando esto no existe, la información queda repartida entre la plataforma, la pasarela y la bandeja de entrada de alguien, y tomar cualquier decisión se convierte en una investigación. ### 6. Datos Qué se mide y con qué números se decide. Ventas, altas, bajas, recuperación de impagos, avance del alumno. Sin esta capa se decide por sensación. ## Los cinco fallos que aparecen una y otra vez No son hipótesis. Son los que me encuentro al abrir el capó de un negocio que factura: 1. **El acceso desacoplado del pago.** Lo primero que compruebo siempre. Si nadie puede decirme en un minuto quién debería tener acceso hoy y por qué, ya sé por dónde se está yendo el dinero. 2. **Solo está montado el caso feliz.** La integración contempla "paga y entra". No contempla el impago, la baja, el reembolso, el cambio de plan ni la compra con un email distinto al de acceso. 3. **El email como identificador.** Todo se relaciona por correo electrónico. Hasta que alguien paga con el email de su empresa y entra con el personal, y aparecen dos personas donde había una. 4. **Nadie reconcilia.** Nada compara cada día lo que hay en la pasarela con lo que hay en la plataforma. Las diferencias existen desde el primer mes; se descubren cuando alguien se queja. 5. **El lanzamiento como excepción.** El sistema aguanta el día a día y se rompe justo el día que concentra la mitad de la facturación del año. Para eso está el [checklist técnico de un lanzamiento](https://fcgsystems.es/blog/checklist-tecnico-lanzamiento/): probar con volumen antes, no descubrirlo en directo. Todos comparten la misma raíz: son procesos que fallan sin dar error. Nadie ve una alarma. Solo ves, meses después, las consecuencias. ## Qué construir en cada etapa (y qué no) El error de criterio más caro no es quedarse corto, es montar una infraestructura de negocio grande para un producto que todavía no ha vendido nada. **Primer producto, sin validar.** Una plataforma que integre pagos, contenido y accesos, y un email. Punto. No necesitas CRM propio ni tracking avanzado ni automatizaciones. Necesitas saber si alguien paga. Vender antes de construir no es atajo, es el orden correcto. **Producto validado, ventas recurrentes.** Aquí toca ordenar: identificador de cliente compartido entre pasarela, plataforma y email; accesos automáticos según el estado del pago; y una reconciliación diaria. Con esto se elimina la mayor parte del trabajo manual y de las fugas. **Varios productos o lanzamientos grandes.** El CRM pasa a ser la fuente de verdad del cliente, el tracking tiene que aguantar la atribución entre canales, la facturación se integra con los cobros y el sistema necesita logs, alertas con responsable y documentación. Es el punto en el que la herramienta de turno deja de dar de sí y hay que decidir qué se construye a medida. **Equipo y operación estable.** Procesos documentados, permisos por rol, entornos de prueba y capacidad de auditar qué pasó con cualquier cliente y cuándo. La señal para pasar de una etapa a la siguiente no es facturar más. Es esta: **alguien del equipo dedica horas cada semana a cuadrar a mano lo que dos sistemas deberían cuadrar solos**. Ese coste no aparece en ninguna factura y es el más alto de todos. ## Checklist mínimo antes de vender - Página de venta con la promesa y el precio claros. - Cobro funcionando, probado con una compra real (no solo en modo prueba). - Acceso concedido automáticamente a partir del estado del pago. - Baja automática cuando el pago deja de estar al corriente. - Contenido alojado con control de acceso, no en un enlace público. - Email de bienvenida con las instrucciones exactas para entrar. - Identificador de cliente compartido entre la pasarela y la plataforma. - Origen del lead guardado en el alta. - Un sitio único donde consultar quién es cada cliente y qué compró. - Comprobación diaria o semanal de que accesos y cobros cuadran. - Factura emitida por un sistema que declare cumplir la normativa española. - Alguien concreto recibe los avisos cuando algo falla. ## Dónde entra alguien de sistemas Si estás lanzando tu primer curso, no necesitas a nadie. Necesitas una plataforma, una pasarela y vender. Cuando la cosa cambia es cuando el negocio ya factura y el sistema empieza a costar dinero en silencio: accesos que no cuadran, impagos que nadie persigue, datos repartidos en cinco sitios, lanzamientos que se sostienen a base de gente pendiente del móvil. Eso es exactamente el trabajo del servicio de [infraestructura de lanzamientos](https://fcgsystems.es/servicios/infraestructura-de-lanzamientos/) y, cuando el problema es el día a día y no la campaña, de la [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/): conectar pagos, accesos, entregas y datos para que la operación funcione sin que nadie haga de pegamento. Si tu infoproducto ya vende pero por dentro hay más trabajo manual del que reconoces, [cuéntame cómo está montado](https://fcgsystems.es/contacto/) y lo revisamos. ## Preguntas frecuentes ### ¿Qué es un infoproducto? Un infoproducto es un producto digital cuyo valor está en el conocimiento que transmite: un curso online, una membresía, una plantilla, un ebook, una mentoría o una comunidad de pago. Se vende y se entrega por internet, sin soporte físico, y su coste de entrega por unidad adicional es muy bajo una vez construido. ### ¿Qué tipos de infoproductos hay? Se agrupan bien por cómo se entregan: descarga directa (ebook, plantilla, preset), acceso a contenido alojado (curso grabado, biblioteca de vídeos), acceso recurrente (membresía, comunidad, newsletter de pago), sesiones en directo (cohorte, taller, mentoría) y servicios productizados. Cada grupo exige una infraestructura distinta, y ahí es donde se decide si escala. ### ¿Qué necesito técnicamente para vender un infoproducto? Como mínimo: una página de venta, una pasarela de pago, un sistema que dé y quite el acceso según el estado del pago, un sitio donde vive el contenido, un canal de email y un lugar único donde queden los datos del cliente. Todo lo demás son capas que se añaden cuando el volumen lo justifica. ### ¿Cuál es el fallo técnico más común en un infoproducto? El acceso desacoplado del pago. Alguien paga y no entra, o deja de pagar y sigue dentro meses. Ocurre porque el acceso se concede a mano o porque la integración solo contempla el caso feliz: no escucha las bajas, los impagos ni los reembolsos. Es el fallo que más dinero cuesta y el que más tarde se detecta. ### ¿Hace falta una plataforma de infoproductos o es mejor montarlo por piezas? Al principio, una plataforma que integre pagos, contenido y accesos evita meses de trabajo y es la decisión correcta. Montarlo por piezas compensa cuando ya tienes varios productos, política de accesos propia, tráfico que medir con precisión o necesitas que el CRM sea la fuente de verdad del cliente. La señal de que toca cambiar es cuando alguien del equipo dedica horas cada semana a cuadrar accesos y cobros a mano. ## Servicios relacionados - [Infraestructura de lanzamientos](https://fcgsystems.es/servicios/infraestructura-de-lanzamientos/): Captación, tracking, reparto a tu equipo comercial y WhatsApp listos para miles de registros. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Qué es un lead (en marketing, en ventas y dentro de tu CRM) > Qué es un lead, qué significa en español, qué tipos existen y en qué se diferencia de un contacto. Con el matiz que importa: cómo se define en tu CRM. - URL: https://fcgsystems.es/blog/que-es-un-lead/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Automatización · Formato: Breakdown · Lectura: 4 min - Palabra clave: qué es un lead (también: que es un leads, qué es un lead en marketing, qué es un lead en ventas, leads en español, qué es un lead en un crm) **Un lead es una persona que ha dejado sus datos de forma voluntaria y ha mostrado interés en lo que vendes.** En español equivale a contacto interesado o cliente potencial. La diferencia con un contacto cualquiera es doble: hay una señal de interés y hay un origen conocido. Sin esas dos cosas, tienes un registro en una base de datos, no un lead. Esa definición vale para cualquier manual de marketing. Lo que casi nunca se explica es que la definición útil no es esa: es la que está escrita en tu CRM y que decide qué pasa con cada persona que entra. ## ¿Qué es un lead en marketing y qué es en ventas? La misma palabra significa cosas distintas según quién la use, y ahí empiezan la mayoría de las discusiones sobre cifras. - **En marketing**, un lead es el resultado medible de una campaña: alguien rellenó el formulario. La pregunta que responde es cuánto cuesta conseguirlo. - **En ventas**, un lead es alguien con quien hay que hablar antes de saber si sirve de algo. La pregunta que responde es cuántos se convierten en oportunidad. De esa diferencia salen las dos etiquetas que más se usan: | Etiqueta | Qué significa | Quién decide | |---|---|---| | MQL (Marketing Qualified Lead) | Encaja con el perfil de cliente y ha mostrado interés suficiente | Marketing, normalmente con criterios automáticos | | SQL (Sales Qualified Lead) | Alguien ha confirmado que hay necesidad, encaje y capacidad de decidir | Ventas, tras un contacto real | Las etiquetas solo tienen valor si cada una dispara algo distinto: una secuencia, una llamada, una asignación. Si MQL y SQL reciben el mismo trato, sobran las dos. ## ¿En qué se diferencia un lead de un contacto, una oportunidad y un cliente? Es una escalera de estados, y conviene que solo haya una por negocio: 1. **Visita anónima.** Alguien entra en la web. No tienes sus datos. 2. **Contacto.** Tienes un correo o un teléfono. Puede venir de cualquier sitio. 3. **Lead.** Ese contacto tiene origen conocido, señal de interés y está dentro de un proceso comercial activo. 4. **Oportunidad.** Se ha confirmado que hay una venta posible: necesidad, encaje y alguien que decide. 5. **Cliente.** Ha comprado. El error habitual es saltarse el escalón 3 y llamar leads a todos los contactos. El resultado es una tasa de conversión que baja cada mes sin que nadie sepa por qué: no baja la conversión, sube el ruido. ## ¿Qué necesita un lead para ser útil? Un lead que no se puede trabajar es peor que ninguno, porque ocupa sitio en las cifras y en el tiempo de alguien. Para que sirva, el registro necesita cuatro cosas desde el primer segundo. - **Origen.** Campaña, formulario y página exactos. Sin esto no puedes saber qué inversión funciona, y es lo primero que se pierde por el camino. Por qué GA4, Meta y el CRM nunca dan la misma cifra lo explicamos en [atribución rota](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/). - **Marca de tiempo.** Cuándo entró. La velocidad de la primera respuesta es la variable que más pesa en el resultado, y no se puede medir sin esta marca. - **Consentimiento registrado.** Qué aceptó exactamente y cuándo. La normativa española de protección de datos ([LOPDGDD](https://www.boe.es/buscar/act.php?id=BOE-A-2018-16673), consultada en septiembre de 2026) exige poder acreditarlo. No es asesoramiento legal: revisa tu caso con quien lleve vuestro cumplimiento. - **Responsable.** Una persona o un criterio automático de asignación. Un lead sin dueño es un lead sin seguimiento. ## ¿Qué significa tener más leads? Casi nunca lo que parece. Un aumento de leads puede venir de tres sitios muy distintos: - **Más demanda real.** La que interesa. - **Menos filtro.** Se ha quitado un campo del formulario, o se ha ampliado la audiencia de la campaña. Entran más, pero cualifican peor. - **Duplicados.** La misma persona rellena dos formularios y el sistema crea dos registros. La cifra sube y el negocio no. Por eso el número de leads, solo, no es un indicador. El indicador es el par: cuántos entran y qué porcentaje llega a oportunidad. Si el primero sube y el segundo baja en la misma proporción, no ha pasado nada. ## De dónde vienen los leads que se pierden En la práctica, los leads no suelen perderse por falta de interés. Se pierden en el trayecto entre el formulario y la persona que debería llamar: - El formulario envía a una hoja de cálculo que alguien revisa por las mañanas. - La integración se cae un domingo y nadie se entera hasta el miércoles. - El correo y el teléfono llegan sin normalizar, y el mismo cliente aparece tres veces. - El lead entra correctamente, pero sin responsable asignado, y se queda esperando. Ninguno de estos fallos genera un error visible. Simplemente, la cifra del mes es más baja. El recorrido completo, de formulario a comercial y sin un Excel de por medio, está en [leads que se pierden](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). ## Cómo debería definirse "lead" en tu sistema Una definición sirve cuando cabe en una frase y un sistema puede comprobarla. Por ejemplo: *un lead es un contacto con correo válido, origen identificado y consentimiento registrado, que ha solicitado información en los últimos 90 días*. Con una definición así, el CRM puede hacer tres cosas que con la definición de manual no puede hacer: decidir automáticamente qué registros entran, detectar duplicados antes de crearlos y avisar cuando uno lleva demasiado tiempo sin tocarse. Qué es un CRM y qué hace de verdad lo desarrollamos en [esta guía](https://fcgsystems.es/blog/que-es-un-crm/). ## Cómo lo abordamos en FCG Systems La definición de lead es una decisión de negocio; hacerla cumplir es una decisión de sistema. Construimos el recorrido completo (captura, normalización, deduplicación, asignación y aviso) con registros de lo que entra y alertas cuando algo deja de llegar, para que la cifra del CRM signifique siempre lo mismo. Puedes ver cómo trabajamos en [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/) o [contarnos dónde se os están quedando los leads](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Qué quiere decir lead en español? Lead se traduce como contacto interesado o cliente potencial. Es una persona que ha dejado sus datos de forma voluntaria (un formulario, una descarga, una solicitud de presupuesto) y que, por tanto, ha mostrado algún grado de interés. No es lo mismo que una visita anónima ni que un contacto que alguien ha añadido a una lista. ### ¿Qué es un lead en un CRM? Dentro de un CRM, un lead es un registro en un estado concreto del proceso comercial: ha entrado, todavía no está cualificado y aún no tiene una oportunidad asociada. Lo importante no es la palabra, sino qué condiciones hacen que pase al siguiente estado y qué se dispara cuando lo hace. ### ¿Qué son los leads en ventas? En ventas, un lead es el punto de partida del embudo: alguien con quien merece la pena hablar, pero de quien todavía no sabes si tiene necesidad, presupuesto y capacidad de decidir. Cuando eso se comprueba, deja de ser un lead y pasa a ser una oportunidad. ### ¿Qué tipos de leads existen? Los más usados son MQL (lead cualificado por marketing, cumple el perfil y ha mostrado interés) y SQL (lead cualificado por ventas, alguien ha confirmado que hay necesidad real y encaje). También se habla de lead frío, templado o caliente. Estas etiquetas solo sirven si cada una dispara una acción distinta. ### ¿Qué diferencia hay entre un lead y un contacto? Un contacto es cualquier persona cuyos datos tienes. Un lead es un contacto con una señal de interés y un origen conocido, que está dentro de un proceso comercial activo. Tratar toda tu base de datos como leads es la forma más rápida de que las cifras del CRM dejen de significar nada. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Qué es un UTM y cómo montar una nomenclatura de campañas que no se rompe > Qué es un UTM, para qué sirve cada parámetro y cómo fijar una nomenclatura de campañas que no rompa la atribución cuando cada persona escribe lo que quiere. - URL: https://fcgsystems.es/blog/que-es-utm/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Breakdown · Lectura: 7 min - Palabra clave: utm (también: parametros utm, utm que es, nomenclatura utm, que es utm en marketing, utm source medium campaign) Un UTM es un parámetro que se añade al final de una URL para indicar de dónde viene una visita. Los más usados son `utm_source`, `utm_medium` y `utm_campaign`. La analítica los lee cuando se carga la página y agrupa esa visita por canal y por campaña, en lugar de dejarla caer en el cajón de "tráfico directo". Hasta aquí, la definición de manual. Lo que decide si te sirven o no es otra cosa: que todo el mundo los escriba igual. Sin una convención, los UTM no arreglan la atribución; la rompen con más detalle. ## ¿Cómo es una URL con UTM? ``` https://tudominio.com/masterclass/?utm_source=instagram&utm_medium=cpc&utm_campaign=lanzamiento-abril&utm_content=video-testimonio ``` La página que se abre es la misma. Lo que cambia es que el navegador lleva esa información y la analítica puede leerla. Los parámetros van después de `?`, separados por `&`, y deben ir en minúsculas, sin tildes ni espacios. ## ¿Qué significa cada parámetro UTM? | Parámetro | Qué identifica | Ejemplos | ¿Obligatorio? | |---|---|---|---| | `utm_source` | La plataforma o el sitio concreto del que viene la visita | `instagram`, `newsletter`, `youtube` | Sí | | `utm_medium` | El tipo de tráfico | `cpc`, `email`, `social`, `referral`, `affiliate` | Sí | | `utm_campaign` | La acción comercial | `lanzamiento-abril`, `black-friday-2026` | Sí | | `utm_content` | La variante concreta del enlace: creatividad, posición, botón | `video-testimonio`, `cta-footer` | Recomendable | | `utm_term` | La palabra clave, en campañas de búsqueda de pago | `crm-para-agencias` | Solo en SEM | La documentación de referencia es la de Google sobre [URLs de campaña personalizadas](https://support.google.com/analytics/answer/10917952), y su [generador de URLs](https://ga-dev-tools.google/campaign-url-builder/) sirve para salir del paso, aunque más abajo verás por qué un generador propio es mejor idea. Un matiz que confunde a mucha gente: `source` y `medium` responden a preguntas distintas. `source` es **quién** te manda la visita; `medium`, **de qué tipo** es ese tráfico. Un anuncio en Instagram es `instagram` + `cpc`. Una publicación orgánica en Instagram es `instagram` + `social`. Misma fuente, medios distintos, y esa distinción es la que permite separar lo que pagas de lo que no. ## ¿Por qué se rompe la atribución si cada uno pone lo que quiere? Porque la analítica no interpreta: agrupa cadenas de texto exactas. Estas cinco visitas vienen del mismo sitio y producen cinco filas distintas en el informe: - `utm_source=Instagram` - `utm_source=instagram` - `utm_source=ig` - `utm_source=IG_stories` - `utm_source=instagram ` (con un espacio final que nadie ve) Ninguna está "mal" técnicamente. Todas juntas hacen que la pregunta "¿cuánto trae Instagram?" no tenga respuesta. Y el daño no se arregla a posteriori: los datos ya registrados se quedan como se registraron, así que la convención se fija antes de la campaña, no después. Los otros tres modos de romperlo que veo una y otra vez: - **Enlaces sin UTM.** El anuncio los lleva, pero la bio, la descripción del vídeo y el email del martes no. Todo ese tráfico cae en directo, y el canal orgánico parece que no existe. - **Redirecciones y acortadores que se comen los parámetros.** Una redirección de dominio mal montada o un acortador descuidado descartan lo que va después de `?`. La persona llega; su origen, no. Se comprueba en dos minutos haciendo clic en el enlace real y mirando la barra de direcciones. - **UTM en enlaces internos.** Poner UTM en el menú o en un botón interno reinicia la sesión en la analítica y sobrescribe el origen real. El origen se marca al entrar desde fuera, nunca al moverse por dentro. ## Una convención de nombres UTM que puedes copiar Esto es lo que dejo escrito en los proyectos. Un folio, no un manual. ### Reglas de escritura 1. **Todo en minúsculas.** Sin excepciones ni nombres propios. 2. **Sin tildes, sin eñes, sin espacios.** Guiones (`-`) para separar palabras dentro de un valor. 3. **Guion bajo (`_`) para separar bloques** dentro de `utm_campaign`, si necesitas estructura. 4. **Valores de una lista cerrada** en `source` y `medium`. Si hace falta uno nuevo, se añade a la lista y se avisa; no se improvisa en el momento de publicar. 5. **Fecha en la campaña con formato `aaaamm`** cuando la campaña se repita: `lanzamiento_2026-04`. ### Valores permitidos de `utm_medium` | Valor | Cuándo se usa | |---|---| | `cpc` | Tráfico de pago por clic (Meta Ads, Google Ads, TikTok Ads) | | `paid-social` | Pago en redes, si prefieres separarlo de la búsqueda de pago | | `social` | Publicaciones orgánicas en redes | | `email` | Newsletters y secuencias | | `whatsapp` | Difusiones y enlaces enviados por mensajería | | `referral` | Enlaces desde webs de terceros, pódcast, colaboraciones | | `affiliate` | Enlaces de afiliados o partners | | `organic-video` | Descripciones de YouTube, vídeos orgánicos | | `bio` | Enlaces desde biografías de perfiles | Una lista corta y cerrada vale más que una taxonomía perfecta que nadie respeta. ### Estructura de `utm_campaign` ``` __ ``` Ejemplos: `lanzamiento_masterclass-crm_2026-04`, `evergreen_webinar-leads_2026-04`, `remarketing_carrito_2026-04`. Así puedes filtrar por prefijo para comparar todos los lanzamientos entre sí, o todo lo de abril, sin depender de la memoria de nadie. ### Ejemplos completos | Sitio donde se publica | Enlace | |---|---| | Anuncio de Meta | `?utm_source=instagram&utm_medium=cpc&utm_campaign=lanzamiento_masterclass-crm_2026-04&utm_content=video-testimonio` | | Email de la secuencia | `?utm_source=brevo&utm_medium=email&utm_campaign=lanzamiento_masterclass-crm_2026-04&utm_content=email-2-recordatorio` | | Bio de Instagram | `?utm_source=instagram&utm_medium=bio&utm_campaign=evergreen_perfil_2026` | | Descripción de YouTube | `?utm_source=youtube&utm_medium=organic-video&utm_campaign=evergreen_video-crm_2026-04` | ## ¿Cómo se consigue que la convención se cumpla? No con buena voluntad. Con tres piezas: 1. **Un generador de enlaces interno.** Una hoja de cálculo con desplegables o una página pequeña con selectores. Si nadie teclea los valores a mano, nadie los escribe de tres maneras distintas. Es una tarde de trabajo que se amortiza en la primera campaña. 2. **Un registro de enlaces publicados.** Dónde se publicó cada enlace y con qué UTM. Suena burocrático hasta el día en que un informe muestra una fuente rara y nadie sabe de dónde salió. 3. **Una revisión antes de cada lanzamiento.** Un repaso de cinco minutos a los enlaces del anuncio, del email y de la bio, haciendo clic en cada uno. Forma parte del [checklist técnico antes de abrir registros](https://fcgsystems.es/blog/checklist-tecnico-lanzamiento/). ## Los UTM no llegan solos al CRM Este es el punto donde se pierde más dinero y el que casi ningún artículo sobre UTM cubre: los parámetros viven en la URL del navegador. El CRM no los ve a menos que alguien se los envíe. La secuencia que funciona: 1. **Leer los parámetros al llegar a la página** y guardarlos durante la visita (la persona puede navegar dos páginas antes de registrarse). 2. **Enviarlos en campos ocultos del formulario**, junto con el resto de respuestas: fuente, medio, campaña, contenido y página de entrada. 3. **Guardar el primer origen y el último origen** en el CRM, sin sobrescribir el primero. Con esos dos campos ya puedes responder qué canal descubre audiencia y cuál cierra registros. Sin este paso, la analítica sabe que "alguien de Instagram se registró" y el CRM tiene a la persona sin saber de dónde viene. Los dos datos nunca vuelven a juntarse. Es el fallo central que desmonto en [por qué GA4, Meta y tu CRM nunca dan la misma cifra](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/). Dos límites que conviene asumir desde el principio: - **Los UTM solo cubren el tráfico con enlace.** Una conversación de WhatsApp, una llamada o un boca a boca no tienen URL. Para eso existe el resto del sistema de [atribución](https://fcgsystems.es/blog/que-es-la-atribucion/) y, cuando hay varios puntos de contacto, la discusión de los [modelos de atribución](https://fcgsystems.es/blog/modelos-de-atribucion/). - **Los UTM no sustituyen al envío de conversiones a las plataformas.** Son para tus informes; las plataformas de anuncios optimizan con sus propias señales. Si envías eventos por el navegador y por servidor, revisa cómo [usar el píxel y la API de conversiones sin contar cada conversión dos veces](https://fcgsystems.es/blog/pixel-meta-api-conversiones-duplicados/). ## Checklist de UTM - Existe una convención escrita con listas cerradas de `source` y `medium`, y el equipo sabe dónde está. - Todos los valores van en minúsculas, sin tildes ni espacios. - Hay un generador de enlaces; nadie los escribe a mano. - Los enlaces orgánicos (bio, vídeos, emails, pódcast) también los llevan. - Ningún enlace interno de la web lleva UTM. - Has comprobado que ninguna redirección ni acortador elimina los parámetros. - Cada formulario guarda fuente, medio, campaña y página de entrada en campos ocultos. - El CRM conserva el primer origen y el último origen de cada contacto. - Existe un registro de qué enlace se publicó dónde. ## Por dónde empezar Abre el informe de adquisición de los últimos 90 días y ordena por fuente. Cuenta cuántas filas son en realidad el mismo canal escrito de formas distintas, y cuánto tráfico hay en "directo". Esas dos cifras son la medida exacta de lo que te está costando no tener convención. En FCG Systems esto entra en [datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): convención, captura del origen en el formulario y atribución hasta el CRM. Si tus informes por canal no te sirven para repartir presupuesto, [cuéntame cómo está montado ahora](https://fcgsystems.es/contacto/) y te digo dónde miraría primero. ## Preguntas frecuentes ### ¿Qué es un UTM? Un UTM es un parámetro que se añade al final de una URL para indicar de dónde viene una visita. Los más usados son utm_source, utm_medium y utm_campaign. La analítica los lee al cargar la página y así puede agrupar el tráfico por canal y por campaña en lugar de dejarlo como tráfico directo. ### ¿Para qué sirve cada parámetro UTM? utm_source identifica la plataforma o el sitio concreto (instagram, newsletter, un medio). utm_medium identifica el tipo de tráfico (cpc, email, social, referral). utm_campaign identifica la acción comercial (lanzamiento-abril). utm_content distingue creatividades o variantes del mismo enlace, y utm_term se usa para la palabra clave en campañas de búsqueda de pago. ### ¿Los UTM distinguen mayúsculas y minúsculas? Sí. Para la analítica, Instagram e instagram son dos fuentes distintas y aparecerán como dos filas separadas en el informe. Por eso la primera regla de cualquier convención es escribir siempre en minúsculas, sin tildes ni espacios, usando guiones para separar palabras. ### ¿Los UTM afectan al SEO o generan contenido duplicado? Los parámetros crean URLs distintas para la misma página, así que no conviene usarlos en enlaces internos de la web ni en enlaces que se vayan a indexar. Para enlaces externos es la práctica habitual: se usan en anuncios, emails y publicaciones, no en la navegación interna del sitio. ### ¿Dónde se guardan los UTM para que lleguen al CRM? En campos ocultos del formulario. Se leen los parámetros de la URL al llegar a la página, se conservan mientras la persona navega y se envían junto con el resto de respuestas. Así el origen viaja con el registro hasta el CRM y no depende de que la analítica haya podido medir esa sesión. ## Servicios relacionados - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Casos relacionados - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/): Formularios, tracking, CRM y agenda comercial conectados en un solo sistema, con el origen de cada lead a la vista. Las tres etapas del funnel mejoraron. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Revisar código generado por IA: qué mirar antes de que toque dinero, datos o accesos > Cómo revisar el código que genera la IA antes de publicarlo: permisos, secretos, dependencias, validación y registro, ordenado por las categorías de OWASP 2025. - URL: https://fcgsystems.es/blog/revisar-codigo-generado-por-ia/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Software · Formato: Breakdown · Lectura: 9 min - Palabra clave: revisar código generado por ia (también: seguridad código ia, owasp, owasp top 10 2025, auditar app hecha con ia, code review ia, vibe coding seguridad) Antes de que un código generado por IA toque dinero, datos personales o accesos, hay que revisar siete cosas: **quién puede hacer qué, dónde están los secretos, qué dependencias entran, qué se valida, qué se registra, qué pasa cuando algo falla y quién responde después**. No es una auditoría completa: es el mínimo para no publicar un agujero. La IA escribe código inseguro igual de rápido que código correcto. Tu trabajo no es teclear menos; es juzgar mejor. Esta pieza cierra el bloque que empieza en [qué es el vibe coding](https://fcgsystems.es/blog/que-es-vibe-coding/) y sigue en [de prototipo con IA a producción](https://fcgsystems.es/blog/de-prototipo-ia-a-produccion/). Aquí va lo concreto: qué abrir, qué buscar y en qué orden. ## ¿Por qué el código generado necesita otro tipo de revisión? Porque falla en un sitio distinto al que estamos acostumbrados a vigilar. Un modelo casi nunca comete errores de sintaxis. Lo que produce compila, arranca y hace lo que le pediste. Donde falla es en las **decisiones que no le pediste explícitamente**: si esa consulta debería filtrar por usuario, si ese endpoint debería estar protegido, si ese valor debería venir del cliente o calcularse en el servidor, si esa librería es la correcta o una con nombre parecido. Hay un detalle que lo agrava: el modelo escribe con el mismo tono de seguridad en los dos casos. No hay una señal en el código que diga "esto lo he improvisado". Y el prompt tampoco ayuda, porque nadie escribe "hazme un panel de administración, y por cierto, que un usuario no pueda ver los pedidos de otro". Se da por supuesto. El modelo no supone. Por eso la revisión no es leer línea a línea buscando fallos. Es ir a los sitios donde se toman decisiones de confianza y comprobar cada una. ## ¿Qué es OWASP y por qué usarlo de guion? [OWASP](https://owasp.org/www-project-top-ten/) es una fundación sin ánimo de lucro dedicada a la seguridad del software, y su **Top 10** es la lista de referencia de las categorías de riesgo más críticas en aplicaciones web. Es pública, gratuita y está mantenida por la comunidad. La edición vigente es el [OWASP Top 10:2025](https://top10.owasp.org/2025) (consultada en septiembre de 2026), con estas categorías: | Código | Categoría | |---|---| | A01:2025 | Broken Access Control (control de acceso roto) | | A02:2025 | Security Misconfiguration (configuración de seguridad incorrecta) | | A03:2025 | Software Supply Chain Failures (fallos en la cadena de suministro) | | A04:2025 | Cryptographic Failures (fallos criptográficos) | | A05:2025 | Injection (inyección) | | A06:2025 | Insecure Design (diseño inseguro) | | A07:2025 | Authentication Failures (fallos de autenticación) | | A08:2025 | Software or Data Integrity Failures (fallos de integridad) | | A09:2025 | Security Logging and Alerting Failures (fallos de registro y alerta) | | A10:2025 | Mishandling of Exceptional Conditions (mal manejo de condiciones excepcionales) | Uso esta lista como guion de revisión por una razón práctica: está ordenada por lo que de verdad aparece en aplicaciones reales, no por lo que suena más grave. Y resulta que las tres primeras son exactamente donde una app generada con IA suele estar más floja. No hace falta cubrir las diez para una revisión de prototipo. Sí las que siguen. ## 1. Control de acceso: ¿quién puede hacer qué? (A01) El primero de la lista, [A01:2025 Broken Access Control](https://top10.owasp.org/2025/A01_2025-Broken_Access_Control/), y el que más veces encuentro mal. **Qué comprobar:** - **¿Dónde se decide el permiso?** Si la única comprobación es que el botón no se pinta, no hay permiso. Busca cada ruta de la API y comprueba que valida la sesión y el rol antes de hacer nada. - **Cambiar el identificador.** Coge una URL con un id (`/pedidos/1042`) y prueba con el id de otro usuario desde una cuenta distinta. Si devuelve datos, tienes un agujero de manual. - **Consultas sin filtro de propietario.** Busca en el código las consultas a tablas con datos de clientes y comprueba que todas filtran por el usuario o la organización de la sesión. - **Reglas a nivel de base de datos.** Si la base de datos se consulta desde el navegador, las políticas de fila son obligatorias. La [documentación de Supabase](https://supabase.com/docs/guides/database/postgres/row-level-security) lo dice literalmente: *"una tabla en un esquema expuesto sin RLS es legible y escribible por cualquier rol que tenga permiso sobre ella"* (consultado en septiembre de 2026). - **Rutas administrativas.** Los paneles de administración generados suelen quedar accesibles por URL directa. Pruébalo desde una sesión normal y desde ninguna sesión. **La prueba que lo resume todo:** crea dos cuentas de usuario distintas con datos distintos, e intenta con cada una llegar a los datos de la otra. Por URL, por API, por lo que sea. Si lo consigues, no se publica. ## 2. Secretos y configuración (A02) [A02:2025 Security Misconfiguration](https://top10.owasp.org/2025/A02_2025-Security_Misconfiguration/). Barato de revisar, caro de ignorar. - **Claves en el navegador.** Abre las herramientas de desarrollo, busca en el código que se descarga cadenas como `sk_`, `api_key`, `secret`, `token`. Una clave de servicio ahí es una brecha, no un descuido. - **Variables de entorno.** En muchos frameworks, cualquier variable con cierto prefijo acaba en el bundle del cliente. Comprueba cuáles llevan ese prefijo y por qué. - **Modo depuración apagado** en producción, y mensajes de error que no devuelvan trazas internas ni consultas SQL al usuario. - **CORS** que no permita cualquier origen. - **Cabeceras de seguridad** básicas puestas. - **Endpoints de prueba** y datos de ejemplo eliminados. Las apps generadas dejan usuarios de demo con contraseñas obvias con una frecuencia sorprendente. ## 3. Dependencias: qué ha metido el modelo en tu proyecto (A03) [A03:2025 Software Supply Chain Failures](https://top10.owasp.org/2025/A03_2025-Software_Supply_Chain_Failures/) subió mucho en esta edición, y con la generación automática tiene todo el sentido. - **Revisa el fichero de dependencias entero.** Cada paquete que hay ahí es código de un tercero ejecutándose en tu producto. - **Comprueba que cada paquete existe y es el que crees.** Los modelos a veces citan nombres plausibles pero equivocados, y ese hueco lo aprovecha quien registra ese nombre con contenido malicioso. - **Vulnerabilidades conocidas**: pasa una auditoría de dependencias y trata lo crítico antes de publicar. - **Versiones fijadas** con su fichero de bloqueo, para que un despliegue no traiga una versión distinta de la que probaste. - **Paquetes abandonados**: si la última publicación es de hace años y toca autenticación o pagos, cámbialo. ## 4. Validación de entradas (A05) [A05:2025 Injection](https://top10.owasp.org/2025/A05_2025-Injection/). El código generado suele usar consultas parametrizadas por defecto, que es buena noticia, pero hay que confirmarlo. - **Consultas SQL construidas concatenando texto**: busca cualquier sitio donde una variable se pegue dentro de una consulta. - **Validación en el servidor**, no solo en el formulario. Todo lo que llega del cliente es sospechoso, incluidos los campos ocultos. - **Contenido de usuario que se pinta en HTML** sin escapar. - **Ficheros subidos**: tipo comprobado de verdad, tamaño limitado, y guardados fuera de la raíz pública. - **Si hay una IA dentro del producto** que recibe texto del usuario y luego actúa (llama a herramientas, consulta la base de datos), esa entrada es una superficie de ataque más, no menos. ## 5. Lógica de negocio: el punto ciego (A06) [A06:2025 Insecure Design](https://top10.owasp.org/2025/A06_2025-Insecure_Design/) es la categoría que ningún escáner automático va a encontrarte, porque no es un patrón de código: es una regla de tu negocio que falta. Preguntas que hago siempre: - ¿El **precio** se calcula en el servidor o llega desde el navegador? - ¿Se puede pedir una **cantidad negativa**, o cero, o un número absurdo? - ¿Un usuario del **plan básico** puede llamar directamente al endpoint de la función premium? - ¿Se puede **aplicar el mismo descuento** diez veces? - ¿Qué pasa si alguien **pulsa dos veces** el botón de comprar? ¿Y si el webhook llega duplicado? - ¿Se puede llegar al **estado final** de un flujo saltándose un paso intermedio? - ¿Qué pasa si el **pago falla a mitad** del proceso: queda el usuario creado sin acceso, con acceso sin pagar, o nada? Estas preguntas no salen de una lista genérica: salen de conocer el negocio. Por eso la revisión no se puede delegar entera a una herramienta. ## 6. Registro y alertas (A09) [A09:2025 Security Logging and Alerting Failures](https://top10.owasp.org/2025/A09_2025-Security_Logging_and_Alerting_Failures/). - ¿Queda **registro** de los inicios de sesión, los cambios de permisos, los pagos y las altas y bajas de acceso? - ¿Los logs guardan **datos sensibles** que no deberían (contraseñas, tarjetas, tokens)? Eso también es un fallo. - ¿Hay **alerta** cuando algo crítico falla, y llega a un sitio que alguien mira? - ¿Se pueden **reconstruir los hechos** de un incidente de hace una semana con lo que hay guardado? ## 7. Qué pasa cuando algo falla (A10) [A10:2025 Mishandling of Exceptional Conditions](https://top10.owasp.org/2025/A10_2025-Mishandling_of_Exceptional_Conditions/) es nueva en esta edición y encaja como un guante con el código generado, que casi siempre implementa el camino feliz y poco más. - ¿Qué pasa si el **servicio de terceros no responde**? ¿Se reintenta? ¿Se reintenta infinitamente? - ¿Un **fallo a mitad** de una operación deja datos a medias (usuario creado, pago no registrado)? - ¿Los errores se **capturan y se tragan en silencio**? Un `catch` vacío es un incidente futuro. - ¿El mensaje de error que ve el usuario le dice algo útil sin contarle cómo está montada la aplicación por dentro? ## ¿Y los escáneres integrados en las propias herramientas? Úsalos. Son útiles y ahorran la primera pasada. Lovable, por ejemplo, incluye un escaneo básico con revisión de políticas RLS, del esquema de base de datos y de dependencias, y uno más profundo con revisión de control de acceso, protección de endpoints y vulnerabilidades a nivel de código. Y en la misma página deja claro el límite: *"estas herramientas ayudan a identificar problemas de seguridad comunes, pero no pueden garantizar una seguridad completa"*, no sustituyen *"una revisión de seguridad exhaustiva"*, y *"eres responsable de asegurar que tu app cumple los requisitos de seguridad apropiados para su caso de uso"* ([documentación de seguridad de Lovable](https://docs.lovable.dev/features/security), consultada en septiembre de 2026). Eso es exactamente lo que hay: un escáner cubre lo que se puede detectar por patrón. Los puntos 5, 6 y 7 de esta lista —lógica de negocio, registro útil y comportamiento ante fallos— siguen siendo humanos. ## Cómo pedir esta revisión si no la vas a hacer tú Si eres responsable de un proyecto y no vas a abrir el código, tu palanca es exigir evidencia. No "¿está seguro?", que siempre se responde que sí, sino: 1. "Enseñadme la prueba de que el usuario A no puede ver los datos del usuario B." Una captura de la petición y la respuesta denegada. 2. "Enseñadme el resultado de la auditoría de dependencias." 3. "¿Dónde está la comprobación de permisos de este endpoint?" Señalando la línea. 4. "¿Qué pasa si el webhook de pago llega dos veces?" La respuesta correcta menciona idempotencia. 5. "¿A qué canal llega la alerta si esto falla un domingo?" Cinco preguntas. Si las respuestas son vagas, el proyecto no está listo, independientemente de lo bien que se vea la interfaz. ## Qué hacer con lo que encuentres Ordenado por lo que arreglaría primero: 1. **Bloqueante**: cualquier acceso a datos de otro usuario, cualquier secreto expuesto, cualquier importe calculado en el cliente. No se publica hasta que esté. 2. **Antes de usuarios reales**: validación en servidor, webhooks idempotentes, límites de peticiones, copias de seguridad. 3. **Primeras semanas**: logs y alertas completos, dependencias al día, manejo de errores. 4. **Continuo**: un plan de mantenimiento con responsable, porque las dependencias envejecen solas y las vulnerabilidades se publican después de que lanzaste. Si al revisar aparece que los permisos hay que rehacerlos enteros y la lógica de negocio vive repartida por la interfaz, ya no estás revisando: estás reconstruyendo. Ese camino, por piezas y sin parar la operación, está en [de prototipo con IA a producción](https://fcgsystems.es/blog/de-prototipo-ia-a-produccion/) y, cuando lo que hay debajo es un stack no-code, en [de no-code a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/). ## ¿Quieres una revisión de lo que habéis construido? Si tenéis una app generada con IA y os la vais a jugar con ella delante de usuarios de un cliente, esta revisión es el paso barato antes del paso caro. La hago sobre lo que ya existe: os digo qué es bloqueante, qué se aprovecha y qué hay que reconstruir, con prioridades y sin adornos. También en **white label**, para que la agencia siga siendo la cara ante su cliente. [Cuéntame qué habéis construido y con qué](https://fcgsystems.es/contacto/). Si después toca levantar la versión sólida, eso es [software a medida](https://fcgsystems.es/servicios/software-a-medida/); si lo que buscáis es tener criterio técnico detrás de forma continuada, es [partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/). ## Preguntas frecuentes ### ¿Por qué hay que revisar el código que genera una IA? Porque genera con la misma soltura una solución correcta y una insegura, y no distingue entre ambas: no conoce tu modelo de negocio ni quién debería poder ver qué. La revisión no busca errores de sintaxis, que no suele cometer, sino decisiones equivocadas sobre permisos, datos y confianza. ### ¿Qué es OWASP y por qué se usa como referencia? OWASP es una fundación sin ánimo de lucro dedicada a la seguridad del software. Su Top 10 es la lista de las categorías de riesgo más críticas en aplicaciones web, mantenida públicamente en owasp.org, y funciona bien como guion de revisión porque ordena por frecuencia real, no por sensación. ### ¿Los escáneres automáticos de Lovable o Bolt no bastan? Ayudan y conviene usarlos, pero su propia documentación advierte de que no garantizan seguridad completa ni sustituyen una revisión exhaustiva. Un escáner encuentra patrones conocidos; no sabe que en tu producto un usuario del plan básico no debería poder descargar el informe completo. ### ¿Cuánto tiempo lleva revisar una app generada con IA? Una primera pasada sobre los siete puntos críticos de este artículo suele llevar entre medio día y dos días en una aplicación pequeña. Arreglar lo que aparece lleva más, y depende sobre todo de si los permisos hay que rehacerlos enteros o solo completarlos. ### ¿Hace falta ser desarrollador para hacer esta revisión? Para ejecutar las comprobaciones, sí hace falta criterio técnico. Para exigirlas, no: un responsable de proyecto puede pedir evidencia de cada punto de la lista y no aceptar un lanzamiento sin ella. Saber qué preguntar ya cambia el resultado. ## Servicios relacionados - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/): Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. - [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/): Servidores, despliegues, backups y alertas para que tu operación no se caiga y sea tuya. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Si todo depende de una persona no tienes un sistema, tienes un rehén > Un negocio donde todo pasa por una cabeza no es un negocio ágil, es un negocio secuestrado. Cómo saber si el rehén eres tú y por dónde se empieza a soltar. - URL: https://fcgsystems.es/blog/cuando-el-sistema-eres-tu/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Opinión · Lectura: 4 min - Palabra clave: negocio que depende de una persona (también: cuello de botella del fundador, bus factor negocio digital, delegar tareas técnicas) Hay una frase que suena muy bien en las reuniones y que casi siempre significa lo contrario de lo que parece: "esto lo llevo yo directamente". La dices porque eres rápido. Porque conoces el negocio mejor que nadie. Porque explicarlo tarda más que hacerlo. Y todo eso es verdad. El problema es que cuando lo repites doscientas veces, lo que has construido no es un negocio ágil. Es un negocio con un rehén dentro. Y normalmente el rehén eres tú. ## La dependencia no se nota, se disfruta Al principio esto se vive bien. Control total. Cero fricción. Nadie hace las cosas a medias porque las haces tú. Si algo se rompe lo arreglas en diez minutos, y esos diez minutos te confirman que el sistema funciona. No funciona. Lo que funciona eres tú. La diferencia se ve el día que no estás. Un lanzamiento con un webhook caído y la única persona que sabe dónde mirar está en un avión. Un cliente que pide su factura y el único acceso a la plataforma de pagos está en una cuenta personal. Un comercial que no sabe a quién asignar un lead porque la regla real no está escrita en ningún sitio, está en la cabeza del fundador. Ninguna de esas cosas es un fallo técnico. Son la misma cosa: conocimiento que vive en una persona en vez de vivir en el sistema. ## Por qué contratar a alguien no lo arregla Esta es la parte que más gente se salta, y la entiendo porque yo también pensaba que era un tema de manos. Cuando el negocio te ahoga, el reflejo es contratar. Un técnico, un asistente, una agencia. Y durante tres semanas parece que funciona. Después vuelve la misma sensación, solo que ahora con un coste fijo más alto. El motivo es simple. Si el criterio no está escrito, la persona nueva tiene que preguntártelo todo. Has convertido "hacer la tarea" en "explicar la tarea, revisarla y corregirla", que suele costar más tiempo que hacerla. Cambiaste una dependencia por dos. Contratar funciona cuando hay algo que dirigir. Si no lo hay, lo que estás haciendo no es delegar: es repartir tu cuello de botella. Sobre cuándo conviene un equipo externo en vez de una contratación lo desarrollo en [capacidad técnica sin montar un departamento](https://fcgsystems.es/blog/dependencia-de-una-persona-capacidad-tecnica/). ## El rehén tiene varias caras No siempre eres tú. A veces el rehén es el negocio y el carcelero es alguien que ni siquiera lo sabe. - **El freelance de confianza.** Montó las automatizaciones hace tres años, lo hizo bien, y hoy es el único que entiende qué hace cada escenario. No es su culpa. Nadie le pidió que escribiera nada. - **La persona de operaciones que se acuerda de todo.** El sistema real de la empresa es su memoria. El día que se va, se lleva la mitad del negocio en la cabeza sin querer. - **La herramienta que solo una persona sabe tocar.** Un CRM configurado a medida, un dashboard con fórmulas encadenadas, un servidor al que solo hay una clave. En los tres casos la pregunta es la misma y da un poco de miedo formularla en alto: si esta persona desaparece mañana, ¿cuánto tardamos en volver a operar con normalidad? Si la respuesta se mide en semanas, no tienes una dependencia, tienes un riesgo operativo sin cubrir. ## Soltar al rehén es un trabajo aburrido No hay un truco elegante para esto. Hay tres movimientos y ninguno es emocionante. **Escribir el criterio, no la tarea.** La documentación que sirve no es "haz clic aquí y luego allá". Es "cuando pasa X, se decide Y, porque Z". Los clics cambian cada seis meses. El porqué no. Si pones el porqué junto al cómo, otra persona puede tomar la decisión sin llamarte. **Sacar las llaves de las cuentas personales.** Credenciales, dominios, pasarelas de pago, acceso al servidor. Todo en cuentas de la empresa, con un sitio donde estén y alguien que sepa cuál es ese sitio. Es media tarde de trabajo y elimina la clase de problema que solo aparece en el peor momento posible. **Que los avisos vayan a un sistema, no a una persona.** Mientras el detector de incidencias sea tu intuición, no puedes desconectar nunca. Un proceso crítico que falla tiene que generar una alerta sin depender de que alguien lo note. Es poco vistoso, sí. Pero entender es tener el control, y aquí "entender" significa que el negocio entienda cómo funciona el negocio, no solo tú. ## La prueba honesta Hay un test que no falla y que casi nadie quiere hacer: desaparece una semana de verdad. Sin mirar el móvil, sin el "por si acaso", sin el grupo de WhatsApp abierto. Lo que se rompa esa semana es tu lista de tareas real. No lo que tú crees que es prioritario. No lo que dice el roadmap. Lo que se rompió. Y si te da pánico solo pensarlo, ya no hace falta que hagas la prueba. La respuesta ya la tienes. Un negocio que depende de una persona puede facturar mucho y aun así no valer nada el día que quieras venderlo, escalarlo o simplemente descansar. Eso no se arregla con más esfuerzo tuyo. Se arregla poniendo por escrito lo que hoy solo existe dentro de tu cabeza. ## Preguntas frecuentes ### ¿Cómo sé si mi negocio depende demasiado de mí? Mira tus dos últimas semanas de vacaciones o de baja. Si no las has tenido, ya lo sabes. Si las tuviste y volviste a una montaña de cosas paradas que solo tú podías desatascar, tampoco es un tema de organización: es que las decisiones importantes no tienen otro sitio donde ocurrir que tu cabeza. ### ¿Contratar a alguien resuelve la dependencia? Solo si además escribes cómo se toman las decisiones. Si contratas sin documentar, cambias un cuello de botella por dos: el suyo y el tuyo revisándole. La dependencia no se resuelve añadiendo personas, se resuelve sacando el criterio de las cabezas y poniéndolo en procesos, reglas y sistemas que cualquiera pueda seguir. ### ¿Qué documento hay que escribir primero? El mapa de lo crítico: qué procesos mueven dinero o accesos, qué herramienta manda en cada uno, dónde están las credenciales y quién responde si falla un domingo. Cabe en dos folios y es lo único que se va a leer de verdad cuando haya un problema. ## Servicios relacionados - [Partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/): Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Tipos de CRM: operativo, analítico, colaborativo y el cuarto que casi nadie menciona > Qué tipos de CRM existen, qué resuelve cada uno, en qué se quedan cortos y cuándo un negocio digital necesita un CRM a medida en vez de otro SaaS. - URL: https://fcgsystems.es/blog/tipos-de-crm/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Breakdown · Lectura: 6 min - Palabra clave: tipos de crm (también: clasificacion de crm, crm operativo, crm analitico, crm colaborativo, tipos de crm ejemplos) **Los tipos de CRM que se distinguen habitualmente son tres: operativo, analítico y colaborativo.** El operativo automatiza el trabajo comercial del día a día, el analítico explota los datos para decidir y el colaborativo reparte la información del cliente entre equipos. Hay un cuarto caso que las clasificaciones suelen omitir: el CRM a medida, cuando ninguno de los tres encaja sin parches. La clasificación es útil solo si sirve para decidir. Aquí está ordenada por lo que cambia en la práctica: qué resuelve cada tipo, en qué se queda corto y qué señales indican que necesitas otra cosa. Si todavía no tienes claro [qué hace exactamente un CRM y qué problema resuelve](https://fcgsystems.es/blog/que-es-un-crm/), ese es el paso previo. ## ¿Qué tipos de CRM existen y qué resuelve cada uno? | Tipo | Qué resuelve | Señal de que lo necesitas | Dónde se queda corto | |---|---|---|---| | Operativo | Captura, deduplicación, asignación, etapas, tareas y mensajes automáticos | Los leads entran por varios canales y nadie sabe quién atiende cada uno | Da poca respuesta al "por qué": registra el proceso, no lo explica | | Analítico | Conversión por etapa, canal y comercial; valor de cliente; previsión | Hay que decidir dónde invertir en captación y nadie tiene la cifra | Depende de que el dato de origen sea limpio desde el primer registro | | Colaborativo | Historial compartido entre marketing, ventas, soporte y socios externos | Un cliente cuenta lo mismo tres veces a tres personas distintas | Necesita permisos y disciplina de uso, no solo la herramienta | | A medida | Reglas propias de asignación, permisos y datos que ningún estándar cubre | El SaaS ya solo funciona a base de parches y exportaciones | Hay que construirlo y mantenerlo: exige responsable | Ninguna herramienta real es "solo operativa" o "solo analítica". La clasificación no sirve para etiquetar productos, sino para saber qué le vas a exigir al que contrates. ## CRM operativo: el que quita trabajo manual Es el punto de entrada natural. Su trabajo es que un lead no dependa de que alguien se acuerde de él. Lo que debe hacer bien: - Recoger contactos de formularios, anuncios, mensajería y pagos, con su origen. - Detectar duplicados antes de asignar, por reglas propias y no solo por email. - Asignar un responsable único, con criterio explícito y no por turno manual. - Mover oportunidades por etapas con condiciones de entrada claras. - Disparar tareas, recordatorios y mensajes sin intervención. **Dónde se rompe:** cuando la automatización se monta encima de datos sucios. Un CRM operativo con duplicados asigna el mismo contacto dos veces y dos comerciales llaman a la misma persona. Ese tramo, del formulario al comercial, está desmenuzado en [leads que se pierden](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). ## CRM analítico: el que responde "¿y esto funciona?" Es la capa que convierte el registro en decisión: conversión por etapa, por canal y por comercial, tiempo medio de cierre, valor de un cliente a lo largo de su vida, previsión de ingresos. Lo que debe hacer bien: - Conservar el origen de cada contacto sin sobrescribirlo en el segundo toque. - Distinguir entre fecha de entrada, fecha de primer contacto y fecha de cierre. - Permitir segmentar por cohortes, no solo mirar el total del mes. - Exportar o conectarse a la herramienta donde vive el resto del dato. **Dónde se rompe:** en el dato de origen. Si el registro llega sin campaña, o el CRM guarda como origen el último clic en vez del primero, el informe será impecable y equivocado. Por qué GA4, la plataforma de anuncios y el CRM nunca dan la misma cifra está en [atribución rota](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/). Un aviso de criterio: no hace falta un CRM analítico cuando se cierran seis ventas al mes. Con ese volumen, cualquier porcentaje es ruido. Primero volumen y dato limpio; después, análisis. ## CRM colaborativo: el que evita que el cliente lo cuente tres veces Su objetivo es que la información del cliente esté disponible para todo el que la necesita: marketing, comerciales, soporte, administración y, a veces, socios o distribuidores externos. Lo que debe hacer bien: - Historial unificado de conversaciones, sea cual sea el canal por el que entraron. - Permisos por rol, para que cada persona vea lo que le corresponde. - Registro de quién cambió qué y cuándo. - Notas y estados visibles sin tener que preguntar por privado. **Dónde se rompe:** en el canal que se queda fuera. En muchos negocios digitales la conversación real ocurre en WhatsApp, desde el móvil de cada comercial, y ahí el CRM nunca tendrá el historial completo. Qué implica meter ese canal dentro del sistema está en [WhatsApp Business API](https://fcgsystems.es/blog/whatsapp-business-api/). ## El cuarto tipo: el CRM a medida Las clasificaciones se quedan en tres porque las tres describen productos que se compran. El cuarto describe una decisión: dejar de adaptar el negocio a una herramienta y construir la pieza que os diferencia. Señales de que el CRM estándar se ha quedado corto: - La lógica de asignación real no cabe en las reglas del producto y vive en automatizaciones externas que nadie documenta. - Hay campos personalizados usados para tres cosas distintas porque no quedaban más. - Los informes que importan se montan exportando a una hoja cada semana. - El coste de licencias crece por usuarios o contactos por encima del valor que aporta. - Necesitáis una interfaz específica para un rol concreto y la del producto obliga a ocho clics. No es un salto de todo o nada. Lo habitual es híbrido: SaaS para lo estándar, software propio para lo que diferencia y automatizaciones con registro conectando ambas partes. Las señales concretas y cómo migrar por piezas están en [de no-code a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/), y la comparación económica entre SaaS y desarrollo propio, en [CRM para pymes: SaaS o a medida](https://fcgsystems.es/blog/crm-para-pymes-saas-o-a-medida/). ## ¿Y qué pasa con el ERP? Es la confusión más repetida al hablar de tipos de CRM: pensar que el CRM analítico "ya hace lo del ERP". No. El CRM trabaja con la relación comercial; el ERP, con los recursos internos y el dinero ya comprometido. Qué cubre cada uno y cómo conectarlos sin duplicar clientes está en [diferencia entre CRM y ERP](https://fcgsystems.es/blog/diferencia-crm-erp/). ## ¿Qué tipo de CRM necesita tu negocio? Una forma sencilla de situarse: - **Vendéis con equipo comercial y entran leads de varios canales** → prioridad operativa. Exige deduplicación, asignación y etapas antes que cualquier panel. - **Invertís en captación de pago y hay que decidir dónde poner el presupuesto** → prioridad analítica. Exige origen conservado y cohortes. - **Varias personas o departamentos tocan al mismo cliente** → prioridad colaborativa. Exige permisos e historial unificado. - **Vuestro proceso comercial es lo que os diferencia y ya vivís de parches** → valorad a medida, empezando por la pieza que más duele. Si encajáis en más de una, el orden sensato es operativo primero, analítico después. Sin proceso ordenado, el análisis mide el desorden. ## Errores comunes al elegir tipo de CRM - **Comprar la capa analítica antes de tener el proceso ordenado.** Informes precisos sobre datos sucios. - **Confundir "muchos informes" con CRM analítico.** Lo que importa es qué decisiones cambian con ellos. - **Dejar un canal de conversación fuera del sistema.** El historial incompleto vale menos que ninguno, porque genera falsa confianza. - **Usar campos personalizados como parche permanente.** Es la señal más clara de que la herramienta no encaja. - **Elegir por la lista de funciones.** La mitad no se usará; la que falta es la integración que necesitabais. - **Saltar a un CRM a medida sin haber diseñado el proceso.** El desorden se muda de herramienta y cuesta más. ## Checklist para decidir - Está escrito cuál de los tres tipos es vuestra prioridad real, y por qué. - El origen del lead se captura en el primer registro y no se sobrescribe. - Hay reglas de deduplicación y un único responsable por contacto. - Los canales donde ocurre la conversación real entran en el sistema. - Los permisos por rol están definidos antes de importar datos. - Sabemos qué informes van a cambiar una decisión concreta. - El coste está calculado con el volumen y el equipo de dentro de dos o tres años. - Si la opción es a medida, hay responsable de mantenimiento con nombre. ## ¿Cuándo conviene delegarlo? Con un equipo pequeño y un proceso comercial sencillo, esta clasificación y dos semanas de pruebas bastan para elegir. Cuando el CRM tiene que conectarse con formularios, pagos, accesos y mensajería, cuando hay reglas de asignación entre setters y closers, o cuando la duda real es contratar o construir, la decisión es de arquitectura y no de producto. Eso se aborda con un [Systems Audit dentro de arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/); si la conclusión es construir, con [software a medida](https://fcgsystems.es/servicios/software-a-medida/), y las integraciones con [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/). Si tenéis CRM y aun así nadie sabe cuántos leads hay abiertos, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Cuáles son los tipos de CRM que existen? La clasificación clásica son tres: operativo, que automatiza el trabajo diario de marketing, ventas y soporte; analítico, que explota los datos para entender qué funciona; y colaborativo, que comparte la información del cliente entre departamentos o con socios externos. A esos tres conviene añadir un cuarto caso: el CRM a medida, cuando el proceso comercial es tan propio que ningún producto estándar lo cubre sin parches. ### ¿Qué es un CRM operativo? Es el que soporta el día a día comercial: captura leads, los deduplica, los asigna a un responsable, mueve las oportunidades por etapas y dispara tareas o mensajes automáticos. Es el tipo por el que casi todo el mundo empieza, porque es el que quita trabajo manual desde la primera semana. ### ¿Qué es un CRM analítico y cuándo hace falta? Es el que convierte los datos comerciales en decisiones: conversión por etapa, por canal y por comercial, tiempo medio de cierre o valor de cliente. Hace falta cuando ya hay volumen suficiente para que los promedios signifiquen algo y cuando las decisiones de inversión en captación dependen de esos números. Sin datos limpios de origen, un CRM analítico produce informes bonitos y falsos. ### ¿Los tipos de CRM son productos distintos? No necesariamente. La mayoría de CRM del mercado cubren algo de los tres, con distinto grado de profundidad, y la clasificación sirve más para saber qué le vas a exigir que para elegir marca. Lo útil es decidir cuál de los tres es tu prioridad real y comprobar que el candidato es fuerte justo ahí. ### ¿Cuándo compensa un CRM a medida frente a uno estándar? Cuando el proceso comercial es la forma de operar del negocio y el SaaS obliga a vivir de campos personalizados, automatizaciones parche y exportaciones manuales. Para procesos estándar, un SaaS bien configurado sigue siendo la mejor opción. Lo habitual es un modelo híbrido: SaaS para lo común y software propio para la pieza que diferencia. ## Servicios relacionados - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Transcripción de audio a texto con IA: cómo automatizarla para llamadas, reuniones y contenido > Cómo pasar audio a texto con IA y automatizarlo de verdad: llamadas de ventas al CRM, actas y contenido, con criterios de precisión, idioma y coste. - URL: https://fcgsystems.es/blog/transcripcion-audio-texto-ia/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: IA aplicada · Formato: Arquitectura · Lectura: 8 min - Palabra clave: transcripción audio a texto (también: transcripcion audios a texto, transcripcion de audio a texto, transcribir llamadas ia, pasar audio a texto, actas de reuniones con ia) Transcribir audio a texto con IA consiste en enviar una grabación a un modelo de reconocimiento de voz que devuelve el texto, normalmente con marcas de tiempo y, en algunos servicios, con separación por interlocutor. La parte resuelta es esa. La parte que decide si te sirve o no es qué ocurre con ese texto después. Hay cientos de herramientas para arrastrar un fichero y copiar el resultado. Este artículo no va de eso. Va de para qué usa un negocio la transcripción (llamadas de ventas que alimentan el CRM, actas de reuniones, contenido) y de cómo se monta con criterio: precisión, idioma, privacidad y coste. ## ¿Para qué sirve de verdad la transcripción en un negocio? Tres usos que se pagan solos y uno que suele decepcionar. ### 1. Llamadas de ventas que llegan al CRM El comercial cuelga y el CRM sigue vacío. La ficha se rellena horas después, de memoria, o no se rellena. Con la llamada transcrita y procesada, la ficha se actualiza sola con lo que se dijo: objeciones, presupuesto mencionado, próximo paso y fecha de seguimiento. El valor no está en tener el texto: está en que deja de depender de la memoria y de las ganas de alguien a las siete de la tarde. Es el mismo problema que cuento en [leads que se pierden entre el formulario y el comercial](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/), un paso más adelante en el circuito. ### 2. Actas de reuniones que alguien usa Una reunión de una hora produce cuatro decisiones y seis tareas. Lo demás es contexto. Una transcripción en bruto de 9.000 palabras no la lee nadie; lo útil es el paso siguiente: decisiones, responsables y fechas, con enlace al minuto exacto de la grabación por si hay discusión. ### 3. Contenido a partir de lo que ya dices Formaciones, pódcast, sesiones de soporte. El material existe en audio y se queda ahí. Transcrito, se convierte en materia prima para artículos, respuestas de la base de conocimiento o preguntas frecuentes reales, con las palabras que usan tus clientes y no las que tú crees que usan. ### 4. El que decepciona: "analizar todas las llamadas con IA" Transcribir mil llamadas y pedirle a un modelo que te diga "qué está pasando" produce párrafos correctos e inútiles. Sin una pregunta concreta y una lista cerrada de cosas que buscas, el resultado no cambia ninguna decisión. Si vas a hacerlo, define primero qué campos quieres extraer y qué harás cuando aparezcan. ## Los cuatro criterios que deciden si funciona ### Precisión: depende del audio, no del modelo La diferencia entre una transcripción utilizable y una basura casi nunca está en el modelo. Está en el audio: - **Audio telefónico comprimido** pierde frecuencias y sube los errores frente a una grabación de micrófono. - **Dos personas hablando a la vez** rompen la separación por interlocutor, que es justo lo que necesitas en una llamada de ventas. - **Ruido de fondo y sala con eco** degradan más que un acento marcado. - **Vocabulario propio** (nombres de producto, planes, siglas internas) es donde más fallos verás, y donde más molestan. La forma seria de decidir: coge veinte audios reales tuyos, de los peores que tengas, transcríbelos con dos o tres opciones y cuenta los errores **que te importan**. Un fallo en una muletilla da igual; un fallo en el importe de un presupuesto, no. Ese es tu criterio de calidad, no la tasa de error que anuncie nadie. ### Idioma y variante Comprueba el español de España con las variantes de tus clientes, no con un audio de demostración. Y si recibes llamadas en varios idiomas, mira si el servicio detecta el idioma automáticamente o si hay que decírselo, porque un flujo que asume español y recibe catalán o inglés no falla: devuelve algo peor que un fallo, devuelve un texto plausible y equivocado. Los servicios grandes publican sus idiomas soportados, como hace Google en su [lista de idiomas de Speech-to-Text](https://cloud.google.com/speech-to-text/docs/speech-to-text-supported-languages) (consultado en septiembre de 2026). ### Privacidad: es la parte que menos se mira y más duele Una llamada con un cliente contiene datos personales y, a veces, datos de salud, económicos o de terceros. Antes de montar nada: - **Informa antes de grabar**, con un aviso claro al inicio de la llamada, y ten una base jurídica válida para hacerlo. Las guías de referencia están en la [Agencia Española de Protección de Datos](https://www.aepd.es/). - **Mira dónde se procesa el audio** y qué hace el proveedor con él. Si ofrece la opción de no usar tus datos para entrenar, actívala y guarda la evidencia. - **Define cuánto tiempo conservas** audio y transcripción, y bórralo cuando toque. Un bucket con tres años de llamadas es un problema esperando fecha. - **Limita quién accede.** La transcripción de una llamada no debería ser visible para todo el equipo por defecto. Si el contenido es especialmente sensible, existe la opción de ejecutar un modelo abierto en tu propia infraestructura. Cuesta más operarlo y hay que saber lo que se hace, pero el audio no sale de tu servidor. Es la misma decisión de fondo que planteo en [n8n: Cloud o self-hosted](https://fcgsystems.es/blog/n8n-precios-cloud-self-hosted/): no es una cuestión de precio, es una cuestión de qué estás dispuesto a operar. ### Coste: mira el segundo paso, no el primero La transcripción se cobra normalmente por minuto de audio y, salvo volúmenes altos, es la parte barata. Lo que se dispara es lo de después: si a cada llamada de 40 minutos le pasas la transcripción entera a un modelo de lenguaje para resumirla, estás pagando texto largo una y otra vez. Consulta siempre los precios en la página oficial del proveedor antes de calcular, y haz el cálculo con tus minutos reales al mes, no con un ejemplo. Tres decisiones que bajan el coste sin perder nada: 1. **No transcribir todo.** Las llamadas de menos de un minuto o los audios sin voz no aportan nada. 2. **Resumir sobre un texto ya recortado**, no sobre la transcripción completa. 3. **Guardar el resultado** para no reprocesar lo mismo cuando alguien vuelva a abrir la ficha. ## Cómo se monta: la arquitectura mínima Seis piezas. Se puede montar con un flujo de automatización tipo n8n o Make, o con código propio si el volumen lo pide. 1. **Disparador.** Se acaba una llamada en la centralita, se sube una grabación a una carpeta, termina una videollamada. Aquí es donde se decide qué entra y qué no. 2. **Almacenamiento del audio** con un identificador que apunte al contacto del CRM. Sin ese identificador, tendrás transcripciones huérfanas que no sirven para nada. 3. **Transcripción** enviando el fichero al servicio elegido, pidiendo marcas de tiempo y separación por interlocutor si la llamada es a dos. Los servicios publican sus formatos y límites; la referencia de OpenAI está en su [guía de speech to text](https://platform.openai.com/docs/guides/speech-to-text) (consultado en septiembre de 2026). 4. **Extracción estructurada**, que es el paso que aporta el valor: del texto a campos concretos. No pidas "un resumen": pide una lista cerrada de campos (próximo paso, fecha, objeción principal, producto de interés) con valores permitidos. 5. **Escritura en el destino:** CRM, base de datos o gestor de tareas, marcando de forma visible que ese campo lo ha rellenado un proceso automático y no una persona. 6. **Registro y alertas.** Cada ejecución deja rastro: audio de entrada, coste, duración, resultado. Sin esto tendrás una automatización que falla en silencio, el patrón que desmonto en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ### La regla que evita el 80 % de los sustos **Lo determinista, en código; lo interpretativo, en el modelo.** El modelo transcribe y extrae. Clasificar si un lead está cualificado, mover una oportunidad de etapa o disparar un cobro son decisiones con reglas: van en código, con umbrales escritos, leyendo los campos que el modelo ha extraído. Un modelo que decide la etapa del CRM te la cambiará un martes sin que nadie sepa por qué. Lo mismo aplica al control de calidad: guarda siempre la transcripción literal junto al resumen. La transcripción es la prueba; el resumen es una interpretación que alguien tiene que poder contrastar. ## ¿Herramienta suelta o montarlo en tu sistema? | Situación | Qué haría | |---|---| | Transcribes cuatro reuniones al mes y las lees tú | Herramienta suelta. Montar un flujo no compensa | | Quieres actas con decisiones y tareas en el gestor del equipo | Herramienta con integración nativa, si la tuya la tiene | | Cada llamada de ventas debe actualizar el CRM | Flujo propio: el valor está en la escritura en el CRM, no en el texto | | Procesas cientos de audios al mes con reglas propias | Flujo propio con control de coste, reintentos y registro | | El contenido es especialmente sensible | Modelo en tu infraestructura, asumiendo el coste de operarlo | La pregunta útil no es cuánta transcripción necesitas. Es qué proceso quieres que ocurra **solo** después de cada llamada. Si no hay ninguno, no montes nada. ## Errores habituales - **Empezar por la herramienta** en vez de por el proceso que quieres automatizar. - **No informar de la grabación** y descubrirlo cuando llega una reclamación. - **Guardar solo el resumen.** El día que alguien discuta lo que se dijo, no tendrás la prueba. - **Dejar que el modelo decida etapas o precios.** Eso es lógica de negocio, no interpretación. - **No medir la calidad.** Sin una muestra revisada a mano de vez en cuando, no sabes si el proceso se degradó hace tres semanas. - **Transcribirlo todo por defecto.** Coste que sube y ruido que tapa lo que importa. Este enfoque (una tarea concreta, criterio de éxito medible, límites claros) es el mismo que aplico a cualquier pieza de IA dentro de un proceso, y que desarrollo en [IA aplicada a negocios digitales](https://fcgsystems.es/blog/ia-aplicada-negocios-digitales/) y en [agentes de IA para negocios](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/). Si además estás pensando en que la IA hable por teléfono, y no solo que escuche, el terreno cambia bastante: lo cuento en [agente de voz con IA](https://fcgsystems.es/blog/agente-de-voz-ia/). ## Por dónde empezar Coge las diez últimas llamadas de ventas y mira qué campos del CRM quedaron sin rellenar. Esos campos son tu especificación. Transcribe esas diez llamadas a mano con la herramienta que sea y comprueba si el texto contiene la respuesta. Si la contiene, tienes un caso de automatización claro. Si no, el problema estaba en otro sitio. En FCG Systems esto entra en [inteligencia artificial aplicada](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/) y, cuando hay que conectar centralita, CRM y avisos, en [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/). Si tu equipo comercial rellena fichas de memoria, [cuéntame cómo es vuestro circuito de llamadas](https://fcgsystems.es/contacto/) y te digo qué automatizaría primero. ## Preguntas frecuentes ### ¿Cómo se pasa un audio a texto con IA? Se envía el fichero de audio a un modelo de reconocimiento de voz, que devuelve el texto y, según el servicio, marcas de tiempo y separación por interlocutor. Se puede hacer a mano subiendo el archivo a una herramienta, o de forma automática: la grabación llega a un almacenamiento, un flujo la envía al modelo y el resultado se guarda donde vaya a usarse. ### ¿Cuál es la precisión real de la transcripción automática? Depende sobre todo de la calidad del audio, no del modelo. Con micrófono decente y una persona hablando, el resultado suele ser muy bueno. Con audio telefónico comprimido, ruido de fondo, dos personas solapándose o vocabulario propio del sector, los errores suben. La forma seria de decidir es transcribir veinte audios reales tuyos y contar los fallos que te importan. ### ¿Es legal grabar y transcribir llamadas con clientes? Grabar conversaciones con clientes implica tratar datos personales, así que hay que informar con claridad antes de grabar, tener una base jurídica válida, limitar quién accede y definir cuánto tiempo se conserva. La Agencia Española de Protección de Datos publica las guías de referencia. Si el proveedor de transcripción está fuera de la UE, hay que mirar además dónde se procesa el audio. ### ¿Qué diferencia hay entre transcribir y resumir una llamada? La transcripción convierte el audio en texto literal; el resumen o la extracción convierte ese texto en campos útiles: objeciones, presupuesto, próximo paso, fecha de seguimiento. Son dos pasos distintos y conviene guardarlos por separado, porque la transcripción es la prueba y el resumen es una interpretación revisable. ### ¿Merece la pena montar la transcripción o uso una herramienta suelta? Una herramienta suelta vale mientras el volumen sea bajo y el resultado lo lea una persona. Montarlo dentro del sistema compensa cuando la transcripción alimenta otra cosa: el CRM, un panel, un aviso al comercial. La pregunta no es cuánta transcripción necesitas, sino qué proceso quieres que ocurra solo después de cada llamada. ## Servicios relacionados - [Sistemas de IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Tu stack no está roto por usar no-code, está roto por no saber dónde vive la verdad > Defensa honesta del no-code y de su límite real. El problema casi nunca es la herramienta: es que el mismo dato vive en cuatro sitios y ninguno manda. - URL: https://fcgsystems.es/blog/no-code-fuente-de-verdad/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Automatización · Formato: Opinión · Lectura: 4 min - Palabra clave: fuente de verdad no-code (también: límites del no-code, cuándo dejar el no-code, datos duplicados entre herramientas) Cada pocos meses aparece el mismo debate y siempre se plantea mal: no-code sí o no-code no, como si fuera una cuestión de bando. He visto negocios facturando de verdad sobre herramientas visuales, funcionando bien y sin drama. Y he visto desarrollos a medida, con su repositorio y su equipo, tan enredados que nadie se atrevía a tocarlos. La herramienta no era la variable. La variable es otra, y es bastante más aburrida: saber dónde vive el dato bueno. ## El problema real se llama "cuatro copias del mismo cliente" Coge un negocio digital cualquiera que lleve dos años creciendo. Es muy probable que un cliente suyo exista, a la vez, en cuatro sitios. Está en la plataforma de pagos, porque ahí es donde cobra. Está en la herramienta de email, porque ahí recibe las secuencias. Está en el CRM, porque ahí lo trabaja el comercial. Y está en una hoja de cálculo, porque alguien necesitaba un informe y esa fue la forma rápida de sacarlo. Cuatro copias. Ninguna manda. Cuando ese cliente cambia de email, actualiza una. Cuando pide la baja, se da de baja en otra. Cuando el equipo necesita saber si sigue activo, cada persona mira su sitio favorito y todas responden distinto. Eso no lo ha causado el no-code. Lo causa que nadie decidió, el primer día, cuál de esos sistemas tiene la última palabra sobre cada dato. ## Por qué el no-code se lleva la culpa Se la lleva porque hace visible el desorden más rápido. Cuando conectas herramientas visuales, cada decisión que no tomaste se convierte en un escenario nuevo. Un flujo que sincroniza el CRM con el email. Otro que arregla lo que el primero rompió. Otro que corrige los duplicados que crearon los dos anteriores. Al año tienes cuarenta automatizaciones y ninguna persona capaz de dibujar el mapa entero en una pizarra. Con código pasa exactamente lo mismo, solo que más despacio y con menos testigos. La diferencia es que en el no-code el caos se ve en una pantalla con cajitas y flechas, y eso da munición al que ya quería venderte otra cosa. Buahh, y aquí es donde se cuela el argumento fácil: "es que el no-code no escala". No. Lo que no escala es la lógica de negocio repartida entre veinte sitios sin documentar. Escríbela en Python y tampoco escalará. ## La pregunta que ordena todo el stack Hay una pregunta que resuelve más discusiones de arquitectura que cualquier comparativa de herramientas, y es esta: **Para cada dato importante, ¿qué sistema tiene razón cuando dos se contradicen?** Hazla sobre los cinco o seis datos que de verdad mueven tu negocio: quién es cliente, qué compró, si está pagando, a qué tiene acceso, en qué punto del funnel está, quién lo está atendiendo. Si para cada uno puedes señalar un sistema sin dudar, tu stack está bien montado aunque esté hecho con cinco herramientas de arrastrar y soltar. Si dudas en alguno, ahí tienes tu próximo problema y probablemente ya esté costando dinero. Lo bonito de esta pregunta es que no la responde un técnico. La responde el negocio. Es una decisión de criterio, no de sintaxis. ## Dónde está el límite de verdad El no-code tiene un techo, claro que lo tiene. Pero no está donde suelen decir. No lo alcanzas por volumen. Lo alcanzas cuando la lógica que necesitas ya no cabe en el modelo mental de la herramienta. Reglas con muchas condiciones encadenadas, procesos que deben ser transaccionales, cálculos que tienen que dar el mismo resultado siempre, permisos finos, auditoría de quién cambió qué. Y hay una frontera que para mí no se negocia: los accesos, los cobros y los precios los decide código determinista, no una cadena de nodos que nadie ha probado bajo carga, y desde luego no un modelo de IA. Eso tiene que ser aburrido, repetible y verificable. El otro síntoma de techo es económico y se detecta en el mantenimiento, no en la factura de la suscripción. Si cada cambio pequeño obliga a tocar cinco flujos y a cruzar los dedos, ya estás pagando el coste de un desarrollo a medida sin tener sus ventajas. Cuándo tiene sentido dar ese salto lo desarrollo en [de no-code a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/). ## Lo que haría yo antes de migrar nada Cuando alguien me dice "esto hay que rehacerlo en condiciones", casi siempre propongo el mismo orden. Primero, el mapa. Un folio con los datos críticos y, al lado de cada uno, el sistema que manda. Media hora de trabajo que suele generar dos o tres discusiones incómodas y necesarias. Segundo, la limpieza. Quitar las automatizaciones que existen solo para arreglar lo que rompe otra. Suelen ser más de las que nadie recuerda. Tercero, y solo entonces, decidir qué se construye a medida. Casi nunca es todo. Suele ser una pieza: el sitio donde vive la verdad, con lo demás sincronizándose contra ella. Migrar sin hacer los dos primeros pasos es mudarse de casa con las cajas sin etiquetar. El desorden viaja contigo y encima ahora es más caro. ## El punto Construir sin entender es fracaso con buena pinta, y da igual si lo construyes arrastrando cajas o escribiendo código. La pregunta buena nunca fue "¿no-code o desarrollo?". Fue "¿sabes dónde vive cada dato y quién manda cuando hay conflicto?". Responde eso y la elección de herramienta se vuelve casi irrelevante. No lo respondas y ninguna herramienta te va a salvar. ## Preguntas frecuentes ### ¿Qué es una fuente de verdad en un stack de herramientas? Es el sistema que tiene la última palabra sobre un dato concreto. Si el email de un cliente aparece en el CRM, en la plataforma de email y en la de pagos, uno de los tres tiene que mandar y los otros dos deben copiarlo de ahí. Sin esa regla escrita, cada herramienta cree que la versión buena es la suya y nadie puede decidir quién tiene razón. ### ¿El no-code aguanta un negocio serio? Aguanta bastante más de lo que dicen quienes venden desarrollo a medida. Un negocio con miles de contactos puede funcionar años sobre herramientas visuales si la arquitectura está bien pensada. Lo que no aguanta es lógica de negocio repartida en veinte automatizaciones que nadie ha documentado. ### ¿Cuándo hay que migrar a software propio? Cuando el coste de mantener la solución no-code supera al de construir la tuya, o cuando la herramienta te impide hacer algo que el negocio necesita. Normalmente se nota antes en el mantenimiento que en el precio: cada cambio pequeño obliga a tocar cinco sitios y a rezar. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Vendí un infoproducto en el que dejé de creer, y eso decide lo que construyo hoy > Me fui del primer infoproducto que vendí porque no cumplía lo que prometía. Lo que aquello me enseñó sobre construir sistemas que se pueden defender. - URL: https://fcgsystems.es/blog/vendi-un-infoproducto-en-el-que-deje-de-creer/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Sistemas · Formato: Opinión · Lectura: 4 min - Palabra clave: criterio sobre humo infoproductos (también: ética en infoproductos, tecnología de un negocio digital, defender lo que construyes) El primer infoproducto que vendí lo vendía bien. Ese fue exactamente el problema. No entré a aquello con mala intención. Entré convencido. Me creí el argumentario porque quien me lo dio se lo creía, o lo aparentaba tan bien que daba igual. Y durante un tiempo hice lo que hace todo el mundo en esa posición: repetir. Repetir el gancho, repetir la promesa, repetir las frases que funcionan porque funcionan. Lo que se rompió no fue una discusión ni una bronca. Fue una acumulación. Empecé a mirar por dentro, que es un vicio que tengo desde crío, cuando abría ordenadores no para que arrancaran, sino para saber por qué arrancaban. Y por dentro la cosa no daba lo que decía por fuera. Había una distancia entre lo que la gente compraba y lo que la gente recibía. Una distancia que no se cerraba currando más. Me fui. Sin épica, sin carta abierta, sin nombres. Me fui y ya está. ## La incomodidad concreta: repetir algo que ya no sostienes La parte que más me costó no fue irme. Fue el tiempo anterior, el de seguir vendiendo mientras la duda ya estaba dentro. Porque vender algo así no se siente como mentir. Se siente como estar un poco incómodo y no saber por qué. Y esa incomodidad tiene una forma muy reconocible: es no querer que un cliente te pregunte cosas. Cuando vendes algo que se sostiene, una pregunta difícil te gusta, porque es una oportunidad de demostrar que sabes. Cuando vendes humo, cada pregunta es una amenaza, y desarrollas reflejos para esquivarla: cambiar de tema, devolverla, envolverla en una frase motivadora. Ese es el mejor detector que conozco, y me lo llevé de allí. **Si te incomoda que te pregunten cómo funciona lo que vendes, ya sabes la respuesta.** Sirve para infoproductos y sirve exactamente igual para software, para agencias y para cualquiera que facture con algo que el cliente no puede auditar. ## Qué me enseñó sobre el humo: el método, no las personas Voy a ser preciso con esto, porque es importante. El problema de aquello no era que hubiera gente mala. Era un método. El método consiste en vender un resultado y entregar una esperanza. Se construye el producto empezando por el argumento de venta, no por el problema del comprador. Cuando haces eso, el producto es siempre una consecuencia del marketing, y cualquier cosa que no se pueda contar bien en una landing se deja fuera, aunque sea justo lo que el cliente necesitaba. Ese método también produce una cosa muy concreta: gente que se queda enganchada al siguiente. El que compra el sueño y se queda con la deuda no concluye que el sueño era falso. Concluye que le faltaba pieza, y compra otra. Yo fui esa persona antes de ser la que vendía, así que no lo digo desde la superioridad. Y no va de personas ni de marcas con nombre. Hay infoproductos excelentes, y hoy trabajo con gente que factura de verdad y entrega de verdad; en ese sector aprendí la mitad de lo que sé. Lo que hay que atacar es el método. ## Cómo cambió lo que construyo Salir de ahí me dejó tres reglas que siguen decidiendo casi todo lo que hago. **Solo construyo lo que entiendo.** No lo que sé configurar: lo que entiendo por dentro. Si acepto un proyecto con una pieza que no comprendo, estoy repitiendo el patrón de antes, solo que en técnico: vendiendo una superficie que no puedo sostener si alguien la abre. Construir sin entender es fracaso con buena pinta. **Todo lo que entrego tiene que poder defenderse delante de quien lo paga.** No delante de un compañero técnico, que se conforma con "usa la última versión de X". Delante del que firma. Eso significa poder explicar en cristiano por qué cada decisión es esa y no otra, y qué pasa cuando falle. Es una vara de medir incómoda y es la que evita el 90% del humo. **Las decisiones que importan no se delegan a algo que estadísticamente acierta.** Quién entra en tu producto, cuánto se le cobra y qué precio ve lo decide código determinista, no un modelo que la mayoría de las veces da en el clavo. Suena a manía técnica y no lo es: es la misma regla de antes en otra capa. Si no puedes explicar por qué un cliente entró o dejó de entrar, no controlas tu negocio, lo estás administrando de oídas. Y una consecuencia práctica de las tres: digo que no bastante. A proyectos donde lo que se pide es que algo *parezca* que funciona para un lanzamiento, y a clientes cuyo problema real es que su oferta no se sostiene. Un sistema impecable no arregla eso. Solo hace que se rompa más tarde y con más gente dentro. ## El criterio que te llevas Esto no es una historia de redención. Es una historia sobre lo que hace una persona cuando descubre la distancia entre lo que se promete y lo que se entrega. Puedes cerrar esa distancia por los dos lados: bajando la promesa o subiendo lo que entregas. Lo único que no puedes hacer, si vas a durar, es quedarte en medio fingiendo que no existe. Yo elegí subir lo que entrego, y por eso miro las cosas por dentro antes de hablar de ellas. Sigue siendo lo mismo que hacía con los ordenadores de crío. Solo ha cambiado la caja: ahora es la operativa de un negocio. ## Servicios relacionados - [Partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/): Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Verifactu: qué cambia en tu facturación y qué tiene que hacer tu software (no tu asesor) > Qué es Verifactu, qué exige el reglamento a tu software de facturación, qué plazos marca el BOE y qué tienes que tocar en tus sistemas antes de 2027. - URL: https://fcgsystems.es/blog/verifactu-que-es/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Automatización · Formato: Breakdown · Lectura: 9 min - Palabra clave: verifactu que es (también: que es verifactu, verifactu obligatorio, verifactu entrada en vigor, reglamento sistemas informáticos de facturación, registro de facturación de alta) Verifactu es la modalidad de funcionamiento de un sistema informático de facturación que remite a la Agencia Tributaria, de forma automática y continuada, un registro de cada factura en el momento de emitirla. No es un programa que tengas que instalar ni un trámite: es una exigencia sobre cómo debe comportarse el software con el que facturas. Y ahí está el malentendido más caro. Verifactu se comenta como si fuera un asunto de asesoría, y la parte que le toca a tu asesor es pequeña: decirte si te aplica y desde cuándo. El trabajo de verdad está en tus sistemas. En qué programa emite las facturas, en si ese programa cumple, y en qué pasa con las facturas que hoy genera tu CRM, tu pasarela de pago o un flujo de n8n que alguien montó hace dos años. Este artículo cubre la parte técnica: qué exige la norma al software, qué plazos hay en el BOE a septiembre de 2026 y qué tienes que revisar en tu operativa. **No es asesoramiento fiscal.** En FCG Systems no lo damos: integramos sistemas. Para saber si te aplica, a partir de cuándo y con qué consecuencias, habla con tu asesor. ## De dónde sale Verifactu De dos normas, y conviene tenerlas identificadas porque casi todo lo que se lee por ahí las mezcla: - El **[Real Decreto 1007/2023, de 5 de diciembre](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840)**, que aprueba el Reglamento de requisitos de los sistemas informáticos de facturación (el RRSIF). Es la norma que dice qué tiene que hacer el software. - La **[Orden HAC/1177/2024, de 17 de octubre](https://www.boe.es/diario_boe/txt.php?id=BOE-A-2024-22138)**, que desarrolla las especificaciones técnicas, funcionales y de contenido: formatos de los registros, código QR, la mención "VERI*FACTU" en la factura. Ambas están enlazadas desde el portal de la AEAT dedicado a [sistemas informáticos de facturación y Verifactu](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu.html) (consultado en septiembre de 2026), que es la fuente que conviene revisar antes de tomar cualquier decisión: es donde se publican las notas informativas cuando algo cambia. ## Fechas: qué dice el BOE a septiembre de 2026 Esta es la parte donde más información desactualizada circula, porque los plazos se han movido dos veces. Las fechas vigentes las fijó el **[Real Decreto-ley 15/2025, de 2 de diciembre](https://www.boe.es/buscar/doc.php?id=BOE-A-2025-24446)**, que modificó el Real Decreto 1007/2023 y amplió un año los plazos anteriores. La Agencia Tributaria las recoge en su [nota informativa sobre la ampliación del plazo de adaptación](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/nota-informativa-ampliacion-plazo-adaptacion-facturacion.html) (consultado en septiembre de 2026): | Quién | Fecha límite para tener los sistemas adaptados | |---|---| | Contribuyentes del Impuesto sobre Sociedades | Antes del **1 de enero de 2027** | | Resto de obligados tributarios | Antes del **1 de julio de 2027** | Hay una tercera fecha que casi nunca se menciona y que es la que te afecta como comprador de software: los **productores y comercializadores** de sistemas de facturación debían ofrecer productos adaptados en un plazo máximo de nueve meses desde la entrada en vigor de la Orden HAC/1177/2024, según la disposición final del Real Decreto 1007/2023. Es decir, desde el verano de 2025. Traducido: si tu proveedor todavía no tiene una versión que cumpla, eso ya es una señal. Dicho lo anterior, y para que no me lo cites como verdad eterna: esta normativa se ha aplazado dos veces. Antes de planificar nada con fechas al límite, comprueba el portal de la AEAT. ## Qué tiene que hacer tu software para cumplir Aquí está lo que de verdad importa si tienes sistemas propios o integrados. El Reglamento no pide "usar Verifactu": pide que el sistema con el que facturas se comporte de una forma concreta. ### 1. Generar un registro de facturación por cada factura Cada vez que se emite una factura, el sistema tiene que generar automáticamente un **registro de facturación de alta** con un formato y una estructura estandarizados: identificación del obligado, número y fecha de la factura, descripción de la operación, importes, desglose de IVA, identificación del sistema informático y marca temporal precisa. Cuando una factura se emite por error, se genera un **registro de facturación de anulación** que referencia a la original. Ojo con esto: no se borra nada. El registro de alta sigue existiendo y se le añade uno de anulación. ### 2. Encadenar los registros con una huella Cada registro incluye la huella (*hash*) del registro anterior, formando una cadena. Si alguien altera un registro intermedio, la cadena deja de cuadrar. Es el mismo principio que usa cualquier log que quiere ser verificable: la inmutabilidad no se consigue prohibiendo editar, se consigue haciendo que editar sea detectable. ### 3. Firmar electrónicamente… o remitir a la AEAT Aquí aparecen las dos modalidades: | Modalidad | Cómo funciona | Qué exige | |---|---|---| | **VERI\*FACTU** | El sistema remite cada registro a la AEAT de forma continuada y automática | Se presume conforme por diseño; queda exento de la firma electrónica de cada registro | | **No VERI\*FACTU** | Los registros se quedan en tus sistemas | Firma electrónica de cada registro, conservación y puesta a disposición de la AEAT cuando la requiera | La segunda opción suena más cómoda porque no hay que enviar nada. En la práctica te obliga a sostener tú la conservación, la firma y la capacidad de entregar todo eso íntegro si te lo piden. Es más trabajo, no menos. ### 4. Registrar los eventos del propio sistema El sistema tiene que anotar automáticamente sus propios eventos: accesos, copias de seguridad, intentos de modificación, exportaciones. Un log de auditoría, en vocabulario de ingeniería. Esta es la exigencia que más software casero suspende, porque un script que genera PDFs no registra nada de esto. ### 5. Incluir el QR y la mención en la factura La factura emitida debe llevar un código QR con información parcial de la factura y, cuando el sistema remite los registros, la mención "VERI*FACTU" o la frase equivalente sobre su verificabilidad en la sede electrónica de la AEAT. Los detalles de composición están en el artículo 20 de la Orden HAC/1177/2024. ### 6. Tener una declaración responsable El Reglamento exige que el sistema esté acompañado de una **declaración responsable** del productor que certifique por escrito que cumple los requisitos. No es un sello ni una certificación de un tercero: es una declaración del fabricante. Esto tiene una consecuencia directa para ti: **la pregunta que hay que hacerle a cada proveedor es "¿me das la declaración responsable?"**. Si la respuesta es vaga, tienes la respuesta. ## Qué significa esto para un negocio digital La conversación útil no es "¿me aplica Verifactu?". Es "¿desde qué sistemas salen hoy mis facturas?". Y en un negocio digital con varios productos, esa lista casi siempre es más larga de lo que el dueño cree: - La pasarela de pago, que envía recibos que parecen facturas y no lo son. - La plataforma de cursos o de membresía, que emite sus propios documentos. - El CRM o el ERP, para las ventas que se cierran a mano o por transferencia. - Un flujo de automatización que genera un PDF y lo manda por email. - Una hoja de cálculo con una plantilla, para los casos raros. Cada una de esas vías es un sistema informático de facturación potencial. Y cada una tiene que estar o bien dentro de un software que cumpla, o bien fuera del circuito de facturación fiscal. El patrón que funciona es el mismo que aplico con cualquier dato crítico: **una sola fuente de verdad**. Un único sistema emite la factura fiscal; el resto le pasan los datos y consumen el resultado. Si dos sistemas emiten facturas con numeraciones distintas, el problema no es Verifactu, es que ya tenías un descontrol y la norma lo va a hacer visible. Un detalle que conviene mirar de cerca: una factura anulada o rectificada ya no se puede "arreglar" editando el registro. Si tu operativa incluye corregir facturas a mano cuando alguien detecta un error, esa costumbre deja de ser viable y hay que sustituirla por rectificativas que el sistema genere solo. Es justo el tipo de proceso manual que, cuando se automatiza mal, [falla en silencio durante meses](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/) sin que nadie lo note. ## Las dudas técnicas que aparecen siempre **¿Y si mi software es a medida?** Entonces el obligado a la declaración responsable eres tú, como productor de tu propio sistema, y tienes que implementar los registros, el encadenamiento, la firma o el envío, el log de eventos y el QR. Es asumible, pero es un proyecto con fecha, no un parche. Si tu operación está en ese punto en el que el no-code ya no llega y el software propio todavía asusta, el artículo sobre [cuándo pasar de no-code a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/) plantea el mismo dilema con otro ejemplo. **¿Y si facturo con una herramienta internacional?** Muchas herramientas de pagos o de suscripciones generan documentos perfectamente útiles para el cliente que no son facturas conformes al Reglamento español. La salida habitual es conectar esa herramienta con un software de facturación que sí cumpla: los datos del cobro viajan, la factura fiscal la emite quien tiene la declaración responsable. Comprueba lo que declara cada proveedor, no lo que parece. **¿Puedo seguir emitiendo con mi ERP actual?** Depende de si su fabricante ha publicado una versión adaptada. Pregunta por la versión concreta, la fecha y la declaración responsable. **¿Y las sanciones?** El artículo 201 bis de la [Ley 58/2003, General Tributaria](https://www.boe.es/buscar/act.php?id=BOE-A-2003-23186) tipifica las infracciones por tener sistemas que no cumplan las especificaciones exigidas, tanto para quien los usa como para quien los fabrica o comercializa. El importe concreto que te aplicaría en tu caso es, de nuevo, una pregunta para tu asesor fiscal. ## Qué hacer ahora, en orden 1. **Inventaria los emisores.** Lista todos los sistemas desde los que hoy sale una factura. Todos, incluidos los que nadie recuerda. 2. **Pregunta a cada proveedor por la declaración responsable** y por la versión en la que su producto cumple. 3. **Decide la fuente de verdad.** Un solo sistema emite la factura fiscal. 4. **Mapea las integraciones que faltan.** Qué tiene que llegar a ese sistema desde la pasarela, el CRM o la plataforma, y con qué identificador de cliente. Cómo se monta esa tubería, con reintentos y control de duplicados, está en [integrar la facturación electrónica con el resto de tus sistemas](https://fcgsystems.es/blog/facturacion-electronica-integracion/). 5. **Decide modalidad con tu asesor.** Verifactu o conservación con firma. La decisión es fiscal; las consecuencias, técnicas. 6. **Prueba con datos reales antes de la fecha límite.** La AEAT habilita un periodo previo de pruebas. Un cierre de mes completo en pruebas vale más que cualquier demo. 7. **Confirma las fechas en la sede de la AEAT.** Han cambiado dos veces. ## Dónde acaba tu asesor y empieza tu sistema Tu asesor te dice si estás obligado, desde cuándo, qué modalidad conviene y qué riesgo asumes. Todo eso es su terreno y ahí no me meto. Lo que no te va a resolver es que tu CRM, tu pasarela y tu plataforma de cursos hablen con el software de facturación sin que nadie copie datos a mano. Eso es integración, y es donde suele estar el trabajo real: conectar los cobros con las altas, las altas con las facturas y las facturas con la contabilidad, con identificadores estables y con trazas de qué hizo el sistema y cuándo. Es el tipo de proyecto que llevamos como [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/), y cuando ninguna herramienta del mercado encaja, como [software a medida](https://fcgsystems.es/servicios/software-a-medida/). Si no tienes claro desde cuántos sitios salen hoy tus facturas, [cuéntame cómo está montada tu operativa](https://fcgsystems.es/contacto/) y lo revisamos. ## Preguntas frecuentes ### ¿Qué es Verifactu exactamente? Verifactu es la modalidad de funcionamiento de un sistema informático de facturación que envía a la Agencia Tributaria, de forma continuada y automática, el registro de cada factura en cuanto se emite. Es una de las dos formas de cumplir el Reglamento aprobado por el Real Decreto 1007/2023; la otra es conservar esos registros firmados electrónicamente en tus propios sistemas. ### ¿Cuándo es obligatorio Verifactu? Según la nota informativa de la Agencia Tributaria tras el Real Decreto-ley 15/2025, de 2 de diciembre, los contribuyentes del Impuesto sobre Sociedades deben tener sus sistemas adaptados antes del 1 de enero de 2027 y el resto de obligados tributarios antes del 1 de julio de 2027. Son las fechas vigentes a septiembre de 2026; la normativa ya se ha aplazado dos veces, así que conviene comprobarlas en la sede de la AEAT. ### ¿Verifactu es lo mismo que la factura electrónica obligatoria? No. Verifactu regula cómo tiene que comportarse el software que emite facturas: registro inmutable, huella encadenada y envío a la AEAT. La factura electrónica obligatoria entre empresas viene de la Ley 18/2022 y del Real Decreto 238/2026, y regula en qué formato estructurado se intercambian las facturas entre emisor y destinatario. Son dos obligaciones distintas que conviven. ### ¿Tengo que usar Verifactu si mis facturas las emite Stripe, mi CRM o mi plataforma de cursos? Cualquier programa que emita tus facturas entra en el ámbito del Reglamento, sea una herramienta internacional, un CRM o un desarrollo propio. Lo que hay que comprobar es si ese proveedor ofrece una declaración responsable de que su sistema cumple el Reglamento para España. Si no la ofrece, la factura fiscal tendrá que emitirla otro sistema que sí cumpla. ### ¿Quién queda fuera de Verifactu? El propio Reglamento excluye los supuestos del artículo 3 y adapta su aplicación a los regímenes forales de País Vasco y Navarra, que tienen sus propios sistemas. Como esto depende de tu situación fiscal concreta, es una pregunta para tu asesor fiscal, no para tu proveedor de software. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Sistemas para negocios digitales: qué son, qué capas tienen y cuándo los necesitas > Qué es un sistema para negocios digitales, qué capas tiene (automatización, software, IA, infraestructura y datos) y cómo saber si tu operación ya lo necesita. - URL: https://fcgsystems.es/blog/sistemas-para-negocios-digitales/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 (15 de septiembre de 2026) - Tema: Sistemas · Formato: Arquitectura · Lectura: 11 min - Palabra clave: sistemas para negocios digitales (también: sistemas para infoproductores, sistemas para academias online, infraestructura tecnológica para negocios digitales, automatización para negocios digitales) Un **sistema para negocios digitales** es el conjunto de automatizaciones, software, IA, infraestructura y datos que hace funcionar la operación de una empresa que vende online, diseñado como una sola pieza: cada dato tiene una fuente de verdad, cada proceso sabe qué hacer cuando algo falla y alguien es responsable de mantenerlo. La diferencia con "tener herramientas" parece pequeña hasta que sube el volumen. Un negocio digital suele crecer por acumulación: un formulario para captar, un CRM porque el equipo comercial lo pidió, una automatización en Make para avisar por WhatsApp, un Excel para cuadrar ventas, un dashboard que alguien montó para dirección. Cada decisión tenía sentido por separado. El problema aparece cuando nadie ha diseñado el conjunto. Esta guía explica qué capas tiene un sistema, cómo encajan, qué señales indican que tu operación lo necesita y por dónde empezar sin parar lo que ya funciona. Es la página de referencia del blog de FCG Systems: desde aquí enlazo a los artículos que profundizan en cada problema. ## ¿Qué es exactamente un sistema para un negocio digital? Cuando hablo de sistema me refiero a tres cosas a la vez: 1. **Un diseño explícito del flujo de datos.** Cómo viaja un lead desde el anuncio hasta la venta, un pago hasta el acceso al curso o una baja hasta la factura. 2. **Reglas de operación.** Qué herramienta manda para cada dato, qué ocurre si una integración falla, qué se reintenta y qué se avisa. 3. **Ownership.** Documentación, logs, backups y una persona o equipo responsable de que siga funcionando dentro de seis meses. Si falta cualquiera de las tres, lo que tienes es una colección de herramientas que funciona mientras nadie la estrese. En FCG Systems diseñamos, construimos y operamos estos sistemas para empresas digitales que ya venden: infoproductores, academias online, agencias, comunidades y equipos comerciales con volumen de leads. ### ¿Por qué "sistemas para infoproductores" o "para academias online" y no un software estándar? Porque la operación de un negocio digital rara vez cabe en un único producto. Una academia online combina captación, formularios, CRM, llamadas comerciales, pagos, plataforma formativa, control de accesos, WhatsApp y soporte. Un infoproductor que trabaja por lanzamientos concentra en pocos días la mayor parte de la captación y de las ventas. Ningún SaaS cubre todo eso bien, y encadenar cinco SaaS sin diseño crea exactamente los problemas que se querían evitar. ## ¿Qué capas tiene un sistema para negocios digitales? Trabajamos sobre cuatro capas y un tejido que las atraviesa. No son productos que se compren por separado: son partes de la misma arquitectura. | Capa | Qué resuelve | Ejemplos en un negocio digital | |---|---|---| | Automatización | Procesos que avanzan sin que alguien los empuje | Lead routing, altas y bajas, onboarding, avisos, sincronización entre plataformas | | Software | Herramientas hechas alrededor de tu operación | Paneles internos, CRMs verticales, portales, backoffices, APIs | | IA | Tareas de juicio repetitivo dentro de un proceso | Clasificar leads, resumir conversaciones, scoring, asistentes internos | | Infraestructura | La base técnica que mantiene todo disponible | Servidores, Docker, bases de datos, backups, despliegues, monitorización | | Datos y tracking (tejido) | Una lectura fiable de lo que pasa | Eventos, atribución, dashboards, KPIs comerciales | ### Automatización: procesos que no dependen de que alguien se acuerde Es la capa que más se ve y la que más se rompe. Automatizar bien no es conectar dos aplicaciones con un webhook: es decidir qué pasa cuando el webhook llega dos veces, cuando la API de destino no responde o cuando el dato viene incompleto. La [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/) tiene que incluir logs, reintentos y avisos, o acabarás con [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/) y nadie se entera hasta que un cliente se queja. Las herramientas (n8n, Make, Airtable, scripts propios) se eligen según el sistema, no al revés. Si estás en esa decisión, la comparativa [n8n vs Make](https://fcgsystems.es/blog/n8n-vs-make/) la plantea con volumen real, y si un flujo ya ha dejado de recibir datos, empieza por [por qué un webhook de n8n no funciona](https://fcgsystems.es/blog/webhook-n8n-no-funciona/). ### Software: cuando la operación ya no cabe en herramientas genéricas Llega un punto en que la automatización deja de ser suficiente: la lógica es demasiado específica, el volumen hace caro cada ejecución o el equipo necesita una interfaz que ninguna herramienta ofrece. Ahí entra el [software a medida](https://fcgsystems.es/servicios/software-a-medida/): un panel comercial, un portal de alumnos, un backoffice para admisiones. En el artículo sobre [cuándo pasar de no-code a software propio](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/) detallo las señales concretas. ### IA: juicio repetitivo dentro de procesos reales La IA útil en un negocio digital no es un chatbot en la home. Es clasificar miles de mensajes entrantes, resumir llamadas para el CRM, puntuar leads o preparar borradores que una persona revisa. Se integra dentro de un proceso con métricas de calidad, igual que cualquier otra pieza. Lo explico con casos concretos en [dónde tiene sentido la IA aplicada en un negocio digital](https://fcgsystems.es/blog/ia-aplicada-negocios-digitales/), y cuándo compensa dar un paso más con [agentes de IA](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/), y en la página de [IA aplicada](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/). ### Infraestructura: lo que nadie ve hasta que falla Servidores, bases de datos, dominios, backups, despliegues y monitorización. En un negocio digital la infraestructura suele estar repartida entre cuentas personales, servicios que alguien contrató hace años y ninguna copia de seguridad probada. La [infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/) bien planteada deja sistemas disponibles, mantenibles y documentados. Mi regla: si un dato no puede reconstruirse, necesita backup, y un backup que nunca se ha restaurado no cuenta. Un ejemplo concreto de esta capa es [n8n self-hosted en producción](https://fcgsystems.es/blog/n8n-precios-cloud-self-hosted/). ### Datos y tracking: el tejido que conecta las capas No lo cuento como capa porque atraviesa todas. Sin eventos bien definidos y una fuente de datos fiable no puedes saber qué canal trae ventas, qué paso del funnel pierde gente ni si una automatización está haciendo lo que debe. Por eso [los datos de GA4, Ads y el CRM nunca coinciden](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/) en tantos negocios: cada herramienta mide su parte y nadie ha diseñado la lectura completa. Un caso típico es [usar el píxel de Meta y la API de conversiones sin duplicar conversiones](https://fcgsystems.es/blog/pixel-meta-api-conversiones-duplicados/). El servicio de [datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/) existe para resolver eso. ## ¿Qué es una fuente de verdad y por qué es lo primero que miro? Una fuente de verdad es el sistema que manda para un tipo de dato. Si el email de un contacto cambia, ¿dónde se cambia primero y quién se entera? Si un alumno pide la baja, ¿qué herramienta decide que ya no tiene acceso? Cuando audito una operación, lo primero que hago es preguntar dónde vive cada dato crítico: contactos, ventas, pagos y accesos. Si la respuesta es "depende" o "en varios sitios", ya sé dónde está buena parte de los errores. La misma persona aparece dos veces, dos comerciales llaman al mismo lead, la cifra de ventas de dirección no cuadra con la de facturación. Un sistema bien diseñado responde a esa pregunta con un nombre para cada dato: - **Contactos y leads:** el CRM (cómo elegirlo y cuándo compensa uno a medida está en [CRM para pymes y negocios digitales](https://fcgsystems.es/blog/crm-para-pymes-saas-o-a-medida/)). - **Pagos:** la pasarela de pago, sincronizada hacia el CRM, nunca al revés. - **Accesos:** la plataforma formativa o el sistema de membresía, alimentado por el estado del pago (lo aterrizo con Stripe en [pagos fallidos y control de accesos](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/)). - **Atribución:** el origen capturado en el primer registro y conservado hasta la venta. Esto no requiere herramientas nuevas. Requiere decidirlo, documentarlo y construir las integraciones para que respeten esa decisión. ## ¿Cómo sé si mi operación ya necesita un sistema? Hay una pregunta que uso en todas las conversaciones iniciales: > ¿Qué parte de vuestra operación dejaría de funcionar o crecería mucho más lento si mañana duplicaseis el volumen? La respuesta casi siempre señala el sistema que falta. Si es "el equipo comercial no daría abasto repartiendo leads", el problema está en la asignación y el CRM. Si es "el lanzamiento se nos caería", está en la infraestructura. Si es "no sabríamos qué campaña funciona", está en el tracking. ### Señales que se repiten en negocios digitales - **Leads que se pierden** entre el formulario y el comercial, o que llegan tarde y sin contexto. Lo desarrollo en [leads perdidos y Excel como CRM](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). - **WhatsApp es un canal de ventas pero funciona como un móvil compartido.** Cuándo pasar a la API oficial está en [WhatsApp Business o API oficial](https://fcgsystems.es/blog/whatsapp-business-api/). - **El mismo dato vive en tres herramientas** y ninguna coincide. - **Una hoja de cálculo hace de CRM**, de base de datos y de sistema de reporting a la vez. - **Los lanzamientos se preparan a última hora** y se descubre durante el pico que algo no aguanta. Para eso escribí el [checklist técnico antes de abrir registros](https://fcgsystems.es/blog/checklist-tecnico-lanzamiento/). - **Automatizaciones que fallan sin avisar** y se detectan días después. - **Todo depende de una persona**: la que montó las integraciones y es la única que sabe tocarlas. Hablo de ello en [cuando la capacidad técnica depende de una sola persona](https://fcgsystems.es/blog/dependencia-de-una-persona-capacidad-tecnica/). - **Cada herramienta nueva añade trabajo** en lugar de quitarlo. - **Pagáis SaaS** que nadie sabe si se siguen usando. Con dos o tres de estas señales a la vez, seguir añadiendo herramientas empeora la situación. ## ¿En qué se diferencia operar con herramientas sueltas de operar con un sistema? | Aspecto | Herramientas sueltas | Sistema diseñado | |---|---|---| | Datos | Duplicados, cada herramienta con su versión | Una fuente de verdad por tipo de dato | | Errores | Se descubren cuando alguien se queja | Logs, avisos y reintentos definidos | | Reporting | Se monta a mano exportando datos | Dashboards que leen de una fuente fiable | | Conocimiento | En la cabeza de una persona | Documentación, arquitectura e instrucciones operativas | | Crecimiento | Más volumen significa más trabajo manual | Más volumen se absorbe con el mismo equipo | | Lanzamientos | Cada campaña se monta desde cero | Infraestructura reutilizable de una campaña a otra | | Cambios | Tocar algo rompe otra cosa sin saber por qué | Se conoce el impacto antes de cambiar | La columna de la derecha no sale de comprar mejores herramientas. Sale de diseñar la operación antes de seguir añadiendo piezas, que es justo lo que hace la [arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/). ## ¿Cómo se ve un sistema en un caso real? Tres ejemplos publicados, anonimizados cuando se trata de trabajo para clientes: ### Funnel, tracking y CRM conectados en una academia online Una academia captaba con formularios, llamadas comerciales y WhatsApp, pero cada pieza vivía en una herramienta distinta y el reporting se hacía a mano. Conectamos tracking de fuentes con GA4 y Google Tag Manager, formularios en Tally hacia una base común en Airtable, un pipeline con las etapas reales de la venta, agenda con Calendly y dashboards por etapa y fuente. Durante el proyecto, con las campañas activas, las tres etapas medidas mejoraron: opt-in del 70,81 % al 77,61 %, preinscripción del 36,85 % al 44,72 % y llamadas del 9,89 % al 16,22 %. Son mejoras del conjunto, no atribuibles a una sola pieza. Todo el detalle está en el [caso del sistema comercial para una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/). ### Infraestructura para lanzamientos con miles de registros Registros llegando a la vez desde YouTube, Instagram, Telegram, Ads y email. El sistema añadió tracking multicanal, deduplicación antes de asignar, reparto comercial por reglas y capacidad, distribución a comunidades y dashboards visibles durante la campaña. El aprendizaje que más repito: la deduplicación va antes de la asignación, nunca después. Lo cuento en el [caso de infraestructura para lanzamientos de alto volumen](https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/) y en la página de [infraestructura de lanzamientos](https://fcgsystems.es/servicios/infraestructura-de-lanzamientos/). ### CommunityRedirect: un problema recurrente convertido en producto Los grupos de WhatsApp de un lanzamiento se llenan justo cuando más tráfico llega. En lugar de cambiar enlaces a mano en cada campaña, construimos un enlace único que consulta capacidad, rota destinos y centraliza la analítica. Es un producto propio de FCG Systems y está explicado en el [caso de CommunityRedirect](https://fcgsystems.es/casos/communityredirect-distribucion-comunidades-whatsapp/). ## ¿Por dónde empiezo sin parar lo que ya funciona? La tentación es rehacerlo todo. Casi nunca compensa. Una operación que vende no puede detenerse para migrar, así que el orden importa más que la ambición. ### 1. Mapa antes que herramientas Un **Systems Audit** dura entre 5 y 10 días laborables. Documenta el mapa de herramientas, los flujos de datos, los procesos manuales y los puntos de fallo, y termina con una arquitectura objetivo y un roadmap de 90 días. Sirve aunque después lo ejecutes con tu equipo o con otro proveedor. ### 2. Un cuello de botella cada vez Un **Automation Sprint** de 1 a 3 semanas elimina un problema concreto: lead routing, onboarding, seguimiento comercial, accesos o reporting. Incluye pruebas, logs básicos, documentación y traspaso. Es la forma más rápida de ver resultado sin comprometer toda la operación. ### 3. Sistema completo alrededor de un proceso crítico Un **Business System Build** de 3 a 8 semanas construye un sistema entero: base de datos, backoffice, automatizaciones, APIs, dashboard, permisos, tracking e infraestructura. Tiene sentido cuando el proceso es crítico y las piezas sueltas ya no dan más de sí. ### 4. Capacidad continua Un **Technology Partner** es una relación mensual en la que FCG Systems actúa como la capa técnica externa del negocio: mantenimiento, incidencias, mejoras y nuevos sistemas, con capacidad definida en planes Core, Growth y Scale. Tienes todos los formatos en la página de [servicios](https://fcgsystems.es/servicios/) y el detalle del modelo en [partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/). Si lo que buscas es entender quién hay detrás y cómo trabajamos, está en la página de [empresa](https://fcgsystems.es/empresa/). ## ¿Qué debe entregar cualquier proyecto de sistemas? Independientemente del proveedor, pide esto. Si no está, el sistema no está terminado: - Solución funcionando en producción, no en una demo. - Credenciales gestionadas correctamente, nunca pegadas en un documento o un chat. - Documentación y diagrama de arquitectura. - Instrucciones operativas para tu equipo. - Responsable claro de cada pieza. - Plan de mantenimiento. Y cuatro reglas técnicas que aplico en todos los proyectos: cada dato crítico tiene una fuente de verdad; las automatizaciones críticas soportan reintentos sin duplicar (idempotencia); un proceso crítico sin logs no está terminado; si un dato no puede reconstruirse, necesita backup. ## Checklist: ¿tu negocio digital funciona como un sistema? Repasa esta lista con tu equipo. Cada "no" es un punto de partida. - Sabemos qué herramienta manda para contactos, ventas, pagos y accesos. - Existe un mapa actualizado de herramientas e integraciones. - Cada lead llega al comercial con su origen visible y un único responsable. - Los registros duplicados se detectan antes de asignar. - Si una automatización falla, alguien recibe un aviso el mismo día. - Las automatizaciones críticas tienen logs que se pueden consultar. - Los datos que no pueden reconstruirse tienen backup y se ha probado a restaurarlo. - Ninguna integración depende de que una sola persona sepa cómo funciona. - El reporting de dirección se genera sin exportar datos a mano. - El próximo lanzamiento no se monta desde cero. - Sabemos qué SaaS pagamos y quién los usa. - Hay un responsable del mantenimiento del sistema, con nombre. ## ¿Qué proceso os está frenando? Un sistema para negocios digitales no es un proyecto de tecnología por la tecnología. Es la forma de que tu operación no se vuelva más difícil cada vez que el negocio crece. Normalmente no hace falta empezar por todo: hace falta encontrar el cuello de botella que más cuesta y construir alrededor de él con criterio de sistema. Si al leer la checklist has marcado varios "no", [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/). Te respondo con una primera lectura del problema y el siguiente paso que tendría sentido dar. ## Preguntas frecuentes ### ¿Qué diferencia hay entre tener herramientas y tener un sistema? Las herramientas resuelven tareas sueltas: un formulario, un CRM, una plataforma de email. Un sistema define cómo viaja cada dato entre ellas, qué herramienta manda para cada tipo de dato, qué pasa cuando algo falla y quién lo mantiene. Puedes tener las mismas herramientas y operar de forma muy distinta según exista o no ese diseño. ### ¿Un negocio pequeño necesita un sistema para negocios digitales? Depende del volumen y de lo que cueste un error, no del tamaño del equipo. Si todavía gestionas pocos leads y un fallo se arregla a mano en minutos, basta con ordenar lo que tienes. Cuando empiezas a tener varios canales, un equipo comercial o lanzamientos, el coste de no tener un sistema crece más rápido que la facturación. ### ¿Hay que cambiar todas las herramientas para construir un sistema? Casi nunca. Lo habitual es mantener buena parte del stack y cambiar cómo se conecta: definir fuentes de verdad, rehacer las integraciones frágiles, añadir logs y quitar pasos manuales. Sustituir una herramienta solo tiene sentido cuando es la causa del problema y no un síntoma. ### ¿Por dónde se empieza a construir un sistema? Por un mapa. Un Systems Audit de 5 a 10 días laborables documenta herramientas, flujos de datos, procesos y puntos de fallo, y termina en una arquitectura objetivo con un roadmap de 90 días. A partir de ahí se ataca primero el cuello de botella que más cuesta. ### ¿Quién mantiene el sistema una vez construido? Tiene que quedar decidido antes de construirlo. Puede mantenerlo tu equipo con la documentación y las instrucciones operativas del proyecto, o un partner tecnológico con capacidad mensual definida. Lo que no funciona es que nadie sea responsable y el sistema se degrade en silencio. ## Servicios relacionados - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. - [Partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/): Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Casos relacionados - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/): Formularios, tracking, CRM y agenda comercial conectados en un solo sistema, con el origen de cada lead a la vista. Las tres etapas del funnel mejoraron. - [Infraestructura para lanzamientos con miles de registros](https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/): Miles de registros desde cinco canales, sin duplicados, repartidos al equipo comercial y medidos mientras el lanzamiento sigue en marcha. - [CommunityRedirect: un enlace para no perder registros en grupos llenos](https://fcgsystems.es/casos/communityredirect-distribucion-comunidades-whatsapp/): Un enlace único que consulta la capacidad, rota destinos y evita enviar usuarios a grupos de WhatsApp llenos. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Atribución rota: por qué GA4, Meta y tu CRM nunca dan la misma cifra > Seguimos el recorrido de un registro para ver dónde se pierde su origen entre anuncio, formulario, WhatsApp y CRM, y cómo montar una atribución de leads fiable. - URL: https://fcgsystems.es/blog/atribucion-rota-ga4-crm/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 (15 de septiembre de 2026) - Tema: Sistemas · Formato: Teardown · Lectura: 9 min - Palabra clave: atribución de leads (también: tracking para infoproductores, por qué no coinciden GA4 y el CRM, UTMs en formularios, tracking server-side) La atribución de leads es el proceso de asignar a cada registro y a cada venta el canal y la campaña que lo originaron. Es fiable cuando el origen se captura en el primer contacto, viaja con el lead hasta el CRM y se conserva aunque la persona vuelva por otro canal. Sin eso, cada herramienta cuenta una historia distinta. Si alguna vez has puesto en la misma mesa el informe de Meta Ads, el de GA4 y el recuento del CRM, conoces la escena: tres cifras, ninguna coincide y la reunión acaba discutiendo cuál es "la buena" en lugar de decidir dónde mover presupuesto. En este artículo desmonto el recorrido de un registro típico para ver en qué punto exacto se rompe el dato. ## ¿Por qué GA4, Meta y el CRM dan cifras distintas? Primero, lo que no es un error: cada herramienta mide una cosa diferente. | Herramienta | Qué cuenta | Qué no ve | |---|---|---| | Meta Ads | Conversiones que atribuye a sus anuncios, según sus propias ventanas de atribución (que pueden incluir visualizaciones, no solo clics) | Lo que pasa fuera de su píxel o de las conversiones que le envías | | GA4 | Sesiones y eventos que ha podido medir en tu web, repartidos según su modelo de atribución | Visitas sin consentimiento o con bloqueadores, conversaciones de WhatsApp, llamadas | | CRM | Personas registradas, su etapa y la venta final | El origen, si nadie lo guardó al entrar | Meta tiende a atribuirse conversiones que GA4 asigna a otro canal, porque ve impactos que GA4 no puede ver. GA4 pierde sesiones que el navegador no le deja medir. Y el CRM, que es el único que sabe quién compró, a menudo no sabe de dónde venía esa persona. Por eso "cuadrar al 100 %" no es un objetivo realista ni útil. El objetivo es otro: tener una fuente de verdad para decidir y saber por qué las demás difieren. Google lo explica en su propia guía de [atribución en GA4](https://support.google.com/analytics/answer/10596866): el reparto del crédito depende del modelo que elijas. ## Teardown: el recorrido de un registro en un lanzamiento Vamos a seguir a una persona en un lanzamiento típico de un infoproducto. Ve un anuncio en Instagram, se registra a una clase gratuita, entra en un grupo de WhatsApp, reserva una llamada y compra. Cada flecha es un punto donde el origen puede perderse. ### Paso 1: el clic en el anuncio El anuncio lleva parámetros UTM en la URL: `utm_source`, `utm_medium`, `utm_campaign`. Hasta aquí, bien. El primer fallo aparece antes de llegar a la web: - **Enlaces sin UTMs.** El anuncio los lleva, pero la bio de Instagram, el vídeo de YouTube o el email de la semana pasada no. Todo ese tráfico cae en "directo" o "referral". - **UTMs inconsistentes.** "instagram", "Instagram", "ig" e "IG_stories" son cuatro fuentes para cualquier informe. Sin una convención escrita, el dato no se puede agrupar. La [guía de Google sobre URLs de campaña](https://support.google.com/analytics/answer/10917952) es un buen punto de partida para fijarla. ### Paso 2: la llegada a la landing - **Redirecciones que se comen los parámetros.** Un acortador de enlaces, una redirección de dominio o un cambio de `http` a `https` mal configurado pueden descartar la parte de la URL que lleva los UTMs. El usuario llega; su origen, no. - **Consentimiento y bloqueadores.** Si la persona rechaza las cookies de analítica o usa un bloqueador, GA4 puede no registrar esa sesión con su origen. No voy a darte un porcentaje porque depende de tu audiencia, tu banner y tu configuración. Lo importante es asumir que existe y no construir la atribución solo sobre la analítica del navegador. ### Paso 3: el formulario de registro Aquí está el fallo más caro y el más fácil de arreglar. El formulario guarda nombre, email y teléfono, pero no guarda el origen. La analítica sabe que "alguien de Instagram se registró"; el CRM tiene a la persona, pero sin saber de dónde viene. Los dos datos nunca se vuelven a juntar. La solución son los UTMs en formularios: leer los parámetros al llegar a la página, conservarlos durante la visita (la persona puede navegar dos páginas antes de registrarse) y enviarlos en campos ocultos junto con las respuestas. Herramientas como Tally permiten recibir esos valores como campos ocultos; en un formulario propio se hace con unas líneas de código. ### Paso 4: el grupo de WhatsApp Tras registrarse, la persona entra en un grupo o una comunidad de WhatsApp. WhatsApp no conserva los UTMs: una conversación no tiene URL. Si a partir de aquí el seguimiento pasa por WhatsApp y alguien apunta el lead a mano, el origen se pierde o se rellena de memoria. Por eso conviene que el registro (con su origen) ocurra antes de enviar a nadie a WhatsApp, y que el enlace al grupo salga del sistema, no de un enlace suelto copiado en diez sitios. Es parte de lo que resolvimos con [CommunityRedirect](https://fcgsystems.es/casos/communityredirect-distribucion-comunidades-whatsapp/): un único enlace que reparte usuarios entre grupos y centraliza la analítica en el punto de redirección. ### Paso 5: la agenda externa La persona reserva una llamada en Calendly o en otra agenda. Dos problemas habituales: - **La reserva no lleva el origen.** Muchas agendas externas solo registran los UTMs si llegan en el enlace o en el embed. Comprueba cómo lo hace la tuya con una reserva de prueba. - **La reserva no se vincula al lead.** La persona usa otro email al reservar y aparece como un contacto nuevo sin historial. En el CRM, esa llamada "no viene de ningún sitio". ### Paso 6: el cambio de dispositivo Vio el anuncio en el móvil, se registró desde el móvil y compra días después desde el portátil del trabajo. Para la analítica del navegador son dos personas distintas. Para el CRM es la misma, si el email coincide. Este es el mejor argumento para que el CRM, y no la analítica, sea la fuente de verdad de la venta. ### Paso 7: la venta La compra ocurre en la pasarela de pago o se cierra en la llamada. Si el pago no se cruza con el lead del CRM por email o por un identificador, la venta existe en la contabilidad pero no en el funnel. Nadie puede decir qué campaña la trajo. ## ¿Cuál debería ser la fuente de verdad de la atribución? Mi respuesta, para negocios que venden con registros, llamadas o lanzamientos: el CRM o la base de datos donde vive el lead. Es el único sistema que puede unir las tres cosas que importan: quién es la persona, de dónde vino y si compró. Eso no convierte a GA4 ni a Meta en inútiles. Cada una tiene su trabajo: - **Plataformas de anuncios:** optimizar campañas y audiencias con las señales que reciben. - **GA4:** entender el comportamiento en la web, detectar fugas en la landing y comparar tendencias. - **CRM:** contar registros, llamadas y ventas por origen, y decidir presupuesto. La regla es no mezclar esos trabajos. Cuando dirección pregunta "¿qué canal trae ventas?", la respuesta sale del CRM. Cuando el equipo de campañas pregunta "¿qué anuncio convierte mejor dentro de Meta?", sale de Meta. ## ¿Cómo se monta un tracking para infoproductores que aguante? La arquitectura que propongo tiene cuatro piezas. Ninguna es exótica. ### 1. Convención de UTMs escrita y compartida Un documento corto con valores permitidos para `utm_source`, `utm_medium` y `utm_campaign`, en minúsculas, y un generador de enlaces para que nadie los escriba a mano. Aburrido, sí. Sin esto, todo lo demás mide basura con precisión. ### 2. Captura del origen en el primer toque Campos ocultos en cada formulario con fuente, medio, campaña y la página de entrada. Se guarda el **primer origen** (cómo descubrió el negocio) y, si vuelve a registrarse, se añade el **último origen** sin sobrescribir el primero. Con esos dos datos ya puedes responder qué canal descubre audiencia y cuál cierra. ### 3. Un identificador que viaja con el lead El email normalizado o un ID propio que acompaña al lead a la agenda, a WhatsApp y a la pasarela de pago. Es lo que permite deduplicar y cruzar la venta con su origen. En [la infraestructura para lanzamientos con miles de registros](https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/) cada registro entraba con su canal y su campaña, se deduplicaba antes de llegar al CRM y los dashboards mostraban registros, asignaciones y ventas por fuente mientras la campaña estaba activa. ### 4. Eventos coherentes en la analítica y, cuando compense, server-side GA4 y Google Tag Manager con eventos definidos para cada paso del funnel (registro, preinscripción, llamada agendada), con los mismos nombres que las etapas del CRM. El tracking server-side, por ejemplo con [Google Tag Manager en servidor](https://developers.google.com/tag-platform/tag-manager/server-side), tiene sentido cuando necesitas enviar conversiones a las plataformas de anuncios con más control o cuando la medición en el navegador se queda corta para tu volumen. No es el primer paso: si el origen no se guarda en el formulario, el server-side no lo arregla. Y si envías eventos a Meta desde el navegador y desde un servidor a la vez, revisa cómo [usar el píxel y la API de conversiones sin contar cada conversión dos veces](https://fcgsystems.es/blog/pixel-meta-api-conversiones-duplicados/). ## ¿Qué cambia cuando la atribución está bien montada? En el [caso del funnel, tracking y CRM de una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/), el punto de partida era justo este: las cifras de cada herramienta no coincidían y el reporting se montaba a mano. Montamos GA4 y Google Tag Manager con eventos para cada paso, formularios en Tally que enviaban cada registro con su fuente a una base común en Airtable, y dashboards de conversión por etapa y por fuente. Durante el proyecto, las tres etapas medidas mejoraron: opt-in del 70,81 % al 77,61 %, preinscripción del 36,85 % al 44,72 % y llamadas del 9,89 % al 16,22 %. Las mejoras se midieron con el funnel en marcha, así que no se atribuyen a una sola pieza. El aprendizaje que me llevo de ese proyecto es más simple que cualquier cifra: sin tracking fiable no hay optimización. Primero se mide cada paso; después se discute qué cambiar. ## Checklist de atribución de leads Repasa estos puntos con quien lleva campañas y con quien lleva el CRM, juntos: - Existe una convención de UTMs escrita y todos los enlaces publicados la siguen, también los orgánicos (bio, vídeos, emails). - Ninguna redirección ni acortador elimina los parámetros de la URL; lo has comprobado haciendo clic en el enlace real. - Cada formulario guarda fuente, medio, campaña y página de entrada en campos ocultos. - El CRM conserva el primer origen y el último origen de cada lead, sin sobrescribir el primero. - Las reservas de la agenda llevan el origen o se vinculan al lead existente. - El enlace a WhatsApp se entrega después del registro, desde el sistema. - Las ventas se cruzan con el lead del CRM por email o por un identificador común. - Los eventos de GA4 usan los mismos nombres que las etapas del CRM. - Hay un dashboard de registros, llamadas y ventas por fuente que lee del CRM, sin exportaciones manuales. - El equipo sabe qué herramienta responde a cada pregunta y por qué las cifras no coinciden. Si os falta más de la mitad, el problema no es de analítica: es de arquitectura. Es la capa de datos que describo en la guía sobre [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/), y va de la mano del circuito comercial que explico en [leads que se pierden entre el formulario y el comercial](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). Si tienes un lanzamiento cerca, revisa también el [checklist técnico antes de abrir registros](https://fcgsystems.es/blog/checklist-tecnico-lanzamiento/). ## ¿Por dónde empezar a arreglar la atribución? Coge un registro real de esta semana y sigue su rastro hacia atrás: del CRM al formulario, del formulario a la landing, de la landing al anuncio. Anota dónde desaparece el origen. Ese es tu primer arreglo, y casi siempre está en el formulario. En FCG Systems este trabajo encaja en [tracking server-side y atribución hasta el CRM](https://fcgsystems.es/servicios/datos-tracking-analitica/) y, cuando el problema es de cómo se conectan las herramientas, en [arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/). Si tu equipo pasa los lunes montando informes que no cuadran, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y te digo dónde miraría primero. ## Preguntas frecuentes ### ¿Por qué no coinciden los datos de Meta Ads, GA4 y el CRM? Porque cada herramienta cuenta cosas distintas con reglas distintas. Meta atribuye conversiones con sus propias ventanas, que pueden incluir visualizaciones de anuncios; GA4 solo ve las visitas que ha podido medir y aplica su modelo; el CRM registra personas y ventas reales. Que difieran es normal; lo que no es normal es no saber cuál usar para decidir. ### ¿Qué herramienta debería ser la fuente de verdad de la atribución? Para decisiones de negocio, el CRM o la base de datos donde vive el lead, porque es la única que conecta el registro con la venta. GA4 y las plataformas de anuncios siguen siendo útiles para optimizar campañas y estudiar el comportamiento en la web, pero no para contar cuántas ventas trajo cada canal. ### ¿Cómo se guardan los UTMs en un formulario? Leyendo los parámetros de la URL al llegar a la página, conservándolos durante la visita y enviándolos en campos ocultos del formulario junto con el resto de respuestas. Así el origen viaja con el registro hasta el CRM y no depende de que la analítica haya podido medir esa sesión. ### ¿Necesito tracking server-side para tener una atribución fiable? No siempre. Si el origen se captura en el formulario y se conserva en el CRM, ya tienes una base fiable para decidir. El tracking server-side tiene sentido cuando necesitas enviar conversiones a las plataformas de anuncios con más control, o cuando la medición en el navegador se queda corta para tu volumen. ### ¿Qué modelo de atribución debería usar? Empieza por guardar el primer origen y el último origen de cada lead en el CRM. Con esos dos datos puedes responder qué canal descubre audiencia y qué canal cierra registros. Los modelos más complejos solo compensan cuando esa base ya es fiable. ## Servicios relacionados - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Casos relacionados - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/): Formularios, tracking, CRM y agenda comercial conectados en un solo sistema, con el origen de cada lead a la vista. Las tres etapas del funnel mejoraron. - [Infraestructura para lanzamientos con miles de registros](https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/): Miles de registros desde cinco canales, sin duplicados, repartidos al equipo comercial y medidos mientras el lanzamiento sigue en marcha. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Automatización de procesos con IA: qué automatizar primero, qué dejar en reglas y dónde todavía no compensa > Qué procesos se pueden automatizar con IA y cuáles no, en qué se diferencia de una automatización normal, y cómo controlar la calidad en producción. - URL: https://fcgsystems.es/blog/ia-aplicada-negocios-digitales/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 · Actualizado: 2026-09-16 (16 de septiembre de 2026) - Tema: IA aplicada · Formato: Breakdown · Lectura: 11 min - Palabra clave: automatización de procesos con IA (también: automatizar procesos con ia, IA aplicada a negocios digitales, qué procesos se pueden automatizar con IA, IA para academias online, IA para infoproductores) La **automatización de procesos con IA** consiste en meter un modelo de lenguaje dentro de un proceso que ya existe, en el paso concreto donde hay que interpretar algo ambiguo (clasificar un mensaje, resumir una llamada, extraer datos de un texto), y dejar el resto del proceso en reglas deterministas. No sustituye a la automatización de siempre: le añade juicio en el punto donde una regla no llega. Si no hay proceso ni métrica que deba mejorar, lo que hay es una demo. En FCG Systems partimos de una idea sencilla: no se vende IA, se vende una mejora medible en una operación. Parece un matiz, pero cambia cómo se decide qué construir. La pregunta deja de ser "¿dónde podemos meter IA?" y pasa a ser "¿qué tarea repetitiva consume horas de mi equipo y tiene un resultado que se puede revisar?". ## ¿En qué se diferencia de una automatización normal? Es la distinción que más dinero ahorra, y casi nunca se explica. Hay tres cosas distintas que se venden con el mismo nombre: | | Automatización clásica | Automatización con IA | Agente de IA | |---|---|---|---| | Quién decide el camino | El flujo, definido de antemano | El flujo; la IA resuelve un paso concreto | El modelo, dentro de los límites que le pongas | | Qué resuelve | Reglas claras: si pasa X, haz Y | Pasos donde hay que interpretar lenguaje | Tareas abiertas cuyo orden cambia en cada caso | | Previsibilidad | Total | Alta en el recorrido, variable en ese paso | La más baja | | Coste y latencia | Los más bajos | Medios | Los más altos | | Cuándo elegirlo | Siempre que la lógica quepa en un `if` | Cuando el dato de entrada es texto libre | Cuando ni siquiera el orden de los pasos es fijo | La inmensa mayoría de lo que un negocio necesita cae en las dos primeras columnas. La tercera es la que más se vende y la que menos veces hace falta: cuándo compensa de verdad lo explico en [agentes de IA para negocios](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/). La regla práctica: **la IA interpreta, las reglas deciden**. El modelo lee el mensaje y devuelve "intención: quiere precio". La decisión de a qué comercial va, con qué prioridad y en cuánto tiempo, es una regla escrita en código. Predecible, auditable y fácil de cambiar. ## ¿Qué procesos se pueden automatizar con IA y cuáles no? La respuesta corta cabe en una pregunta: **¿la entrada es texto libre que hay que interpretar?** Si la respuesta es sí (un formulario con un campo abierto, un mensaje de WhatsApp, una transcripción de llamada, un correo de soporte, un PDF de un proveedor), hay caso. Si la respuesta es no (un pago aprobado, un país, una fecha, un importe), no hace falta ningún modelo: eso es una automatización normal y saldrá más barata, más rápida y más fiable. Añade tres condiciones antes de dar el sí por bueno: - **El proceso existe y está definido.** Automatizar el caos lo acelera. - **El resultado se puede revisar.** Si nadie sabría decir si una salida es correcta, no hay forma de medir nada. - **El volumen lo justifica.** Cinco mensajes al día los clasifica una persona mejor y gratis. ## ¿Por qué tantos proyectos de IA se quedan en demo? Porque empiezan por la tecnología. Alguien prueba un chatbot, funciona bien con cinco preguntas preparadas y se da por hecho que funcionará con cinco mil mensajes reales. Luego aparecen los problemas que la demo no enseñaba: - **Nadie definió qué es una buena respuesta**, así que no hay forma de saber si el sistema acierta. - **No está conectado a nada**: la salida del modelo acaba copiada a mano en el CRM o en una hoja. - **No hay revisión** en los pasos donde un error cuesta dinero o reputación. - **No hay logs**, así que cuando algo sale mal nadie puede reconstruir qué entró y qué salió. - **Se usa IA para decisiones que deberían ser reglas**, y el resultado cambia de un día para otro sin motivo aparente. La IA en producción es sobre todo integración, control de calidad y documentación. El prompt es la parte pequeña. ## ¿Dónde ahorra trabajo de verdad la IA en academias e infoproductores? Estos son los seis tipos de caso que más encajan en negocios digitales con volumen: academias online, infoproductores, comunidades y equipos comerciales. Para cada uno, lo que importa es lo mismo: qué entra, qué sale, quién revisa, cómo se mide y qué puede salir mal. ### 1. Clasificar leads y mensajes entrantes Formularios con campos abiertos, mensajes de WhatsApp, emails de soporte. Alguien los lee uno a uno para decidir qué son y a dónde van. - **Entrada:** el texto del mensaje y el contexto mínimo (origen, producto). - **Salida:** una categoría de una lista cerrada (duda de pago, interés comercial, soporte técnico, baja) y un campo de confianza. - **Quién revisa:** nadie en los casos de alta confianza; una persona en los dudosos. - **Métrica:** tiempo hasta la primera respuesta y porcentaje de mensajes que acaban en la cola correcta. - **Riesgo:** categorías mal definidas. Si tu equipo no se pone de acuerdo en qué es cada categoría, el modelo tampoco. ### 2. Resumir llamadas y conversaciones Llamadas comerciales, sesiones de admisión, conversaciones largas de soporte. El comercial toma notas a medias o no las toma. - **Entrada:** transcripción de la llamada o hilo de conversación. - **Salida:** un resumen con estructura fija (necesidad, objeciones, siguiente paso, fecha acordada) guardado en la ficha del CRM. - **Quién revisa:** el propio comercial, que corrige en segundos en lugar de escribir desde cero. - **Métrica:** fichas con siguiente paso registrado y tiempo de administración por llamada. - **Riesgo:** que el resumen invente un compromiso que no se dijo. Por eso la estructura es fija y el comercial valida. ### 3. Generar contenido estructurado No hablo de escribir el blog con IA. Hablo de convertir información en formatos que la operación necesita: fichas de producto a partir de un temario, respuestas base para preguntas frecuentes, descripciones de lecciones, extracción de datos de documentos. - **Entrada:** material fuente del negocio (temario, documento, transcripción). - **Salida:** campos concretos en un formato validable (JSON, filas de una tabla). - **Quién revisa:** la persona responsable del contenido antes de publicar. - **Métrica:** horas de preparación por pieza. - **Riesgo:** datos incorrectos que se publican. Nada generado sale al cliente sin revisión si afecta a precios, condiciones o promesas. ### 4. Recuperar conocimiento para soporte y setters El equipo pregunta lo mismo una y otra vez: condiciones del programa, fechas, políticas de devolución, cómo se accede a la plataforma. La respuesta existe, pero está repartida entre documentos. - **Entrada:** la pregunta y una base de conocimiento interna mantenida. - **Salida:** una respuesta con referencia al documento de origen. - **Quién revisa:** el setter o agente de soporte, que decide si la usa. - **Métrica:** tiempo de respuesta y consultas escaladas a la persona que "lo sabe todo". - **Riesgo:** base de conocimiento desactualizada. Si el documento está mal, la respuesta también. Mantener la fuente es parte del sistema. ### 5. Scoring de leads Asignar una puntuación a cada lead según señales: lo que escribió en el formulario, cómo interactuó, qué preguntó. - **Entrada:** respuestas del formulario, historial de interacción. - **Salida:** señales estructuradas (intención, urgencia, encaje) que alimentan un scoring. - **Quién revisa:** dirección comercial, comparando el scoring con los resultados reales de venta. - **Métrica:** conversión por tramo de puntuación. - **Riesgo:** dejar que el modelo decida la prioridad final. La IA extrae señales del texto; la fórmula del scoring y los umbrales van en código. Qué necesitáis tener antes de puntuar nada, cómo se construye la tabla de puntos y qué hacer con el score una vez calculado está desarrollado en [lead scoring con reglas o con IA](https://fcgsystems.es/blog/lead-scoring-reglas-o-ia/). ### 6. Workflows asistidos Procesos con varios pasos donde la IA prepara el trabajo y una persona aprueba: preparar un borrador de propuesta con los datos del discovery, redactar un seguimiento personalizado a partir del resumen de llamada, revisar una solicitud de admisión contra criterios definidos. - **Entrada:** datos del proceso ya estructurados. - **Salida:** un borrador listo para aprobar o editar. - **Quién revisa:** siempre una persona antes de enviar. - **Métrica:** tiempo por ciclo completo del proceso. - **Riesgo:** que la aprobación se vuelva automática por costumbre. Conviene medir cuántos borradores se editan: si nadie edita nada, o todo es perfecto o nadie está mirando. Aquí es donde suele aparecer la palabra "agentes". Un agente de IA en un proceso es útil cuando tiene herramientas acotadas, permisos mínimos y un punto de aprobación humana. Un agente con acceso libre al CRM y al email no es un sistema, es un riesgo. Qué es exactamente un agente, cuándo compensa y cómo se construye con límites está en [agentes de IA para negocios](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/). ## ¿Dónde no conviene usar IA todavía? Esta parte es tan importante como la anterior. Estos son los casos donde digo que no, o que todavía no: | Situación | Por qué no | Qué hacer en su lugar | |---|---|---| | Decisiones deterministas: umbrales, reglas de asignación, cálculo de comisiones, permisos de acceso | Tienen que dar siempre el mismo resultado y ser auditables | Reglas en código, con tests | | Procesos sin datos o sin histórico | No hay con qué comprobar si el modelo acierta | Primero registrar y medir el proceso | | Pasos sensibles sin revisión humana: pagos, bajas, promesas contractuales, datos de salud | Un error tiene coste alto y difícil de deshacer | IA como borrador, persona como decisora | | Procesos que aún no están definidos | Automatizar el caos lo acelera | Diseñar el proceso antes | | Tareas que una regla simple ya resuelve | Más coste, más latencia y menos predecible | Usar la regla | La regla que aplico: si puedes escribir la lógica como un `if`, escríbela como un `if`. La IA entra donde hay lenguaje ambiguo que interpretar, no donde hay una decisión que tomar con criterios claros. ## ¿Cómo se lleva un caso de IA a producción? Es lo que en FCG Systems llamamos un [AI Workflow](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): un proyecto cerrado alrededor de un proceso, con estos entregables. 1. **Definición del caso.** Qué proceso, qué tarea concreta, qué métrica debe mejorar y cómo se mide hoy. 2. **Arquitectura.** Dónde entra el dato, dónde se llama al modelo, dónde se guarda la salida, qué pasa si el modelo falla o tarda. 3. **Modelos y prompts.** Elección del modelo según tarea, coste y latencia; prompts versionados, con salidas en formato validable. 4. **Integración.** Conexión con el CRM, la base de datos o las automatizaciones existentes. Suele ir junto a [automatizar los procesos que rodean al modelo](https://fcgsystems.es/servicios/automatizacion-de-procesos/), porque la IA casi nunca vive sola. 5. **Control de calidad.** Casos de prueba, revisión humana donde toca y alertas. 6. **Métricas.** Antes y después, medidos con el mismo criterio. 7. **Documentación.** Qué hace, cómo se cambia un prompt, qué hacer si falla y quién es responsable. ### ¿Cómo se controla la calidad? Sin control de calidad no hay IA en producción. Lo mínimo: - **Conjunto de pruebas.** Una colección de entradas reales con la salida correcta acordada por el equipo. Cada cambio de prompt o de modelo se pasa por ahí antes de desplegar. - **Salidas validadas.** Si el modelo tiene que devolver una categoría de una lista, el sistema comprueba que es de la lista. Si no lo es, va a revisión. - **Human-in-the-loop.** Revisión humana en los pasos sensibles y en los casos de baja confianza. - **Muestreo.** Revisar periódicamente una muestra de salidas en producción, no solo las que alguien reporta. - **Logs de entradas y salidas.** Qué prompt, qué versión, qué entrada, qué respuesta y cuándo. Un proceso crítico sin logs no está terminado, y con IA todavía menos. - **Alternativa ante fallos.** Si el proveedor no responde o la salida no valida, el proceso sigue por un camino manual en lugar de romperse en silencio. Sobre esto tienes más en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ### ¿Qué pasa con la privacidad de los datos? Es una decisión de arquitectura. Al modelo se le envía solo lo necesario para la tarea, se revisan las condiciones de uso de datos del proveedor antes de integrarlo, y cuando el caso lo pide se anonimizan nombres, emails o teléfonos antes de procesar. Las credenciales se gestionan como cualquier otro secreto: nunca en un documento compartido ni en un chat. ## Un escenario para aterrizarlo Imagina una academia online que recibe cientos de mensajes por WhatsApp y email en la semana de un lanzamiento. Dos personas los leen y los reparten a mano entre soporte y el equipo de setters. Los leads con intención de compra esperan detrás de las dudas de acceso. Un primer AI Workflow razonable sería: 1. Cada mensaje entrante se clasifica en una lista cerrada de categorías, con confianza. 2. Las reglas de enrutado (qué categoría va a qué cola, qué setter tiene capacidad) están en código, no en el prompt. 3. Los casos de baja confianza van a una cola de revisión. 4. Todo queda registrado: mensaje, categoría, versión del prompt, quién lo atendió. 5. Se mide el tiempo hasta primera respuesta por categoría, antes y después. Nada de chatbot respondiendo solo. Solo una tarea repetitiva que deja de hacerse a mano, con un resultado que se puede comprobar. Si los leads, además, se pierden entre el formulario y el CRM, el problema es anterior a la IA: lo explico en [leads perdidos y Excel como CRM](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). ## Checklist antes de meter IA en un proceso - El proceso existe, se repite y está documentado. - Sabemos qué métrica debe mejorar y cuánto vale hoy. - La salida del modelo tiene un formato cerrado y validable. - Las decisiones con reglas claras están en código, no en el prompt. - Hay un conjunto de pruebas con casos reales antes de desplegar. - Los pasos sensibles tienen revisión humana. - Se registran entradas, salidas y versión del prompt. - Existe un camino alternativo si el modelo falla o no responde. - Hemos revisado qué datos se envían al proveedor y en qué condiciones. - Hay una persona responsable del sistema y de su mantenimiento. ## ¿Por dónde empezar con la IA en tu operación? La IA funciona mejor como una capa más de un sistema bien diseñado, junto a la automatización, el software y la infraestructura. Es la idea que desarrollo en la guía sobre [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/). Y si la operación ya se sostiene en decenas de escenarios no-code, a veces el paso previo es [pasar parte de esa lógica a software propio](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/). No necesitas una estrategia de IA. Necesitas un proceso que hoy consume demasiadas horas y un criterio claro para medir si mejora. [Cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y vemos si la IA es la respuesta o si una regla bien puesta lo resuelve antes. ## Preguntas frecuentes ### ¿Qué procesos se pueden automatizar con IA? Aquellos cuya entrada es texto libre que hay que interpretar: clasificar mensajes y leads, resumir llamadas, extraer datos de correos o documentos, recuperar conocimiento para soporte y preparar borradores para que alguien los apruebe. Si la entrada ya es un dato estructurado (un pago aprobado, un país, un importe), no hace falta un modelo: eso es una automatización normal y sale más barata y más fiable. ### ¿Cómo se hace una automatización de procesos con IA? Se parte de un proceso que ya existe y de una métrica que debe mejorar. Se identifica el único paso donde hay que interpretar algo ambiguo, ahí entra el modelo, y todo lo demás se queda en reglas deterministas. Después: integración con el CRM o la base de datos, casos de prueba reales, revisión humana en los pasos sensibles, logs de cada entrada y salida, y medición antes y después. ### ¿En qué se diferencia la automatización con IA de una automatización normal? En una automatización clásica el camino está definido de antemano y siempre da el mismo resultado. En una automatización con IA el camino sigue siendo fijo, pero un paso concreto lo resuelve un modelo porque la entrada es lenguaje ambiguo. Un agente de IA va más allá: decide él mismo el orden de los pasos, con más coste, más latencia y menos previsibilidad. ### ¿La IA puede decidir sola a qué comercial asignar un lead? La IA puede aportar señales, como la intención detectada en un mensaje. La decisión de asignación, con sus reglas, umbrales y capacidad de cada comercial, debe ir en código, porque tiene que ser predecible, auditable y fácil de cambiar. ### ¿Cómo se controla que la IA no se equivoque en producción? Con un conjunto de casos de prueba reales antes de desplegar, revisión humana en los pasos sensibles, muestreo periódico de salidas y logs de cada entrada y respuesta. El modelo puede fallar; el sistema tiene que detectarlo y tener una alternativa. ### ¿Qué pasa con los datos personales que se envían al modelo? Solo se envía la información necesaria para la tarea, se revisan las condiciones de uso de datos del proveedor antes de integrarlo y, cuando el caso lo exige, se anonimizan los datos antes de procesarlos. Es una decisión de arquitectura, no un detalle de configuración. ## Servicios relacionados - [Sistemas de IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Cuando todo depende de una persona: capacidad técnica sin montar un departamento > Si tus automatizaciones dependen de una sola persona, tienes un riesgo operativo. Cómo repartirlo: documentación, ownership y un departamento técnico externo. - URL: https://fcgsystems.es/blog/dependencia-de-una-persona-capacidad-tecnica/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 (15 de septiembre de 2026) - Tema: Sistemas · Formato: Opinión · Lectura: 7 min - Palabra clave: departamento técnico externo (también: partner tecnológico para negocios digitales, capacidad técnica sin contratar, dependencia de una persona) Un **departamento técnico externo** es un equipo que mantiene y evoluciona los sistemas de tu negocio de forma continua, con una capacidad mensual acordada y documentando todo lo que toca. Es la alternativa a que la operación dependa de una sola persona o a contratar un departamento completo que quizá todavía no puedes llenar ni dirigir. Casi todos los negocios digitales que crecen pasan por la misma fase. Alguien del equipo, o un freelance de confianza, montó las primeras automatizaciones. Conectó los formularios con el CRM, preparó los avisos por WhatsApp, configuró el tracking y resolvió los problemas de los lanzamientos a base de horas y buena voluntad. Funcionó. Y ahora esa persona es la única que sabe cómo funciona casi todo. No escribo esto contra esa persona. Suele ser la más valiosa del equipo técnico. Lo escribo porque esa situación es un riesgo operativo que casi nadie trata como tal hasta que se materializa. ## ¿Por qué es un problema que todo dependa de una persona? Porque el conocimiento no está en el sistema, está en una cabeza. Mientras esa persona está disponible, todo parece ir bien. El problema aparece en tres momentos previsibles: - **Cuando no está.** Vacaciones, enfermedad, otro proyecto, un cambio de trabajo. Una integración falla un viernes y nadie más sabe dónde mirar. - **Cuando sube el volumen.** Esa persona pasa de construir a apagar fuegos. Las mejoras se aplazan y la operación empieza a acumular parches. - **Cuando hay que cambiar algo.** Nadie conoce el impacto de tocar un flujo, así que o no se toca o se toca con miedo. Las dos opciones frenan el negocio. Imagina una academia online con un lanzamiento programado. Las credenciales de la plataforma de email están en la cuenta personal del freelance que lo montó, los webhooks apuntan a un escenario de Make que solo él entiende y el reparto de leads vive en una fórmula de una hoja de cálculo. Nada de esto es raro. Tampoco es un sistema: es una operación que funciona mientras una persona concreta esté atenta. ## ¿Cómo sé si mi negocio tiene este problema? Hazte estas preguntas con honestidad: - Si mañana la persona que montó las automatizaciones desaparece, ¿cuánto tardaríais en entender qué hace cada una? - ¿Las credenciales de las herramientas críticas están en cuentas de la empresa o en cuentas personales? - ¿Existe un documento que explique qué integración mueve qué dato y hacia dónde? - ¿Cuando algo falla, lo detecta un sistema o lo detecta un cliente? - ¿Hay tareas que se aplazan porque "solo él sabe hacerlo"? Si más de una respuesta te incomoda, el riesgo ya existe. La buena noticia es que se reduce con trabajo ordenado, no con una reestructuración. ## ¿Contrato a alguien, busco un freelance o trabajo con un partner? Es la duda lógica en este punto, y la respuesta honesta es que depende de dos cosas: cuánto trabajo técnico continuo tienes y si alguien en tu empresa puede dirigirlo. | Opción | Dónde encaja | Riesgo principal | |---|---|---| | Freelance | Tareas acotadas con alcance claro | El conocimiento se va con la persona si no hay documentación | | Contratación interna | Trabajo técnico continuo y alguien que lo dirija | Una sola persona cubriendo varias especialidades; volvéis a depender de alguien | | Agencia | Proyectos con entregable cerrado | Se entrega y se va; el mantenimiento queda en el aire | | Partner tecnológico | Operación que necesita arquitectura, construcción y mantenimiento continuo | Requiere definir bien la capacidad y las prioridades | Contratar en plantilla es buena idea cuando hay trabajo para llenar el puesto y alguien capaz de priorizar, revisar calidad y tomar decisiones de arquitectura. Si no existe esa figura, la persona contratada acaba sola tomando decisiones que afectan a todo el negocio. Has cambiado un freelance del que dependes por un empleado del que dependes. El freelance funciona muy bien para trabajos con principio y final. Funciona peor cuando se convierte, sin que nadie lo decida, en el responsable de toda la operación técnica. La agencia suele resolver un proyecto concreto. El problema es lo que pasa después: ¿quién mantiene lo entregado, quién responde cuando falla, quién lo evoluciona? Un [partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/) cubre arquitectura, implementación, despliegue, monitorización, mantenimiento y evolución. No es la opción correcta para todo el mundo. Es la adecuada cuando tu operación necesita capacidad técnica de varias especialidades pero no llena ni puede dirigir un departamento propio. ## ¿Qué tiene que exigir mi negocio a quien lleve la parte técnica? Da igual si es una persona interna, un freelance o un proveedor. Estos mínimos no son negociables, y son los mismos que aplicamos en FCG Systems a cualquier proyecto: ### Documentación que sobreviva a quien la escribió Cada sistema recurrente debe tener arquitectura, instrucciones operativas, checklist y una definición de terminado. No hace falta una enciclopedia. Hace falta que otra persona competente pueda entender qué hace cada pieza sin preguntar. ### Credenciales en cuentas de la empresa Las herramientas críticas se contratan a nombre del negocio. Las contraseñas se gestionan en un gestor de contraseñas, nunca en un documento compartido, un chat o un Markdown. Si hoy no sabes dónde están tus credenciales, ese es el primer punto a resolver. ### Ownership claro de cada pieza Para cada integración, cada automatización y cada servidor debe haber un responsable con nombre. Ownership no significa que esa persona lo haga todo: significa que responde de que funcione. ### Logs y avisos Un proceso crítico sin logs no está terminado. Si una automatización falla y nadie recibe un aviso, el sistema depende de que alguien lo revise a mano, que es otra forma de depender de una persona. Lo desarrollo en el artículo sobre [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ### Backups probados Si un dato no puede reconstruirse, necesita backup. Y un backup que nunca se ha restaurado es una suposición, no una garantía. ### Cambios con proceso Los cambios en producción se validan antes. Lo que queda fuera del alcance se registra, se estima, se aprueba y después se ejecuta. Absorber continuamente cambios "pequeños" sin registrarlos es cómo un sistema ordenado vuelve a convertirse en un conjunto de parches. ## ¿Por qué desconfío de quien ofrece "todo lo que necesites"? Porque no es verdad y porque impide priorizar. Ningún equipo tiene capacidad infinita. Cuando un proveedor promete todo, en la práctica atiende lo que más ruido hace, no lo que más importa. Lo que funciona es lo contrario: una **capacidad mensual explícita**. Sabes cuánto trabajo cabe cada mes y decides con tu proveedor qué va primero: una incidencia crítica, una mejora del proceso comercial o la preparación del próximo lanzamiento. Esa conversación obliga a ordenar prioridades, y esa es buena parte del valor. En FCG Systems el formato Technology Partner se organiza así, en tres planes: - **Core:** mantenimiento y mejoras pequeñas. - **Growth:** desarrollo continuo y nuevos sistemas. - **Scale:** partnership tecnológico completo. Tampoco prometemos soporte instantáneo por defecto. Las incidencias se clasifican por gravedad (sistema crítico caído, función importante degradada, bug no crítico, mejora) y la respuesta depende del plan acordado. Prefiero decir esto claro al principio que descubrirlo en mitad de un lanzamiento. ## ¿Cómo se sale de la dependencia sin romper nada? No hace falta despedir a nadie ni rehacer la operación. El orden que recomiendo es este: 1. **Inventario.** Qué herramientas hay, qué integraciones las conectan, dónde están las credenciales y quién toca qué. Es la base de la [arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/). 2. **Documentación mientras la relación sigue activa.** Si la persona que montó todo sigue disponible, es el mejor momento para escribir cómo funciona. Hacerlo después, a partir de ingeniería inversa, es mucho más lento. 3. **Fuentes de verdad.** Decidir qué herramienta manda para contactos, ventas, pagos y accesos. Mucha dependencia nace de que solo una persona sabe dónde está el dato bueno. En la parte comercial esa herramienta suele ser el CRM, y [qué debe sostener exactamente](https://fcgsystems.es/blog/que-es-un-crm/) conviene decidirlo antes de elegir producto. 4. **Logs y avisos en lo crítico.** Que los fallos los detecte el sistema, no alguien que se acuerda de mirar. 5. **Repartir ownership.** Cada pieza con un responsable, sea interno o externo. 6. **Decidir el modelo.** Con el mapa hecho, ya puedes valorar con datos si necesitas contratar, mantener al freelance para tareas acotadas o trabajar con un departamento técnico externo. Un Systems Audit de 5 a 10 días laborables cubre los tres primeros puntos y termina con un roadmap de 90 días. Si quieres ver cómo encaja todo esto dentro de la operación completa, la guía de [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/) explica las capas y por dónde empezar. ## Checklist para reducir la dependencia de una persona - Las herramientas críticas están contratadas a nombre de la empresa. - Las credenciales viven en un gestor de contraseñas con acceso de al menos dos personas. - Existe un mapa de integraciones actualizado. - Cada automatización crítica tiene logs y un aviso cuando falla. - Hay instrucciones operativas para las tareas recurrentes. - Cada pieza del sistema tiene un responsable con nombre. - Los backups de datos no reconstruibles se han restaurado al menos una vez. - Los cambios en producción se validan antes de aplicarse. - La capacidad técnica mensual está definida, sea interna o externa. - Alguien que no montó el sistema podría explicar qué hace cada flujo. ## ¿Qué parte de vuestra operación solo sabe tocar una persona? La dependencia de una persona no se arregla con más horas de esa persona. Se arregla convirtiendo su conocimiento en sistema: documentación, fuentes de verdad, logs y responsables claros. A partir de ahí, decidir si contratar o trabajar con un partner es una decisión de negocio, no una urgencia. Si te has reconocido en este artículo, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y quién lo sostiene hoy. Te respondo con una primera lectura de dónde está el riesgo y qué haría primero. Si quieres saber quién hay detrás de FCG Systems, lo tienes en la página de [empresa](https://fcgsystems.es/empresa/). ## Preguntas frecuentes ### ¿Qué es un departamento técnico externo? Es un equipo tecnológico que trabaja para tu negocio de forma continua sin estar en plantilla. Se ocupa de mantener, corregir y evolucionar tus sistemas con una capacidad mensual acordada, y deja documentado todo lo que construye para que el conocimiento no dependa de nadie en concreto. ### ¿Es mejor contratar a alguien en plantilla o trabajar con un partner tecnológico? Depende del volumen de trabajo técnico y de si puedes dirigirlo. Si tienes trabajo continuo para una persona y alguien que sepa priorizar y revisar lo que hace, contratar tiene sentido. Si el trabajo va por picos, abarca varias especialidades o nadie en la empresa puede dirigirlo, un partner con capacidad definida suele encajar mejor. ### ¿Cómo reduzco la dependencia del freelance que montó nuestras automatizaciones? Empieza por un inventario: qué integraciones existen, dónde están las credenciales, qué hace cada flujo y qué pasa si falla. Pide que esa documentación se escriba mientras la relación sigue activa. Después decide qué se mantiene, qué se rehace y quién será responsable de cada pieza. ### ¿Qué incluye un Technology Partner de FCG Systems? Es una relación mensual con capacidad explícita, en planes Core, Growth y Scale. Según el plan cubre mantenimiento, incidencias, mejoras, nuevas automatizaciones, soporte a lanzamientos, infraestructura y roadmap. No se vende como todo lo que necesites, sino como capacidad priorizada de un equipo tecnológico. ## Servicios relacionados - [Partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/): Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # El problema de muchas automatizaciones no es que fallen: es que nadie sabe que han fallado > Por qué las automatizaciones que fallan sin avisar son más peligrosas que las que se rompen del todo, y cómo hacer observable un flujo de n8n, Make o Zapier. - URL: https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 (15 de septiembre de 2026) - Tema: Automatización · Formato: Opinión · Lectura: 9 min - Palabra clave: automatizaciones que fallan (también: monitorizar automatizaciones n8n, alertas de automatizaciones, errores en Make, idempotencia) Las automatizaciones que fallan en silencio son flujos que dejan de hacer su trabajo sin generar ningún error visible: siguen "funcionando" para la herramienta, pero no crean el contacto, no envían el email o lo duplican. El daño no está en el fallo, sino en el tiempo que pasa hasta que alguien, normalmente un cliente, lo descubre. Esta es una frase que repito mucho: el problema de muchas automatizaciones no es que fallen. Es que nadie sabe que han fallado. Una automatización que se rompe del todo es casi una buena noticia. Todo se para, alguien se queja en una hora y se arregla. La que de verdad hace daño es la que falla a medias durante tres semanas: los leads de un canal que no llegan al CRM, el acceso al curso que no se activa para quien pagó con un método concreto, la factura que se genera dos veces. Nadie ve un error. Solo ves, mucho después, las consecuencias. ## ¿Por qué fallan en silencio las automatizaciones de un negocio digital? Porque casi todas se construyen para el caso feliz. Alguien monta un flujo en n8n, Make o Zapier, lo prueba con dos registros, funciona y pasa a otra cosa. El flujo no tiene logs propios, nadie es responsable de él y nadie ha pensado qué debería pasar cuando algo cambia fuera de la automatización. Es la diferencia entre conectar dos herramientas y [automatizar un proceso de verdad](https://fcgsystems.es/blog/que-es-automatizacion-de-procesos/). Y fuera de la automatización las cosas cambian constantemente. Estos son los fallos silenciosos que más veo: | Tipo de fallo | Qué ocurre | Por qué nadie se entera | |---|---|---| | Credencial caducada | Un token de acceso a una API expira o alguien cambia una contraseña | Según la herramienta, el flujo puede quedar pausado o fallar sin que nadie mire el panel | | Cambio de campo en un formulario | Alguien renombra "Teléfono" por "Móvil" | El flujo sigue ejecutándose, pero envía el campo vacío | | Límite de una API | Un pico de volumen supera el límite de peticiones | Parte de las ejecuciones se descartan o se retrasan | | Webhook que no llega | El sistema de origen no envía el aviso, o lo envía y el destino no responde | Si no hay ejecución, no hay error que registrar | | Ejecución a medias | El flujo crea el contacto pero falla al darle acceso | El registro existe, así que parece que todo fue bien | | Duplicados por reintento | Un reintento repite un paso que ya se había hecho | No hay error: hay dos emails, dos cargos o dos contactos | Fíjate en la columna de la derecha. En la mayoría de casos la herramienta no tiene forma de saber que algo va mal, porque desde su punto de vista no ha pasado nada raro. Por eso "tenemos las notificaciones de errores activadas" no es una respuesta suficiente. ## ¿Cuánto cuesta una automatización que falla sin avisar? No voy a darte una cifra, porque depende por completo de qué proceso toque. Pero sí puedo darte la forma de calcularlo, que es la que usamos en FCG Systems antes de proponer nada: cuántos registros pasan por ese flujo, qué vale cada uno, cuánto tarda de media en detectarse un fallo y cuántas horas cuesta después reconstruir lo que se perdió. En un negocio que vende por lanzamientos o que capta leads a diario, el tiempo de detección es la variable que más pesa. Un flujo que falla un martes y se descubre el viernes no pierde "un error": pierde tres días de registros, de accesos o de seguimiento comercial. Si además esos datos no se pueden reconstruir, el coste ya no es de horas, es de clientes. Hay un coste menos visible: la confianza. Cuando el equipo descubre dos o tres veces que "la automatización no funcionaba", empieza a comprobarlo todo a mano. Y en ese momento has pagado la automatización y sigues haciendo el trabajo manual. ## ¿Qué significa que un sistema sea observable? Un sistema observable es el que te dice, sin que tengas que ir a buscarlo, si está haciendo su trabajo. No es una herramienta concreta. Es una forma de construir que se puede aplicar a un flujo de Make igual que a un servicio propio en un servidor. En FCG Systems tenemos una regla técnica que no negociamos: **un proceso crítico sin logs no está terminado**. Da igual que funcione en la demo. Si no puedes saber qué hizo ayer, no lo puedes operar. Estas son las piezas que hacen observable una automatización: ### Logs que cuentan lo que pasó con cada registro No basta con el historial de ejecuciones de la herramienta, que suele conservarse un tiempo limitado y es difícil de consultar. Un log útil guarda, para cada operación, qué registro entró, qué pasos se completaron, cuál falló y por qué. Puede vivir en una tabla de Postgres, en Airtable o en el sistema que ya uséis, siempre que se pueda consultar. ### Alertas con dueño Una alerta que llega a un canal donde la leen cinco personas no la atiende nadie. Cada alerta tiene que tener un responsable y una severidad. Y tiene que ser poco ruidosa: si salta diez veces al día por cosas sin importancia, en una semana todo el mundo la ignora. ### Reintentos idempotentes Reintentar es necesario, porque las APIs fallan de forma temporal. Pero un reintento sin idempotencia es la receta perfecta para duplicados. La [idempotencia](https://docs.stripe.com/api/idempotent_requests) consiste en que ejecutar dos veces la misma operación produzca el mismo resultado que ejecutarla una: antes de crear, compruebas si ya existe; antes de cobrar, usas un identificador único de operación. ### Reconciliación diaria Es la pieza que más fallos silenciosos destapa y la que menos se implementa. Consiste en comparar, una vez al día, lo que entró en el origen con lo que llegó al destino: formularios recibidos contra contactos creados, pagos contra accesos activados. Si los números no cuadran, hay un fallo aunque ninguna herramienta haya marcado error. ### Cola de errores Cuando algo falla definitivamente, después de los reintentos, el registro no puede desaparecer. Va a una cola de errores (lo que en ingeniería se llama *dead letter queue*): un lugar donde se guarda con su contexto para revisarlo y reprocesarlo cuando se corrija la causa. ### Heartbeat Algunos fallos no producen ejecuciones con error, producen ausencia de ejecuciones. Un heartbeat es una comprobación de vida: si un flujo que normalmente se ejecuta cada hora lleva seis sin hacerlo, salta una alerta. Es la única forma de detectar el webhook que nunca llega. ## ¿No es suficiente con los avisos de error de n8n o Make? Son un buen punto de partida y conviene activarlos. n8n, por ejemplo, permite definir un [flujo de error](https://docs.n8n.io/build/flow-logic/handle-errors-gracefully/) que se ejecuta cuando otro falla, y Make permite añadir rutas de gestión de errores dentro de cada escenario. Pero cubren solo una parte de la tabla de antes: las ejecuciones que la herramienta reconoce como fallidas. No detectan el campo que llega vacío, el webhook que nunca se disparó ni el duplicado que genera un reintento. Para eso necesitas comprobaciones que miren el resultado de negocio, no el estado técnico de la ejecución. Si el fallo concreto es un webhook que no entra en n8n, las causas habituales están en [por qué un webhook de n8n no funciona](https://fcgsystems.es/blog/webhook-n8n-no-funciona/); cómo gestiona los errores cada herramienta, en la comparativa [n8n vs Make](https://fcgsystems.es/blog/n8n-vs-make/). Mi opinión es que el aviso de error de la herramienta es el detector de humo. La reconciliación y el heartbeat son quien comprueba que la casa sigue en pie. ## ¿Qué hacer cuando salta una alerta? Clasificarla. No todo fallo merece despertar a nadie, y tratar todo como urgente es la forma más rápida de que nada lo sea. Usamos la misma clasificación de severidad para automatizaciones que para cualquier otro sistema: | Nivel | Qué significa | Ejemplo en automatización | |---|---|---| | P1 | Sistema crítico caído | Los registros de un lanzamiento no llegan a ningún sitio | | P2 | Función importante degradada | Los leads llegan al CRM, pero sin asignar a ningún comercial | | P3 | Bug no crítico | Un campo secundario llega con formato incorrecto | | P4 | Mejora o petición | Añadir un dato nuevo a la notificación del equipo | Una aclaración honesta: los tiempos de respuesta dependen del acuerdo con cada negocio. No existe soporte instantáneo por defecto, y quien lo promete sin contrato y sin capacidad reservada suele acabar incumpliéndolo. Lo que sí debe existir siempre es claridad sobre quién atiende cada nivel. ## ¿Quién es responsable de una automatización cuando falla? Esta pregunta incomoda, y por eso es importante. En muchos negocios la respuesta real es "la persona que la montó", que a veces ya no está o que tiene otras veinte cosas. Cuando el conocimiento de un flujo crítico vive en la cabeza de una sola persona, el fallo silencioso se convierte en fallo permanente. Hablo de ese problema en el artículo sobre [la dependencia de una persona y cómo tener capacidad técnica sin un departamento](https://fcgsystems.es/blog/dependencia-de-una-persona-capacidad-tecnica/). El ownership de una automatización incluye tres cosas: saber que existe y qué hace (documentación), saber cuándo falla (observabilidad) y tener capacidad para arreglarla (mantenimiento). Si falta una, el flujo está huérfano aunque funcione. Esto conecta con una idea más amplia: las automatizaciones no son piezas sueltas, son parte de un sistema. Si quieres ver cómo encajan con el software, los datos y la infraestructura, lo explico en la guía de [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/). Y si tus fallos se concentran en el paso del formulario al comercial, te interesa el artículo sobre [leads que se pierden y Excel como CRM](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). ## Checklist: ¿tus automatizaciones fallan en silencio? Repasa tus flujos críticos con estas preguntas. Cada "no" es un punto ciego. - ¿Tienes una lista de todas las automatizaciones activas, con qué hace cada una y quién es su responsable? - ¿Sabes cuáles son críticas, es decir, cuáles cuestan dinero o clientes si fallan? - ¿Cada flujo crítico guarda un log consultable por registro, no solo el historial de la herramienta? - ¿Las alertas de error llegan a una persona concreta, con severidad definida? - ¿Los reintentos son seguros, o un reintento puede duplicar contactos, emails o cobros? - ¿Comparas cada día lo que entra en el origen con lo que llega al destino? - ¿Los registros que fallan definitivamente van a una cola de errores en lugar de perderse? - ¿Tienes alertas cuando un flujo lleva demasiado tiempo sin ejecutarse? - ¿Sabes qué credenciales y tokens caducan, y cuándo? - ¿Alguien revisa qué automatizaciones se rompen si cambia un formulario o un campo del CRM? - ¿Las credenciales están gestionadas en un gestor de secretos y no pegadas en un documento o un chat? - ¿Podrías reconstruir los datos de la última semana si un flujo hubiera fallado sin avisar? ## ¿Por dónde empiezo si mis automatizaciones no son observables? Por las críticas, no por todas. Elige los dos o tres flujos que más te dolería que fallaran (captación, pagos y accesos suelen estar ahí), y añade primero la reconciliación diaria y las alertas con dueño. Son las dos piezas que más fallos silenciosos destapan con menos esfuerzo. Si prefieres que lo hagamos nosotros, en FCG Systems lo resolvemos como parte de nuestro servicio de [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/): un Automation Sprint de 1 a 3 semanas para rehacer o reforzar un flujo concreto con logs, pruebas, documentación y handoff. Cuando la fiabilidad depende también de servidores, bases de datos o backups, lo conectamos con [infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/). Si tienes la sospecha de que algo lleva tiempo fallando sin que nadie lo vea, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y lo miramos juntos. ## Preguntas frecuentes ### ¿Cómo sé si una automatización está fallando sin avisar? La forma más fiable es comparar lo que entra con lo que sale. Si cada día cuentas los registros de origen y los que llegaron al destino, cualquier diferencia te avisa aunque la herramienta no haya marcado ningún error. A eso se suma una alerta cuando un flujo lleva demasiado tiempo sin ejecutarse. ### ¿n8n, Make o Zapier tienen alertas de errores? Sí, las tres permiten enterarte de ejecuciones con error, por ejemplo n8n con flujos de error dedicados. El problema es que solo detectan lo que la herramienta reconoce como fallo. Un formulario que cambia un campo o un webhook que nunca llega no generan un error visible, y por eso hacen falta comprobaciones propias. ### ¿Qué significa que una automatización sea idempotente? Que puedes ejecutarla dos veces con el mismo dato sin provocar efectos duplicados. Si un reintento vuelve a crear el mismo contacto o a enviar el mismo email, el flujo no es idempotente. Se consigue comprobando si el registro ya existe o usando un identificador único por operación. ### ¿Hace falta rehacer todas las automatizaciones para hacerlas observables? Normalmente no. Lo habitual es empezar por los procesos críticos, los que cuestan dinero o clientes si fallan, y añadirles logs, alertas con responsable, reintentos seguros y una reconciliación diaria. El resto puede esperar a una segunda fase. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/): Servidores, despliegues, backups y alertas para que tu operación no se caiga y sea tuya. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Leads que se pierden: del formulario al comercial sin un Excel de por medio > Por qué se pierden leads entre formulario, WhatsApp y comercial, cuándo un Excel deja de servir como CRM y cómo automatizar la asignación sin parar las ventas. - URL: https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 (15 de septiembre de 2026) - Tema: Automatización · Formato: Antes y después · Lectura: 9 min - Palabra clave: automatización de leads para infoproductores (también: CRM para academias online, Excel como CRM, lead routing, asignación de leads) La automatización de leads para infoproductores consiste en que cada registro entre en una única base de datos con su origen, se deduplique, se asigne a un responsable por reglas y dispare el seguimiento sin intervención manual. El objetivo no es tener más herramientas, sino que ningún lead dependa de que alguien revise una hoja a tiempo. Lo digo porque es un patrón habitual en academias online y negocios de lanzamientos: el funnel capta bien, pero entre el formulario y la primera llamada hay un tramo que nadie ha diseñado. Ese tramo suele ser un Excel, un grupo de WhatsApp del equipo y mucha buena voluntad. ## ¿Dónde se pierden los leads exactamente? Casi nunca se pierden en la captación. Se pierden en las costuras entre herramientas. Imagina una academia que capta alumnos con un formulario de Tally, agenda llamadas con Calendly y hace el seguimiento por WhatsApp. Cada pieza funciona por separado. El problema está en lo que pasa entre ellas: - **Del formulario a la hoja.** Alguien exporta los registros, o una automatización los copia a Google Sheets. Si la automatización falla un martes por la noche, nadie se entera hasta que un comercial pregunta por qué no le llegan contactos. - **De la hoja al comercial.** El reparto se hace a mano: "tú coges de la fila 200 a la 260". Si dos setters leen la hoja a la vez, los dos llaman al mismo lead. Si uno está de vacaciones, sus filas se quedan sin tocar. - **Del comercial a la agenda.** El lead reserva en Calendly con otro email o con el móvil de su pareja. La reserva no se vincula a la fila original y aparece como un contacto nuevo, sin historial. - **De la agenda a WhatsApp.** La conversación real ocurre en el móvil del comercial. Lo que se dijo no vuelve a ninguna parte. Si ese comercial se va, la conversación se va con él. Ninguno de estos puntos parece grave por separado. Juntos explican por qué un lead caliente llega al comercial dos días tarde y sin saber de qué anuncio venía. ## ¿Por qué un Excel funciona como CRM al principio y después deja de hacerlo? Porque al principio el Excel no es un CRM: es una lista que gestiona una persona que lo tiene todo en la cabeza. Mientras esa persona sea la misma que capta, llama y cierra, la hoja basta. El contexto vive en su memoria. El Excel se rompe cuando pasa alguna de estas cosas: 1. **Entra una segunda persona a trabajar los leads.** A partir de ahí hacen falta reglas de propiedad (quién es el responsable de cada lead) y una hoja no las impone. Solo las sugiere. 2. **Los registros llegan por varios canales a la vez.** YouTube, Instagram, Telegram, anuncios y email. La misma persona se registra dos veces y aparece en dos filas, cada una con un origen distinto. 3. **Necesitas saber qué fuente trae ventas, no solo registros.** La columna "origen" se rellena a mano, cuando se rellena, y el dato deja de ser comparable. Este problema tiene su propio artículo: [por qué GA4, Meta y el CRM nunca dan la misma cifra](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/). 4. **El seguimiento depende de fechas.** "Llamar en tres días si no ha reservado." Una hoja no avisa. Alguien tiene que acordarse. 5. **Un error cuesta dinero.** Durante un lanzamiento, un lead que no se contacta en la ventana de apertura no se recupera la semana siguiente. ### ¿Cuándo sí basta con una hoja de cálculo? No quiero demonizar la hoja. Si vendes a pocas personas al mes, trabajas solo y cada lead entra por un único canal, montar un CRM con automatizaciones es gastar tiempo en la herramienta en lugar de en vender. Mi regla práctica: la hoja basta mientras puedas responder de memoria a "¿quién ha hablado con este lead y qué le ha dicho?". El día que tengas que preguntarlo en el grupo del equipo, ya no basta. ## Antes y después: cómo cambia el circuito de un lead Esta es la comparación que uso en una primera sesión. Los pasos son los mismos. Lo que cambia es quién los ejecuta y dónde queda el dato. | Paso | Antes (formularios, hoja y WhatsApp sueltos) | Después (sistema con fuente de verdad) | |---|---|---| | Registro | El formulario guarda la respuesta en su propia herramienta | El registro entra en una base de datos común con fuente, campaña y fecha | | Duplicados | Se detectan (o no) al ver dos filas parecidas | Se detectan por email y teléfono normalizados antes de asignar | | Asignación | Reparto manual por filas o por turnos en el grupo | Regla automática por capacidad, producto o canal, con un único responsable | | Aviso al comercial | "Mirad la hoja" | Notificación con el contexto del lead: origen, respuestas y paso del funnel | | Llamada | Reserva en la agenda sin vínculo con el registro | La reserva se vincula al lead y actualiza su etapa | | Seguimiento | Depende de la memoria de cada comercial | Tareas y recordatorios según la etapa y el tiempo sin respuesta | | Reporting | Alguien monta el informe a mano el lunes | Dashboard que lee de la misma base de datos | La fila que más impacto tiene no es la más vistosa. Es la de duplicados. En [nuestra infraestructura para lanzamientos con miles de registros](https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/) la regla fue deduplicar antes de asignar, nunca después: deshacer un reparto lleno de duplicados cuesta mucho más que evitarlo. ## ¿Qué piezas necesita un sistema de gestión de leads para una academia online? Un CRM para academias online no es una marca de software concreta. Es un conjunto de cinco piezas que pueden vivir en herramientas distintas, siempre que estén conectadas y haya una que mande. ### 1. Una fuente de verdad para el lead Un único sitio donde está el registro "bueno" de cada persona. Puede ser Airtable, un CRM comercial o una base de datos Postgres. Lo que importa es la regla: si el dato de un lead no coincide entre dos herramientas, gana la fuente de verdad y las demás se corrigen desde ella, no al revés. ### 2. Captura del origen en el primer toque La fuente y la campaña se guardan en el momento del registro, desde los parámetros UTM de la URL, y viajan con el lead hasta la venta. Si el origen se añade después, a mano, ya no sirve para decidir dónde invertir. ### 3. Deduplicación con criterio Email en minúsculas, teléfono con prefijo y sin espacios, y una regla clara sobre qué hacer cuando la misma persona llega dos veces: se fusiona y se conserva el primer origen, se conserva el último, o se guardan los dos. No hay respuesta universal, pero tiene que haber una respuesta escrita. ### 4. Lead routing con propietario único La asignación de leads decide quién es el responsable de cada contacto. Las reglas típicas: - **Por turnos** (round robin), cuando el equipo es homogéneo. - **Por capacidad**, cuando cada persona puede asumir un volumen distinto. - **Por producto o idioma**, cuando no todos venden lo mismo. - **Por origen**, cuando un canal necesita un tratamiento especial. Sea cual sea la regla, el sistema tiene que dejar escrito el propietario y bloquear que otra persona lo trabaje sin reasignarlo. ### 5. Seguimiento que no depende de la memoria Etapas reales de la venta (registro, preinscripción, llamada agendada, resultado) y tareas que se crean solas: si un lead lleva un tiempo definido sin reservar, se genera un recordatorio para su responsable. WhatsApp entra en el flujo como un canal más del seguimiento, no como una conversación suelta en un móvil. Cuándo compensa pasar de la app a la API oficial para conseguirlo lo explico en [WhatsApp Business o API oficial](https://fcgsystems.es/blog/whatsapp-business-api/). ## ¿Qué cambia cuando el circuito está bien montado? El ejemplo más claro que puedo enseñar es el [caso del funnel, tracking y CRM de una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/). Conectamos formularios de Tally, una base común en Airtable, reservas de Calendly vinculadas al lead, asignación de cada llamada a su comercial y dashboards por etapa y por fuente. Durante el proyecto, las tres etapas medidas del funnel mejoraron: el opt-in pasó del 70,81 % al 77,61 %, la preinscripción del 36,85 % al 44,72 % y las llamadas del 9,89 % al 16,22 %. Conviene leer esas cifras con el matiz con el que las publicamos: se midieron con el funnel en marcha y las campañas activas, así que no se atribuyen a una sola pieza del sistema. Lo que sí puedo decir es dónde estuvo el mayor salto: en la última etapa. Que el lead llegue al comercial a tiempo y con contexto importa tanto como captarlo. ## ¿Cómo migrar de un Excel a un sistema sin parar las ventas? Esta es la pregunta que más frena a los equipos, y con razón. Nadie quiere tocar el circuito comercial en mitad de una campaña. La forma de hacerlo sin riesgo es por capas y en paralelo. 1. **Congela el formato de la hoja actual.** Antes de migrar, decide qué columnas son de verdad necesarias. La mitad suelen ser notas que nadie lee. 2. **Monta la fuente de verdad en paralelo.** Los registros nuevos empiezan a entrar en la base de datos nueva y, a la vez, se siguen escribiendo en la hoja. El equipo no cambia nada todavía. 3. **Compara durante unos días.** Si el número de registros de las dos fuentes no coincide, hay un fallo en la captura. Mejor encontrarlo ahora que en pleno lanzamiento. 4. **Importa el histórico con limpieza.** Deduplica, normaliza teléfonos y emails, y marca los leads antiguos sin origen como "origen desconocido" en lugar de inventarles uno. 5. **Activa la asignación automática en un solo canal.** Empieza por el canal con más volumen o con más errores, no por todos. 6. **Mueve al equipo cuando el sistema ya ha demostrado que funciona.** El día del cambio, la hoja pasa a solo lectura. Mantenerla editable "por si acaso" crea dos fuentes de verdad. 7. **Pon logs y alertas antes de retirar la hoja.** Un proceso crítico sin logs no está terminado. Si la entrada de leads se para, alguien tiene que saberlo en minutos, no el lunes. Lo explico con más detalle en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). Si todavía no tenéis CRM, qué exigirle y cuándo compensa uno a medida lo explico en [CRM para pymes y negocios digitales](https://fcgsystems.es/blog/crm-para-pymes-saas-o-a-medida/). Con n8n o Make esto se puede montar sin escribir una aplicación desde cero (en [n8n vs Make](https://fcgsystems.es/blog/n8n-vs-make/) comparo cuál encaja según el volumen y el equipo). La herramienta se elige según el sistema, no al revés: si el volumen o las reglas lo piden, la base de datos y la asignación pasan a código propio. ## Checklist para revisar tu circuito de leads Si quieres saber en qué punto estás, repasa esta lista con tu equipo comercial delante: - Existe un único sitio donde está el registro bueno de cada lead, y todo el equipo sabe cuál es. - Cada registro guarda su fuente y su campaña en el momento de entrar, sin intervención manual. - Los duplicados se detectan antes de asignar, con email y teléfono normalizados. - Cada lead tiene un único responsable asignado por una regla que está escrita. - El comercial recibe el lead con contexto: origen, respuestas del formulario y etapa. - Las reservas de la agenda se vinculan al lead que ya existe, no crean uno nuevo. - Las conversaciones de WhatsApp dejan rastro en el seguimiento. - Hay tareas automáticas para los leads que llevan tiempo sin avanzar. - Si la entrada de registros se detiene, alguien recibe una alerta. - El dashboard comercial lee de la misma base de datos que usa el equipo. - Si mañana duplicaseis el volumen, el reparto seguiría funcionando sin que nadie lo haga a mano. Si tachas menos de la mitad, el problema no es de herramientas: es que falta un sistema entre ellas. Esa es la capa que describo en la guía sobre [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/), y la que construimos en FCG Systems desde [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/) y [atribución de leads hasta el CRM](https://fcgsystems.es/servicios/datos-tracking-analitica/). ## ¿Por dónde empezar esta semana? No empieces comprando un CRM. Empieza dibujando el recorrido de un lead real, desde el anuncio hasta la llamada, y marca cada punto donde alguien copia, reparte o recuerda algo a mano. Esos puntos son tu lista de trabajo, ordenada por lo que cuesta cada error. Si al hacerlo ves que el circuito necesita algo más que un par de conexiones, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/). Te respondo con una primera lectura del problema y con lo que construiría primero. ## Preguntas frecuentes ### ¿Puedo seguir usando Google Sheets como CRM? Sí, mientras una sola persona gestione los leads, el volumen sea bajo y no necesites saber de qué fuente viene cada venta. Cuando entran varios comerciales o setters, o los registros llegan por varios canales a la vez, la hoja deja de ser fiable porque nadie controla quién toca cada fila ni qué pasó antes. ### ¿Qué es el lead routing? Es la regla que decide automáticamente a qué persona del equipo comercial se asigna cada lead nuevo. Puede repartir por turnos, por capacidad, por idioma, por producto o por origen, y debe dejar registrado quién es el responsable para que nadie más contacte a ese lead. ### ¿Hace falta cambiar de herramientas para automatizar la gestión de leads? No siempre. Muchas veces el problema se resuelve conectando bien las herramientas que ya usáis, como Tally, Calendly o WhatsApp, a una base de datos común. Solo compensa cambiar una pieza cuando no deja sacar los datos o no permite reglas de asignación fiables. ### ¿Cuánto se tarda en montar un sistema de asignación y seguimiento de leads? Un circuito concreto de captación, asignación y seguimiento suele encajar en un Automation Sprint de 1 a 3 semanas. Si además hace falta una base de datos propia, un panel comercial y dashboards, pasa a ser un Business System Build de 3 a 8 semanas. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. ## Casos relacionados - [Funnel, tracking y CRM conectados en una academia online](https://fcgsystems.es/casos/sistema-comercial-y-funnel-academia-online/): Formularios, tracking, CRM y agenda comercial conectados en un solo sistema, con el origen de cada lead a la vista. Las tres etapas del funnel mejoraron. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # n8n precios: Cloud o self-hosted, qué cuesta de verdad y qué necesitas para operarlo en producción > Precios de n8n Cloud, qué cuenta como ejecución, cuánto cuesta de verdad n8n self-hosted y qué necesita en producción: Postgres, clave de cifrado y backups. - URL: https://fcgsystems.es/blog/n8n-precios-cloud-self-hosted/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 · Actualizado: 2026-09-16 (16 de septiembre de 2026) - Tema: Infraestructura · Formato: Arquitectura · Lectura: 9 min - Palabra clave: n8n precios (también: n8n pricing, n8n self hosted, n8n cloud, n8n docker, n8n es gratis, vps n8n) **n8n Cloud cuesta desde 20 € al mes con facturación anual (plan Starter, 2.500 ejecuciones) y n8n self-hosted en su edición Community no tiene coste de licencia.** La diferencia real no está en la licencia: con Cloud pagas por ejecuciones y n8n opera la instalación; con self-hosted pagas servidor y, sobre todo, el tiempo de quien lo instala, actualiza, hace backups y responde cuando falla. Esta guía compara los dos modelos con los precios publicados, explica cuándo compensa cada uno y, si eliges autoalojarlo, qué necesita n8n para sostener captación, pagos o accesos sin sustos. Termina con un checklist de producción que puedes copiar. Parte de que ya sabes [en qué consiste n8n](https://fcgsystems.es/blog/que-es-n8n/); aquí solo se habla de dinero y de operación. ## ¿Cuánto cuesta n8n Cloud? Datos de la [página de precios de n8n](https://n8n.io/pricing/) (consultada en septiembre de 2026). Los importes publicados son mensuales con facturación anual: | Plan | Precio | Ejecuciones | Ejecuciones simultáneas | Dónde se ejecuta | |---|---|---|---|---| | Starter | 20 €/mes, facturación anual | 2.500 al mes | 5 | Cloud (alojado por n8n) | | Pro | 50 €/mes, facturación anual | 10.000 al mes | 20 | Cloud (alojado por n8n) | | Business | 667 €/mes, facturación anual | 40.000 al mes | — | Self-hosted con licencia | | Enterprise | Bajo consulta | A medida | 200 o más | Cloud o self-hosted | | Community | Sin licencia | Sin cuota de ejecuciones | Depende de tu servidor | Self-hosted | Tres detalles de esa misma página que cambian la cuenta: - **Una ejecución es una ejecución completa del workflow**, da igual cuántos pasos tenga. Por eso un flujo largo no encarece la factura; uno que se dispara muchas veces sí. - **El historial también tiene límite en Cloud**: como máximo 2.500 ejecuciones guardadas en Starter y 25.000 en Pro, con 7 y 30 días de retención de logs respectivamente. Si necesitas saber qué pasó con cada registro hace tres meses, guárdalo en tu propia tabla. - **Si superas la cuota en Business o Enterprise**, su FAQ indica que los flujos siguen ejecutándose y pueden aplicarse cargos por exceso. Para Starter y Pro, revisa las condiciones de la página antes de un lanzamiento. La prueba de n8n Cloud dura 14 días con funciones de Pro, según su [guía para elegir cómo usar n8n](https://docs.n8n.io/choose-how-to-use-n8n/) (consultada en septiembre de 2026), y la página de precios indica que no pide tarjeta. ## ¿Cuánto cuesta de verdad n8n self-hosted? La licencia de la edición Community es gratuita y, según esa misma guía, incluye casi todas las funciones; SSO, entornos, proyectos, secretos externos, log streaming o control de versiones con Git requieren un plan de pago. El coste está en otro sitio: | Coste | Cloud | Self-hosted (Community) | |---|---|---| | Licencia | Cuota mensual por plan | Sin coste | | Servidor y base de datos | Incluido | Lo pagas y lo dimensionas tú | | Instalación, actualizaciones y seguridad | Las gestiona n8n | Tu responsabilidad | | Backups y restauración | Gestión de n8n | Tu responsabilidad, incluida la clave de cifrado | | Monitorización y respuesta a caídas | Parte del servicio | Tu responsabilidad | | Límite de ejecuciones | Por plan | El que aguante tu infraestructura | No hay una cifra universal para la columna de la derecha porque depende de quién hace ese trabajo y a qué coste. La pregunta útil es otra: si mañana el servidor falla un domingo, ¿quién lo restaura y en cuánto tiempo? ## ¿Cuándo compensa n8n Cloud y cuándo self-hosted? La [documentación de n8n](https://docs.n8n.io/choose-how-to-use-n8n/) (consultada en septiembre de 2026) plantea la decisión así: Cloud no requiere conocimientos técnicos ni mantenimiento; self-hosted requiere instalar, configurar y mantener la infraestructura, a cambio de control total. | Tu situación | Opción razonable | |---|---| | Nadie en el equipo puede mantener un servidor | n8n Cloud | | Quieres empezar rápido y validar flujos | n8n Cloud | | Tus flujos se disparan pocas veces pero tienen muchos pasos | n8n Cloud suele encajar bien con su modelo por ejecución | | Necesitas que los datos no salgan de tu infraestructura | Self-hosted | | Tus flujos se ejecutan muchísimas veces al mes y la cuota de Cloud se queda corta | Self-hosted | | Tienes (o contratas) capacidad técnica con responsable claro | Self-hosted | Si todavía estás decidiendo entre n8n y otras herramientas, lo comparamos en [n8n vs Make y alternativas a n8n](https://fcgsystems.es/blog/n8n-vs-make/). El resto de esta guía es para quien elige autoalojarlo. ## ¿Qué arquitectura mínima necesita n8n en producción? No hace falta nada exótico, pero cada pieza tiene un motivo: | Pieza | Para qué | Qué pasa si falta | |---|---|---| | Servidor dedicado a servicios internos (VPS o similar) | Aislar n8n de la web y de otros proyectos | Un pico en otro servicio tumba tus automatizaciones | | Docker con versión fijada | Instalación reproducible y actualizaciones controladas | Una actualización automática cambia comportamiento sin aviso | | Reverse proxy con HTTPS | Exponer webhooks y editor de forma segura | Servicios externos rechazan el webhook o el tráfico va sin cifrar | | PostgreSQL | Base de datos con backups y restauración estándar | Todo depende de un fichero SQLite que hay que copiar y restaurar con más cuidado | | Backups fuera del servidor | Recuperarte si el servidor desaparece | Pierdes flujos, credenciales e historial a la vez | | Monitorización y alertas | Enterarte de caídas y fallos | Te enteras por un cliente | Según la documentación sobre [la base de datos de n8n](https://docs.n8n.io/deploy/host-n8n/configure-n8n/choose-n8ns-database/) (consultada en septiembre de 2026), la instalación autoalojada usa SQLite por defecto y admite PostgreSQL. Para procesos críticos, Postgres es la opción que recomendamos por operación: backups y restauraciones con herramientas conocidas. ## ¿Qué variables de configuración son críticas? ### La clave de cifrado n8n cifra las credenciales antes de guardarlas en la base de datos. Según la guía para [definir una clave de cifrado propia](https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/set-a-custom-encryption-key/) (consultada en septiembre de 2026), n8n genera una clave aleatoria en el primer arranque y la guarda en la carpeta `~/.n8n`; puedes fijar la tuya con `N8N_ENCRYPTION_KEY`, y en modo cola tiene que estar definida en todos los workers. En la práctica: define la clave tú, guárdala en un gestor de secretos y trátala como parte del backup. Una base de datos restaurada sin su clave no te devuelve credenciales utilizables. ### La URL de los webhooks detrás de un proxy Detrás de un reverse proxy, n8n no puede deducir su URL pública. La documentación sobre [webhooks con reverse proxy](https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/configure-webhook-urls-with-reverse-proxy/) (consultada en septiembre de 2026) indica que hay que fijar `N8N_WEBHOOK_URL` con la URL pública (sustituye a `WEBHOOK_URL`, obsoleta desde n8n 2.35.0), poner `N8N_PROXY_HOPS=1` y reenviar las cabeceras `X-Forwarded-For`, `X-Forwarded-Host` y `X-Forwarded-Proto` desde el proxy. Si no, n8n puede registrar en servicios externos una URL interna que nadie puede alcanzar. ### La poda del historial de ejecuciones Cada ejecución guarda datos, y eso hace crecer la base de datos. Según la referencia de [variables de ejecuciones](https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/executions/) (consultada en septiembre de 2026), por defecto la poda está activada (`EXECUTIONS_DATA_PRUNE=true`), se borran las ejecuciones con más de 336 horas (`EXECUTIONS_DATA_MAX_AGE`) y se conservan como máximo 10.000 (`EXECUTIONS_DATA_PRUNE_MAX_COUNT`). Revisa que nadie la haya desactivado y decide si necesitas guardar las ejecuciones con éxito o solo las fallidas. Ojo: el historial de ejecuciones no es un log de negocio. Si necesitas saber qué pasó con cada registro dentro de seis meses, guárdalo en tu propia tabla. ## ¿Cómo se hace un backup de n8n que sirva? Un backup útil tiene tres partes y una prueba: 1. **Base de datos completa**, con copias periódicas y retención definida. 2. **Clave de cifrado**, guardada aparte y con acceso restringido. 3. **Configuración de despliegue**: variables de entorno (sin secretos en texto plano), fichero de Docker Compose o equivalente y configuración del proxy. 4. **Restauración probada** en un servidor limpio, con los flujos críticos ejecutándose. Las copias van fuera del servidor que protegen. Aplicamos dos reglas en todos los proyectos: si un dato no puede reconstruirse, necesita backup, y un backup que nunca se ha restaurado no cuenta. Como red adicional, exportar los workflows periódicamente con las opciones de [exportación e importación](https://docs.n8n.io/build/manage-workflows/export-and-import/) (consultado en septiembre de 2026) permite versionarlos, pero no sustituye al backup de la base de datos. ## ¿Cómo se actualiza n8n sin romper flujos? 1. Fija la versión en la configuración; nada de `latest` en producción. 2. Lee las notas de versión buscando cambios que afecten a nodos que usas. 3. Haz backup de base de datos y clave justo antes. 4. Prueba la nueva versión en una copia con los flujos críticos. 5. Actualiza producción en una ventana tranquila, nunca en mitad de un lanzamiento. 6. Comprueba ejecuciones reales después y ten documentada la vuelta a la versión anterior. ## ¿Cómo te enteras de que algo ha fallado? Hay dos niveles: - **La instancia:** comprobación externa de que el editor y los webhooks responden, espacio en disco, memoria y estado de la base de datos. - **Los flujos:** un [error workflow](https://docs.n8n.io/build/flow-logic/handle-errors-gracefully/) (consultado en septiembre de 2026) que avise a una persona concreta cuando un flujo crítico falla, y un heartbeat para los flujos que deberían ejecutarse con regularidad y dejan de hacerlo. El error workflow solo detecta lo que n8n reconoce como error. El webhook que nunca llega o el campo que viene vacío necesitan comprobaciones propias; lo explicamos en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ## ¿Qué seguridad mínima necesita? - Editor accesible solo por HTTPS, con usuarios individuales y 2FA activado para cada persona. - Nada de cuentas compartidas ni credenciales pegadas en notas de un flujo. - Servidor con actualizaciones de sistema, cortafuegos y solo los puertos necesarios expuestos. - Auditoría periódica con la [auditoría de seguridad de n8n](https://docs.n8n.io/deploy/host-n8n/configure-n8n/security/run-security-audits/) (consultada en septiembre de 2026), que se lanza con `n8n audit`, por API o desde el propio nodo de n8n. ## Errores comunes con n8n autoalojado - **Perder la clave de cifrado** al recrear el contenedor sin volumen persistente o sin haberla definido. - **Dejar SQLite creciendo** sin revisar poda ni espacio en disco. - **Webhooks con localhost o IP interna** registrados en servicios externos por no fijar la URL pública. - **Backups que nunca se han restaurado**, o guardados en el mismo servidor. - **Actualizar sin probar**, a veces con la etiqueta `latest`, justo antes de una campaña. - **Una sola persona sabe cómo está montado.** Si se va, nadie puede tocarlo. Es el problema que tratamos en [cuando todo depende de una persona](https://fcgsystems.es/blog/dependencia-de-una-persona-capacidad-tecnica/). ## Checklist de producción para n8n self-hosted Cópialo y márcalo con tu equipo: - Hay un responsable con nombre de la instancia de n8n. - La versión de n8n está fijada y las actualizaciones siguen un procedimiento. - La base de datos es PostgreSQL, o hay una decisión documentada de seguir con SQLite. - `N8N_ENCRYPTION_KEY` está definida y guardada en un gestor de secretos. - El editor y los webhooks van por HTTPS detrás de un reverse proxy. - `N8N_WEBHOOK_URL` apunta a la URL pública y `N8N_PROXY_HOPS` está configurado. - La poda de ejecuciones está activa y el espacio en disco se vigila. - Hay backups automáticos de base de datos fuera del servidor. - Se ha probado a restaurar en un servidor limpio en los últimos meses. - Los flujos críticos tienen error workflow con aviso a una persona. - Los flujos periódicos tienen heartbeat. - Cada usuario tiene cuenta propia con 2FA. - Se ejecuta la auditoría de seguridad de n8n periódicamente. - Existe documentación de la instalación y de cómo volver a la versión anterior. ## ¿Cuándo conviene delegarlo? Si n8n sostiene la captación de leads, los pagos o los accesos de tu academia, la instancia ya es infraestructura crítica. Autoalojarlo tiene sentido cuando alguien puede asumir su operación con criterio; si esa persona no existe o está saturada, el ahorro en licencia sale caro el día que falla. En FCG Systems montamos y operamos instancias de n8n dentro del servicio de [infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/): servidor, Docker, proxy, Postgres, backups con restauración probada, monitorización y documentación. Y si lo que necesitas es reforzar los propios flujos, lo hacemos [automatizando el proceso de punta a punta](https://fcgsystems.es/servicios/automatizacion-de-procesos/). Para ver dónde encaja la infraestructura dentro de toda la operación, tienes la guía de [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/). Y si tu n8n funciona pero no sabrías restaurarlo mañana, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y lo revisamos. ## Preguntas frecuentes ### ¿Cuánto cuesta n8n? Según su página de precios, consultada en septiembre de 2026, n8n Cloud Starter cuesta 20 € al mes con facturación anual e incluye 2.500 ejecuciones, y Pro 50 € al mes con facturación anual y 10.000 ejecuciones. Business, 667 € al mes con facturación anual, es autoalojado con licencia. La edición Community autoalojada no tiene coste de licencia. ### ¿n8n es gratis si lo instalo en mi servidor? La edición Community es gratuita y, según la documentación de n8n, incluye casi todas las funciones. Algunas, como SSO, entornos o log streaming, requieren plan de pago. Lo que no es gratis es operarlo: servidor, backups, actualizaciones y el tiempo de quien lo mantiene. ### ¿Qué cuenta como una ejecución en n8n? Una ejecución es una ejecución completa del workflow, sin importar cuántos pasos tenga ni cuántos datos procese. Un flujo de veinte nodos que se dispara una vez cuenta como una ejecución, igual que uno de dos nodos. ### ¿Qué VPS necesito para n8n con Docker? Depende del número de flujos, de cuántos se ejecutan a la vez, del tamaño de los datos que mueven y de si guardas mucho historial de ejecuciones. Más importante que el tamaño inicial es poder medir consumo, ampliar sin reinstalar y tener la base de datos con backup fuera del propio servidor. ### ¿Qué pasa si pierdo la clave de cifrado de n8n? n8n usa esa clave para cifrar las credenciales antes de guardarlas en la base de datos. Sin la clave original, las credenciales almacenadas no se pueden usar y habría que volver a introducirlas todas. Por eso la clave se guarda como un secreto y se incluye en el plan de backup. ## Servicios relacionados - [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/): Servidores, despliegues, backups y alertas para que tu operación no se caiga y sea tuya. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # n8n vs Make y otras alternativas a n8n: cuál elegir para un negocio digital que ya tiene volumen > n8n vs Make y otras alternativas a n8n para un negocio digital: coste por ejecución o por crédito, gestión de errores, servidor propio y cuándo elegir cada una. - URL: https://fcgsystems.es/blog/n8n-vs-make/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 · Actualizado: 2026-09-16 (16 de septiembre de 2026) - Tema: Automatización · Formato: Breakdown · Lectura: 7 min - Palabra clave: n8n vs make (también: make vs n8n, alternativas a n8n, n8n alternatives, diferencias entre n8n y make, zapier vs n8n) **n8n y Make resuelven lo mismo, conectar aplicaciones y automatizar procesos, pero cobran y se operan de forma muy distinta.** Make cobra por cada acción que ejecuta un módulo; n8n cobra por ejecución completa del flujo y, además, puede instalarse en tu propio servidor. Para un negocio digital con volumen, la elección depende de cuántos pasos tienen tus flujos, cuántas veces corren y quién va a mantenerlos. Casi todas las comparativas se quedan en la interfaz y la lista de integraciones. Aquí la comparación se hace desde el sistema: coste real según tu volumen, qué pasa cuando algo falla y qué responsabilidad técnica asumes con cada opción. Si todavía no has visto la herramienta por dentro, empieza por [qué es n8n y para qué se usa](https://fcgsystems.es/blog/que-es-n8n/). ## ¿Qué diferencias hay entre n8n y Make? | Aspecto | n8n | Make | |---|---|---| | Unidad de coste | Ejecución completa del workflow, sin importar cuántos pasos tenga | Crédito por operación de módulo | | Dónde se ejecuta | n8n Cloud o autoalojado en tu servidor | En la nube de Make | | Opción gratuita | Edición Community autoalojada | Plan gratuito con créditos limitados | | Gestión de errores | Error workflow que se dispara cuando otro flujo falla | Manejadores de error y ejecuciones incompletas (desactivadas por defecto) | | Perfil del equipo | Cómodo con APIs, JSON y algo de código | Más visual, curva más suave | | Mantenimiento | En Cloud lo gestiona n8n; autoalojado, tú | Lo gestiona Make | | Datos | Autoalojado, los datos no salen de tu infraestructura | Los datos pasan por la nube de Make | Las dos tienen integraciones de sobra para lo habitual en un negocio digital: formularios, CRM, email, pagos, hojas de cálculo y webhooks. La diferencia que de verdad pesa con volumen está en las tres primeras filas. ## ¿Cómo se compara el coste de n8n y Make? Los modelos de cobro son distintos, y eso cambia el resultado según la forma de tus flujos: - **n8n:** según su [página de precios](https://n8n.io/pricing/) (consultada en septiembre de 2026), una ejecución es una ejecución completa del workflow, da igual cuántos pasos tenga o cuántos datos procese. El plan Starter de n8n Cloud cuesta 20 € al mes con facturación anual e incluye 2.500 ejecuciones; el plan Pro, 50 € al mes con facturación anual y 10.000 ejecuciones. La edición Community autoalojada no tiene coste de licencia. - **Make:** según su [centro de ayuda sobre créditos](https://help.make.com/credits) (consultado en septiembre de 2026), en aplicaciones que no son de IA una operación equivale a un crédito. Cada módulo que lee, crea, actualiza o transforma datos consume. Los precios de cada plan están en la web de Make y conviene revisarlos con tu volumen real. ### Un ejemplo con aritmética, no con facturas Imagina un flujo de 8 módulos: recibe el registro de un formulario, normaliza los datos, busca duplicados en el CRM, crea o actualiza el contacto, asigna un comercial, envía un email, avisa por WhatsApp y guarda un log. Si corre 3.000 veces al mes: | | Cálculo | Consumo mensual | |---|---|---| | Make | 8 operaciones × 3.000 ejecuciones | 24.000 créditos | | n8n | 1 ejecución × 3.000 veces | 3.000 ejecuciones | Es solo la aritmética del modelo, no una factura: en la práctica hay módulos que no se ejecutan en todas las ramas, iteradores que multiplican operaciones y pasos que se pueden agrupar. Pero muestra el patrón: **cuantos más pasos tiene un flujo, más se aleja el coste de Make del de n8n**. Con flujos de dos o tres módulos la diferencia se reduce mucho. ### El coste que no aparece en la página de precios n8n autoalojado no cuesta cero. Pagas el servidor, y alguien tiene que instalarlo, actualizarlo, hacer backups, vigilar que no se caiga y responder cuando falla. Si esa persona no existe, el ahorro en licencia se convierte en riesgo operativo. Los precios de cada plan y el coste real de autoalojarlo están en la guía de [n8n precios: Cloud o self-hosted](https://fcgsystems.es/blog/n8n-precios-cloud-self-hosted/). ## ¿Qué pasa cuando un flujo falla en cada herramienta? Para un negocio que vende, esta es la pregunta más importante y la que menos aparece en las comparativas. - **n8n** permite definir un [error workflow](https://docs.n8n.io/build/flow-logic/handle-errors-gracefully/) (consultado en septiembre de 2026): un flujo que se ejecuta cuando otro falla y que puede avisar a una persona, guardar el registro fallido o abrir una incidencia. Hay que configurarlo en cada workflow crítico. - **Make** tiene manejadores de error dentro del escenario y [ejecuciones incompletas](https://help.make.com/incomplete-executions) (consultado en septiembre de 2026), que guardan la ejecución que falló para reintentarla o resolverla después. Están desactivadas por defecto: si no las activas, el dato del registro que falló puede perderse. En ninguna de las dos basta con lo que trae la herramienta. Un campo que llega vacío o un webhook que nunca se dispara no generan error. Por eso insistimos en logs propios, reconciliación y alertas con responsable, como explicamos en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ## ¿Cuándo elegir Make? - El equipo que va a mantener los flujos no tiene perfil técnico y necesita un editor visual con curva suave. - Los flujos son cortos (pocos módulos) y el volumen es moderado. - No quieres gestionar servidores ni actualizaciones. - Necesitas resultados rápidos con integraciones estándar. ## ¿Cuándo elegir n8n? - Los flujos tienen muchos pasos o se ejecutan miles de veces al mes. - Necesitas lógica propia: código, llamadas a APIs sin integración oficial, transformaciones complejas. - Por privacidad o control quieres que los datos no salgan de tu infraestructura. - Tienes, o contratas, capacidad técnica para mantener un servidor: backups, actualizaciones y monitorización. Si eso no está claro, [n8n Cloud](https://docs.n8n.io/choose-how-to-use-n8n/) (consultado en septiembre de 2026) es una opción intermedia. ## ¿Qué alternativas a n8n tiene sentido valorar? Quien busca "alternativas a n8n" suele venir de uno de tres sitios: n8n le parece demasiado técnico, el self-hosted le da miedo o el volumen empieza a pesar. Para cada caso, la alternativa razonable es distinta: | Si el problema con n8n es… | Alternativa a valorar | Lo que ganas | Lo que cedes | |---|---|---|---| | Curva de aprendizaje para un equipo sin perfil técnico | Make | Editor visual y ninguna infraestructura que mantener | Coste por operación que crece con los pasos de cada flujo | | Conectar aplicaciones con flujos muy sencillos | Zapier | Rapidez para integraciones estándar | Menos control y el mismo dilema de coste por uso con volumen | | No querer mantener un servidor | n8n Cloud (antes de cambiar de herramienta) | La misma herramienta sin operar la instalación | Cuota de ejecuciones por plan | | La lógica de negocio ya no cabe en flujos | Software propio con una API, y n8n o Make solo para orquestar | Reglas probadas, datos con claves únicas y permisos | Desarrollo y mantenimiento de código | Dos avisos antes de migrar. Primero, cambiar de herramienta no arregla flujos sin logs ni gestión de errores: el problema se muda. Segundo, compara siempre con tu volumen real y en el mes de más carga, no con el plan de entrada. ## ¿Y si ninguna de las dos es la respuesta? A veces el problema no es la herramienta. Si los flujos se han convertido en la lógica central del negocio, con reglas muy específicas, un volumen que encarece cada ejecución o un equipo que necesita una interfaz propia, lo razonable puede ser pasar parte de esa lógica a código. Las señales concretas están en el artículo sobre [pasar de no-code a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/). Lo habitual es una arquitectura híbrida: n8n o Make para integraciones y software propio para el núcleo. ## Errores comunes al elegir entre n8n y Make - **Decidir por el precio del plan de entrada.** Lo que importa es el consumo con tu volumen y la forma de tus flujos, sobre todo en el mes de un lanzamiento. - **Programar comprobaciones cada minuto sin necesidad.** Un trigger que consulta una API periódicamente consume aunque no haya datos nuevos. Si la aplicación de origen admite webhooks, úsalos. - **Autoalojar n8n sin backups ni responsable.** Funciona hasta el día que el servidor falla y nadie sabe restaurarlo. - **No activar la gestión de errores.** Ni el error workflow de n8n ni las ejecuciones incompletas de Make están configurados por defecto. - **Mezclar las dos sin criterio.** Tener flujos críticos repartidos entre n8n, Make y Zapier sin documentación multiplica los puntos de fallo. Si conviven, que sea por diseño. - **Migrar todo de golpe.** Cambiar de herramienta con la operación en marcha exige ir flujo a flujo y comprobar resultados. ## Checklist para decidir - ¿Cuántos pasos tienen de media tus flujos críticos? - ¿Cuántas veces al mes se ejecutan, y cuánto sube eso en un lanzamiento? - ¿Quién mantiene los flujos hoy y qué perfil técnico tiene? - ¿Hay datos que, por privacidad o contrato, no deberían pasar por una nube de terceros? - ¿Quién respondería si el servidor de n8n se cayera un domingo? - ¿Tienes activada la gestión de errores y sabes qué registros fallaron la semana pasada? - ¿Algún flujo contiene lógica de negocio que debería vivir en software propio? ## ¿Cuándo conviene delegar esta decisión? Si ya tienes decenas de flujos, varios de ellos críticos, y la duda es migrar, consolidar o reforzar lo que hay, la decisión deja de ser de herramienta y pasa a ser de arquitectura. En FCG Systems la herramienta se elige según el sistema, no al revés: mapeamos los flujos, medimos qué consume y qué falla, y proponemos dónde debe vivir cada proceso. Lo hacemos dentro del servicio de [automatización de procesos con n8n y Make](https://fcgsystems.es/servicios/automatizacion-de-procesos/) y, cuando n8n va autoalojado, con [infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/) para que el servidor no dependa de la suerte. Si quieres ver cómo encaja la automatización con el resto de piezas de la operación, empieza por la guía de [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/). Y si estás a punto de elegir o migrar, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y te digo qué opción tiene sentido con tu volumen. ## Preguntas frecuentes ### ¿Es mejor n8n o Make? Ninguno es mejor en abstracto. Make suele encajar mejor en equipos sin perfil técnico con flujos cortos y volumen moderado. n8n compensa cuando los flujos tienen muchos pasos, el volumen es alto o necesitas alojarlo en tu propia infraestructura y tienes quién la mantenga. ### ¿Qué alternativas a n8n hay? Para un negocio digital, las alternativas habituales son Make y Zapier, servicios en la nube que cobran por uso, y el software propio cuando la lógica ya es el núcleo del negocio. La elección depende de cuántas veces se ejecutan tus flujos, cuántos pasos tienen, quién los mantiene y dónde deben estar los datos. ### ¿Qué pasa si me quedo sin ejecuciones en n8n o sin créditos en Make? En los planes Business y Enterprise, según la FAQ de precios de n8n, al superar la cuota los flujos siguen ejecutándose y pueden aplicarse cargos por exceso; para Starter y Pro, revisa las condiciones en su página de precios. En Make, su centro de ayuda indica que puedes subir de plan, comprar créditos extra o activar la compra automática. Conviene vigilar el consumo antes de un lanzamiento. ### ¿Se puede migrar de Make a n8n? Sí, pero no hay una conversión automática fiable: los escenarios se rehacen como workflows. Lo sensato es migrar flujo a flujo, empezando por el que más consume o más falla, y mantener el antiguo activo hasta comprobar que el nuevo produce el mismo resultado. ### ¿Y Zapier? ¿Dónde encaja frente a n8n y Make? Zapier es una opción muy extendida para conectar aplicaciones con flujos sencillos. La pregunta para decidir es la misma que con n8n y Make: cuánto consume tu volumen real con su modelo de precios, cómo gestiona los errores y quién mantiene los flujos. Compara con los datos de tu operación, no con el plan de entrada. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/): Servidores, despliegues, backups y alertas para que tu operación no se caiga y sea tuya. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Pagos fallidos en Stripe: cómo recuperarlos y dar o quitar el acceso al curso sin hacerlo a mano > Qué hace Stripe con un pago recurrente fallido, qué estado de suscripción debe dar o quitar el acceso a tu curso o membresía y cómo automatizarlo sin errores. - URL: https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 (15 de septiembre de 2026) - Tema: Automatización · Formato: Breakdown · Lectura: 9 min - Palabra clave: pagos fallidos stripe (también: recuperar pagos fallidos, quitar acceso al curso si no paga, control de accesos membresía, stripe past_due unpaid, smart retries stripe) Cuando un pago recurrente falla en Stripe, lo primero no es escribir al alumno: es dejar que Stripe reintente el cobro con Smart Retries y envíe el email para actualizar la tarjeta. El acceso al curso o a la membresía no debería depender de ese fallo puntual, sino del **estado de la suscripción**: se da con `active`, se mantiene o no durante `past_due` según tu política y se quita con `unpaid` o `canceled`. El problema real en una academia online o una membresía casi nunca es Stripe. Es lo que pasa entre Stripe y la plataforma formativa: alumnos que siguen dentro meses después de dejar de pagar, alumnos que pagan y no tienen acceso porque el aviso no llegó, o alguien del equipo revisando cada semana una lista de impagos para dar y quitar accesos a mano. Esta guía explica qué hace Stripe por sí solo, qué tiene que decidir tu sistema y cómo montar el circuito para que funcione sin intervención y sin fallar en silencio. ## ¿Por qué falla un pago recurrente? Porque el banco emisor lo rechaza, y no todos los rechazos son iguales. Para decidir qué hacer conviene separarlos en dos grupos: | Tipo de rechazo | Ejemplos | ¿Stripe puede reintentarlo? | Qué necesita | |---|---|---|---| | Temporal | Fondos insuficientes, fallo puntual del emisor | Sí, con reintentos automáticos | Tiempo y un buen calendario de reintentos | | Definitivo (*hard decline*) | `lost_card`, `stolen_card`, `incorrect_number`, `authentication_required`, `transaction_not_allowed` | No, hasta que haya un método de pago nuevo | Que el cliente actualice la tarjeta o confirme el pago | La lista completa de códigos que Stripe no reintenta está en su [documentación de reintentos automáticos](https://docs.stripe.com/billing/revenue-recovery/smart-retries) (consultado en septiembre de 2026). En esos casos los reintentos programados siguen contando, pero el cobro solo se ejecuta cuando Stripe detecta un método de pago nuevo. `authentication_required` merece atención aparte: aparece cuando el banco exige que el titular confirme el pago (3D Secure). Ningún reintento lo resuelve sin que el alumno haga algo. ## ¿Qué hace Stripe por sí solo cuando falla un cobro? Bastante, si está configurado. Todo lo siguiente se activa desde el Dashboard, sin código, según la documentación de [recuperación de ingresos](https://docs.stripe.com/billing/revenue-recovery) y de [emails a clientes](https://docs.stripe.com/billing/revenue-recovery/customer-emails) (consultado en septiembre de 2026): - **Smart Retries.** Reintenta el cobro en los momentos que su modelo considera más probables de éxito, dentro del número de intentos y el plazo que elijas: 1 semana, 2 semanas, 3 semanas, 1 mes o 2 meses. La configuración recomendada por defecto es **8 intentos en 2 semanas**. Si prefieres reglas fijas, puedes definir hasta tres reintentos con días concretos entre ellos. - **Email de pago fallido.** Con *Send emails when card payments fail* activado, Stripe envía un email tras cada fallo con un enlace para actualizar el método de pago. - **Email para confirmar pagos.** Para pagos que requieren 3D Secure, puede enviar un enlace a una página alojada por Stripe donde el cliente confirma el cobro. - **Portal de cliente.** Una página alojada donde el cliente actualiza su método de pago o cancela la suscripción, según lo que permitas en el [portal de cliente](https://docs.stripe.com/customer-management) (consultado en septiembre de 2026). - **Actualización automática de tarjetas.** Stripe actualiza la tarjeta guardada cuando el cliente recibe un número nuevo. Y una decisión que tienes que tomar tú en la configuración de pagos fallidos: **qué pasa con la suscripción cuando se agotan los reintentos**. | Opción al agotar reintentos | Estado final | Qué implica | |---|---|---| | Cancelar la suscripción | `canceled` | Estado terminal. Para volver, el alumno necesita una suscripción nueva | | Marcar como no pagada | `unpaid` | La suscripción sigue existiendo, se generan facturas en borrador y no se intenta cobrar | | Dejarla vencida | `past_due` | Se siguen generando facturas y se cobra según la configuración de reintentos | ## ¿Qué estado de la suscripción debe dar o quitar el acceso al curso? Aquí está la decisión que Stripe no toma por ti. La regla que aplico en cualquier sistema de accesos es la misma que en la guía de [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/): **el pago manda y el acceso obedece**. La pasarela es la fuente de verdad del estado del cobro y la plataforma formativa solo refleja ese estado. Traducido a los estados de una suscripción en Stripe, según su documentación de [webhooks de suscripciones](https://docs.stripe.com/billing/subscriptions/webhooks) (consultado en septiembre de 2026): | Estado | Qué significa | Acción recomendada sobre el acceso | |---|---|---| | `trialing` | Periodo de prueba | Dar acceso | | `active` | Suscripción al corriente | Dar acceso | | `incomplete` | El primer pago no se ha completado (tiene 23 horas) o requiere acción | No dar acceso todavía | | `incomplete_expired` | El primer pago no se completó en 23 horas | No dar acceso | | `past_due` | El último pago falló o no se intentó; puede haber reintentos | Decisión de negocio: mantener con aviso o restringir | | `unpaid` | Reintentos agotados, sin nuevos intentos de cobro | Quitar acceso (lo indica Stripe) | | `canceled` | Suscripción cancelada, estado terminal | Quitar acceso (lo indica Stripe) | | `paused` | Prueba terminada sin método de pago | No dar acceso | `past_due` es la fila que más discusiones genera. Quitar el acceso al primer fallo castiga a alumnos con una tarjeta caducada que habrían pagado en dos días. Mantenerlo indefinidamente regala el producto. Lo razonable es escribir la política (por ejemplo, acceso completo mientras duran los reintentos y aviso visible dentro de la plataforma) y que el sistema la aplique igual para todos. ## ¿Qué eventos de Stripe hay que escuchar? Stripe notifica los cambios con eventos de webhook. Para controlar accesos bastan cuatro: - `invoice.paid`: la factura se ha pagado. Stripe indica que puedes dar acceso al recibirlo si la suscripción está `active`. - `invoice.payment_failed`: un cobro ha fallado. Su campo `attempt_count` indica cuántos intentos van. - `customer.subscription.updated`: la suscripción ha cambiado, incluidos los cambios de estado como el paso a `past_due` o `unpaid`. - `customer.subscription.deleted`: la suscripción ha terminado. Tres detalles de la [documentación de webhooks](https://docs.stripe.com/webhooks) (consultado en septiembre de 2026) que evitan la mayoría de errores: 1. **Stripe no garantiza el orden de los eventos.** No construyas la lógica suponiendo que `invoice.paid` llega antes o después de `customer.subscription.updated`. Ante cualquier evento, consulta el estado actual de la suscripción y decide con ese dato. 2. **El mismo evento puede llegar más de una vez.** Guarda los identificadores de evento procesados y descarta los repetidos. 3. **Si tu endpoint no responde bien, Stripe reintenta la entrega hasta tres días** en modo live con retroceso exponencial. Responde con un `2xx` rápido antes de hacer trabajo pesado y verifica la firma de cada evento. ## Cómo montar el control de accesos paso a paso ### 1. Configura la recuperación en Stripe antes de automatizar nada Activa Smart Retries, los emails de pago fallido y de confirmación de pago, y elige qué pasa al agotar los reintentos. Buena parte de los cobros se recuperan aquí sin que tu sistema haga nada. ### 2. Escribe la política de acceso Una tabla como la anterior, con tu decisión sobre `past_due`, firmada por quien decide en el negocio. Sin esta pieza, la automatización solo reproduce más rápido la improvisación de siempre. ### 3. Relaciona cliente de Stripe y alumno con un identificador, no con el email Guarda el ID de cliente de Stripe en la ficha del alumno (en el CRM o en la plataforma) desde la primera compra. El email cambia, se escribe con mayúsculas distintas o se usa uno diferente para pagar y para entrar al curso. Un identificador estable evita dar acceso a la persona equivocada o no encontrar a nadie. ### 4. Construye el flujo que aplica la regla Da igual que viva en n8n, en Make o en un servicio propio. El flujo mínimo: 1. Recibe el evento y verifica la firma. 2. Comprueba si ese ID de evento ya se procesó. Si es así, termina. 3. Consulta el estado actual de la suscripción en Stripe. 4. Busca al alumno por el ID de cliente. 5. Aplica la política: dar, mantener o quitar acceso. 6. Registra qué hizo, con qué evento y con qué resultado. El paso 5 tiene que ser idempotente: quitar el acceso a quien ya no lo tiene no debe dar error ni duplicar nada. Si el flujo corre en n8n y los eventos no llegan, revisa las causas habituales en [por qué un webhook de n8n no funciona](https://fcgsystems.es/blog/webhook-n8n-no-funciona/). ### 5. Reconciliación diaria Una vez al día, compara las suscripciones activas en Stripe con los accesos activos en la plataforma. Cualquier diferencia es un fallo, aunque ninguna herramienta haya marcado error: alguien con acceso sin suscripción, o alguien pagando sin acceso. Es la comprobación que más fallos silenciosos destapa, como explico en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ### 6. Avisos con responsable Si el flujo falla o la reconciliación encuentra diferencias, alguien concreto tiene que enterarse el mismo día. ## Errores comunes en el control de accesos por pago - **Quitar el acceso con `invoice.payment_failed`.** El primer fallo no significa impago: con Smart Retries puede quedar todavía una serie de reintentos por delante. - **Dar acceso en cuanto el alumno vuelve de la página de pago.** El pago puede requerir confirmación o fallar después. El acceso se da con el estado de la suscripción, no con la redirección. - **Depender del orden de los eventos.** Si la lógica solo funciona cuando los eventos llegan en un orden concreto, fallará de vez en cuando y nadie sabrá por qué. - **No descartar eventos duplicados.** Un reintento de entrega puede enviar dos veces el email de bienvenida o crear dos altas. - **Buscar al alumno por email.** Funciona hasta el primer alumno que paga con el email de su empresa. - **No reconciliar nunca.** Los accesos que sobran o faltan se descubren cuando alguien se queja, meses después. - **Revisar impagos a mano cada semana.** Además del tiempo, garantiza que la regla se aplica distinto según quién la revise. ## ¿Y si la plataforma formativa no permite dar o quitar acceso por API? Entonces el cuello de botella no está en Stripe. Las opciones, de menos a más trabajo: usar la integración nativa entre la plataforma y la pasarela si existe y cubre tu política, gestionar el acceso en una capa que sí controlas (un área de miembros o un portal propio) o cambiar de plataforma cuando el control de accesos es crítico para el negocio. Si la operación ya no cabe en las herramientas que tienes, el artículo sobre [cuándo pasar de no-code a software propio](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/) ayuda a decidir. ## Checklist: control de accesos y pagos fallidos - Smart Retries o reglas de reintento configuradas. - Emails de pago fallido y de confirmación de pago activados. - Decidido qué pasa con la suscripción al agotar los reintentos. - Política de acceso escrita para cada estado, incluido `past_due`. - ID de cliente de Stripe guardado en la ficha de cada alumno. - Firma de los webhooks verificada. - Eventos duplicados descartados por su ID. - La lógica consulta el estado actual y no depende del orden de los eventos. - Acciones de dar y quitar acceso idempotentes. - Log de cada decisión de acceso. - Reconciliación diaria entre suscripciones activas y accesos activos. - Un responsable recibe los avisos de fallo. ## ¿Cuándo conviene delegarlo? Si tienes pocas suscripciones y la plataforma formativa trae integración nativa con Stripe, configura bien los reintentos y los emails y probablemente sea suficiente. Conviene que lo construya alguien con experiencia en sistemas cuando el acceso depende de varias herramientas (pasarela, CRM, plataforma, comunidad), cuando hay más de un producto o plan, cuando ya has encontrado alumnos con acceso sin pagar o cuando alguien del equipo dedica horas cada semana a revisarlo. El control de accesos es uno de los ejemplos típicos de un Automation Sprint de 1 a 3 semanas dentro del servicio de [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/): diseño, integración, pruebas, logs, documentación y traspaso. Si la plataforma no da más de sí, lo planteamos como [software a medida](https://fcgsystems.es/servicios/software-a-medida/). Si tus accesos y tus cobros no cuadran y no sabes desde cuándo, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y lo revisamos. ## Preguntas frecuentes ### ¿Stripe reintenta automáticamente los pagos fallidos de una suscripción? Sí, si lo configuras en Billing. Smart Retries elige el momento de cada reintento dentro del número de intentos y el plazo que definas; la configuración recomendada por Stripe es 8 intentos en 2 semanas. No reintenta cuando el banco devuelve un rechazo definitivo, como una tarjeta robada o una autenticación requerida, hasta que el cliente aporta un método de pago nuevo. ### ¿Cuándo hay que quitar el acceso a un alumno que no ha pagado? La documentación de Stripe indica revocar el acceso cuando la suscripción pasa a canceled o unpaid, porque en ese punto ya se han agotado los reintentos. Mientras está en past_due la decisión es de negocio: muchos proyectos mantienen el acceso con un aviso durante los reintentos. Lo importante es que la regla esté escrita y la aplique el sistema, no una persona. ### ¿Qué diferencia hay entre past_due y unpaid en Stripe? past_due significa que el último pago falló o no se intentó y que Stripe puede seguir reintentando. unpaid solo aparece si lo eliges en la configuración de pagos fallidos: la suscripción sigue existiendo y genera facturas, pero ya no se intenta cobrar. Al terminar los reintentos puedes elegir entre cancelar, marcar como unpaid o dejarla en past_due. ### ¿Qué hago con los pagos que fallan por authentication_required? Stripe no puede reintentarlos por su cuenta porque requieren que el cliente confirme el pago. Activa el email con enlace alojado por Stripe para confirmar pagos que lo necesiten y avisa al alumno desde tu propio canal, porque sin su intervención ese cobro no se va a completar. ### ¿Se puede automatizar el control de accesos con n8n o Make? Sí, siempre que tu plataforma formativa permita dar y quitar acceso por API o por integración. El flujo escucha los eventos de Stripe, verifica la firma, ignora eventos ya procesados, consulta el estado actual de la suscripción y aplica la regla de acceso. Sin reconciliación diaria y sin logs, ese flujo acabará fallando en silencio. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Píxel de Meta y API de conversiones: cómo usar los dos sin contar cada conversión dos veces > Por qué Meta cuenta leads y compras dos veces al usar píxel y API de conversiones, cómo funciona la deduplicación con event_id y qué revisar paso a paso. - URL: https://fcgsystems.es/blog/pixel-meta-api-conversiones-duplicados/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 (15 de septiembre de 2026) - Tema: Sistemas · Formato: Breakdown · Lectura: 8 min - Palabra clave: pixel de meta y api de conversiones (también: api de conversiones meta, eventos duplicados meta, deduplicación event_id, api de conversiones o pixel de meta) Para usar el píxel de Meta y la API de conversiones a la vez sin duplicar resultados, el evento que envía el navegador y el que envía el servidor tienen que llevar el mismo nombre de evento y el mismo identificador (`eventID` en el píxel, `event_id` en la API). Meta recomienda usar los dos en configuración redundante, y solo descarta el duplicado si ambos llegan con esos dos campos iguales y dentro de 48 horas desde el primero con ese `event_id`. Si tus leads o compras en Meta no cuadran con lo que ves en el CRM, la causa suele estar en uno de estos tres sitios: eventos que llegan por dos vías sin identificador común, varias integraciones enviando el mismo evento o eventos que se disparan en el momento equivocado. Esta guía explica cómo funciona la deduplicación, cómo hacer inventario de quién envía cada evento y qué revisar antes de dar por buena la medición. ## ¿Píxel, API de conversiones o los dos? Los dos, porque miden desde lugares distintos y cada uno cubre un hueco del otro: | | Píxel de Meta | API de conversiones | |---|---|---| | Desde dónde envía | Navegador del usuario | Un servidor: tu plataforma de pago, CRM, backend o automatización | | Qué lo bloquea | Bloqueadores, restricciones del navegador, consentimiento rechazado | Nada del lado del navegador; depende de que tu servidor envíe bien | | Qué ve bien | La navegación y la interacción en la página | Hechos confirmados: pago aprobado, registro guardado, lead cualificado | | Riesgo típico | Perder eventos | Duplicar eventos si no se deduplica | En su documentación, Meta recomienda implementar la API de conversiones junto al píxel en lo que llama una configuración redundante, y explica que esa configuración exige deduplicar para no contar dos veces el mismo evento ([deduplicación de eventos del píxel y del servidor](https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events), consultado en septiembre de 2026). La pregunta "¿API de conversiones o píxel?" tiene truco: elegir solo uno te obliga a aceptar pérdidas (solo píxel) o a renunciar a la señal del navegador (solo servidor). El trabajo real está en que convivan. ## ¿Cómo deduplica Meta los eventos? Meta ofrece dos métodos. Conviene conocer los dos porque tienen límites distintos. ### Método recomendado: nombre de evento + event_id Meta considera que dos eventos son el mismo cuando: - el `event` del píxel coincide con el `event_name` de la API de conversiones (por ejemplo, `Purchase` y `Purchase`), y - el `eventID` del píxel coincide con el `event_id` de la API de conversiones. Además, solo deduplica si los eventos llegan dentro de las 48 horas siguientes a la recepción del primero con ese `event_id`. Un evento de servidor que envías tres días después, por ejemplo al reprocesar una cola de errores, ya no se deduplica contra el del navegador. ### Método alternativo: fbp o external_id También puede comparar `event_name` con `fbp` o `external_id`. Tiene dos limitaciones documentadas: solo funciona cuando el evento llega primero desde el navegador y después desde el servidor, y no descarta el evento del servidor si el del navegador no llega en 48 horas. Sirve como apoyo, no como estrategia principal. ## ¿Por qué se duplican los eventos en la práctica? Estos son los patrones que explican la mayoría de cifras infladas o incoherentes: | Síntoma | Causa probable | Cómo comprobarlo | |---|---|---| | Cada compra aparece dos veces | Píxel y API envían `Purchase` con `event_id` distinto o sin él | Compara el identificador en los dos eventos de una compra de prueba | | Compras triplicadas | Plugin del CMS + etiqueta de GTM + integración de la plataforma de pago enviando lo mismo | Inventario de fuentes (paso 1 de abajo) | | Leads que no existen en el CRM | El evento `Lead` se dispara al pulsar el botón, no al confirmar el registro | Envía un formulario con error y mira si el evento se dispara igual | | Duplicados solo en algunos casos | Recargas de la página de gracias o reintentos del servidor que reenvían sin mismo `event_id` | Recarga la página de gracias en una prueba | | Meta deduplica unas veces sí y otras no | El evento de servidor llega más de 48 horas después | Revisa cuándo se envía el evento de servidor, sobre todo en pagos pendientes | Si tu plataforma de pago o de cursos envía eventos por servidor además de por navegador, trátala como una fuente más en el inventario: no des por hecho que ya deduplica con lo que tú envías desde GTM o desde tu web. ## ¿Cómo configuro píxel y API de conversiones sin duplicados? ### 1. Haz inventario de quién envía cada evento Antes de tocar nada, rellena esta tabla para cada evento que te importa. Es la plantilla que evita la mayoría de problemas: | Evento | Se envía desde el navegador por | Se envía desde el servidor por | Momento en que se dispara | event_id | Quién genera el event_id | |---|---|---|---|---|---| | Lead | | | | | | | CompleteRegistration | | | | | | | InitiateCheckout | | | | | | | Purchase | | | | | | Si en una fila aparecen tres herramientas o la columna del `event_id` está vacía, ya tienes el origen del problema. Cada evento debería tener, como máximo, un emisor en navegador y uno en servidor. ### 2. Define un identificador único por conversión El `event_id` tiene que representar un hecho de negocio, no una carga de página. Los mejores candidatos son identificadores que ya existen en tu operación: - **Compra:** el identificador del pedido o de la transacción. - **Registro o lead:** el identificador del registro que crea tu formulario o tu CRM. - **Lead cualificado:** el identificador del lead en el CRM más el nombre de la etapa. Lo que no funciona es generar un valor aleatorio en el navegador y otro distinto en el servidor. Los dos lados tienen que poder obtener el mismo valor. ### 3. Pasa el mismo valor a ambos lados Si el identificador nace en el servidor (el pedido), expónlo a la página de confirmación para que el píxel lo use como `eventID`. Si nace en el navegador (un registro que todavía no existe en el servidor), envíalo junto con el formulario para que el servidor lo reutilice como `event_id`. Es la misma idea que explico en la [atribución de leads](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/): un identificador que viaja con el lead de principio a fin. ### 4. Dispara en la confirmación, no en el clic Un `Lead` debería enviarse cuando el registro existe, y un `Purchase` cuando el pago está aprobado. Disparar al pulsar el botón cuenta intentos, formularios con errores y dobles clics. En pagos que quedan pendientes, decide qué evento se envía y cuándo, y ten presente la ventana de 48 horas. ### 5. Envía desde el CRM las conversiones que solo existen allí Muchas búsquedas de "CRM con la API de conversiones de Meta" responden a una necesidad concreta: que Meta aprenda de los leads que de verdad avanzan, no de todos los registros. Si tu venta pasa por llamada o por un equipo comercial, el CRM es el único que sabe qué lead se cualificó o compró. Enviar ese evento desde el CRM, con el identificador del lead, convierte la API de conversiones en una señal de negocio y no solo en una copia de lo que ya mide el píxel. ### 6. Prueba con una conversión real antes de escalar campañas Haz una compra o un registro de prueba y verifica en el Administrador de eventos de Meta, con su herramienta de prueba de eventos, que llegan el evento del navegador y el del servidor y que comparten nombre e identificador. Repite recargando la página de confirmación y con un formulario que falle. Documenta el resultado: dentro de dos lanzamientos nadie recordará qué se probó. ## ¿Qué errores conviene evitar? - **Añadir la API de conversiones sin retirar nada.** Activar la integración de servidor de una plataforma mientras sigue activa tu etiqueta de servidor en GTM crea un emisor más, no un respaldo. - **Tratar la deduplicación como algo de Meta.** Meta deduplica lo que le mandas bien etiquetado. Decidir el identificador y quién lo envía es trabajo tuyo. - **Reprocesar eventos antiguos sin pensar en las 48 horas.** Un reenvío masivo tras un fallo puede inflar resultados. - **Mezclar pruebas y producción.** Los eventos de prueba que se cuelan en el conjunto de datos real ensucian el aprendizaje de las campañas. - **Esperar que Meta, GA4 y el CRM coincidan.** La API de conversiones reduce pérdidas y, bien deduplicada, evita dobles conteos, pero no iguala las cifras. Cada herramienta atribuye con sus reglas; lo explico con un recorrido completo en [por qué GA4, Meta y tu CRM nunca dan la misma cifra](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/). - **Descubrirlo en pleno lanzamiento.** Si vendes por lanzamientos, la medición se valida antes de abrir registros, como cualquier otra pieza del [checklist técnico de un lanzamiento](https://fcgsystems.es/blog/checklist-tecnico-lanzamiento/). ## Checklist: píxel y API de conversiones sin duplicados - Existe una tabla con cada evento, su emisor en navegador, su emisor en servidor y su `event_id`. - Ningún evento tiene más de un emisor por lado. - El nombre del evento es idéntico en píxel y servidor. - El `event_id` sale de un identificador de negocio (pedido, registro, lead) y es el mismo en ambos lados. - `Lead` y `Purchase` se disparan en la confirmación, no en el clic. - Recargar la página de confirmación no genera un evento nuevo. - Los eventos de servidor se envían dentro de las 48 horas siguientes al del navegador. - Las conversiones cualificadas del CRM se envían con el identificador del lead. - Hay una prueba documentada con compra real, recarga y formulario con error. - Está claro qué herramienta es la fuente de verdad de leads y ventas, y no es Meta. ## ¿Cuándo conviene delegarlo? Si tienes un solo checkout, un formulario y una integración nativa bien configurada, puedes resolverlo con esta guía y una tarde de pruebas. Cambia cuando la operación tiene varias plataformas enviando eventos, venta por llamada, pagos pendientes, lanzamientos con picos o campañas donde un dato inflado decide dónde va el presupuesto. Ahí el problema ya no es de una etiqueta: es de arquitectura de datos. Qué sistema genera cada identificador, cómo viaja hasta el CRM y qué conversiones vuelven a Meta. Es exactamente el trabajo del servicio de [tracking server-side y API de conversiones](https://fcgsystems.es/servicios/datos-tracking-analitica/), que conecta eventos, atribución y dashboards con una fuente de datos fiable. Encaja dentro de la visión de conjunto que describo en la guía de [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/). Si tus cifras de Meta no se parecen a lo que factura el negocio, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y revisamos por dónde se duplican o se pierden los eventos. ## Preguntas frecuentes ### ¿Uso el píxel de Meta o la API de conversiones? Los dos. Meta recomienda una configuración redundante: el píxel envía el evento desde el navegador y la API de conversiones lo envía desde un servidor. Así, si el navegador bloquea el píxel, el evento del servidor sigue llegando. La condición es que ambos compartan nombre de evento e identificador para que Meta los cuente una sola vez. ### ¿Por qué Meta me cuenta las compras o los leads duplicados? Casi siempre porque el mismo evento llega por dos vías sin un identificador común, o porque dos integraciones distintas envían el mismo evento: un plugin, una etiqueta de Google Tag Manager y la propia plataforma de pago. Meta solo deduplica cuando el nombre del evento y el event_id coinciden en el navegador y en el servidor. ### ¿Qué es el event_id? Es el identificador único de una conversión concreta. En el píxel se envía como eventID y en la API de conversiones como event_id. Si una compra genera el mismo valor en los dos lados, por ejemplo el identificador del pedido, Meta entiende que es un solo evento recibido dos veces y descarta el duplicado. ### ¿La API de conversiones hace que Meta, GA4 y el CRM den la misma cifra? No. Reduce los eventos que se pierden y, bien deduplicada, evita contar dos veces, pero Meta, GA4 y el CRM siguen midiendo con reglas distintas: ventanas de atribución, visualizaciones, consentimiento y cambios de dispositivo. La cifra de negocio debe salir de tu fuente de verdad, normalmente el CRM o la pasarela de pago. ### ¿Necesito tracking server-side para usar la API de conversiones? Necesitas que algo envíe eventos desde un servidor, pero no siempre un contenedor server-side propio. Puede hacerlo tu plataforma de pago si tiene la integración, tu CRM o una automatización. Un tracking server-side completo compensa cuando hay volumen, varias plataformas y necesidad de controlar qué datos salen y cuándo. ## Servicios relacionados - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Qué tiene que estar listo antes de abrir registros en un lanzamiento: checklist técnico > Checklist técnico de un lanzamiento por fases: captación, tracking, deduplicación, CRM, asignación, WhatsApp y dashboards listos antes de abrir registros. - URL: https://fcgsystems.es/blog/checklist-tecnico-lanzamiento/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 (15 de septiembre de 2026) - Tema: Infraestructura · Formato: Arquitectura · Lectura: 11 min - Palabra clave: checklist técnico de un lanzamiento (también: infraestructura de lanzamientos, lanzamiento de infoproductos, preparar un lanzamiento online) Un checklist técnico de un lanzamiento es la lista de comprobaciones que confirma, antes de abrir registros, que cada capa del sistema aguanta el pico: captación, tracking, deduplicación, CRM, asignación comercial, comunidades, mensajería y dashboards. Su objetivo no es que todo funcione en una prueba tranquila, sino que siga funcionando con miles de registros en pocas horas. He trabajado en lanzamientos que concentran en pocos días la mayor parte de la captación y de las ventas de un negocio, con registros entrando a la vez desde YouTube, Instagram, Telegram, Ads y email. Lo que aprendes ahí es incómodo: durante el pico no hay tiempo para diagnosticar nada. O el sistema estaba preparado, o improvisas con el equipo comercial esperando leads y la audiencia haciendo clic en enlaces que no llevan a ninguna parte. Este artículo es la versión ordenada de ese aprendizaje. Primero, cómo se ve la arquitectura de un lanzamiento; después, el checklist por fases. Si lo que vas a lanzar es un curso o una membresía, conviene tener antes clara la máquina de entrega: la repaso en [infoproductos: qué son y qué exigen por debajo](https://fcgsystems.es/blog/infoproductos-que-son/). ## ¿Por qué colapsan los lanzamientos si "todo funcionaba" la semana anterior? Porque la semana anterior no había volumen. Un formulario que recibe diez registros al día no te enseña nada sobre cómo se comporta cuando recibe cientos en una hora. Los errores pequeños, con volumen, se multiplican. En un lanzamiento típico, los síntomas se parecen mucho entre sí: - **Formularios que dejan de enviar datos** o que los envían sin la fuente, así que nadie sabe de qué canal viene cada registro. - **Leads duplicados**: la misma persona se registra desde un anuncio y luego desde un email, y aparece dos veces en el CRM. - **Dos comerciales llamando al mismo lead**, porque el reparto se hizo antes de detectar el duplicado. - **Grupos de WhatsApp llenos**: el enlace publicado en anuncios y emails apunta a un grupo que ya no admite a nadie más, justo cuando más tráfico llega. - **Cifras que llegan tarde**: el informe del lanzamiento se reconstruye al día siguiente, cuando ya no sirve para mover presupuesto ni para repartir mejor el trabajo. Ninguno de estos problemas es exótico. Lo que los hace caros es el momento en que aparecen. Por eso un lanzamiento se diseña como un sistema, no como una colección de herramientas conectadas a última hora. Si quieres el marco general de cómo se piensan estas capas, lo explico en la guía de [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/). ## ¿Qué capas tiene el sistema técnico de un lanzamiento? Cuando reviso la infraestructura de un lanzamiento, no empiezo por las herramientas. Empiezo por el recorrido de un registro: desde que alguien hace clic en un anuncio hasta que un comercial habla con él o entra en una comunidad. Ese recorrido atraviesa siempre las mismas capas. | Capa | Qué tiene que resolver | Pregunta que me hago | |---|---|---| | Captación | Páginas y formularios que aguantan el tráfico | ¿Qué pasa si el formulario falla a mitad del pico? | | Tracking | Canal y campaña de cada registro | ¿Puedo saber de dónde viene cada lead sin mirar tres herramientas? | | Deduplicación | Un único registro por persona | ¿Qué ocurre cuando alguien se registra dos veces desde canales distintos? | | CRM | Fuente de verdad del lanzamiento | ¿Qué sistema manda si dos herramientas no coinciden? | | Asignación comercial | Un responsable por lead, según reglas y capacidad | ¿Quién llama a este lead y cómo lo sabe? | | Comunidades | Distribución a grupos sin saturarlos | ¿A dónde va el usuario número mil cuando el grupo está lleno? | | Email y WhatsApp | Mensajes que llegan a tiempo y a la persona correcta | ¿Qué se envía, desde dónde y con qué límites de envío? | | Dashboards | Lectura por fuente mientras la campaña está activa | ¿Puedo decidir hoy con los datos de hoy? | | Soporte en ventana crítica | Alguien que sabe qué hacer si algo cae | ¿Quién responde, en cuánto tiempo y con qué plan? | ### Captación: el punto donde se pierden registros sin que nadie lo vea La captación es la capa más visible y, curiosamente, la que menos se prueba. Una página que carga bien en tu portátil puede ir lenta con tráfico concentrado, y un formulario conectado por un webhook puede dejar de enviar datos sin mostrar ningún error al usuario. El usuario ve "gracias por registrarte" y el registro no existe en ningún sitio. Lo mínimo aquí: saber exactamente dónde se guarda cada registro en el momento en que se envía, y tener una copia de respaldo si el destino principal falla. ### Tracking: la fuente de cada registro tiene que viajar hasta el CRM Si el canal y la campaña no se guardan en el propio registro, la atribución del lanzamiento se convierte en una discusión entre GA4, la plataforma de anuncios y el CRM, que nunca van a dar la misma cifra. Profundizo en ese problema en el artículo sobre [atribución rota entre GA4 y el CRM](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/). Para un lanzamiento, la regla práctica es sencilla: cada registro entra etiquetado con su canal y su campaña, y esa etiqueta no se pierde por el camino. ### Deduplicación antes de asignación, nunca después Este es probablemente el aprendizaje más caro de todos los que salen del [caso de infraestructura para lanzamientos de alto volumen](https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/). Si el reparto de leads ocurre antes de detectar duplicados, dos comerciales acaban hablando con la misma persona y deshacer ese reparto con el lanzamiento en marcha cuesta muchísimo más que evitarlo. La deduplicación tiene que decidir qué dato identifica a una persona (email normalizado, teléfono con prefijo, o una combinación), qué registro se conserva cuando hay dos y qué información del duplicado se fusiona, por ejemplo una segunda fuente. ### CRM y asignación: un lead, un responsable El CRM es la fuente de verdad del lanzamiento. Si hay una hoja de cálculo paralela "por si acaso", ya tienes dos fuentes de verdad y ninguna fiable. La asignación comercial reparte cada lead por reglas explícitas (capacidad de cada comercial, tipo de lead, horario) y deja constancia de quién es el responsable. ### Comunidades: el enlace que no puede apuntar a un grupo lleno Muchos lanzamientos usan grupos y comunidades de WhatsApp para calentar a la audiencia, enviar recordatorios y abrir ventas. Los grupos tienen un límite de participantes y se llenan justo cuando más tráfico llega. Cambiar enlaces a mano en anuncios, emails y páginas durante la campaña es lento y propenso a errores. Este problema aparecía en cada lanzamiento, y por eso lo convertimos en producto: [CommunityRedirect](https://fcgsystems.es/casos/communityredirect-distribucion-comunidades-whatsapp/) es un enlace único que consulta la capacidad, rota destinos y no envía a nadie a un grupo sin plazas. Tanto si usas una herramienta así como si lo resuelves de otra forma, la pregunta del checklist es la misma: ¿qué pasa con el siguiente clic cuando el grupo actual se llena? Y si además envías recordatorios y avisos automáticos por WhatsApp, decide antes del lanzamiento si van por la app o por la API oficial, con sus plantillas y límites: lo comparo en [WhatsApp Business o API oficial](https://fcgsystems.es/blog/whatsapp-business-api/). ### Dashboards: leer el lanzamiento mientras ocurre Un dashboard de lanzamiento no es un informe bonito para el lunes. Es la herramienta con la que decides, durante la campaña, qué canal está trayendo registros de calidad, si hay que mover presupuesto o si el equipo comercial está saturado. Solo sirve si lee de una fuente en la que todos confían, y eso nos devuelve a las capas anteriores. ## ¿Cómo se prueba un lanzamiento antes de abrir registros? Con volumen. Un lanzamiento se prueba con carga antes de abrir registros, porque durante el pico no hay tiempo para diagnosticar. Probar que "un registro de prueba llega al CRM" no es suficiente. Lo que conviene simular: 1. **Registros en ráfaga** desde varios canales a la vez, con fuentes distintas, para ver que el tracking no se mezcla. 2. **Duplicados intencionados**: la misma persona desde dos canales, con el email escrito de forma distinta (mayúsculas, espacios), para comprobar que la deduplicación los detecta. 3. **Asignación con capacidad llena**: qué pasa cuando todos los comerciales llegan a su límite. 4. **Fallo de una integración**: desconectar a propósito un destino y confirmar que los registros no se pierden y que alguien recibe una alerta. 5. **Grupo lleno**: forzar que un destino de comunidad no tenga plazas y verificar a dónde va el siguiente usuario. Después de las pruebas, se borran los datos ficticios del CRM, de los dashboards y de las listas de envío. Parece obvio, pero un dashboard que arranca el lanzamiento con registros de prueba ya ha perdido la confianza del equipo. ## ¿Qué es un plan B en la infraestructura de un lanzamiento? Es la respuesta escrita, antes del lanzamiento, a la pregunta "¿qué hacemos si esto falla?" para cada capa crítica. No hace falta un documento largo. Hace falta que exista, que el equipo lo conozca y que no dependa de que una persona concreta esté despierta. Un plan B razonable incluye: - **Formulario alternativo** preparado y probado, con los mismos campos y la misma etiqueta de fuente. - **Copia de los registros** en un destino secundario, para poder reconstruir si el principal falla. - **Destinos de comunidad de reserva** listos para recibir tráfico. - **Mensajes preparados** para la audiencia si hay que cambiar una fecha o un enlace. - **Responsable técnico y canal de aviso** definidos para la ventana crítica, con un criterio claro de qué se considera incidencia grave. Sobre este último punto conviene ser honesto: el soporte técnico instantáneo no existe por defecto. Si necesitas a alguien disponible durante las horas críticas del lanzamiento, eso se planifica y se reserva. En FCG Systems, la disponibilidad en directo durante las ventanas críticas se define por escrito antes de empezar (ventanas, prioridades y capacidad reservada), dentro del alcance del proyecto. ## Checklist técnico de un lanzamiento, por fases Esta es la lista que usaría para revisar un lanzamiento de infoproducto. Adáptala a tus herramientas, pero no te saltes fases. ### Semanas antes de abrir registros - Recorrido de un registro dibujado de principio a fin: clic, formulario, CRM, asignación, comunidad, mensajes. - Una fuente de verdad definida para los leads del lanzamiento (y comunicada al equipo). - Parámetros de campaña (UTM o equivalentes) definidos por canal: YouTube, Instagram, Telegram, Ads y email. - Canal y campaña guardados en el propio registro, no solo en la herramienta de analítica. - Criterio de deduplicación decidido: qué identifica a una persona y qué registro se conserva. - Deduplicación colocada antes de la asignación comercial. - Reglas de asignación escritas: capacidad por comercial, prioridades y qué pasa cuando todos están llenos. - Destinos de comunidad preparados, con reservas, y sistema para no enviar a nadie a un grupo lleno. - Secuencias de email y WhatsApp revisadas, con límites de envío de cada plataforma comprobados en su documentación. - Dashboard del lanzamiento conectado a la fuente de verdad, con registros, asignaciones y ventas por fuente. - Logs y alertas en cada integración crítica, con una persona responsable de cada alerta. - Credenciales y accesos revisados: nada caduca durante el lanzamiento, nada está guardado en un chat. - Copias de seguridad de los datos que no se pueden reconstruir. ### 72 horas antes - Prueba de carga con registros en ráfaga desde varios canales. - Prueba de duplicados con variantes de email y teléfono. - Prueba de asignación con comerciales al límite de capacidad. - Prueba de fallo: una integración desconectada a propósito, registros recuperados y alerta recibida. - Prueba de grupo lleno y paso al siguiente destino. - Datos de prueba eliminados del CRM, dashboards y listas. - Plan B escrito y compartido: formulario alternativo, destinos de reserva, mensajes preparados. - Responsable técnico y canal de aviso confirmados para la ventana crítica. - Congelación de cambios: nada nuevo entra en producción sin validación. ### Durante el lanzamiento - Dashboard abierto y revisado a intervalos fijos, no solo cuando alguien pregunta. - Comparación rápida entre registros recibidos en formularios y registros en el CRM, para detectar pérdidas. - Vigilancia de la capacidad del equipo comercial y de los destinos de comunidad. - Alertas atendidas por su responsable, con registro de qué pasó y qué se hizo. - Cambios en caliente solo si están en el plan B; el resto, anotado para después. ### Después del lanzamiento - Reconciliación final: registros, duplicados fusionados, asignaciones y ventas por fuente. - Lista de incidencias con causa, impacto y solución aplicada. - Documentación actualizada con lo aprendido. - Decisión sobre qué problemas se repiten y merecen una solución permanente en lugar de otro parche. - Sistema preparado para reutilizarse en el siguiente lanzamiento, no desmontado. ## ¿Merece la pena montar esto para cada lanzamiento? Si cada lanzamiento se construye desde cero, no. Es caro, cansado y repites los mismos errores. Lo que cambia la ecuación es tratarlo como infraestructura: un sistema documentado que se reutiliza de un lanzamiento a otro y mejora con los datos de cada campaña. En el [caso de lanzamientos de alto volumen](https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/), el resultado fue exactamente ese: operar con un único registro por persona, un responsable comercial por lead y una lectura por fuente disponible durante la campaña, con un sistema que se reutiliza en lugar de montarse cada vez. Las cifras detalladas de esa operación no se publican, pero el patrón sirve para cualquier negocio que viva de lanzamientos. Y hay un último aprendizaje que me parece el más útil: los problemas que aparecen en cada lanzamiento son candidatos a producto. Si tu equipo arregla lo mismo en cada campaña, no necesitas otro parche; necesitas que esa pieza deje de depender de la improvisación. Si además tus automatizaciones fallan sin que nadie se entere, te interesa leer por qué [las automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/) son el riesgo más infravalorado de un lanzamiento. ## ¿Tu próximo lanzamiento tiene alguna capa sin resolver? Si al repasar el checklist has encontrado casillas que no puedes marcar con seguridad, ese es el punto de partida. En FCG Systems diseñamos y construimos [infraestructura de lanzamientos](https://fcgsystems.es/servicios/infraestructura-de-lanzamientos/) para infoproductores, academias y negocios que concentran su captación en pocos días: captación, tracking, deduplicación, asignación, comunidades y dashboards funcionando como un solo sistema. También cubrimos la parte de [datos y tracking](https://fcgsystems.es/servicios/datos-tracking-analitica/) y la [infraestructura técnica](https://fcgsystems.es/servicios/infraestructura-devops/) que hay debajo. Lo mejor es empezar varias semanas antes de abrir registros. [Cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) en el próximo lanzamiento y te digo por qué capa empezaría. ## Preguntas frecuentes ### ¿Con cuánta antelación hay que preparar la parte técnica de un lanzamiento? Lo razonable es empezar varias semanas antes de abrir registros. Construir es la parte rápida; lo que lleva tiempo es probar el sistema con volumen, corregir lo que falla y dejar documentado qué hacer si algo se cae durante el pico. ### ¿Qué es lo primero que suele romperse en un lanzamiento con mucho tráfico? Casi nunca es una sola pieza. Lo habitual es una cadena: un formulario que deja de enviar datos, registros duplicados que llegan al CRM, dos comerciales llamando al mismo lead o un grupo de WhatsApp lleno que convierte clics en registros perdidos. Por eso el checklist se revisa por capas y no herramienta a herramienta. ### ¿Hay que deduplicar antes o después de asignar los leads al equipo comercial? Antes, siempre. Si asignas primero y deduplicas después, tienes que deshacer un reparto que ya está en manos del equipo, con llamadas hechas y conversaciones abiertas. Evitar el duplicado en la entrada cuesta mucho menos que corregirlo en caliente. ### ¿Se puede usar el mismo sistema en el siguiente lanzamiento? Debería. Si cada lanzamiento se monta desde cero, pagas el mismo coste y repites los mismos errores. La idea es que captación, tracking, deduplicación, asignación y dashboards queden como un sistema documentado que se reutiliza y se mejora campaña a campaña. ### ¿El soporte técnico durante el lanzamiento está incluido? Sí, dentro de lo acordado en el proyecto. En FCG Systems, la disponibilidad en directo durante las ventanas críticas se define por escrito antes de empezar: qué horas, qué prioridades y cuánta capacidad queda reservada. Además, el plan de contingencia y la documentación forman parte del sistema para que el equipo sepa qué hacer. ## Servicios relacionados - [Infraestructura de lanzamientos](https://fcgsystems.es/servicios/infraestructura-de-lanzamientos/): Captación, tracking, reparto a tu equipo comercial y WhatsApp listos para miles de registros. - [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden. - [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/): Servidores, despliegues, backups y alertas para que tu operación no se caiga y sea tuya. ## Casos relacionados - [Infraestructura para lanzamientos con miles de registros](https://fcgsystems.es/casos/infraestructura-lanzamientos-alto-volumen/): Miles de registros desde cinco canales, sin duplicados, repartidos al equipo comercial y medidos mientras el lanzamiento sigue en marcha. - [CommunityRedirect: un enlace para no perder registros en grupos llenos](https://fcgsystems.es/casos/communityredirect-distribucion-comunidades-whatsapp/): Un enlace único que consulta la capacidad, rota destinos y evita enviar usuarios a grupos de WhatsApp llenos. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Software a medida o no-code: señales de que Make, n8n o Airtable se os han quedado cortos > Qué es el software a medida, cuándo compensa frente al no-code, señales de que Make, n8n o Airtable no bastan y cómo migrar por piezas sin parar la operación. - URL: https://fcgsystems.es/blog/de-no-code-a-software-a-medida/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 · Actualizado: 2026-09-16 (16 de septiembre de 2026) - Tema: Software · Formato: Breakdown · Lectura: 10 min - Palabra clave: software a medida (también: desarrollo de software a medida, de no-code a software a medida, no code, software a medida para empresas, cuándo dejar Airtable, backoffice a medida) El **software a medida** es software construido alrededor de tu operación (un backoffice, un panel comercial, un portal de alumnos, una API) en lugar de adaptar la operación a una herramienta genérica. Compensa frente al no-code cuando la lógica de negocio, el volumen o los permisos ya no caben en escenarios y bases compartidas. Pasar **de no-code a software a medida** significa mover los datos críticos y la lógica de negocio desde escenarios de Make, n8n, Zapier o bases de Airtable a una base de datos y un código propios, manteniendo en no-code solo lo que sigue funcionando bien. Casi nunca es tirarlo todo: es decidir qué pieza ya no aguanta y sustituirla. Lo digo porque es una conversación que se repite. El stack no-code hizo exactamente lo que tenía que hacer: permitió lanzar rápido, validar un funnel y conectar herramientas sin esperar a un equipo de desarrollo. El problema aparece después, cuando el negocio ya vende, el volumen crece y ese conjunto de escenarios pasa a ser la operación entera sin que nadie lo haya diseñado como tal. ## ¿Por qué un stack no-code que funcionaba empieza a fallar? Porque se construyó para resolver problemas sueltos y ahora sostiene un sistema. Cada escenario tiene sentido por separado: uno mete los registros del formulario en Airtable, otro avisa al comercial por WhatsApp, otro actualiza el CRM, otro genera el acceso al curso. Con cinco escenarios, cualquiera los entiende. Con cuarenta, la lógica del negocio está repartida entre herramientas, cuentas y personas distintas. Lo que falla no suele ser la herramienta. Make, n8n y Airtable son buenas herramientas. Falla que se les pide un papel para el que no se eligieron: ser la base de datos principal, el motor de reglas de negocio y el panel de control a la vez. ## ¿Qué señales indican que el no-code se os ha quedado corto? Estas son las que miro primero cuando reviso un stack. Una sola no justifica reescribir nada. Tres o cuatro juntas, sí justifican sentarse a diseñar. ### Señales en los datos - **Airtable hace de base de datos principal** y empieza a ir lenta con las vistas grandes, las fórmulas encadenadas o los registros vinculados. - **El mismo dato vive en tres sitios** (Airtable, CRM y una hoja) y ninguno coincide del todo. - **No hay forma fácil de saber qué pasó** con un registro concreto: quién lo tocó, qué escenario lo modificó y cuándo. - **Los permisos son todo o nada**: o alguien ve la base entera o no ve nada, y eso no encaja con setters, comerciales, soporte y dirección mirando lo mismo. ### Señales en la lógica - **Las reglas de negocio están dentro de los escenarios**: cómo se asigna un lead, qué cuenta como alumno activo, cuándo se revoca un acceso. Cambiar una regla obliga a tocar varios flujos. - **Hay escenarios que dependen del orden** en que se ejecutan otros, y nadie lo tiene documentado. - **Los reintentos duplican cosas**: un fallo a mitad de flujo y el reintento crea dos contactos o manda dos mensajes. - **Los errores se descubren tarde**, cuando alguien del equipo nota que falta algo. De esto hablo más en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/). ### Señales en el coste y la operación - **La factura crece con cada ejecución** y buena parte de esas ejecuciones son sondeos, filtros o pasos que no aportan nada. - **Estáis rozando límites** de operaciones, de registros o de tiempo de ejecución de vuestro plan, y la respuesta siempre es subir de plan. - **Una sola persona entiende el conjunto**. Si esa persona se va de vacaciones, nadie toca nada. - **Las herramientas marcan lo que se puede hacer**: "eso no se puede porque Make no lo permite" es una frase que aparece en reuniones de negocio. ## ¿Qué conviene mantener en no-code y qué pasar a código? La herramienta se elige según el sistema, no al revés. Esta tabla resume el criterio que aplico en FCG Systems. No es una regla fija, pero sirve para ordenar la conversación. | Pieza | Mantener en no-code cuando… | Pasar a código cuando… | |---|---|---| | Base de datos | El volumen es bajo, pocas personas la editan y no hay permisos finos | Es la fuente de verdad de contactos, ventas o accesos y la usan varios roles | | Reglas de negocio | Son simples, cambian poco y viven en un solo flujo | Se repiten en varios escenarios, tienen excepciones o afectan a dinero y accesos | | Integraciones entre SaaS | Son conexiones estándar con conectores mantenidos | Necesitan idempotencia, colas, reintentos controlados o volumen alto | | Avisos y notificaciones | Casi siempre: Slack, email, WhatsApp internos | Rara vez hace falta moverlos | | Paneles internos | Una vista de consulta para una persona | Varios roles con permisos distintos, acciones y auditoría | | Procesos de lanzamiento | Pruebas y campañas pequeñas | Picos de miles de registros en pocas horas | La idea de fondo: el no-code es muy bueno orquestando y conectando. Es peor como almacén de datos críticos y como sitio donde vive la lógica que define cómo funciona tu negocio. ## ¿Cómo es una arquitectura híbrida que funciona? La que más veces acaba teniendo sentido en negocios digitales (academias, infoproductores, comunidades, equipos comerciales) tiene cuatro capas: 1. **Postgres como fuente de verdad.** Contactos, compras, matrículas, asignaciones y accesos viven en una base de datos relacional con claves únicas, restricciones y un historial de cambios. Cada tipo de dato crítico tiene un sistema principal, y es este. 2. **Una API o capa de lógica propia.** Las reglas de negocio (a quién se asigna un lead, cuándo alguien tiene acceso, cómo se deduplica un registro) se escriben una vez, en TypeScript o Python, con tests. Herramientas como Xano pueden cubrir esta capa cuando el caso lo permite. 3. **Un backoffice a medida.** El panel donde setters, comerciales, soporte y dirección trabajan, cada uno con sus permisos. Es la parte que el equipo ve y la que más tiempo manual quita. 4. **Automatizaciones que orquestan.** n8n o Make siguen haciendo lo que hacen bien: escuchar webhooks, mover datos entre SaaS, lanzar avisos. La diferencia es que ya no deciden nada importante: llaman a la API y la API decide. Si la duda es cuál de las dos usar, está en [n8n vs Make](https://fcgsystems.es/blog/n8n-vs-make/); si n8n va en tu propio servidor, en [n8n self-hosted en producción](https://fcgsystems.es/blog/n8n-precios-cloud-self-hosted/). Con este reparto, cambiar una regla es tocar un sitio. Un escenario que falla se puede reintentar sin duplicar nada, porque la API comprueba si el registro ya existe. Y si mañana cambiáis de herramienta de email o de CRM, la fuente de verdad no se mueve. Esto encaja con cómo pienso los [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/) en general: automatización, software, IA e infraestructura como capas de un mismo sistema, no como compras sueltas. ## ¿Cómo se migra sin parar la operación? Por piezas. Una migración "big bang", donde se apaga lo viejo un lunes y se enciende lo nuevo, es la forma más rápida de romper un negocio que factura. El orden que sigo: ### 1. Mapear antes de tocar Inventario de escenarios, bases, hojas y cuentas: qué hace cada uno, qué datos lee y escribe, quién depende de él. Suele aparecer lógica duplicada y escenarios que ya nadie usa. Si el stack es grande, esto es literalmente un [Systems Audit](https://fcgsystems.es/servicios/arquitectura-de-sistemas/) de 5 a 10 días laborables. ### 2. Elegir la pieza que más duele No la más fácil ni la más bonita: la que más cuesta hoy en horas manuales, errores o ventas perdidas. Suele ser la gestión de leads y asignación comercial, o los accesos a la formación. ### 3. Crear la fuente de verdad y sincronizar Se monta la base de datos y la API para esa pieza, y durante un tiempo conviven los dos mundos: los escenarios existentes escriben también en el sistema nuevo. Así se compara con datos reales si el resultado coincide. ### 4. Cambiar el origen, no todo a la vez Cuando los datos coinciden, los escenarios pasan a leer del sistema nuevo. Después se retira la base antigua de esa pieza. El resto del stack sigue igual. ### 5. Repetir con la siguiente pieza Cada pieza migrada deja documentación, logs y un responsable claro. Un proceso crítico sin logs no está terminado. Un proceso crítico bien acotado suele encajar en un [Business System Build de software a medida](https://fcgsystems.es/servicios/software-a-medida/) de 3 a 8 semanas. Si lo que duele es un único cuello de botella, a veces basta un [Automation Sprint](https://fcgsystems.es/servicios/automatizacion-de-procesos/) de 1 a 3 semanas que rehaga ese flujo con idempotencia y logs, sin construir software todavía. ## ¿Construir software propio o contratar otro SaaS? Es la pregunta correcta y no siempre gana construir. Mi criterio: - **Contrata un SaaS** si el proceso no es el centro de tu negocio y una herramienta existente lo resuelve casi entero. Nadie necesita un sistema de facturación propio porque sí. El caso de libro es el CRM, con el criterio de coste desglosado en [CRM para pymes: de catálogo o a medida](https://fcgsystems.es/blog/crm-para-pymes-saas-o-a-medida/). - **Construye** si el proceso es tu forma de operar (cómo captas, asignas, vendes y das acceso), si el SaaS te obliga a vivir de parches o si las licencias crecen más rápido que el valor que aportan. - **Combina** en la mayoría de casos: SaaS para lo estándar, software propio para lo que te diferencia, automatizaciones para unirlo. Hay una trampa frecuente: sustituir un stack no-code desordenado por otro SaaS "todo en uno" sin haber diseñado el proceso. El desorden se muda de herramienta. Antes de comprar o construir, conviene saber qué sistema queréis tener. Y si lo que tenéis encima de la mesa no es un stack no-code sino una demo generada con IA, el salto tiene sus propias trampas: las repaso en [de prototipo a producción](https://fcgsystems.es/blog/de-prototipo-ia-a-produccion/). ### ¿Y quién es dueño de lo que se construye? Pregunta obligatoria antes de empezar. En FCG Systems el repositorio, la base de datos y las credenciales quedan a nombre de la empresa del cliente, y la arquitectura se documenta para que cualquier equipo técnico pueda continuar. Si el software lo mantiene luego tu equipo o lo mantenemos nosotros como [partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/), es una decisión que se toma con el plan de mantenimiento, no una dependencia oculta. ## Un escenario para aterrizarlo Imagina una academia online que capta con formularios de Tally, guarda todo en Airtable, asigna leads a cuatro setters con un escenario de Make, agenda llamadas con Calendly y da acceso a la plataforma formativa con otro escenario. Durante un lanzamiento, Airtable empieza a ir lenta, dos setters llaman al mismo lead porque el escenario de asignación se ejecutó dos veces tras un error, y un alumno que pagó no recibe acceso porque un paso falló sin avisar. Nadie sabe cuántos casos más hay. La migración por piezas sería: 1. Postgres para contactos, compras y accesos, con una clave única por persona. 2. Una API que asigna leads por reglas y capacidad, y que no asigna dos veces el mismo registro. 3. Un backoffice donde cada setter ve solo sus leads y dirección ve el conjunto. 4. Tally, Calendly y la plataforma formativa siguen donde están; Make escucha sus webhooks y llama a la API. 5. Logs y alertas en los flujos de pago y acceso (cómo dar y quitar accesos según el estado del pago está en [pagos fallidos en Stripe y control de accesos](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/)). Tally no se cambia. Calendly tampoco. Lo que cambia es dónde vive la verdad y quién decide. ## Checklist para decidir si dar el salto - Tenemos un inventario de escenarios, bases y hojas con lo que hace cada uno. - Sabemos qué sistema es la fuente de verdad de contactos, ventas y accesos. - Hemos contado cuántos escenarios contienen reglas de negocio repetidas. - Hay logs y alertas en los flujos que tocan dinero o accesos. - Los reintentos no duplican registros ni mensajes. - Más de una persona entiende cómo funciona el conjunto. - Sabemos cuánto crece la factura de herramientas por volumen. - Hemos identificado la pieza que más cuesta hoy (horas, errores o ventas). - Hemos valorado si un SaaS existente resuelve esa pieza antes de construir. - Está claro a nombre de quién quedan código, base de datos y credenciales. Si marcáis pocas casillas, el primer paso no es escribir código: es diseñar el sistema. ## ¿Por dónde empezar con vuestro stack? No hace falta decidir hoy entre no-code y software a medida. Hace falta saber qué pieza está frenando la operación y qué pasaría si mañana duplicaseis el volumen. A partir de ahí la herramienta sale sola. Si tu stack ya se parece a los cuarenta escenarios de los que hablaba al principio, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y lo miramos juntos. Y si estáis valorando meter IA en alguno de esos flujos, antes echa un vistazo a [dónde la IA aplicada ahorra trabajo de verdad](https://fcgsystems.es/blog/ia-aplicada-negocios-digitales/). ## Preguntas frecuentes ### ¿Qué es el software a medida? Es software construido alrededor de la operación de una empresa en lugar de adaptar la empresa a una herramienta genérica: paneles internos, CRMs verticales, portales, backoffices o APIs. En un negocio digital suele convivir con SaaS y automatizaciones, que siguen resolviendo lo estándar. ### ¿Hay que abandonar Make, n8n o Airtable para pasar a software a medida? No. Lo habitual es un sistema híbrido: los datos críticos y la lógica de negocio pasan a una base de datos y a código propio, y las herramientas no-code siguen orquestando integraciones y avisos. Se retira solo lo que ya no aguanta. ### ¿Cuánto se tarda en pasar de no-code a software propio? Depende de cuántas piezas haya que mover. Un proceso crítico bien acotado suele encajar en un Business System Build de 3 a 8 semanas. Migrar por piezas permite que el negocio siga funcionando mientras tanto. ### ¿El software que se construye es nuestro? Sí. En FCG Systems el repositorio, la base de datos y las credenciales quedan a nombre de tu empresa, y la arquitectura se documenta para que cualquier equipo técnico pueda continuar el trabajo. ### ¿Cuándo compensa contratar un SaaS en lugar de construir? Cuando el proceso no es central para tu negocio y una herramienta existente lo resuelve casi entero. Construir compensa cuando el proceso es tu forma de operar, el SaaS obliga a vivir de parches o las licencias crecen más rápido que el valor que aportan. ## Servicios relacionados - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # Webhook de n8n que no funciona: causas, cómo diagnosticarlo y cómo evitar que vuelva a fallar > Por qué un webhook de n8n funciona en pruebas y no en producción, qué significan 404 y 524 y cómo diagnosticarlo paso a paso sin perder los datos que llegan. - URL: https://fcgsystems.es/blog/webhook-n8n-no-funciona/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 (15 de septiembre de 2026) - Tema: Automatización · Formato: Breakdown · Lectura: 9 min - Palabra clave: webhook n8n no funciona (también: n8n webhook error, test url vs production url n8n, webhook n8n 404, n8n error trigger) Cuando un webhook de n8n no funciona, casi siempre es por una de estas causas: la plataforma de origen apunta a la Test URL en lugar de la Production URL, el workflow no está publicado, el método o la ruta no coinciden, o n8n está detrás de un reverse proxy y registra una URL que no es accesible desde fuera. En n8n Cloud hay una más: si el webhook tarda más de 100 segundos en responder, la petición falla con un 524. La parte que más confunde es que las ejecuciones de producción no aparecen en el editor, así que parece que "no llega nada" cuando en realidad sí llegó. Esta guía ordena el diagnóstico de lo más probable a lo menos probable, con la comprobación concreta para cada caso, y termina con lo que hay que añadir para que el siguiente fallo no pase días sin que nadie lo vea. Da por sabido [cómo está montado n8n](https://fcgsystems.es/blog/que-es-n8n/) y cómo se lee una ejecución. ## ¿Qué diferencia hay entre Test URL y Production URL? Cada nodo Webhook genera dos URL, y la mitad de los problemas vienen de mezclarlas. Según la [documentación de problemas comunes del nodo Webhook](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/common-issues/) (consultado en septiembre de 2026): | | Test URL | Production URL | |---|---|---| | Cómo se activa | Pulsando **Listen for test event** y enviando un evento de prueba | Publicando el workflow | | Cuánto tiempo escucha | 120 segundos | Hasta que despublicas el workflow | | ¿Se ven los datos en el editor? | Sí | No: se consultan en la pestaña **Executions** | La consecuencia práctica: si pegaste la Test URL en tu formulario, tu pasarela de pago o tu CRM, funcionará mientras tengas el editor abierto escuchando y dejará de funcionar en cuanto cierres la pestaña. Y si usas la Production URL, no busques los datos en el lienzo: abre **Executions** y selecciona la ejecución. La ruta de la Production URL contiene `/webhook/` y la de la Test URL `/webhook-test/` en la configuración por defecto, así que basta con mirar la URL configurada en el origen para descartar esta causa. ## ¿Cómo diagnostico un webhook de n8n que no se ejecuta? Sigue la tabla en orden. Cada fila se comprueba en minutos. | Síntoma | Causa probable | Cómo comprobarlo | Solución | |---|---|---|---| | Funciona al probar, deja de funcionar después | El origen usa la Test URL | Mira la URL configurada en la plataforma que envía | Sustitúyela por la Production URL | | La Production URL no responde o devuelve 404 | El workflow no está publicado, o la ruta o el método no coinciden | Estado del workflow y método HTTP configurado en el nodo | Publica el workflow; iguala método y ruta con lo que envía el origen | | Aviso de que la ruta ya está en uso | Otro workflow publicado usa la misma ruta y método | Busca otros workflows con esa ruta | Despublica el conflictivo o cambia ruta o método | | Llega un GET pero el nodo espera POST (o al revés) | El nodo acepta un solo método por defecto | Método del emisor frente al del nodo | Cambia el método o activa **Allow Multiple HTTP Methods** en Settings | | En self-hosted, la URL que muestra n8n usa `localhost`, el puerto 5678 o `http` | n8n está detrás de un reverse proxy sin URL pública configurada | URL mostrada en el nodo frente a tu dominio real | Define `N8N_WEBHOOK_URL` con tu dominio y `N8N_PROXY_HOPS=1` | | Peticiones desde IP permitidas rechazadas | Reverse proxy delante de n8n | ¿Hay proxy entre internet y n8n? | Ajusta `N8N_PROXY_HOPS` al número de proxies | | Error 524 en n8n Cloud | El webhook no responde en 100 segundos | Duración de las ejecuciones que fallan | Responde de inmediato y procesa después | | Falla con envíos grandes o archivos | Supera el tamaño máximo de payload (16 MiB por defecto) | Tamaño de la petición | En self-hosted, `N8N_PAYLOAD_SIZE_MAX`; mejor aún, enviar un enlace al archivo | | El origen dice "enviado" pero no hay ejecución | La petición no llega a n8n | Registro de entregas del emisor y logs del proxy | Revisa DNS, certificado y firewall; prueba con curl | ### El caso del reverse proxy en n8n self-hosted Si alojas n8n tú mismo detrás de Nginx, Traefik o similar, n8n construye la URL del webhook con su protocolo, host y puerto internos, que no son los que ve internet. La [guía de webhooks detrás de un reverse proxy](https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/configure-webhook-urls-with-reverse-proxy/) (consultado en septiembre de 2026) indica tres cosas: - Definir `N8N_WEBHOOK_URL` con la URL pública, para que n8n muestre y registre la dirección correcta. `WEBHOOK_URL` sigue funcionando como alias, pero está marcada como obsoleta desde la versión 2.35.0. - Definir `N8N_PROXY_HOPS=1`. - Que el último proxy reenvíe las cabeceras `X-Forwarded-For`, `X-Forwarded-Host` y `X-Forwarded-Proto`. ```bash export N8N_WEBHOOK_URL=https://n8n.tudominio.com/ export N8N_PROXY_HOPS=1 ``` Este fallo es especialmente traicionero con integraciones que registran el webhook automáticamente en el servicio externo: n8n registra una URL interna y el servicio nunca consigue entregar nada. Si estás montando o revisando tu instancia, lo cuento con más contexto en la guía de [n8n self-hosted en producción](https://fcgsystems.es/blog/n8n-precios-cloud-self-hosted/). ### El caso del 524 en n8n Cloud n8n Cloud pasa por Cloudflare y, si el webhook no responde en 100 segundos, la petición falla con un 524. Ocurre cuando el nodo está configurado para responder al terminar el último nodo y el workflow hace algo lento: llamar a una IA, generar un documento o esperar a otra API. El nodo Webhook tiene tres modos de respuesta: **Immediately**, **When Last Node Finishes** y **Using 'Respond to Webhook' Node**. Para procesos largos, la documentación propone responder enseguida y separar el trabajo: un webhook que inicia el proceso y contesta al momento, y otro que se consulta para conocer el estado y recoger el resultado. ## ¿Cómo pruebo el webhook sin depender de la plataforma de origen? Con curl, desde tu ordenador. Así separas "n8n no recibe" de "el origen no envía". La documentación oficial usa ejemplos como estos (sustituye la URL por la tuya y el método por el que tengas configurado): ```bash # Petición sin parámetros curl --request GET https://tu-n8n.com/webhook/ruta # Petición con un parámetro en el cuerpo curl --request POST https://tu-n8n.com/webhook/ruta --data 'key=value' ``` Si curl llega y la plataforma no, el problema está en el origen: URL mal copiada, método distinto, autenticación o un envío que ni siquiera se dispara. Si curl tampoco llega, el problema está en n8n o en lo que tiene delante: publicación, ruta, proxy, DNS o certificado. Con la Production URL, después de lanzar la petición, comprueba la pestaña **Executions**. Si la ejecución aparece, el webhook funciona y el fallo está más adelante en el workflow. ## ¿Por qué el workflow se ejecuta dos veces? Porque los emisores de webhooks reintentan. Si tu endpoint tarda en responder o devuelve un error, el emisor vuelve a enviarlo, y algunos avisan de que un mismo evento puede llegar más de una vez aunque todo vaya bien: - Stripe reintenta la entrega en modo live durante un máximo de tres días con retroceso exponencial y documenta que un endpoint puede recibir el mismo evento más de una vez. Recomienda registrar los identificadores de evento ya procesados ([webhooks de Stripe](https://docs.stripe.com/webhooks), consultado en septiembre de 2026). - Hotmart reintenta automáticamente las notificaciones con error hasta cinco veces o hasta recibir una respuesta correcta ([webhook de Hotmart](https://help.hotmart.com/es/article/360001491352/-como-configuro-la-api-de-mi-producto-usando-el-webhook-postback-), consultado en septiembre de 2026). En el foro oficial de n8n hay hilos abiertos justo con estos síntomas, tanto de [webhooks que funcionan con la Test URL y no en producción](https://community.n8n.io/t/production-webhook-not-triggering-but-test-url-works/134549) como de [ejecuciones duplicadas por webhook](https://community.n8n.io/t/webhook-receiving-duplicate-executions-doubling-execution-count/197126). Borrar el contacto duplicado de hoy no resuelve nada. La solución es que el workflow sea idempotente: antes de crear un contacto, dar un acceso o registrar un pago, comprueba si ese identificador de evento o de pedido ya se procesó. Si varias ejecuciones pueden llegar a la vez, esa comprobación tiene que apoyarse en algo que garantice unicidad, como una restricción única en la base de datos, y no solo en una búsqueda previa. ## ¿Qué errores comunes conviene evitar? - **Dejar la Test URL en producción** porque "funcionaba" durante la prueba. - **Buscar los datos de producción en el editor** y concluir que no llega nada. - **Duplicar un workflow publicado** y olvidar que el webhook de la copia comparte ruta y método. - **Poner un proceso largo antes de responder** en n8n Cloud y encontrarse con 524 y reintentos del emisor. - **Actualizar el proxy o el dominio** sin revisar `N8N_WEBHOOK_URL`. - **Arreglar el síntoma y no el riesgo:** el webhook vuelve a funcionar, pero nadie recupera los eventos que se perdieron mientras fallaba ni se entera la próxima vez. ## ¿Cómo evito que el webhook vuelva a fallar sin que nadie lo vea? Un webhook caído no genera errores en n8n: si no llega la petición, no hay ejecución que falle. Por eso hacen falta varias capas, que desarrollo en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/): 1. **Error workflow.** Crea un workflow que empiece con el nodo [Error Trigger](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.errortrigger/) (consultado en septiembre de 2026) y asígnalo en **Settings > Error workflow** del workflow crítico. Se ejecuta cuando ese workflow falla en una ejecución automática; no se dispara con ejecuciones manuales, así que no lo des por probado lanzándolo a mano. 2. **Idempotencia** por identificador de evento, para que los reintentos del emisor no dupliquen nada. 3. **Heartbeat.** Si un webhook recibe normalmente registros cada hora y lleva varias horas sin ejecuciones, alguien tiene que recibir un aviso. Es la única forma de detectar el webhook que ha dejado de llegar. 4. **Reconciliación.** Compara cada día lo que registra el origen (pagos, formularios) con lo que llegó al destino. 5. **Dueño de la alerta.** Una persona concreta, no un canal compartido que nadie mira. ## Checklist para un webhook de n8n en producción - El origen usa la Production URL, no la Test URL. - El workflow está publicado y ningún otro usa la misma ruta y método. - El método HTTP del nodo coincide con el del emisor. - En self-hosted detrás de proxy, `N8N_WEBHOOK_URL` y `N8N_PROXY_HOPS` están definidos y las cabeceras `X-Forwarded-*` se reenvían. - El webhook responde rápido; los procesos largos van después de la respuesta. - Hay una prueba con curl documentada para cada webhook crítico. - El workflow comprueba el identificador del evento antes de crear, cobrar o dar acceso. - Tiene asignado un error workflow con alerta a una persona concreta. - Existe un aviso si el webhook lleva demasiado tiempo sin recibir nada. - Se sabe cómo reenviar desde el origen los eventos perdidos mientras falló. ## ¿Cuándo conviene delegarlo? Si es un webhook de un formulario secundario, esta guía debería bastar. Conviene que lo mire alguien con criterio de sistema cuando el webhook sostiene algo que cuesta dinero o clientes si falla: pagos, altas de alumnos, asignación de leads o registros de un lanzamiento; cuando la instancia de n8n es self-hosted y nadie tiene claro cómo está montada; o cuando el fallo ya ha pasado varias veces y cada arreglo es un parche. En esos casos el trabajo no es "arreglar el webhook", sino rehacer el flujo para que sea observable: idempotencia, logs por registro, alertas con dueño y reproceso de lo que se pierde. Es lo que hacemos en un Automation Sprint dentro del servicio de [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/), y si el origen del problema está en el servidor, el proxy o los backups, lo abordamos con [infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/). Para ver cómo encaja cada flujo en el conjunto de la operación, tienes la guía de [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/). Si tienes un webhook crítico que falla de vez en cuando y nadie sabe por qué, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y lo revisamos. ## Preguntas frecuentes ### ¿Qué diferencia hay entre la Test URL y la Production URL de un webhook de n8n? La Test URL solo escucha durante 120 segundos después de pulsar Listen for test event y muestra los datos en el editor. La Production URL queda registrada cuando publicas el workflow y sigue activa hasta que lo despublicas, pero sus datos no aparecen en el editor, sino en la pestaña Executions. ### ¿Por qué el webhook funciona en pruebas y no en producción? Las causas más habituales son que la plataforma de origen tiene configurada la Test URL, que el workflow no está publicado, que otro workflow publicado ya usa la misma ruta y método, o que n8n está detrás de un reverse proxy sin N8N_WEBHOOK_URL definida y registra una URL que no es accesible desde fuera. ### ¿Por qué no veo los datos de la ejecución en el editor de n8n? Porque las ejecuciones que entran por la Production URL no se muestran en el lienzo del editor. Para ver qué recibió el webhook hay que abrir la pestaña Executions del workflow y seleccionar la ejecución concreta. Si allí tampoco aparece, la petición no llegó a n8n o no coincidía con la ruta y el método. ### ¿Por qué mi workflow de n8n se ejecuta dos veces con el mismo webhook? Muchos emisores reintentan cuando no reciben respuesta a tiempo o reciben un error, y algunos pueden entregar el mismo evento más de una vez. Stripe, por ejemplo, documenta entregas duplicadas. La solución no es solo quitar el duplicado de hoy: el workflow tiene que comprobar el identificador del evento antes de crear o cobrar nada. ### ¿Qué significa el error 524 en un webhook de n8n Cloud? n8n Cloud usa Cloudflare, y si el webhook no responde en 100 segundos la petición falla con un 524. Suele pasar cuando el webhook espera a que termine un proceso largo. Se resuelve respondiendo de inmediato y procesando después, o separando el trabajo en un webhook que inicia el proceso y otro que consulta su estado. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Infraestructura y DevOps](https://fcgsystems.es/servicios/infraestructura-devops/): Servidores, despliegues, backups y alertas para que tu operación no se caiga y sea tuya. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # WhatsApp Business API: qué es, cuánto cuesta y cuándo usarla para vender, automatizar o poner un chatbot > Qué es la WhatsApp Business API, en qué se diferencia de la app, cómo cobra Meta, sus límites y cuándo compensa para ventas, automatización o un chatbot con IA. - URL: https://fcgsystems.es/blog/whatsapp-business-api/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-15 · Actualizado: 2026-09-16 (16 de septiembre de 2026) - Tema: Automatización · Formato: Breakdown · Lectura: 10 min - Palabra clave: whatsapp business api (también: whatsapp api, api de whatsapp, whatsapp business api precio, chatbot whatsapp, agente ia whatsapp, api no oficial whatsapp) La **WhatsApp Business API** (hoy, la Cloud API de la plataforma WhatsApp Business de Meta) es la vía oficial para que tus sistemas envíen y reciban mensajes de WhatsApp por programación: conectarlo a un CRM, a automatizaciones o a un chatbot. La app **WhatsApp Business** sirve mientras las conversaciones las lleva una persona desde un móvil. Meta cobra la API por plantilla entregada, y compensa cuando el volumen o el coste de perder un lead por WhatsApp justifican pagar por mensaje y montar la integración. En un negocio digital WhatsApp suele empezar como el teléfono de alguien del equipo y acabar siendo el canal por el que entra buena parte de las ventas: registros de un lanzamiento, dudas antes de comprar, llamadas que se agendan por chat. El problema aparece cuando ese canal crítico sigue funcionando como un móvil compartido. Esta guía explica qué es la API con lo que publica Meta, en qué se diferencia de la app, cómo cobra, cuándo tiene sentido un chatbot o un agente de IA encima y qué conviene preparar antes de migrar. ## ¿Qué diferencia hay entre la app WhatsApp Business y la API oficial? | Aspecto | App WhatsApp Business | API oficial (Cloud API) | |---|---|---| | Quién envía | Una persona desde la app | Tus sistemas, por programación, y personas desde una herramienta conectada | | Integración con CRM y automatizaciones | Manual | Nativa: webhooks para recibir mensajes y API para enviarlos | | Iniciar conversaciones | Libremente, dentro de las normas de WhatsApp | Solo con plantillas aprobadas fuera de la ventana de atención de 24 horas | | Coste por mensaje | No hay tarifa por mensaje | Meta cobra por plantilla entregada según categoría y país | | Límites de envío | Los de uso normal de la app | Límite de destinatarios únicos en 24 horas que crece por niveles | | Varios agentes y trazabilidad | Limitado | Depende de la herramienta conectada (CRM, bandeja compartida, software propio) | | Consentimiento | Responsabilidad del negocio | Meta exige opt-in explícito para mensajes fuera de la ventana | La diferencia de fondo no es técnica. La app es una herramienta de conversación. La API es una pieza de sistema: recibe eventos, deja registro y se gobierna con reglas, igual que el resto de integraciones del negocio. ## ¿Cómo funciona la API oficial por dentro? Tres conceptos explican casi todo, según la [documentación de la plataforma](https://developers.facebook.com/docs/whatsapp/overview) (consultado en septiembre de 2026): ### La ventana de atención de 24 horas Cuando un usuario te escribe se abre una ventana de atención de 24 horas. Dentro de ella puedes responder con mensajes libres. Fuera de ella, **las plantillas son el único tipo de mensaje que puedes enviar**. ### Las plantillas Una plantilla es un mensaje predefinido que Meta revisa antes de que puedas usarlo. Según la documentación de [plantillas de mensaje](https://developers.facebook.com/docs/whatsapp/business-management-api/message-templates) (consultado en septiembre de 2026): - Cada plantilla se clasifica como **marketing**, **utilidad** o **autenticación**. - Tiene que estar en estado aprobado para poder enviarse. La revisión puede tardar hasta 24 horas. - Tiene una valoración de calidad basada en uso, feedback y engagement, y puede quedar pausada por feedback negativo recurrente o bajas tasas de lectura. En la práctica, esto obliga a planificar: las plantillas de un lanzamiento se preparan y se aprueban antes de abrir registros, no la mañana del directo. El [checklist técnico de un lanzamiento](https://fcgsystems.es/blog/checklist-tecnico-lanzamiento/) tiene sentido también aquí. ### Los límites de envío Los [límites de mensajería](https://developers.facebook.com/docs/whatsapp/messaging-limits) (consultado en septiembre de 2026) marcan a cuántos números únicos puede enviar tu negocio fuera de la ventana de atención en un periodo móvil de 24 horas. Una cartera nueva empieza en 250 y puede subir a 2.000, 10.000, 100.000 o sin límite. Se amplía verificando el negocio, mediante la verificación de un partner o enviando 2.000 mensajes entregados fuera de la ventana a números únicos en 30 días con plantillas de buena calidad. Las respuestas dentro de la ventana de atención no cuentan para ese límite. Si tu plan es escribir a miles de registros el primer día de un lanzamiento con un número recién conectado, el límite inicial lo impide. Hay que escalarlo antes. ## ¿Cómo cobra Meta la API de WhatsApp? Según la [página de precios de la plataforma](https://developers.facebook.com/docs/whatsapp/pricing) (consultado en septiembre de 2026): - Desde el 1 de julio de 2025 **se cobra por mensaje**: solo pagas cuando se entrega una plantilla. - Las plantillas de **marketing** se cobran siempre. - Las de **utilidad** y **autenticación** se cobran fuera de la ventana de atención. Las de utilidad entregadas dentro de una ventana abierta son gratuitas. - Los mensajes que no son plantilla dentro de la ventana de atención son gratuitos. - La tarifa depende del país del destinatario. España tiene tarifa propia, y Meta ha revisado durante 2026 la de marketing: consulta siempre la tabla vigente. No doy cifras por mensaje porque cambian con frecuencia y dependen del país. A la tarifa de Meta se suma lo que cobre el proveedor o la herramienta que uses para conectarte. Antes de migrar, calcula con tu volumen real: cuántas plantillas de marketing envías al mes, cuántas de utilidad y cuántas conversaciones empiezan los propios clientes. ## ¿Chatbot o agente de IA en WhatsApp: qué necesitas? Buena parte de quien busca la API quiere en realidad [un chatbot](https://fcgsystems.es/blog/que-es-un-chatbot/). Conviene separar las piezas: **la API es el canal**, y el chatbot o el agente es la lógica que decide qué responder. Esa lógica puede vivir en una herramienta que ya integre la API, en un flujo de n8n o Make, o en software propio. | Opción | Cómo decide | Encaja cuando | Riesgo principal | |---|---|---|---| | Menú o respuestas por reglas | Árbol de opciones y palabras clave | Preguntas repetidas y previsibles: horarios, accesos, enlaces | Frustra cuando la pregunta se sale del guion | | Chatbot con IA sobre tu base de conocimiento | Un modelo redacta la respuesta a partir de tus contenidos | Muchas dudas distintas sobre el mismo producto o curso | Respuestas inventadas si la base de conocimiento es pobre o no se controla | | Agente de IA con herramientas | Un modelo decide qué acciones tomar: consultar el CRM, reservar, derivar | Tareas con varios pasos y datos de varios sistemas | Acciones equivocadas si tiene más permisos de los necesarios | En los tres casos se aplican las mismas reglas de la plataforma: fuera de la ventana de 24 horas solo puedes escribir con plantillas aprobadas, y cada conversación tiene que poder pasar a una persona. Cuándo compensa un agente y cómo se construye con límites y aprobación humana lo explico en [agentes de IA para negocios](https://fcgsystems.es/blog/agentes-de-ia-para-negocios/). Si prefieres que lo montemos nosotros, es el trabajo de [chatbots y agentes de IA conectados a tus sistemas](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/). ## ¿Qué pasa con el número que ya uso en la app? Meta permite incorporar a la Cloud API un número que ya usa la app WhatsApp Business, lo que suele llamarse coexistencia. Según la documentación para [incorporar usuarios de la app a la Cloud API](https://developers.facebook.com/docs/whatsapp/embedded-signup/custom-flows/onboarding-business-app-users) (consultado en septiembre de 2026): - Se pueden sincronizar los contactos y los chats individuales de los últimos 6 meses si el negocio lo aprueba, y los mensajes quedan reflejados en la app y en la API. - En la app siguen igual los grupos, las llamadas, el catálogo, las respuestas rápidas y las etiquetas, pero nada de eso pasa a la API: los chats de grupo no se sincronizan. - Las listas de difusión se desactivan (las existentes quedan en solo lectura), y en los chats individuales se desactivan los mensajes temporales, los de visualización única y la ubicación en tiempo real. - El rendimiento de envío queda fijado en 20 mensajes por segundo. - Requiere la versión 2.24.17 o superior de la app y hacerlo a través de un proveedor que ofrezca este flujo. Es una buena opción cuando el número tiene historial y reputación entre tus clientes. Revisa antes si tu equipo depende de las listas de difusión de ese número y ten en cuenta que lo que ocurra en grupos no llegará a tu CRM por la API. ## ¿Por qué no usar una API no oficial? Porque convierte el canal de ventas en un riesgo que no controlas. Las herramientas no oficiales conectan un número normal simulando una sesión de WhatsApp Web. Las [condiciones del servicio de WhatsApp](https://www.whatsapp.com/legal/terms-of-service-eea) (consultado en septiembre de 2026) prohíben, entre otras cosas, crear cuentas por medios no autorizados o automatizados y recopilar información de los usuarios de forma no autorizada, y contemplan suspender o cerrar las cuentas que incumplan sus términos. La decisión se parece a la de cualquier otra pieza crítica del sistema: si ese número es por donde entran las ventas de un lanzamiento, perderlo a mitad de campaña cuesta más que la diferencia de precio. ## Cómo pasar a la API oficial paso a paso ### 1. Decide qué conversaciones van por la API Separa los flujos: avisos automáticos (confirmación de registro, recordatorio de directo, acceso al curso), conversaciones comerciales y soporte. Cada uno tiene una categoría de plantilla, un responsable y un coste distinto. ### 2. Revisa el consentimiento La [política de opt-in](https://developers.facebook.com/docs/whatsapp/overview/getting-opt-in) (consultado en septiembre de 2026) exige que la persona sepa que acepta recibir mensajes y de qué negocio. Añade ese consentimiento a formularios y páginas de registro y guárdalo en el CRM junto al contacto. Enviar sin opt-in degrada la calidad del número y acaba en limitaciones. ### 3. Define la fuente de verdad del contacto El CRM decide quién es cada contacto, de dónde viene y quién es su responsable. WhatsApp es un canal, no la base de datos. Si hoy los leads viven en el móvil de un comercial o en un Excel, empieza por ahí: lo explico en [leads que se pierden y Excel como CRM](https://fcgsystems.es/blog/leads-perdidos-excel-como-crm/). ### 4. Conecta la API a tus sistemas Con una herramienta que ya integre la API (CRM o bandeja compartida) o con un flujo propio en n8n o Make que reciba los webhooks de mensajes entrantes y envíe plantillas cuando ocurre un evento. Si dudas entre ambas plataformas, la comparativa [n8n vs Make](https://fcgsystems.es/blog/n8n-vs-make/) ayuda a decidir. ### 5. Prepara y aprueba las plantillas con antelación Redacta, envía a revisión y prueba cada plantilla antes de necesitarla. Ten una alternativa si una plantilla se pausa. ### 6. Escala los límites antes del pico Verifica el negocio y sube de nivel antes de un lanzamiento. El día del pico no es momento de descubrir que solo puedes escribir a 250 números. ### 7. Añade logs y avisos Registra cada envío y su estado. Si las plantillas empiezan a fallar o a pausarse, alguien tiene que enterarse el mismo día. ## Errores comunes al llevar las ventas por WhatsApp - **Seguir con un móvil compartido cuando ya hay volumen.** Nadie sabe qué se respondió, a quién y cuándo. - **Tratar WhatsApp como el CRM.** Las conversaciones no sustituyen a una ficha con origen, estado y responsable. - **Montar la operación sobre una API no oficial.** Funciona hasta el día que deja de hacerlo. - **Enviar sin consentimiento documentado.** Afecta a la calidad del número y a los límites. - **Preparar plantillas el mismo día.** La revisión puede tardar hasta 24 horas. - **No escalar límites antes de un lanzamiento.** El límite inicial es bajo para una campaña con miles de registros. - **No calcular el coste por categoría.** Una estrategia basada en plantillas de marketing cuesta muy distinto que una basada en conversaciones iniciadas por el cliente. ## Checklist antes de migrar a la API oficial - Flujos de WhatsApp separados por tipo: avisos, comercial y soporte. - Consentimiento explícito recogido en formularios y guardado en el CRM. - CRM definido como fuente de verdad de contactos y responsables. - Decidido si el número actual se incorpora con coexistencia o se usa uno nuevo. - Revisado si el equipo depende de listas de difusión de ese número. - Plantillas redactadas, clasificadas y aprobadas antes de necesitarlas. - Coste mensual estimado por categoría con la página de precios de Meta. - Negocio verificado y límites escalados antes del próximo pico. - Webhooks de mensajes entrantes conectados y probados. - Logs de envíos y avisos cuando fallan o se pausan plantillas. ## ¿Cuándo conviene delegarlo? Si WhatsApp es un canal de soporte con poco volumen y una persona lo atiende bien desde la app, no hace falta cambiar nada. Conviene hacerlo con alguien que diseñe el sistema completo cuando WhatsApp forma parte del circuito comercial (formulario, CRM, asignación, seguimiento), cuando hay varios agentes o setters, cuando los lanzamientos concentran miles de registros en pocos días o cuando ya dependes de una conexión no oficial. Lo resolvemos dentro de la [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/) y, si el pico está en un lanzamiento, como parte de la [infraestructura de lanzamientos](https://fcgsystems.es/servicios/infraestructura-de-lanzamientos/). La guía de [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/) explica cómo encaja esta pieza con el resto. Si tu WhatsApp ya es un canal de ventas y sigue funcionando como un móvil compartido, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/). ## Preguntas frecuentes ### ¿Qué es la WhatsApp Business API y en qué se diferencia de la app? La app WhatsApp Business está pensada para que personas atiendan conversaciones desde un móvil o un ordenador. La API oficial, la Cloud API de la plataforma WhatsApp Business, permite que tus sistemas envíen y reciban mensajes por programación: conectarla a un CRM, a n8n o a tu propio software, con plantillas aprobadas y límites de envío definidos por Meta. ### ¿Cuánto cuesta la API oficial de WhatsApp? Meta cobra por plantilla entregada desde el 1 de julio de 2025, con tarifas según la categoría del mensaje y el país del destinatario. Los mensajes que no son plantilla dentro de la ventana de atención de 24 horas son gratuitos, y las plantillas de utilidad dentro de esa ventana también. Las tarifas cambian con frecuencia: consulta siempre la página de precios de Meta y el margen de tu proveedor. ### ¿Puedo usar la app WhatsApp Business y la API con el mismo número? Meta permite incorporar a la Cloud API un número que ya usa la app WhatsApp Business, a través de un proveedor que lo soporte. El número sigue pudiendo enviar mensajes individuales desde la app, pero se desactivan funciones como las listas de difusión y el rendimiento de envío queda fijado en 20 mensajes por segundo. ### ¿Es seguro usar una API no oficial de WhatsApp? Es un riesgo operativo. Las condiciones de WhatsApp prohíben usar el servicio por medios no autorizados o automatizados y contemplan suspender cuentas que las incumplan. Si el número con el que vendes es crítico, depender de una conexión que puede desaparecer sin aviso no es una decisión técnica menor. ### ¿Necesito la API para tener un chatbot o un agente de IA en WhatsApp? Para automatizar respuestas desde tus propios sistemas, sí: la API es la vía oficial para recibir mensajes por webhook y responder por programación. El chatbot o el agente es la lógica que decide qué contestar; la API solo es el canal. Conviene que tenga traspaso a una persona y que no invente información. ## Servicios relacionados - [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano. - [Infraestructura de lanzamientos](https://fcgsystems.es/servicios/infraestructura-de-lanzamientos/): Captación, tracking, reparto a tu equipo comercial y WhatsApp listos para miles de registros. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable. --- # English --- # FCG Systems: We build the system that puts you in control of your online education business. > We build the system that puts you in control of your online education business: a CRM for setters and closers, an academy where students pay and get in on their own, and custom development. Source: https://fcgsystems.es/en/ A CRM built around your sales process, an academy where students pay and get in on their own, and whatever development sits in between. All in your name and documented. ## FCG Systems at a glance - **What it is:** FCG Systems is a technology company that builds the systems behind online education businesses that already sell: a custom CRM, an academy where students pay and get in on their own, and whatever custom development is needed, handled as one system. - **Where:** Based in Huelva, Spain, working remotely with clients in Madrid, Barcelona, Andorra and Dubai. - **Who runs it:** Founded by Gabriel Florencio Calvo, who went from setter to the technical team of a large online education business. Whoever designs the solution is on the project from the first call. If another specialist is needed, the client knows and approves it before signing. - **Legal form:** The professional practice of Gabriel Florencio Calvo, a self-employed professional (NIF 49236244Y) based in Huelva. - **Who it is for:** Founders of online education and info-product businesses that already sell on a recurring basis, with setters, closers and support, and their CTOs and CMOs. Also creative and marketing agencies that need a technical partner for their clients. - **How engagements work:** Fixed-scope projects at a fixed price per phase (Systems Audit in 5 to 10 working days, Automation Sprint in 1 to 3 weeks, Business System Build in 3 to 8 weeks, AI Workflow and Launch Infrastructure) or a monthly Technology Partner fee with Core, Growth and Scale plans. Everything stays in the client’s name and documented. - **What it is not:** Not a marketing agency, not IT support and not developers for hire without technical direction or a business goal. - **In-house product:** CommunityRedirect, a system that spreads launch traffic across WhatsApp groups and communities without sending anyone to a full group. - **Contact:** hola@fcgsystems.es. Replies within one working day. ## Services - [Systems architecture](https://fcgsystems.es/en/services/systems-architecture/): An audit of your tools, data and processes, and a clear plan for what to build first. - [Academy and automation](https://fcgsystems.es/en/services/process-automation/): Students pay and get in on their own. Sign-ups, access, renewals and cut-off with nobody doing it by hand. - [Custom CRM and software](https://fcgsystems.es/en/services/custom-software/): A custom CRM for setters and closers: every lead with its source, owner and history. - [AI systems](https://fcgsystems.es/en/services/applied-ai-systems/): Messages sorted, calls summarised in the CRM and leads ranked, with tests and a measured cost. - [Data, tracking and analytics](https://fcgsystems.es/en/services/data-tracking-analytics/): Which channel sells, not just which signs up: tracking, attribution to the CRM and numbers that agree. - [Infrastructure and DevOps](https://fcgsystems.es/en/services/infrastructure-devops/): Servers, deployments, backups and alerts so your operation stays up and stays yours. - [Launch infrastructure](https://fcgsystems.es/en/services/launch-infrastructure/): Capture, tracking, assignment to your sales team and WhatsApp ready for thousands of sign-ups. - [Technology partner](https://fcgsystems.es/en/services/technology-partner/): Your external tech team: maintenance, incidents and new systems with defined monthly capacity. ## Engagements Four ways to work together, from a diagnosis measured in days to an ongoing partnership. If you’re not sure which fits, start with the audit. - **Systems Audit** (5–10 working days): Online education businesses with plenty of tools, automations and processes, but no clear picture of what works and what it costs. Systems and process map; Risks and points of failure; Target architecture; 90-day roadmap. - **Automation Sprint** (1–3 weeks): One specific bottleneck: lead routing, student sign-ups, access, sales follow-up or reporting. Design and automation; Integrations and testing; Error alerts and documentation; Handoff to your team. - **Business System Build** (3–8 weeks): A critical process that needs a full CRM, academy or dashboard, not another standalone automation. Database and internal dashboard; Automations and integrations; Role-based permissions; Tracking and infrastructure. - **Technology Partner** (Monthly): Businesses that want a technical team that answers when something breaks, without building an in-house department. Maintenance and incidents; Ongoing development; Roadmap and architecture; Defined monthly capacity. ### How to start without the risk 1. **The audit comes first.** Systems Audit, 5 to 10 working days. Scope, deliverables and investment are agreed in writing before we start, with no surprises. 2. **What you get is yours.** Systems map, risks, target architecture and a 90-day roadmap. You keep all of it even if we don’t continue, and you can build it with whoever you like. No lock-in. 3. **Then the build.** Only if it makes sense. With the roadmap in hand, the proposal comes with scope, timeline and a fixed price per phase. ## Who it is for Founders of info-product businesses and academies that already sell on a recurring basis, with setters, closers and support, but nobody in-house who truly understands the technical side. The operation is growing faster than the tools. - **Founders of info-product businesses and academies:** They want the technical headache off their plate without building a department, and numbers they can trust. - **CMOs and acquisition leads:** They need to know which channel brings paying students, not just sign-ups. - **CTOs or technical leads:** They run the technology alone or with a small team and need a partner who builds, documents and stays afterwards. - **Creative and marketing agencies:** A partner to hand over builds their team can’t take on, or to take what they prototyped with AI into production. If you doubled your sales tomorrow, which part of your business would stop working? ## Case studies - [An own campus connected to the sales CRM](https://fcgsystems.es/en/case-studies/own-campus-connected-to-the-crm/): Courses, live classes, practice journal and assignment review in one place, connected to the CRM. The team sees what each student consumes without checking tool by tool. - [A custom CRM that replaces Airtable, with commissions per agent](https://fcgsystems.es/en/case-studies/custom-crm-with-agent-commissions/): Leads, opportunities, payments, commissions per agent and permissions by role, in a CRM built around the sales process. - [A shared inbox on the official WhatsApp API](https://fcgsystems.es/en/case-studies/shared-inbox-official-whatsapp-api/): Sales conversations stop living on personal phones: one shared inbox, assigned per rep and synced with the CRM. - [Funnel, tracking and CRM connected for an online academy](https://fcgsystems.es/en/case-studies/sales-funnel-system-online-academy/): Forms, tracking, CRM and sales booking connected into one system, with every lead’s source in sight. All three funnel stages improved. - [Infrastructure for launches with thousands of sign-ups](https://fcgsystems.es/en/case-studies/high-volume-launch-infrastructure/): Thousands of sign-ups from five channels, with no duplicates, assigned to the sales team and measured while the launch is live. - [CommunityRedirect: one link so no sign-up lands in a full group](https://fcgsystems.es/en/case-studies/communityredirect-whatsapp-community-distribution/): A single link that checks capacity, rotates destinations and never sends users to a full WhatsApp group. ## FAQ ### What exactly does FCG Systems do? We build the system that puts you in control of your online education business: a CRM built around your sales process, an academy where students pay and get in on their own, and the custom development you can’t find on the market. We first understand how your business works, then decide what technology it needs. We don’t sell development hours: we sell numbers that add up and a team that stops doing by hand what the system can do. ### Who will I actually be working with? With the person on your first call: they design the solution and stay on the project until delivery. No middlemen, no salespeople who disappear afterwards. If a project needs another specialist, you know and approve it before signing. And everything is documented, so your business doesn’t depend on any one person, us included. ### How are you different from a freelancer or an agency? A cheap freelancer often leaves halfway and hands over something nobody understands. A development agency can be expensive, slow and miss how your business works. We start by understanding how you sell and how your team works, deliver in phases at a fixed price, leave everything documented and in your name, and stay around after delivery, not just until we’re paid. If something breaks, someone answers. ### Which tools do you work with? Whatever your system needs: n8n, Make, Airtable, Postgres, the official WhatsApp API, custom code in TypeScript and Python, GA4 and Google Tag Manager, your own servers, among others. The tool is chosen to fit your business, not the other way round. If what you already use works, we build on it: we don’t replace for the sake of it. ### Do you work with companies outside Spain? Yes. We’re based in Spain and work remotely, in English or Spanish, with clients in Madrid, Barcelona, Andorra and Dubai. Meetings are scheduled at times that suit you and your team. ### How does a project start, and how long does it take? With a diagnostic call about your business: how you sell, how many leads and students you handle, which tools you pay for and what is holding you back. If it’s a fit, we usually start with the audit: 5 to 10 working days, ending with a map of your systems, risks, target architecture and a roadmap you keep even if you stop there. Then a call to present the proposal and, if it suits you, we close. A CRM or an academy usually takes 3 to 8 weeks, with timelines in writing before we start. If you need it, we sign a confidentiality agreement before you share any sensitive information. ### How much does it cost and when does it pay back? Fixed price or hourly? A fixed price per phase, with written scope: before we start you get that phase’s deliverables, timeline and investment. To weigh it, compare it with what you already pay: subscriptions that grow with every user, tools that don’t fit and your team’s hours doing by hand what the system should do. With our team you replace five paid tools with your own systems, saving between €5,000 and €15,000 a year in subscriptions. When that already costs more than owning the system, that is where it pays back. The technology partner plan is a fixed monthly fee with defined capacity. If something comes up that wasn’t in scope, it’s quoted separately before any work, and nothing goes ahead without your sign-off. ### Does everything stay in my name? Will I depend on you? No. Code, repositories, servers and third-party accounts are held in your company’s name, with admin access in your hands. If anything is temporarily hosted on FCG Systems infrastructure during the project, that’s stated in writing and migrated to you at handoff. We work with our own user accounts, which you can revoke whenever you like. Credentials live in a password manager, never in a document or a chat. ### What happens at handoff, or if we stop working together? You get a working system with documentation, architecture, operating instructions and a maintenance plan. Your team can run it, another provider can, or we can on a technology partner plan. If we stop working together, you keep all of that, revoke our access and we hand over to whoever you choose. Nothing is left as a black box. ### Can you show me documentation from a past project, or give me references? Each project’s documentation belongs to that client and is covered by confidentiality, so we don’t share it. Our published cases are anonymised, with no names. The way to see how we document is the audit, whose deliverables you keep. If you need to speak to a past client, we ask that client first and only share the contact with their permission. ### Do you use AI for real, or is it just marketing? We use it where the return is measurable: sorting lead messages, summarising sales calls, scoring leads or answering your students from your own documentation. Every AI automation goes into production with its logs, its limits and its cost control. If a simple rule solves the problem, there’s no need for a model. ### Is my business a fit? Is there a minimum size? There’s no fixed number, but we’re the best fit for online education businesses that already sell on a recurring basis, have a team (setters, closers, support) and lose money or time to errors and manual work. If you don’t sell yet, or your problem isn’t urgent, we’ll say so plainly: before building systems, the offer needs validating. ## Contact Email hola@fcgsystems.es or use the form at https://fcgsystems.es/en/contact/. Reply within one working day. - Company: https://fcgsystems.es/en/company/ --- # We build the system that puts you in control of your online education business > FCG Systems is the technology company behind online education businesses that already sell. We understand how your operation works and build the CRM, academy and software it needs, in your name and documented. Source: https://fcgsystems.es/en/company/ ## FCG Systems at a glance - **What it is:** FCG Systems is a technology company that builds the systems behind online education businesses that already sell: a custom CRM, an academy where students pay and get in on their own, and whatever custom development is needed, handled as one system. - **Where:** Based in Huelva, Spain, working remotely with clients in Madrid, Barcelona, Andorra and Dubai. - **Who runs it:** Founded by Gabriel Florencio Calvo, who went from setter to the technical team of a large online education business. Whoever designs the solution is on the project from the first call. If another specialist is needed, the client knows and approves it before signing. - **Legal form:** The professional practice of Gabriel Florencio Calvo, a self-employed professional (NIF 49236244Y) based in Huelva. - **Who it is for:** Founders of online education and info-product businesses that already sell on a recurring basis, with setters, closers and support, and their CTOs and CMOs. Also creative and marketing agencies that need a technical partner for their clients. - **How engagements work:** Fixed-scope projects at a fixed price per phase (Systems Audit in 5 to 10 working days, Automation Sprint in 1 to 3 weeks, Business System Build in 3 to 8 weeks, AI Workflow and Launch Infrastructure) or a monthly Technology Partner fee with Core, Growth and Scale plans. Everything stays in the client’s name and documented. - **What it is not:** Not a marketing agency, not IT support and not developers for hire without technical direction or a business goal. - **In-house product:** CommunityRedirect, a system that spreads launch traffic across WhatsApp groups and communities without sending anyone to a full group. - **Contact:** hola@fcgsystems.es. Replies within one working day. ## Why FCG Systems exists FCG Systems exists because we kept seeing the same thing inside online education businesses: plenty of sales volume and, behind it, manual work, tools that don’t talk to each other and data nobody trusts. Hiring a full in-house tech department doesn’t always add up. Stringing freelancers together doesn’t fix it either. We work as a technology partner, not an hours vendor. Whoever takes your first call is the one who designs your system, with no middlemen. If a project needs another specialist, you know and approve it before signing. Every system is documented and held in your company’s name, so it doesn’t depend on any one person to keep running, including us. ## Who’s behind it Gabriel Florencio Calvo founded FCG Systems after going from setter to the technical team of one of the largest Spanish-speaking education businesses. He has been in sales and in tech at the same business, and works with clients in Madrid, Barcelona, Andorra and Dubai. ## How we work with you Three kinds of relationship, depending on where your business is. - **Fixed-scope project:** A CRM, an academy or custom development, with scope, timeline and deliverables in writing before we start, and a fixed price per phase. - **Technology partner:** A fixed monthly fee as your external technical team: maintenance, incidents and new systems, with someone who answers when something breaks. - **Own products:** When the same problem shows up across many businesses, we turn it into a product. CommunityRedirect started that way, from WhatsApp groups filling up during every launch. ## What you always get A system isn’t finished when it works in a demo. It’s finished when your team can use it, maintain it and recover it without depending on anyone. ### Every project delivers - The system working in production - Everything in your company’s name, with your access - Documentation - Architecture - Instructions for your team - A clear owner for every component - A maintenance and support plan ### Rules we don’t bend - **One real number:** Every critical piece of data has one primary system. Everything else reads from it, so the CRM, the payment gateway and the bank stop telling you different things. - **No duplicates:** When a process is retried, it doesn’t duplicate leads, payments or access, wherever the platform allows it. - **Failure alerts:** A critical process without logs isn’t finished. When something fails, you need to know when, where and why, before your team notices. - **Backups:** If data can’t be rebuilt, it needs a backup. And a backup that has never been restored doesn’t count. - **Keys kept safe:** Passwords live in a credential manager, never in documents, Notion pages or chat. - **Nothing live untested:** No change reaches your business without validation first. Small changes included. ## How we make decisions - **Understand before selling:** We start with how the business works, then decide what technology it needs. Never the other way round. - **Simple systems:** Technical complexity stays under the hood. Your team gets something simple to use and to maintain. - **Full ownership:** Shipping isn’t enough. Errors, alerts, maintenance and evolution are part of the job from day one. - **Business first:** Every technical decision is driven by what changes in the business, not by whichever tool is trending. - **Reusable by design:** When a pattern shows up more than once, it gets documented and reused. Every project starts from something proven. ## What we don’t do Saying no to what doesn’t fit is what lets us do the rest properly. If what you’re asking for won’t solve anything, we’ll say so, even if it costs us the sale. - Full-service marketing, community management or media buying - Office IT support or computer maintenance - Developers for hire without technical direction or a business goal - Systems for businesses that don’t sell yet: validate the offer first - Projects built only to win on the lowest price ## Contact Email hola@fcgsystems.es or use the form at https://fcgsystems.es/en/contact/. Reply within one working day. --- # Systems architecture > An audit of your tools, data and processes, and a clear plan for what to build first. Source: https://fcgsystems.es/en/services/systems-architecture/ · FCG Systems **Before you spend on code or another tool, know what you have.** Your business sells, but nobody has the full picture. The CRM says one thing, the payment gateway another and the bank a third. That happens because the stack was never designed. It piled up: a form here, a CRM there, three automations someone set up on a Friday afternoon. We map how information moves through your business, where it breaks and what depends on a single person. You leave with a map of what you have, what it costs you and a roadmap ranked by business impact, not by whichever tool is trending. It is the first step of any project with us, and what you get is yours even if we don’t continue: you can run it with your own team, another provider or us. ## Signs you need it - Every tool gives you a different number and you don’t know which is right - Nobody has a complete map of your integrations - An automation fails and you find out days later - Every new tool adds work instead of removing it - Some processes only make sense to one person - You pay for subscriptions nobody is sure you still use ## What we build - **Tool map:** An inventory of every platform: who uses it, what data it touches and what it costs per month. - **From lead to student:** How a lead, a payment or a sign-up moves between systems, step by step. - **Process map:** What your team does by hand, what is automated and where time gets lost. - **Points of failure:** Integrations without error alerts, critical dependencies and data with no backup. - **One real number:** Which system owns each critical record: contacts, sales, payments and access. - **90-day roadmap:** What to build first, in what order and how it pays back against what you spend today. ## How we work 1. **Interviews and access:** We talk to whoever sells, whoever collects payments and whoever touches the tools, and ask for read-only access to what you use. 2. **Systems map:** Which tools exist, which data moves between them and what depends on a single person. 3. **Where it breaks:** Numbers that don’t add up, fragile integrations, manual work and subscriptions nobody uses. 4. **Priorities:** We rank what to fix or build by impact on your business, not by whichever tool is trending. 5. **Roadmap handover:** A document that is yours, with the map, what it costs you and the 90-day plan, even if we don’t continue together. ## Deliverables - Systems and data map - Current process map - Risks and points of failure - Documented target architecture - 90-day roadmap - Walkthrough session with your team ## What changes - **Control:** Your team knows which system owns each piece of data and you can trust what you see. - **Priorities:** You invest first where the bottleneck costs you the most. - **Spend under control:** You spot duplicate tools and redundant automations before renewing them. ## Format - Format: Systems Audit · fixed-scope project - Duration: 5–10 working days - Typical tools: n8n, Make, Airtable, Postgres, REST APIs, Webhooks, GA4 ## FAQ ### What happens after the audit? You get the architecture and the roadmap, and the decision is yours. You can execute it with your own team, another provider or us. If we keep working together, the roadmap becomes the scope of the first project, at a fixed price per phase. ### Do you need access to all of our tools? To map things properly, yes, with read-only permissions wherever the platform allows it. Credentials are shared through a password manager, never over chat or in documents. ### Is it worth it if we already have someone technical? Yes, and it usually moves faster. We bring an outside view of the whole operation, not just the code, and leave your CTO or your team with a map and clear priorities to work from. ### What if a freelancer or an agency already let us down? The audit is built for that. We put in writing what exists, what fails and what is needed, so you don’t start blind with anyone, us included. And because everything is documented, you don’t depend on whoever built it. ## Related case studies - [Funnel, tracking and CRM connected for an online academy](https://fcgsystems.es/en/case-studies/sales-funnel-system-online-academy/) ## Contact Email hola@fcgsystems.es or use the form at https://fcgsystems.es/en/contact/. Reply within one working day. --- # Academy and automation > Students pay and get in on their own. Sign-ups, access, renewals and cut-off with nobody doing it by hand. Source: https://fcgsystems.es/en/services/process-automation/ · FCG Systems **A custom academy: students pay, get in on their own and you see everything.** A custom academy is the whole circuit from the moment someone pays until they get in: payment, automatic sign-up, access to the content, welcome and renewal notices, access control and cut-off for unpaid fees, and a dashboard with enrolments and attendance. If they stop paying, they lose access. With nobody doing it by hand. If today your team signs students up one by one, or you have automations that fail just when most enrolments arrive, the problem is not volume: it is that nobody trusts the circuit. Every failure is a student who can’t get in, a payment that doesn’t add up or access that stays open without payment. We build it with n8n, Make, APIs and custom code, depending on what your academy needs, and we also cover migration from your current stack. Every critical flow ships with error logs, retries and documentation, and everything in your company’s name. An automation that fails silently isn’t finished. ## Signs you need it - Someone signs students up one by one - Some students have access without paying, or the other way round - Sign-ups fail right in the middle of a launch - Support lives on "I can’t log in" messages - Automations fail and nobody notices - To know how many students are active, you open three tools ## Who it is for - **The founder of an academy:** You control who has paid, who has access and who should have lost it, without asking anyone. - **Your CMO:** Every sign-up carries its source all the way through, so they know which acquisition ends in paying students. - **Your CTO or whoever runs the technical side:** Automations with error logs, safe retries and documentation, instead of flows only the person who built them understands. - **Your support team:** Fewer "I can’t log in" messages and a dashboard to solve incidents without asking for technical help. ## What we build - **Payment, sign-up and access:** Payment confirmed, student created, access granted, welcome sent. And the reverse when someone cancels. - **Cut-off for unpaid fees:** If they stop paying, they lose access. Access control in sync with payment status. - **Notices and renewals:** Renewal reminders and failed-payment notices before they turn into a cancellation. - **Academy dashboard:** Enrolments, attendance, access and cancellations on one screen, with no exports. - **Migration and material:** Move from your current platform and load all the content, without losing students or history. - **From lead to student:** Forms, CRM, email and WhatsApp working from the same record, with the source of every sign-up. - **Alerts and logs:** Logs, safe retries and error alerts on every critical flow. ## Rules, AI or custom software. Not everything is automated the same way, and your academy doesn’t need the same thing at every step. This is what we weigh before building. | Criterion | Rule-based automation | AI automation | Custom software | |---|---|---|---| | What it solves | Moving data and running fixed steps between tools | Steps that need reading or interpreting text: classify, summarise, extract | Core processes with their own logic and a dashboard for the team | | Example | Payment confirmed, access granted, welcome sent | Student messages tagged and routed to the right person | A dashboard for enrolments, access and cut-off with permissions and an activity log | | Tools | n8n, Make, webhooks and APIs | n8n or code with AI models and output validation | TypeScript, Python and Postgres | | When it stops being enough | When logic piles up exceptions or volume drives costs up | When the output can’t be checked or measured | Rarely: it grows on the same system | ## How we work 1. **How a student gets in today:** We walk the whole circuit: payment, sign-up, access, notices. How many students it moves, its exceptions and what is done by hand. 2. **Design:** Which system owns each record, which tool fits and what happens when something fails. 3. **Build:** Versioned flows in a test environment, connected to what you already use, without stopping your launches. 4. **Testing:** Real and edge cases: duplicate payments, incomplete data, retries and enrolment peaks. 5. **Migration and go-live:** Move from your current stack and load all the material, with error alerts and documentation for every flow. 6. **Operation:** Upkeep, error reviews and improvements. If something breaks, someone answers. ## Deliverables - Payment, sign-up and access circuit in production - Dashboard with enrolments, attendance and cancellations - Migration from your current stack - Tests with real and edge cases - Logs and error alerts - Documentation and handoff, all in your name ## What changes - **Control:** You know who got in, where they came from, what they paid and who should have lost access. - **Less support:** Fewer access incidents and fewer hours of your team signing people up by hand. - **Room to grow:** The same circuit handles your next launch without adding manual hours. ## Format - Format: Automation Sprint · fixed-scope project - Duration: 1–3 weeks - Typical tools: n8n, Make, Airtable, Postgres, Webhooks, REST APIs, JavaScript, Python ## FAQ ### What does a custom academy include? The whole circuit from the moment someone pays until they get in: automatic sign-up, access to the content, welcome and renewal notices, access control and cut-off, and a dashboard with enrolments and attendance. It includes migration from your current stack and loading all the material. ### What happens if a student stops paying? They lose access automatically, with a prior notice if you want one. Access always follows payment status, so it doesn’t depend on someone remembering to check who owes what. ### What should be automated first? What repeats daily, moves a lot of students and causes errors when done by hand: sign-ups and access after a payment, renewal notices, lead routing and reporting. We start with the bottleneck that costs you the most today, not the easiest one. ### What happens if an automation fails in the middle of a launch? Every critical flow logs what it does and raises an alert when something goes wrong. Processes can be retried without duplicating sign-ups or charges, so a failure is caught when it happens and fixed without redoing work by hand. ### Can you fix the automations we already have? Yes. We start by reviewing what each flow does, where it breaks and what depends on it. Sometimes reinforcing it is enough; sometimes it is better to rebuild it on a structure that can be maintained and doesn’t depend on whoever set it up. ### Do you work with n8n, Make or Zapier? Mostly n8n and Make, plus custom code when volume or logic calls for it. If you already run flows on another tool, we assess them before suggesting a migration. The tool is picked for your system, not out of habit. ### Do you use no-code or code? Both, depending on what the process needs. To move data and run fixed steps, n8n or Make are enough and ship sooner. When there is heavy volume, logic with exceptions or a dashboard of your own, we write code. We decide with your case in front of us and document it so it doesn’t depend on whoever set it up. ### When is an automation no longer enough? When the logic piles up exceptions, the cost per run climbs or your team needs a dashboard of its own. At that point custom software usually pays off, and the move happens without stopping the operation. ## Related case studies - [An own campus connected to the sales CRM](https://fcgsystems.es/en/case-studies/own-campus-connected-to-the-crm/) - [A custom CRM that replaces Airtable, with commissions per agent](https://fcgsystems.es/en/case-studies/custom-crm-with-agent-commissions/) - [A shared inbox on the official WhatsApp API](https://fcgsystems.es/en/case-studies/shared-inbox-official-whatsapp-api/) - [Funnel, tracking and CRM connected for an online academy](https://fcgsystems.es/en/case-studies/sales-funnel-system-online-academy/) - [Infrastructure for launches with thousands of sign-ups](https://fcgsystems.es/en/case-studies/high-volume-launch-infrastructure/) ## Contact Email hola@fcgsystems.es or use the form at https://fcgsystems.es/en/contact/. Reply within one working day. --- # Custom CRM and software > A custom CRM for setters and closers: every lead with its source, owner and history. Source: https://fcgsystems.es/en/services/custom-software/ · FCG Systems **A custom CRM for your setter and closer team.** A custom CRM is a CRM built for your sales process, not a generic product you bend your team around. Every lead arrives with its source, its owner and its history, and payments and commissions per rep add up on their own. With permissions by role. If today you assign leads by hand across spreadsheets, WhatsApp and email, or you pay for a CRM that never fits how you sell, you notice it in the same ways: nobody knows who gets the next lead, the report doesn’t match the bank and your reps work the way the tool dictates. We build it around your sales process: the dashboard where each closer sees their leads, the follow-up cadence, payments and commissions, the WhatsApp inbox on the official API. Your own code, versioned and documented, in your company’s name. ## Signs you need it - Leads are assigned by hand across sheets, WhatsApp and email - Nobody knows who gets the next lead - Payments and commissions are worked out in a separate sheet - When a rep leaves, they take the conversations with them - You pay for a CRM and your team still works outside it - The CRM, the gateway and the bank show different numbers ## Who it is for - **The founder:** You see in one place who got in, where they came from, what they bought, how much they paid and how much is still due. - **Your CMO:** Every lead keeps its source through to the sale, so you know which acquisition ends in closed deals and not just sign-ups. - **Your CTO or whoever runs the technical side:** Your own code, versioned and documented, with role-based permissions and a database in your company’s name. - **Your setters and closers:** The view each one needs, with assigned leads, call reminders and their commissions in sight. ## What we build - **A CRM for your process:** The stages, fields and rules of your sales process, with the source and history of every lead. - **Lead assignment:** Distribution to setters and closers by rules and workload, with a single owner per lead. - **Payments and commissions:** Payments and commissions per rep calculated in the system, with no separate spreadsheets. - **Role-based permissions:** Each person sees what they need to work, and nothing more. - **WhatsApp on the official API:** A shared inbox with assigned conversations, templates, a follow-up cadence and call reminders. - **Dashboards:** Business metrics wired to the source of truth, with no exports. - **Portals and internal tools:** When the process justifies it, the client portal or back office that completes the system. ## Off-the-shelf CRM, no-code or custom. Building doesn’t always pay off. This is the comparison we run before proposing a custom CRM. | Criterion | Off-the-shelf CRM (SaaS) | No-code (n8n, Make, Airtable) | Custom CRM | |---|---|---|---| | Fits when | Your process is standard and the tool covers almost all of it | You need to connect tools or test a process quickly | Your sales process is central to the business and no product covers it without workarounds | | Time to start | Immediate | Days or weeks | 3–8 weeks for a fixed-scope build | | Cost that grows | Per-user licences and features you don’t use | Runs, operations and piled-up exceptions | Initial build and maintenance | | Control of data and rules | The vendor’s, and their roadmap | Partial: depends on the platform | Full: code, database and access in your name | | Typical risk | Your team works the way the tool dictates | Fragile flows as logic grows | Building something that already existed, which is why we check first | ## How we work 1. **How your team sells today:** Stages, setters, closers, payments and commissions. We decide what gets built and what stays as it is. 2. **Design:** Data model, role-based permissions, integrations and which system owns each record. 3. **Build in increments:** A test environment, versioned code and releases your team uses early, not at the end. 4. **Validation:** Real and edge cases, permissions and launch-level volume before going to production. 5. **Go-live:** Production with backups, error alerts, documentation and handoff to your team. 6. **Support and evolution:** A defined maintenance plan and someone who answers when something breaks. ## Deliverables - CRM deployed to production - Code in a repository in your company’s name - Database with backups - Users and role-based permissions - Technical and operational documentation - Maintenance and support plan ## What changes - **Control:** You know who got in, where they came from, what they bought, how much they paid and how much is still due. - **A system people adopt:** The team sells inside the CRM because it follows how they really work. - **No dependence on anyone:** The code and the data are yours. You don’t depend on a vendor’s roadmap or on whoever built it. ## Format - Format: Business System Build · fixed-scope project - Duration: 3–8 weeks - Typical tools: TypeScript, JavaScript, Python, Postgres, Xano, REST APIs, Docker ## FAQ ### What is a custom CRM? It is a CRM designed and built for your company’s sales process, rather than a generic product you configure. It has your stages, your assignment rules and your role-based permissions, and is integrated with forms, payments and WhatsApp. You decide what it does and you own the code and the data. ### How much does it cost and when does it pay back? It depends on scope: users and roles, integrations, data volume and security. We don’t publish rates; after the diagnosis you get a proposal with deliverables, timeline and a fixed price per phase. To weigh it, compare it with what you pay today in per-user licences and in your team’s hours sharing out leads and reconciling commissions by hand: that is usually where it pays back. ### How long does it take? A Business System Build usually takes 3 to 8 weeks, with partial releases your team tests from the start. We set the exact timeline in writing before we begin. ### Do we own the code? Yes. The repository, the database and the credentials are held in your company’s name, with admin access in your hands. We document the architecture so any technical team can pick up the work, with no dependence on us. ### What if a freelancer left us stranded or an agency was too slow? That is why we deliver in phases at a fixed price, with a test environment your team uses from the start and everything documented. And after delivery there is support: if something breaks, someone answers. ### When does building beat buying an off-the-shelf CRM? When your sales process is central to the business, the CRM forces constant workarounds or licence costs grow faster than the value they deliver. If an existing tool solves most of it, we will tell you, even if it costs us the sale. ### Can you move our leads from the CRM we use today? Yes. Migration is part of the project: contacts, history and stages moved from your current tool, tested before you switch systems and without stopping your sales team. ### Who maintains the CRM afterwards? Your team, using the documentation we hand over, another provider, or us through a technology partner plan. Every project ends with a defined maintenance plan. ## Related case studies - [An own campus connected to the sales CRM](https://fcgsystems.es/en/case-studies/own-campus-connected-to-the-crm/) - [A custom CRM that replaces Airtable, with commissions per agent](https://fcgsystems.es/en/case-studies/custom-crm-with-agent-commissions/) - [A shared inbox on the official WhatsApp API](https://fcgsystems.es/en/case-studies/shared-inbox-official-whatsapp-api/) - [CommunityRedirect: one link so no sign-up lands in a full group](https://fcgsystems.es/en/case-studies/communityredirect-whatsapp-community-distribution/) ## Contact Email hola@fcgsystems.es or use the form at https://fcgsystems.es/en/contact/. Reply within one working day. --- # AI systems > Messages sorted, calls summarised in the CRM and leads ranked, with tests and a measured cost. Source: https://fcgsystems.es/en/services/applied-ai-systems/ · FCG Systems **Applied AI for your training business, measured by what it changes.** We put AI into your training business where it genuinely saves hours: student and lead messages sorted, calls summarised in the CRM, leads ranked before they’re assigned and an assistant that answers from your documentation. Every use case starts from a metric, is tested on real situations and measured in production. AI isn’t a project on its own. It’s one more component of the system, worth using when it does something specific better, faster or cheaper than the alternative. If a simple rule solves the problem, we’ll say so instead of selling you a model. If you already tried AI and it never got past the demo, the usual reason is that nobody defined what it had to improve. Here that comes first, with clear limits, human approval where a mistake is expensive and a cost per run you can see. ## Signs you need it - Someone reads and sorts hundreds of messages a day - Call notes never make it into the CRM - The team keeps asking what’s already documented - You tried AI and it never got past the demo - You can’t tell which assistant answers are right - Leads are prioritised by gut feeling ## Who it is for - **Founders with a stretched team:** Student messages, admissions and calls that someone currently reads, summarises and sorts by hand. You get hours back without hiring. - **CMOs and sales teams with lead volume:** Leads ranked on criteria you can review, every call summarised in the CRM and context for the closer before they pick up the phone. - **CTOs and technical owners:** AI in production with logs, cost limits, test cases and the option to swap models without rebuilding the integration. - **Agencies with training clients:** AI assistants and workflows for your clients, built and maintained without growing your technical headcount. ## What we build - **Classification and routing:** Messages, forms and tickets tagged and sent to the right person. - **Summaries and extraction:** Calls, meetings and documents turned into tidy data inside your CRM. - **Lead scoring:** Lead and opportunity prioritisation based on explicit criteria you can review. - **Agents with tools:** Agents that query your CRM, calendar or database and carry out scoped steps, with human approval wherever a mistake is expensive. - **Assistants and chatbots:** Answers grounded in your documentation for the team or for students, with cited sources, defined limits and a handoff to a person. - **Conversation analysis:** Patterns across chats and sales calls: objections, questions and loss reasons. - **Human-in-the-loop workflows:** AI suggests, a person approves, wherever a mistake is expensive. ## Chatbot, AI agent or AI automation. Three ways of using AI that often get mixed up. Choosing well saves you from paying for an agent where a workflow was enough, or a chatbot that can’t actually do anything. | Criterion | Chatbot | AI agent | AI automation | |---|---|---|---| | What it does | Answers questions inside a conversation | Decides the steps and uses tools (CRM, calendar, database) to reach a goal | Runs a fixed workflow with an AI step: classify, summarise or extract data | | When it fits | Frequent student or lead questions answered in your documentation | Multi-step tasks with real variation from case to case | Repetitive, high-volume tasks with an output you can check | | Main risk | Made-up answers if it isn’t tied to sources | Wrong actions if it has no limits or approval | Silent errors without test cases or logs | | Control we add | Answers with sources and a handoff to a person | Scoped tools, stopping conditions and human approval on sensitive steps | Output validation, retries and alerts | ## How we work 1. **Discovery:** We pick one process, measure how it works today and set the metric that has to improve. 2. **Design:** We decide what the model does, what a rule handles and where a person signs off. 3. **Build:** It plugs into the tools your team already uses: CRM, WhatsApp, email or support, all versioned. 4. **Validation:** Real test cases and edge cases before anything touches production. 5. **Deployment:** Production with logs, cost limits and a fallback if the model fails. 6. **Improvement:** We review accuracy, usage and cost on real data and adjust what underperforms. ## Deliverables - Defined use case and success metric - Integration into your team’s tools - Versioned prompts and models, in your name - Test cases to control quality - Usage, cost and accuracy metrics - Documentation ## What changes - **Time:** Repetitive reading, sorting and note-taking come off your team’s plate. - **Quality:** Every change is evaluated against test cases before it reaches production. - **Known cost:** You know what each run costs and what value it delivers, with no surprises on the bill. ## Format - Format: AI Workflow · fixed-scope project - Duration: Depends on the use case, set after discovery - Typical tools: OpenAI, Anthropic, Vercel AI SDK, TypeScript, Python, n8n, Postgres, pgvector ## FAQ ### What exactly do you do with AI in a training business? We connect it to your tools to solve specific tasks: sorting messages, summarising calls into the CRM, scoring leads or answering from your documentation. We test it on real cases and measure what changes in time, quality or cost. We don’t sell it as an end in itself. ### Do you do AI consulting or implementation too? Both, in that order. First we define the use case, the success metric and whether AI is the right option; then we build it, deploy it and maintain it. If a rule or a simple automation solves the problem, we’ll tell you even if it costs us the project. ### Which processes in my business can be automated with AI? The ones that involve reading, interpreting or summarising information at volume: student and lead messages, documents, sales calls, lead prioritisation or questions already answered in your documentation. Decisions with legal, financial or student impact always keep human review. ### How much does it cost and when does it pay back? It depends on the process, the integrations and the volume, so we don’t publish fixed rates. After discovery you get a fixed scope with deliverables and timelines. Model usage is measured per run: you see what each task costs and compare it with the manual hours it replaces. ### Which AI is best for my business? No single model is best at everything. We work with OpenAI and Anthropic, among others, and choose per task by running them against the same test cases for accuracy, cost and speed. The system is designed so the model can be swapped without rebuilding the integration, so you’re not locked into one provider. ### We already tried AI and it never got past the demo. What’s different? Here AI handles a specific task inside a process that already exists, and you can measure the before and after. We don’t build demos or decorative chatbots. If a simple rule solves the problem, we use the rule. ### Is our data used to train models? We use providers and settings that don’t train on your data, and we only send the model what it needs. When the use case requires it, data is anonymised before processing. ### How do you stop the AI from getting things wrong? With real test cases before deployment, human review on sensitive steps and accuracy metrics in production. A model can fail: the system has to catch it and have a fallback. ## Contact Email hola@fcgsystems.es or use the form at https://fcgsystems.es/en/contact/. Reply within one working day. --- # Data, tracking and analytics > Which channel sells, not just which signs up: tracking, attribution to the CRM and numbers that agree. Source: https://fcgsystems.es/en/services/data-tracking-analytics/ · FCG Systems **Tracking and attribution through to the sale, with numbers that agree.** Ads reports one number, the CRM another and the launch spreadsheet a third. When data doesn’t match, decisions come down to gut feeling and budget gets allocated blind. We measure every step, from the first click to the sale closed on a call, and connect every source into a single reference database. When signal loss justifies it, we send conversions from a server you control (server-side GTM or Meta’s Conversions API) instead of relying on the browser alone. On top of that we build the dashboards leadership, marketing and sales actually use: sign-ups by source, conversion by stage and performance by closer. The result: you know which channel sells, which campaign deserves more budget and which numbers you can rely on. ## Signs you need it - Every platform reports a different conversion count - You know which channel brings sign-ups, not which one sells - Reports are built by exporting CSVs by hand - UTMs get lost between the form and the CRM - GA4 is installed, but nobody trusts it - Dashboards break whenever a tool changes ## Who it is for - **CMOs and acquisition leads:** Launches with ads and several sources where the sale closes on a call, far from the pixel. You know which campaign brings sales, not just sign-ups. - **Founders who don’t trust their numbers:** Ads says one figure, the CRM another and the launch sheet a third. One reference source and dashboards that read from it. - **CTOs and technical owners:** A documented measurement plan, events deduplicated between browser and server, and dashboards that don’t break when a tool changes. - **Sales teams:** The source of every lead visible in the CRM and per-closer performance without building reports by hand. ## What we build - **Measurement plan:** What gets measured, what it’s called and where, documented before a single tag goes live. - **GA4 and Google Tag Manager:** Clean event and conversion setup across site, forms and checkout. - **Server-side tracking:** A server-side GTM container when signal loss justifies it, not by default. - **Conversion APIs:** Browser and server events deduplicated with the same identifier, including sales closed away from the website. - **Attribution:** UTMs and sources carried from first click to the CRM and the closed sale. - **Source integration:** Ads, CRM, payments and platforms loaded into one shared database. - **Dashboards:** Business dashboards per team, refreshed without exports. - **Sales KPIs:** Clear definitions for conversion, sales cycle and per-closer performance. ## Browser tracking or server-side. Server-side tracking doesn’t replace a solid browser setup: it complements it. These are the differences that matter when deciding where to spend. | Criterion | Browser tracking | Server-side tracking | |---|---|---| | How events travel | From the user’s browser to each platform, tag by tag | From the browser or backend to a server you control, then on to each platform | | Signal loss | More exposed to blockers and browser restrictions | Less exposed, though it doesn’t bring back users who decline consent | | Data control | Each tag decides what it sends | You decide what data leaves for each platform | | Sales outside the website | Hard to measure | Can be sent from the CRM or payments through conversion APIs | | Cost and upkeep | Low: tags in Google Tag Manager | A server or managed service, configuration and monitoring | ## How we work 1. **Measurement audit:** What’s measured today, where signal is lost and how far each source drifts from the CRM and payments. 2. **Measurement plan:** Events, names, parameters and the reference source for each number, in writing. 3. **Implementation:** GA4 and Google Tag Manager, plus server-side or conversion APIs when they pay off. 4. **Validation:** Test events, browser and server deduplication and a cross-check with CRM and payments. 5. **Dashboards:** Sources loaded into one shared database, with dashboards per team on top. 6. **Upkeep:** Reviews whenever tools, campaigns or the funnel change. ## Deliverables - Documented measurement plan - GA4 and GTM implementation, in your accounts - Source attribution through to the CRM - Analytics database in your name - Dashboards per team - KPI guide and definitions ## What changes - **One number:** Marketing, sales and leadership debate decisions, not which figure is right. - **Smarter budget:** You know which sources drive sales, not just sign-ups, and where to move spend. - **Fewer manual reports:** Dashboards refresh on their own and nobody builds spreadsheets on Monday morning. ## Format - Format: Fixed-scope project - Duration: 1–3 weeks for tracking; 3–8 with database and dashboards - Typical tools: GA4, Google Tag Manager, Server-side GTM, Meta Conversions API, Postgres, Airtable, Looker Studio, Tally ## FAQ ### What is server-side tracking and do I need it? It means sending events to a server you control and on to each platform from there, instead of the browser talking to all of them. You don’t always need it: it pays off when signal loss affects campaigns with meaningful budget or when you want more control over your data. First we make sure the basic tracking is done right. ### Which server-side tracking tool should you use? Usually a server-side GTM container, on your own infrastructure or a managed service. It depends on event volume, how much control you want and who will maintain it. Everything sits in your accounts and is documented, so you don’t depend on us. ### Does server-side tracking remove the need for consent? No. It changes where events are processed, not your privacy obligations: if a user doesn’t consent, that measurement shouldn’t happen anyway. We configure it to respect consent and document what data is sent and to whom, so your legal advisors can review it. ### What is a conversion API? It’s how an ad platform such as Meta receives events straight from your server or CRM instead of from the browser. It lets you report sales that close on a call. It runs alongside the pixel with the same event identifier, so the same conversion isn’t counted twice. ### Why don’t Ads, GA4 and CRM numbers match? Because each platform counts with its own rules, attribution windows and blockers. Getting them to match 100% isn’t realistic, but you can define a reference source and know how far each one drifts, and why. ### How long does it take and when will I see results? Tracking usually takes 1 to 3 weeks; with a database and dashboards, 3 to 8. If you have a launch coming up, we prioritise what you need to measure by that date and deliver the rest afterwards. ### Can you connect dashboards to our CRM? Yes. We bring CRM, forms, payments and ad platforms into a shared database, and dashboards read from there. That way swapping a tool doesn’t break every report. ## Related case studies - [An own campus connected to the sales CRM](https://fcgsystems.es/en/case-studies/own-campus-connected-to-the-crm/) - [A custom CRM that replaces Airtable, with commissions per agent](https://fcgsystems.es/en/case-studies/custom-crm-with-agent-commissions/) - [Funnel, tracking and CRM connected for an online academy](https://fcgsystems.es/en/case-studies/sales-funnel-system-online-academy/) - [Infrastructure for launches with thousands of sign-ups](https://fcgsystems.es/en/case-studies/high-volume-launch-infrastructure/) ## Contact Email hola@fcgsystems.es or use the form at https://fcgsystems.es/en/contact/. Reply within one working day. --- # Infrastructure and DevOps > Servers, deployments, backups and alerts so your operation stays up and stays yours. Source: https://fcgsystems.es/en/services/infrastructure-devops/ · FCG Systems **So your business doesn’t stop the day something goes down.** Your CRM, your academy and your automations run on some server. Too often it was set up by someone who has since left, with no tested backups and no documentation. It works until launch day, which is exactly when it can’t fail. We set up and look after the technical base of your systems: servers, databases, domains and deployments. With backups that actually restore, access in your name and alerts that reach you before a student or a sales rep notices. ## Signs you need it - Nobody knows what runs on each server - Backups exist, but nobody has ever restored one - Touching anything in production feels risky - Passwords get shared over chat - You hear about downtime from your students - Whoever built the setup is no longer around ## What we build - **Servers and hosting:** Setup and hardening of the servers where your CRM, academy and automations live. - **Deployments without scares:** Every change goes live in a repeatable way and can be rolled back if something goes wrong. - **Domains and certificates:** Your domains, SSL and subdomains in order and in your name, with no surprise expiries. - **Database:** Lead, student and payment data with permissions, maintenance and automated backups. - **Backup and restore:** Off-server copies and restores that have been tested, not just scheduled. - **Alerts:** A warning when a service drops, a disk fills up or something critical fails, before your team notices. - **Access and credentials:** Each person with the minimum access they need and keys in a password manager, never in a chat. ## How we work 1. **Inventory:** What runs on each server, who has access, where the domains are and what would break if something goes down. 2. **Design:** Environments, database, backups and alerts designed for your operation, with everything in your company’s name. 3. **Setup and migration:** Versioned servers and deployments, and a move of what already runs without stopping your sales or your classes. 4. **Restore test:** We restore a real backup and simulate an outage to check that everything comes back. 5. **Documentation and handover:** Access sorted out, how it’s deployed and what to do if something fails, written so it depends on nobody. 6. **Monitoring:** Alerts that reach you before your students do, backup checks and updates. ## Deliverables - Documented infrastructure, in your name - Repeatable, reversible deployments - Automated backups with tested restores - Downtime and error alerts - Inventory of access and credentials - What to do if something goes down, in writing ## What changes - **Calm launches:** Your systems handle the peak and problems are caught before a customer feels them. - **Recovery:** If something breaks, there’s a backup and a documented way back, without losing leads or students. - **Ownership:** Everything is documented and in your name. It doesn’t rely on one person’s memory or on a vendor. ## Format - Format: Setup plus monthly operation - Duration: 1–3 weeks of setup, then monthly - Typical tools: Linux, Docker, Traefik, Nginx, Postgres, Redis, GitHub Actions, Cloudflare ## FAQ ### Can I keep my current setup or does everything have to be migrated? We review it first: what runs, who has access, which backups exist and what isn’t documented. Then we stabilise it before changing anything. We only suggest migrating when it’s a real risk to your operation. ### What happens if something goes down mid-launch? That’s why alerts and backups are prepared beforehand. Response times are set in writing by priority: a critical system being down isn’t handled like a feature request. And there’s a written procedure so your team knows what to do meanwhile. ### Will I be locked in to you? No. Servers, domains, accounts and keys stay in your name and the infrastructure is documented. Your team can run it, another provider can, or we can. If we stop working together, you revoke our access and nothing breaks. ### How much does it cost? The setup is quoted at a fixed price by scope before we start, and monthly operation is a fixed fee. It usually costs less than cloud services nobody reviews and a full day of downtime with no sales. ## Related case studies - [A shared inbox on the official WhatsApp API](https://fcgsystems.es/en/case-studies/shared-inbox-official-whatsapp-api/) - [CommunityRedirect: one link so no sign-up lands in a full group](https://fcgsystems.es/en/case-studies/communityredirect-whatsapp-community-distribution/) ## Contact Email hola@fcgsystems.es or use the form at https://fcgsystems.es/en/contact/. Reply within one working day. --- # Launch infrastructure > Capture, tracking, assignment to your sales team and WhatsApp ready for thousands of sign-ups. Source: https://fcgsystems.es/en/services/launch-infrastructure/ · FCG Systems **A launch that holds up, with numbers you can trust.** A launch packs into a few days what other businesses see over months: thousands of sign-ups from YouTube, Instagram, Telegram, ads and email, WhatsApp groups filling up, setters and closers waiting for leads and you asking for numbers every hour. We build or reinforce what carries that peak: capture and tracking by source, leads deduplicated before they’re assigned, routing to your sales team, community distribution and real-time numbers. Tested under load before registrations open, not during. ## Signs you need it - WhatsApp groups filling up mid-campaign - Duplicate leads called by two different reps - You only learn which source sells after it’s over - Setters and closers get leads late or without context - The launch dashboard is a spreadsheet - Every launch is rebuilt from scratch ## What we build - **Capture and sign-ups:** Forms and pages connected to a database built to handle traffic peaks. - **Attribution by source:** Every sign-up arrives with its origin: channel, campaign, ad and affiliate. You know which spend sells. - **Leads without duplicates:** Clean records before they reach the CRM and before they’re assigned. - **Routing to setters and closers:** Every lead with one owner, by rules and workload, visible to the whole team. - **WhatsApp and communities:** Distribution across groups with capacity checks, so no sign-up lands in a full group. - **Webinars and admissions:** Reminders, attendance and admissions connected to the CRM. - **Real-time numbers:** Sign-ups, attendance, calls and sales by source while the launch is live. ## How we work 1. **How you capture and sell today:** Traffic sources, forms, CRM, assignment to setters and closers, WhatsApp and how you measure the launch. 2. **Designing for the peak:** What has to hold, how each lead is assigned and which numbers you need to see while the launch is still open. 3. **Build:** Capture and tracking by source, deduplication, sales assignment and community distribution. 4. **Load test:** We simulate mass sign-ups before opening: duplicates, peaks, full groups and assignment. 5. **Support during the launch:** We stay on call through the key days to fix incidents and adjust while you sell. 6. **After the launch:** We review which source sold and what failed, and leave the base ready for the next one. ## Deliverables - Technical launch plan - Tracking and attribution by source - Deduplication and sales routing - WhatsApp community distribution - Real-time dashboard - Load testing before you open - Technical support on the critical days ## What changes - **Fewer lost sign-ups:** The system is ready for the peak before it arrives, not patched live. - **Sales with context:** Every setter and closer gets clean leads, on time, with their source attached. - **Mid-campaign decisions:** You see which sources work while you can still move budget. ## Format - Format: Per-launch project or retainer - Duration: Best started several weeks before registrations open - Typical tools: n8n, Airtable, Postgres, GA4, Google Tag Manager, Tally, Calendly, WhatsApp, CommunityRedirect ## FAQ ### How far ahead should we start? The earlier the better: several weeks is sensible, so the system is built and load-tested before registrations open. If the launch is close, we prioritise what’s critical: tracking, deduplication and sales routing. ### Can I keep the tools I already use? Yes. We usually reinforce what already works and connect what’s missing. We only suggest replacing a tool if it’s a real risk to the launch. ### What do you do about WhatsApp groups filling up? A single link checks each group’s capacity and spreads traffic across several destinations. It’s CommunityRedirect, our own product, built to solve exactly this problem. ### And if something fails during the launch? There’s support on the critical days, within what the project defines: before we start we agree support windows and priorities in writing. And because the system is load-tested beforehand, surprises are the exception. ### What stays after the launch? Everything stays in your name and documented, ready for the next launch. It isn’t rebuilt from zero each time. ## Related case studies - [Infrastructure for launches with thousands of sign-ups](https://fcgsystems.es/en/case-studies/high-volume-launch-infrastructure/) - [CommunityRedirect: one link so no sign-up lands in a full group](https://fcgsystems.es/en/case-studies/communityredirect-whatsapp-community-distribution/) ## Contact Email hola@fcgsystems.es or use the form at https://fcgsystems.es/en/contact/. Reply within one working day. --- # Technology partner > Your external tech team: maintenance, incidents and new systems with defined monthly capacity. Source: https://fcgsystems.es/en/services/technology-partner/ · FCG Systems **Get the technical burden off your plate without building a department.** Your business already sells and already needs someone who understands all of its technology, but hiring a CTO and two developers doesn’t add up yet. Meanwhile the technical side keeps getting pushed back and each vendor only sees their own piece. We become your external tech team: maintaining what exists, handling incidents, building what comes next and coordinating your other vendors. With explicit monthly capacity and a prioritised roadmap, not a vague promise of “whatever you need”. ## Signs you need it - Each vendor only knows their part of the system - Incidents wait until someone has time - Nobody owns the technical roadmap - Hiring an in-house team doesn’t add up yet - Projects end and nobody maintains them - The freelancer who built it no longer replies ## Who it is for - **Founders who are the bottleneck:** Everything goes through you, technical side included. With a partner you stop firefighting and focus on selling and on your product. - **A solo CTO or technical lead:** Someone already carrying a lot who needs extra capacity, an outside view and documentation that doesn’t depend on anyone. - **CMO or head of acquisition:** Tracking, attribution and acquisition tools looked after continuously, without waiting for someone to have time. - **Agencies with education clients:** A technical partner to delegate what your team can’t cover. ## What we build - **Maintenance:** Updates, error reviews and fixes before they reach your students or your sales team. - **Incidents:** When something breaks, someone answers. Triaged by priority, with response times defined in your plan. - **Ongoing development:** New automations, improvements and features within your monthly capacity. - **Roadmap:** Regular reviews of technical priorities against what the business needs. - **Servers and backups:** The technical base under continuous care: servers, backups and alerts. - **Vendor coordination:** One technical point of contact between your team, your agencies and your tools. - **Launch support:** Extra technical attention when the business is under the most load. ## How we work 1. **Initial diagnosis:** We review your systems, your vendors and what today depends on you or on a single person. 2. **Capacity and priorities:** We agree the monthly capacity and a roadmap ranked by business impact. 3. **Handover and order:** We document access, flows and owners so what exists stops being a mystery. 4. **Monthly delivery:** We maintain what exists, handle incidents and build what comes next within the agreed capacity. 5. **Regular review:** We go over with you what was done, what’s next and what to adjust in the priorities. ## Deliverables - Defined monthly capacity, in writing - Prioritised technical roadmap - Priority-based incident handling - Monthly work and status report - Documentation kept up to date - Quarterly architecture review ## What changes - **Support after delivery:** Knowledge of your systems doesn’t leave when a project ends or when a person leaves. - **Focus:** Each month goes to what has the most business impact, not what makes the most noise. - **Predictability:** A known monthly cost and explicit capacity, with no surprises and no ballooning hours. ## Format - Format: Monthly retainer · Core, Growth and Scale plans - Duration: Monthly, reviewed quarterly - Typical tools: n8n, TypeScript, Python, Postgres, Docker, GA4, Airtable, REST APIs ## FAQ ### How is this different from hiring a freelancer? A freelancer usually executes tasks and, if they leave, takes the knowledge with them. We take on the whole system: architecture, priorities, maintenance and documentation. Everything is in your name and written down, so you don’t depend on one person. ### And from a development agency? Monthly capacity is defined in writing and incidents are handled by priority, with no queues of weeks. We also understand how an education business sells: you don’t need to explain what a setter or a launch is. ### What does each plan include and what does it cost? Core covers maintenance and small improvements. Growth adds ongoing development and new systems. Scale is a full technology partnership. It’s a fixed monthly fee and each plan’s capacity is defined in writing before we start. ### What about requests outside the agreed scope? They’re logged, estimated and approved before any work starts. That keeps monthly capacity on what matters instead of leaking into untracked small changes. ### Can I leave whenever I want? Yes. Code, servers and accounts are in your name and documented. If we stop working together, you revoke our access and hand over to whoever you choose. ## Contact Email hola@fcgsystems.es or use the form at https://fcgsystems.es/en/contact/. Reply within one working day. --- # An own campus connected to the sales CRM > Courses, live classes, practice journal and assignment review in one place, connected to the CRM. The team sees what each student consumes without checking tool by tool. Source: https://fcgsystems.es/en/case-studies/own-campus-connected-to-the-crm/ · FCG Systems - Client: Info-product business with online training and recurring sales - Year: - Services: [Custom CRM and software](https://fcgsystems.es/en/services/custom-software/), [Data, tracking and analytics](https://fcgsystems.es/en/services/data-tracking-analytics/), [Academy and automation](https://fcgsystems.es/en/services/process-automation/) ## Context An info-product business with online training and recurring sales. The content lived on one platform, the students on another and the sales follow-up on a third. ## Problem Nobody had the full picture of anything. To know whether a student was moving forward or stuck, someone had to check tool by tool, and in the end nobody did. With the data scattered, nobody could tell which version was the real one. ## Constraints ## System built - **Own campus:** Courses by level and module on a platform the business owns, not a third party. - **Live classes:** Live sessions sit inside the same campus as the rest of the content. - **Practice journal:** Each student’s practice log lives inside the campus. - **Assignment review:** Submissions are reviewed and corrected without leaving the platform. - **CRM connection:** The campus shares data with the sales CRM: the commercial and the learning side read from the same source. - **Team dashboard:** One dashboard shows what each student consumes and where they are, and issues get solved without depending on the technical team. ## Result An own campus with courses by level and module, live classes, a practice journal and assignment review, all connected to the sales CRM. Students log in to a single place. The team sees from one dashboard what each student consumes and where they are, and solves issues without depending on the technical team. ## Learnings Stack: Campus, CRM --- # A custom CRM that replaces Airtable, with commissions per agent > Leads, opportunities, payments, commissions per agent and permissions by role, in a CRM built around the sales process. Source: https://fcgsystems.es/en/case-studies/custom-crm-with-agent-commissions/ · FCG Systems - Client: Digital business with several sales reps selling at once - Year: - Services: [Custom CRM and software](https://fcgsystems.es/en/services/custom-software/), [Academy and automation](https://fcgsystems.es/en/services/process-automation/), [Data, tracking and analytics](https://fcgsystems.es/en/services/data-tracking-analytics/) ## Context A digital business with several sales reps selling at once. Its sales process lived in a system built on Airtable. ## Problem The system never quite fit the whole sales process, and it relied on automations that kept failing. ## Constraints ## System built - **Leads and opportunities:** A pipeline built on the stages of the real sales process, instead of a base bent to fit. - **Payments:** The CRM includes payment tracking. - **Commissions per agent:** Commissions are handled per agent inside the CRM itself. - **Role permissions:** Each person sees and edits only what belongs to their role. ## Result A CRM built around its sales process, with leads, opportunities, payments, commissions per agent and permissions by role. ## Learnings Stack: CRM, Permissions --- # A shared inbox on the official WhatsApp API > Sales conversations stop living on personal phones: one shared inbox, assigned per rep and synced with the CRM. Source: https://fcgsystems.es/en/case-studies/shared-inbox-official-whatsapp-api/ · FCG Systems - Client: Digital business with several reps selling over WhatsApp - Year: - Services: [Custom CRM and software](https://fcgsystems.es/en/services/custom-software/), [Academy and automation](https://fcgsystems.es/en/services/process-automation/), [Infrastructure and DevOps](https://fcgsystems.es/en/services/infrastructure-devops/) ## Context A digital business with several sales reps selling at once, who use WhatsApp to contact their leads. ## Problem Selling happened on the reps’ personal phones. If someone left, the conversation left with them. Nobody knew whose turn it was to follow up or how many times a lead had been messaged. There was no record of opt-outs or consents, which is a serious problem as soon as data protection comes into play. On top of that, WhatsApp bans kept happening. ## Constraints ## System built - **Official WhatsApp API:** A shared inbox built on the official API, not on personal phones. - **Assigned conversations:** Every conversation has an owning rep, and it is clear whose turn it is to follow up. - **Templates:** Prepared messages for the usual touchpoints of the sale. - **Follow-up cadence:** A follow-up sequence that records how many times each lead has been messaged. - **Call reminders:** Reps get notified of pending calls. - **CRM sync:** What happens in the inbox lands in the CRM, and the conversation stays with the company. ## Result A shared inbox on the official WhatsApp API, with conversations assigned to each rep, templates, a follow-up cadence, call reminders and CRM sync. ## Learnings Stack: WhatsApp API, CRM --- # Funnel, tracking and CRM connected for an online academy > Forms, tracking, CRM and sales booking connected into one system, with every lead’s source in sight. All three funnel stages improved. Source: https://fcgsystems.es/en/case-studies/sales-funnel-system-online-academy/ · FCG Systems - Client: Online education academy - Year: 2024–2025 - Services: [Data, tracking and analytics](https://fcgsystems.es/en/services/data-tracking-analytics/), [Academy and automation](https://fcgsystems.es/en/services/process-automation/), [Systems architecture](https://fcgsystems.es/en/services/systems-architecture/) ## Published metrics - Opt-in: 70.81% → 77.61% - Registration: 36.85% → 44.72% - Sales calls: 9.89% → 16.22% ## Context An online education academy that attracts students through free content, sign-up forms and calls with a sales team. The funnel worked, but every piece lived in a different tool: forms in one place, booking in another, follow-up in spreadsheets and conversations on WhatsApp. ## Problem There was no reliable view of which sources brought sign-ups that turned into calls. Each tool reported different numbers and reporting was assembled by hand. Leads reached the sales team late or without context, and people dropped off between sign-up, registration and call without anyone being able to say where. ## Constraints - The funnel couldn’t stop: campaigns stayed live throughout the project. - The system had to be built on the tools the team already used. - Improvements were measured with the funnel live, so they aren’t attributed to any single component. ## System built - **Source tracking:** GA4 and Google Tag Manager with defined events for every step, and each sign-up’s origin carried through to the CRM. - **Connected forms:** Tally forms sending every sign-up, with its source, into a shared Airtable base. - **Sales CRM:** A pipeline built on the real sales stages: sign-up, registration, booked call and outcome. - **Booking and assignment:** Calendly bookings linked to the lead, with every call assigned to the right rep. - **WhatsApp in the flow:** WhatsApp contact is part of the follow-up instead of living in scattered chats. - **Dashboards:** Conversion by stage and by source, refreshed without manual exports. ## Result All three measured funnel stages improved during the project. The exact rates, measured before and after, are above. The sales team started working from assigned leads with their source visible, and leadership stopped relying on hand-built reports. ## Learnings - Without reliable tracking there’s no optimisation: measure every step first, then argue about what to change. - The biggest jump came at the last stage. Getting the lead to a rep on time and with context matters as much as capturing it. - A shared database is worth more than any dashboard. Dashboards only help when they read from a source everyone trusts. Stack: GA4, Google Tag Manager, Tally, Airtable, Calendly, WhatsApp --- # Infrastructure for launches with thousands of sign-ups > Thousands of sign-ups from five channels, with no duplicates, assigned to the sales team and measured while the launch is live. Source: https://fcgsystems.es/en/case-studies/high-volume-launch-infrastructure/ · FCG Systems - Client: Info-product launch operation - Year: 2024–2025 - Services: [Launch infrastructure](https://fcgsystems.es/en/services/launch-infrastructure/), [Data, tracking and analytics](https://fcgsystems.es/en/services/data-tracking-analytics/), [Academy and automation](https://fcgsystems.es/en/services/process-automation/) ## Context An info-product business that runs on launches: intensive campaigns that pack most of its lead capture and sales into a few days. Sign-ups arrive at the same time from YouTube, Instagram, Telegram, ads and email, with a sales team and several communities waiting on the other side. ## Problem With thousands of sign-ups in a few days, small errors multiply: the same person registered through two channels, leads called by two reps and sources that can’t be compared. Launch numbers were pieced together afterwards, when they could no longer help move budget or balance the team’s workload. ## Constraints - Traffic peaks concentrated in short windows, with no room to fix things live. - Five acquisition channels with different formats and source data. - A sales team that needed clean leads right away, not the next day. ## System built - **Multichannel tracking:** Every sign-up comes in tagged with its channel and campaign, whether from YouTube, Instagram, Telegram, ads or email. - **Deduplication:** Repeat sign-ups are detected and merged before they reach the CRM or get assigned. - **Sales assignment:** Leads distributed to the team by rules and capacity, so each contact has a single owner. - **Community systems:** Users distributed across the launch communities without overloading any group. - **Launch dashboards:** Sign-ups, assignments and sales by source, visible while the campaign is live. ## Result The launch now runs with one record per person, one sales owner per lead and a source-level view available during the campaign. Detailed figures for this operation aren’t published. What remains is a system that carries over from one launch to the next instead of being rebuilt every time. ## Learnings - Deduplication comes before assignment, never after. Unwinding a distribution full of duplicates costs far more than preventing it. - A launch gets load-tested before registrations open. There’s no time to diagnose anything during the peak. - Problems that come back every launch are product candidates. That’s how CommunityRedirect started. Stack: GA4, Google Tag Manager, Airtable, Postgres, WhatsApp, Telegram, Docker --- # CommunityRedirect: one link so no sign-up lands in a full group > A single link that checks capacity, rotates destinations and never sends users to a full WhatsApp group. Source: https://fcgsystems.es/en/case-studies/communityredirect-whatsapp-community-distribution/ · FCG Systems - Client: FCG Systems product - Year: 2025 - Services: [Custom CRM and software](https://fcgsystems.es/en/services/custom-software/), [Launch infrastructure](https://fcgsystems.es/en/services/launch-infrastructure/), [Infrastructure and DevOps](https://fcgsystems.es/en/services/infrastructure-devops/) - Product: CommunityRedirect (https://communityredirect.com) ## Context Many launches use WhatsApp groups and communities to warm up the audience, send reminders and open sales. Each campaign publishes invite links across ads, emails, sign-up pages and social media, often thousands of times within a few hours. ## Problem Groups have a member cap and fill up exactly when traffic peaks. A link pointing to a full group is a lost sign-up at the worst possible moment. Swapping links by hand across ads, emails and pages mid-campaign is slow, error-prone and leaves analytics scattered across destinations. ## Constraints - The published link can’t change: it’s already live in ads, emails and scheduled posts. - Redirects have to be instant, even under concentrated traffic spikes. - It had to work for any launch, not just one. ## System built - **Single link:** One stable link for the whole campaign, regardless of the groups behind it. - **Capacity check:** Before redirecting, the system checks which destinations still have room. - **Destination rotation:** Traffic is spread across several groups and moves on to the next one as each fills up. - **Full-group protection:** No user is ever sent to a group with no room left. - **Centralised analytics:** Clicks and destinations for every group measured in one place. ## Result Launches can publish one link and stop worrying about which group is full: the system handles it on every click. An operational problem that came back every campaign became a reusable product. ## Learnings - Problems that show up every launch deserve a product, not a new patch each time. - At critical moments the invisible parts matter most: a link that always works beats a polished interface. - Centralising analytics at the redirect gives you a view no individual group can provide. Stack: WhatsApp, Postgres, Docker, VPS, REST APIs