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.

¿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.

¿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.

Leer en fcgsystems.es · Blog de FCG Systems

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.
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 (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.

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 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: 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.
• 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, 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 y, cuando hay que conectar centralita, CRM y avisos, en automatización de procesos. Si estás valorando si una IA puede coger tus llamadas, cuéntame qué tipo de llamadas recibes 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.

Leer en fcgsystems.es · Blog de FCG Systems

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.

¿Qué es un agente de IA exactamente?

Anthropic, en su guía 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, 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?

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 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.

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.

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 (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.

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.

¿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.

¿Hay que avisar de que responde una IA?

El artículo 50 del Reglamento de IA de la UE (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 (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, y los casos donde la IA ya ahorra trabajo, en el artículo de IA aplicada en 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 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.

Leer en fcgsystems.es · Blog de FCG Systems

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.

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.

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.

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.

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, y los de CRM, en CRM para pymes y negocios digitales.

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 junto con datos, tracking y analítica, 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.

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.

Leer en fcgsystems.es · Blog de FCG Systems

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. 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.

Leer en fcgsystems.es · Blog de FCG Systems

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.

Leer en fcgsystems.es · Blog de FCG Systems

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.

¿Cómo funciona n8n por dentro?

Tres conceptos y ya se entiende cualquier flujo:

• El disparador. Un webhook que recibe datos cuando algo ocurre, un disparador programado 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.

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.

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.

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.

¿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:

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 y las opciones de instalación, en su documentación de alojamiento (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.
• 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.

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.

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 y, cuando n8n va en servidor propio, con infraestructura y 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.

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.

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.

Leer en fcgsystems.es · Blog de FCG Systems

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: 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:

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.

¿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:

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, 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.

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: se construye lo que diferencia al negocio y se contrata lo estándar.

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.

¿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.

¿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.

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 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 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. Si la conclusión es construir, el CRM o la parte que os diferencia se aborda como un CRM a medida, y las integraciones con la automatización 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.

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.

¿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.

Leer en fcgsystems.es · Blog de FCG Systems

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, y sobre el caso concreto de accesos y cobros, en pagos fallidos y acceso al producto.

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?

Leer en fcgsystems.es · Blog de FCG Systems

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. 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 (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).

Si la app usa Supabase, esto pasa por Row Level Security, y la documentación oficial 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 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.
• 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.
• 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 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, 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, consultado en septiembre de 2026). Y Figma limita Make a asientos completos de planes de pago (centro de ayuda de Figma, 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.
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: 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 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; si lo que necesitáis es tener un equipo técnico detrás de forma continuada y en white label, es partner tecnológico.

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.

Leer en fcgsystems.es · Blog de FCG Systems

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?

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.

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. Y si la duda es qué clase de CRM encaja con tu operación, los cuatro perfiles están en 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.

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.

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, y la parte del puente entre ambos suele resolverse con automatización de procesos o, cuando la lógica es propia del negocio, con software a medida.

Para ver cómo encaja esto con el resto de capas de la operación, empieza por 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.

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.

Leer en fcgsystems.es · Blog de FCG Systems

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.

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.

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.

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.

Leer en fcgsystems.es · Blog de FCG Systems

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.

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.

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.

Leer en fcgsystems.es · Blog de FCG Systems

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:

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.

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, publicado en el BOE el 31 de marzo de 2026. La Agencia Tributaria lo resume en su ficha de novedades de normativa (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 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:

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: 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, 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.

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 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.

Leer en fcgsystems.es · Blog de FCG Systems

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.

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:

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.

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, y qué exigirle al CRM antes de elegirlo, en CRM para pymes y negocios digitales.

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.

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 (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 o la API de conversiones de Meta (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.

¿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.

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.

¿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 cuando el problema es de medición, en arquitectura de sistemas cuando es de cómo encajan las herramientas y en automatización 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.

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.

Leer en fcgsystems.es · Blog de FCG Systems

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.

¿Qué categorías de herramientas de automatización existen?

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 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 y Zapier, consultadas en septiembre de 2026); la comparación con aritmética real está en 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.
• Qué hacen cuando algo falla. n8n permite definir un flujo de error que se dispara cuando otro falla, y Make guarda las ejecuciones incompletas 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.

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.

¿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 y, cuando hay servidor propio de por medio, con infraestructura y DevOps.

Para ver cómo encaja la automatización con el resto de capas de la operación, empieza por 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.

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.

Leer en fcgsystems.es · Blog de FCG Systems

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?

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 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.
• 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.

¿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, y el trasfondo conceptual está en qué es la atribución de marketing.

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.

¿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. La infraestructura para lanzamientos con miles de registros 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 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.

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 y, cuando el lío viene de cómo están conectadas las herramientas, en arquitectura de sistemas. Si tu equipo discute cifras en vez de decisiones, cuéntame qué proceso os está frenando 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.

Leer en fcgsystems.es · Blog de FCG Systems

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.

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.

Leer en fcgsystems.es · Blog de FCG Systems

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.

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.

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 y en CRM para pymes y negocios digitales.

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.

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.
• 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:

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.
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 y de datos, tracking y analítica, y solo cuando está resuelto tiene sentido plantear la capa de IA 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 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.

Leer en fcgsystems.es · Blog de FCG Systems

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

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 (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 (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 (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 (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 (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.

Bolt: el proyecto de ficheros, con ramas

Su centro de ayuda (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 (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 (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 (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 (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 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 (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 (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 (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.

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.

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.
• 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 cuando es un proyecto cerrado, y partner tecnológico 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, y la forma de trabajar con esto delante de un cliente, en prototipos 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.

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.

Leer en fcgsystems.es · Blog de FCG Systems

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 (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 (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 (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 (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 (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 (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.

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: 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 (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 (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 (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ú

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.

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. Si quieres la comparación con las otras opciones, está en 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. 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.

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, y cuando el acompañamiento es continuo, el de partner tecnológico. Para agencias lo hacemos también en marca blanca.

Si tienes un prototipo y no sabes qué le falta para poder cobrarlo, cuéntamelo 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.

Leer en fcgsystems.es · Blog de FCG Systems

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:

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 y en la atribución en Google Ads (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, y el recorrido paso a paso de dónde se pierde el dato, en atribución rota: GA4, Meta y tu 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 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:

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.

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.

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: 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 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.

Leer en fcgsystems.es · Blog de FCG Systems

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.

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 (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 (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.

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.
• 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.

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, o como proyecto cerrado en software a medida.

Si quieres el contexto de las herramientas antes de elegir, empieza por Lovable vs Bolt vs v0 y por qué es Lovable y hasta dónde llega. El recorrido técnico completo está en de prototipo con IA a producción, y el marco general de trabajar así, en qué es el vibe coding.

Si tienes un prototipo encima de la mesa y una propuesta a punto de salir, cuéntamelo antes de enviarla 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.

Leer en fcgsystems.es · Blog de FCG Systems

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 (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.

(Fuentes: documentación de Lovable, soporte de Bolt, documentación de v0, centro de ayuda de Figma y documentación de Cursor, 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 (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 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. 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 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, 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:

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.

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: 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 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; si lo que necesitáis es un equipo técnico detrás de forma continuada, en partner tecnológico.

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.

Leer en fcgsystems.es · Blog de FCG Systems

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.

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, 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.

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.

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.

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.

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. Es la misma lógica con la que elijo los KPIs que de verdad hay que mirar.

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: 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 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.

Leer en fcgsystems.es · Blog de FCG Systems