Coste de desarrollar un chatbot: lo que pagarás de verdad en 2026

Las cinco cosas que la gente entiende por "chatbot"

Antes de poder ponerle precio a un chatbot, tienes que saber cuál estás valorando. "Coste de desarrollo de un chatbot" esconde al menos cinco productos distintos, y no cuestan ni remotamente lo mismo:

• Un widget basado en reglas (flujos de tipo si-esto-entonces-aquello) es lo más barato y lo menos útil, y la fuente de la mayoría de los problemas de los chatbots. La mayoría de los creadores de chatbots sin código empiezan aquí.
• Un chatbot de IA configurado sobre una plataforma de chatbot ya existente, donde lo apuntas a tu documentación y lo pones en marcha. Aquí es donde se sitúan la mayoría de los creadores de chatbots de IA.
• Un bot construido a medida, encargado a una agencia o a un freelancer, integrado en tu propia infraestructura.
• Un desarrollo interno sobre la API cruda del LLM, propiedad y mantenido por tus propios ingenieros.
• Un agente de IA para el helpdesk que se instala en tu helpdesk actual, aprende de los tickets pasados y se factura por uso.

La palabra clave "desarrollo de chatbot" te empuja hacia la opción tres o cuatro (el camino de construir). Medio artículo trata de esto: para la mayoría de los equipos de soporte, el camino de construir es la forma cara de conseguir el mismo resultado. Vamos a ponerle precio a todos.

Qué determina de verdad el coste de desarrollar un chatbot

Elijas el camino que elijas, aparecen las mismas palancas de coste. Conocerlas te permite leer cualquier presupuesto y detectar qué falta.

• Alcance y canales. Un bot de FAQ para un único widget web es barato. Ese mismo bot atendiendo también WhatsApp, correo y Slack, autenticando usuarios y ejecutando acciones (reembolsos, consultas de pedidos) es un proyecto completamente distinto.
• Integraciones. Cada sistema del que el bot tenga que leer o en el que tenga que escribir (tu helpdesk, Shopify, una base de datos de pedidos, un CRM) es tiempo de ingeniería para construirlo y, sobre todo, para mantenerlo funcionando cuando esas APIs cambian.
• Conocimiento y entrenamiento. Alguien tiene que alimentar al bot con tu documentación de ayuda y tickets anteriores, y luego mantener esa base de conocimiento al día. Esto no termina nunca; tu producto cambia, así que las respuestas del bot también tienen que cambiar.
• El modelo subyacente. Si construyes tu propia solución, pagas directamente la factura de la API del LLM, y esta escala con cada mensaje. Un cliente potencial de eesel, una empresa de seguridad de correo que escalaba hacia unas 9.000 interacciones al mes, agotó 200 llamadas a la API en un solo día de pruebas y empezó de inmediato a preocuparse por la factura a volumen real.
• Monitorización y control de calidad. Un bot de soporte que responde mal es peor que no tener bot. Detectar y corregir esas respuestas es un coste permanente, no una configuración de una sola vez.

Ese último bloque es el que hunde los presupuestos de construcción, así que vale la pena mostrar lo que el presupuesto se deja fuera.

Las cuatro formas de conseguir un chatbot de soporte, con precio

Aquí está el panorama de coste honesto para cada camino de compra, con las cifras concretas que he podido verificar en fuentes primarias.

Vale la pena señalar algunas cosas. Las tarifas freelance parecen baratas por hora, pero un bot de soporte real rara vez es un trabajo de 20 horas una vez que cuentas integraciones y pruebas. Las agencias casi nunca publican una tarifa; el patrón en el mercado de servicios de desarrollo de chatbots es un formulario de contacto con presupuesto orientativo y una cotización a medida, lo cual es en sí mismo una fricción para el comprador que merece la pena nombrar. Y la opción de precio por uso es la única en la que tu coste sigue el valor entregado en lugar de una apuesta fija que haces antes de saber si la cosa funciona.

Construir o comprar: el muro del mantenimiento que nadie te presupuesta

