Un agente de IA para WhatsApp que responde con los datos de tu empresa

No te voy a dar un número aquí, porque el mismo agente cuesta muy distinto según cinco cosas, y quien te da un precio sin preguntarlas te lo corrige después. Lo que mueve el precio: primero, el canal —la API oficial de WhatsApp Business cobra por conversación y exige plantillas aprobadas; una integración self-hosted en un VPS propio da más control y menor coste por mensaje, a cambio de hacerte cargo de la infraestructura—. Segundo, cuántos sistemas hay que integrar de verdad: catálogo, stock, agenda, CRM, pasarela de pago; ahí está el grueso del trabajo. Tercero, si el agente sólo informa o además opera, es decir si monta un pedido, cobra o agenda una cita. Cuarto, el volumen de mensajes, que pesa en el coste mensual del canal y del modelo, no en el desarrollo. Y quinto, si hace falta bandeja compartida para que varias personas atiendan el mismo número. Cuéntame cuáles de esas cinco aplican a tu caso y te paso un número que se sostenga.

Un chatbot sigue un árbol de opciones que alguien escribió: si el cliente se sale del guion, se atasca. Un agente entiende lo que le escriben en lenguaje natural, consulta tus sistemas para responder y puede ejecutar acciones dentro de la misma conversación: montar un pedido, agendar, cobrar. La diferencia se nota en las preguntas que nadie previó, que en una empresa real son la mayoría. Y se nota en el mantenimiento: el árbol hay que reescribirlo cada vez que cambia algo, mientras que el agente lee el dato actualizado del sistema.

Hay dos caminos y conviene elegirlo a conciencia. La API oficial es la vía formal, con plantillas aprobadas y coste por conversación. La alternativa es una integración self-hosted, que ejecuto en Docker sobre un VPS propio: más control y menor coste por mensaje, a cambio de hacerse cargo de la infraestructura. Uso las dos según el caso. Te explico el tradeoff con tu volumen real de mensajes encima de la mesa antes de que decidas, porque cambiar de camino después cuesta.

Con dos decisiones de diseño que se toman antes de escribir código. La primera: el agente no guarda los datos, los consulta. Si tu sistema expone una API, pregunta precio y disponibilidad en el momento; si no la expone, se monta un ETL que sincroniza el catálogo de forma automática. Es el mismo mecanismo que usé para mantener sincronizados catálogos con variantes complejas de colores, telas y listas de precios. La segunda: queda escrito qué no debe contestar nunca, y «no tengo ese dato, te paso con alguien del equipo» se define como respuesta correcta, no como fallo.

Sí, y es lo que lo separa de un bot de consultas. Construí un agente de ventas para una pizzería que monta el pedido dentro de la conversación —producto, variantes, extras— y termina con el checkout de pago integrado, usando Stripe y Redsys como pasarelas. El cliente no sale de WhatsApp para comprar. El mismo esquema aplica a otros sectores: el agente resuelve la duda que frenaba la compra y cobra en el mismo hilo, que es justo donde hoy se caen las ventas.

El traspaso es donde se enfrían las oportunidades, así que se resuelve con una bandeja de entrada compartida: la conversación pasa a tu equipo con todo el historial visible, sin pedirle al cliente que repita nada, y cualquiera del equipo puede continuarla desde la misma pantalla. Es la arquitectura que monté para una operación con varias personas atendiendo el mismo número. Un agente sin bandeja detrás no ahorra trabajo: lo esconde hasta que el cliente se cansa.