El chatbot no-code "barato" que te cuesta 3x más en 18 meses
TL;DR
Un chatbot no-code arranca en 50 dólares al mes y un build a medida en varios miles, pero a 18 meses el "barato" suele costar más. No por una sorpresa, sino por cómo está diseñado el modelo de precio: renta que sube con el éxito, candado de salida y un stack de varias suscripciones.
Un chatbot no-code arranca en 50 dólares al mes. Un build a medida arranca en varios miles. La comparación parece cerrada antes de empezar.
Pero el precio del primer mes no es el precio del proyecto. A 18 meses, el chatbot "barato" suele costar más que el build a medida. No por una sorpresa, sino por cómo está diseñado el modelo de precio.
Te explico dónde se acumula el costo. Sin cifras inventadas: nadie puede darte el número exacto sin conocer tu volumen. Solo órdenes de magnitud y la mecánica.
La renta sube justo cuando la herramienta empieza a funcionar
Casi todas las plataformas no-code cobran por conversación, por mensaje resuelto o por asiento de agente. Suena justo. Pagas por lo que usas.
El problema es la curva. Cuando el bot no sirve para nada, casi nadie lo usa, y la factura es mínima. Cuando empieza a funcionar de verdad, el volumen sube, y la factura sube con él.
Dicho de otra forma: el modelo te penaliza por el éxito. El mes en que tu bot atiende el doble de clientes es el mes en que tu costo se duplica. No hay un techo natural.
Un build a medida tiene el problema invertido. El costo grande está al principio (la construcción), y después el costo marginal por conversación tiende a cero. La curva se aplana cuando el volumen sube, no lo contrario.
Por eso la comparación a un mes engaña. A bajo volumen, el no-code gana fácil. Cruzado cierto umbral de tráfico, la renta recurrente se come la diferencia, y luego la supera.
El candado: salir significa reconstruir todo
Aquí está el costo que nadie te enseña en la demo.
Cuando construyes tus flujos dentro de una plataforma no-code, esos flujos viven en su formato. No en un estándar abierto. En su editor visual, sus nodos, su lógica propia.
El día que quieres cambiar de proveedor (porque subió los precios, porque se quedó atrás, porque lo compraron y degradaron el producto), descubres que tus flujos no se exportan. O se exportan a un archivo que ninguna otra herramienta sabe leer.
En la práctica, migrar no es migrar. Es reconstruir desde cero en otro sitio. Vuelves a dibujar cada rama, vuelves a probar cada caso, vuelves a conectar cada integración.
Ese costo de reconstrucción no aparece en ninguna página de precios. Pero es real, y es el que te mantiene atado. Mientras más crece tu bot, más caro es irte, y mejor lo saben ellos. El candado no es un bug del modelo no-code: es parte del modelo.
Un build a medida también tiene su forma de atadura (depende de quién lo mantenga). Pero el código es tuyo, vive en tu repositorio, y cualquier equipo competente puede retomarlo. La diferencia entre "es tuyo" y "es de ellos" se siente el día que quieres moverte.
Un chatbot rara vez es un solo chatbot
La demo te muestra una herramienta. La realidad es un apilamiento.
Un chatbot útil casi nunca trabaja solo. Necesita:
- La plataforma de chat (el bot que habla).
- Una capa de automatización para mover los datos (crear el ticket, agendar la cita, avisar al equipo).
- Una base donde guardar lo que pasa (el contacto, el historial, el estado).
El costo total no es la línea que firmaste
Cada una de esas piezas suele ser una herramienta distinta, con su propia suscripción, su propia curva de precio por volumen, su propio asiento por usuario.
Empiezas pagando una. Terminas pagando tres o cuatro. Y cada una sube por su lado cuando creces. La factura "de 50 dólares" del chatbot era solo la entrada de un menú más largo.
No digo que apilar herramientas esté mal. Para arrancar rápido, es razonable. Lo que digo es que el costo total no es la línea que firmaste, es la suma de todas las líneas que el sistema va a necesitar para funcionar de verdad.
Cuando sumas el stack completo, el delta con un build a medida (que integra esas piezas en un solo sistema) se encoge. A veces desaparece.
El último kilómetro: la demo toma un día, la producción toma meses
Esta es la parte que más subestima todo el mundo, no solo en no-code.
Montar una demo que conversa bien toma un día. A veces unas horas. Le das tus textos, conectas una base de conocimiento, y el bot responde con soltura. Impresiona. Cierra la venta.
Lo que no se ve en la demo es el último kilómetro:
- Escribir de forma fiable en tu CRM, sin duplicar contactos, sin romper cuando un campo viene vacío, sin perder un lead porque la API tardó dos segundos de más.
- Manejar los casos raros: el cliente que escribe tres preguntas en un mensaje, el que cambia de idioma, el que pide algo que el bot no sabe hacer y hay que pasar a un humano sin que se sienta abandonado.
- Monitorear en producción: saber cuándo el bot se equivoca, medir cuántas conversaciones resuelve de verdad, detectar la regresión antes que el cliente.
El último kilómetro sigue siendo ingeniería
Ese trabajo es el 80% del esfuerzo y casi nada del show. Es donde el proyecto se rompe o se sostiene. Y es independiente de la herramienta: lo necesitas igual en no-code que a medida.
La trampa del no-code es que te vende la sensación de que el último kilómetro también es no-code. No lo es. Las integraciones fiables, el manejo de errores y el monitoreo siguen siendo ingeniería. Si la plataforma no te deja meter esa lógica con limpieza, terminas peleando contra la herramienta justo en la parte que más importa.
Entonces, ¿no-code nunca?
No. Sería deshonesto decir eso.
A bajo volumen, con flujos simples, sin integraciones críticas, el no-code es la decisión correcta. Arrancas en horas, pagas poco, validas si la idea sirve antes de invertir en serio. Para un FAQ, una captura de leads básica, un primer piloto, es exactamente la herramienta adecuada.
El no-code no es la trampa. La trampa es no calcular el costo total antes de comprometer tus flujos, tus datos y tu equipo a una plataforma de la que después cuesta salir.
La pregunta correcta no es "¿cuál es más barato este mes?". Es:
- ¿Qué volumen de conversaciones espero en 12 a 18 meses?
- ¿Cuánto sube la factura cuando ese volumen llega?
- ¿Cuánto me costaría reconstruir si tuviera que irme?
- ¿Cuántas suscripciones necesita el stack completo, no solo el chatbot?
Compara el costo real, no el precio de entrada
Si respondes esas cuatro, ya no comparas un precio de entrada. Comparas el costo real a lo largo de la vida del proyecto. Y ahí el "barato" y el "caro" a veces cambian de lado.
Si quieres poner números sobre la mesa antes de decidir, armamos un comparador para esto: te ayuda a estimar el costo real de un agente conversacional según tu volumen, no según el precio del primer mes. Está en nuestro comparador (Pricely), y es justo para esta cuenta.
Al final, todo depende de tu volumen. A poco tráfico, el no-code te conviene. Cuando el tráfico sube, el mismo modelo que te lo hizo barato empieza a jugar en tu contra. Decide con la curva completa a la vista, no con el primer mes.