Esta es la decisión que la mayoría de las búsquedas de "coste de desarrollo de chatbot" están rondando en realidad, así que voy a ser directo, porque lo he visto repetirse decenas de veces.

Construir tu propio bot sobre la API de Claude u OpenAI es una tentación real para un equipo técnico. La API es barata por llamada, mantienes el control total y no pagas el margen de un proveedor. Sobre el papel es la opción más barata. En el propio análisis de cancelaciones de eesel, "lo construiremos nosotros mismos" es una de las razones más comunes por las que los clientes técnicos se van, y varias cuentas concretas hicieron justo eso, una fue directamente a la API de Claude.

Aquí está la clave: construir nunca es la parte cara. Un cliente, un ingeniero líder en una empresa de hardware cripto con una base de conocimiento de más de 300 artículos, lo expresó sin rodeos cuando eligió comprar en lugar de construir:

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

Ingeniero líder en una empresa de cajeros de Bitcoin/hardware cripto, vía eesel

Esa palabra, maintain (mantener), lo es todo. Construir te lleva rápido a una demo funcional. Luego tu producto cambia, tu documentación se queda desactualizada, una API con la que integraste lanza un cambio incompatible, el modelo le da a un cliente una respuesta segura pero equivocada, y de repente un bot "barato" es una línea fija en el calendario de un ingeniero. Algunos de los equipos que dejaron eesel para construir internamente volvieron en cuanto llegó ese muro. La factura de la API era lo de menos; el tiempo de ingeniería era el coste real.

La jugada que va contra la intuición para la mayoría de los equipos: si tu objetivo es un chatbot de soporte y no un producto de machine learning, comprar y configurar casi siempre sale más barato en un año que construir y mantener. Te ahorras tanto la factura de construcción como la de mantenimiento. Ese es todo el argumento de un chatbot de IA para atención al cliente gestionado.

Fíjate en la unidad de facturación, no en el precio de partida

Incluso en el lado de la compra, el precio de portada miente, porque los proveedores cobran en unidades completamente distintas y muchas veces no puedes saber cuál hasta que estás metido de lleno en un presupuesto.

Las cinco unidades con las que te vas a encontrar:

• Por mensaje. Cada respuesta se mide. Tarifa que luce bien, fea a escala en conversaciones largas.
• Por sesión. Tidio factura por sesión de chat, donde cada 15 minutos de una interacción cuentan como una sesión nueva.
• Por usuario activo (MAU). Pagas por el tamaño de tu audiencia, chatee o no.
• Por resolución. Pagas solo cuando el bot resuelve algo de verdad, así que el coste sigue al valor. Es la misma lógica detrás de una métrica de tasa de resolución de IA.
• Por ticket. Un ticket es un cargo, sin importar cuántos mensajes lleve. Así es como factura eesel, a 0,40 $ por ticket.

¿Por qué importa más la unidad que la tarifa? Porque la unidad equivocada a tu volumen puede ser un desastre. Un operador de comercio electrónico con varias empresas, escalando hacia unos 150.000 tickets al mes, proyectó cerca de 30.000 $/mes a unos 20 centavos por interacción, y a mitad de la llamada se hizo un lío sobre si le cobraban por interacción o por ticket, una diferencia de miles de dólares. Otro equipo de gran volumen, con 17.000 tickets al mes, descubrió que el precio por interacción sencillamente no le salía a cuenta. La tarifa estaba bien; el problema era la unidad.

Si te quedas con una sola cosa de esta sección: antes de firmar nada, pregunta "¿qué es exactamente una unidad facturable, y cuántas va a producir mi volumen real?". Un modelo por resolución o por ticket suele ser el más seguro para soporte, porque tu coste solo sube cuando el bot está trabajando de verdad, el mismo principio detrás de la resolución en el primer contacto.

Juega tú mismo con la disyuntiva:

El deslizador de mantenimiento es la parte honesta. Pon las horas de ingeniería a cero y construir parece imbatible; ponlo en unas 15–25 horas al mes, realistas, y el panorama cambia rápido. Ese es exactamente el número que los equipos olvidan poner en el presupuesto.

Un ejemplo real: lo que paga un equipo de soporte de verdad

El precio abstracto no sirve de nada, así que aquí va uno concreto. Digamos que gestionas 1.000 tickets de soporte al mes y quieres que la IA se encargue del tramo repetitivo de nivel 1, el mismo volumen que una buena herramienta de atención al cliente con IA está pensada para absorber.

• Con un agente de precio por uso a 0,40 $/ticket, gestionar los 1.000 sale a 400 $/mes. Enruta solo los 300 más sencillos y pagas 120 $; nunca te cobran por los tickets que resuelven tus humanos.
• Con una suscripción plana, te comprometes con un nivel lo uses o no. Está bien con un volumen estable y duele cuando es irregular. Una clienta generó todo su contenido en tres semanas y luego no tuvo motivo para seguir pagando la cuota mensual fija, así que canceló. El precio por uso la habría retenido.
• Con un desarrollo propio, 400 $/mes de coste de API suena comparable, hasta que añades las 20 horas de ingeniería al mes para mantenerlo vivo. A un coste totalmente cargado de 90 $/hora, eso son 1.800 $/mes solo en mantenimiento, que eclipsan por completo la factura del modelo.

Aquí está la tabla de escalado del camino de precio por uso, directamente de la página de precios de eesel:

Una nota más sobre la predictibilidad: un comprador al que describiré como un equipo de soporte de hardware con presupuesto ajustado había visto cómo el precio de un proveedor anterior se duplicaba con creces, y quería precios fijados por contrato antes de comprometerse. Ese instinto es correcto. El precio por uso con un tope de gasto te da la misma protección sin contrato, ya que fijas un techo mensual y el agente se pausa al llegar a él.

Cómo mantener predecibles los costes de un chatbot

El chatbot más barato es el que puedes prever. Tres cosas mantienen la factura aburrida, en el buen sentido:

Configura, no programes. El mayor coste de un desarrollo propio es el tiempo de ingeniería, así que el mayor ahorro es eliminarlo. Un agente de IA para el helpdesk moderno se configura en lenguaje natural, no en un repositorio de código, lo que significa que la persona a cargo del soporte puede cambiar el comportamiento del bot sin abrir un ticket de ingeniería.

Simula antes de gastar. El chatbot más caro es el que pagas por construir y luego descubres que no funciona. Ejecutar un bot contra tus tickets pasados antes de lanzarlo te dice la tasa de resolución real y, por extensión, el coste mensual real, antes de que llegue un solo dólar de tráfico en vivo. Es lo más parecido a ponerle precio al resultado de antemano.

Mide por tareas y limita el gasto. Cuando te facturan por tarea resuelta y no por puesto o por mensaje, el informe te dice exactamente qué compró cada dólar, lo que también facilita vincular tus KPI de atención al cliente con el gasto. Combina eso con un tope de gasto y alertas por correo, y una factura descontrolada se vuelve estructuralmente imposible. La misma lógica se aplica tanto si gestionas un bot de helpdesk de TI como uno de cara al cliente.

Prueba eesel

Si la respuesta honesta a "cuánto debería costar un chatbot" es "lo menos posible por un resultado que funcione", esa es exactamente la apuesta para la que está construido eesel. Es un agente de IA para el helpdesk que se instala en Zendesk, Freshdesk, HubSpot, Gorgias o Front, aprende de tus tickets pasados y documentación de ayuda desde el primer día, y se factura a 0,40 $ por ticket sin cuota de plataforma, sin cuota por puesto y sin mínimo. Te saltas la factura de construcción y el muro del mantenimiento, y un tope de gasto mantiene la cifra mensual donde tú la fijes.

Aún mejor, puedes simularlo sobre tus propios tickets históricos y ver la tasa de resolución y el coste proyectado antes de comprometerte, que es más de lo que te dará jamás el presupuesto de cualquier agencia.