Qué hace (y qué NO hace) un agente de WhatsApp en 2026
Cuando un cliente nos pregunta "¿me montáis un agente de WhatsApp?", lo primero que hacemos es preguntarle qué se imagina que hace. Casi siempre la respuesta incluye cosas que la política de Meta no permite, y casi nunca incluye las cosas que de verdad dan dinero: responder en segundos, no perder un pedido a las 23h y avisar a un humano cuando toca. Este artículo es la versión sin humo de lo que un agente de WhatsApp puede y no puede hacer en 2026, apoyado únicamente en documentación oficial de Meta/WhatsApp Business: la política de mensajería, la página de precios de la plataforma y los términos de la Solución de Negocio de WhatsApp.
La pieza que lo cambia todo: la ventana de 24 horas
Buena parte de lo que hace o deja de hacer un agente de WhatsApp gira en torno a un concepto: la ventana de servicio de 24 horas. Según la Política de Mensajería de WhatsApp Business, una conversación iniciada por un usuario se abre cuando se entrega el primer mensaje de respuesta de la empresa, y esta puede responder libremente dentro de ese periodo. Fuera de la ventana de 24 horas, solo se pueden enviar Message Templates previamente aprobados por Meta; y la política aclara expresamente que "se aplica el precio estándar para todas las categorías de conversación" cuando se envían mensajes fuera de esa ventana.
Esto tiene una consecuencia práctica que mucha gente no calcula bien: si un cliente pregunta el precio de un producto un lunes a las 10h y no vuelve a escribir, la empresa tiene esas 24 horas para cerrar la conversación con mensajes libres, sin coste asociado a la categoría de servicio. Pasado ese plazo, cualquier recordatorio tiene que ir por una plantilla aprobada, y las plantillas están sujetas a revisión y aprobación por parte de Meta antes de poder usarse, tal y como recoge la propia política.
Foto de dumitru B en Pexels
Cómo se cobran realmente los mensajes
La página oficial de precios de la WhatsApp Business Platform explica el modelo con bastante claridad: las empresas pagan por mensaje entregado (no por mensaje enviado), y el coste depende de dos factores, el país de destino y la categoría del mensaje (marketing, utilidad, autenticación o servicio). Dos puntos importantes que se derivan directamente de esa página:
Los mensajes de categoría servicio no se cobran nunca.
Los mensajes de categoría utilidad que la empresa envía en respuesta a una acción del usuario tampoco se cobran.
Además, cuando un usuario te escribe a partir de un anuncio que lleva a WhatsApp o de un botón de llamada a la acción en la página de Facebook, se abre una ventana de 72 horas en la que todos los mensajes quedan sin coste, sea cual sea la categoría.
Meta también describe "volume tiers" para los mensajes de utilidad y autenticación: cuanto más volumen manda una empresa, mejores tarifas puede desbloquear. La página no publica cifras universales de tramos válidas para todos los mercados —el desglose real varía por país y moneda, y Meta remite a una calculadora propia para consultarlo—, así que cualquier cifra concreta de tramos que veas en otro sitio hay que tratarla como estimación, no como regla fija.
Lo importante aquí es distinguir tres capas de coste que suelen confundirse en una sola factura mental:
El coste de Meta
Lo que Meta cobra por mensaje entregado según categoría y país. Es público y consultable en su página de precios.
El coste del proveedor (BSP)
Si contratas a un proveedor para integrar o mantener el agente, pide que su presupuesto separe ese servicio de los cargos de mensajería de Meta. No presupongas que el coste de la integración está incluido en la tarifa de WhatsApp.
El coste del agente en sí
El diseño, desarrollo y mantenimiento del agente (flujos, plantillas, integraciones, escalado a humano) es un proyecto aparte, independiente de lo que cobren Meta y el BSP.
Cuando un presupuesto mezcla estas tres capas en una sola cifra, es muy fácil que el cliente piense que está pagando "por usar WhatsApp" cuando en realidad está pagando tres cosas distintas con lógicas de precio distintas.
Foto de Amina Filkins en Pexels
Lo que un agente de WhatsApp SÍ puede hacer
Dentro de las reglas de la ventana y las categorías de mensaje, la lista de cosas permitidas es larga y cubre la mayoría de lo que una pyme necesita. La propia política de mensajería permite explícitamente el uso de automatización dentro de la ventana de 24 horas, siempre que existan caminos de escalado claros a un humano (chat, teléfono, email, formulario web, tienda física). Sobre esa base, un agente puede configurarse, por ejemplo, para:
Atención al cliente y FAQ
Responder horarios, precios, disponibilidad, políticas de devolución, dudas sobre el producto. Es el uso más común y el que menos fricción genera.
Seguimiento de pedidos
Consultar el estado de un pedido, dar número de seguimiento, avisar de incidencias en el envío (todo esto encaja en la categoría de utilidad, que no se cobra cuando es respuesta a una acción del usuario).
Reservas y turnos
Agendar citas en clínicas, restaurantes, peluquerías o estudios, con confirmación y recordatorio dentro de la ventana.
Cualificación de leads
Hacer preguntas de filtro antes de pasar el contacto a un comercial: presupuesto, urgencia, tipo de necesidad.
Escalado a humano
Detectar cuándo el caso se sale del guion definido y pasar la conversación a una persona, por la vía de escalado que la política exige tener disponible: transferencia en chat, teléfono, correo, formulario o visita presencial.
El matiz importante en todos estos usos es que el agente tiene que estar acotado a un proceso de negocio concreto, no ser un compañero de conversación general que responde de cualquier tema.
Foto de Mikhail Nilov en Pexels
Lo que un agente de WhatsApp NO debería hacer
Aquí hay algo que merece precisión, porque circulan versiones exageradas: los Términos de la Solución de Negocio de WhatsApp incluyen una cláusula específica sobre "AI Providers". Según esos términos, los proveedores y desarrolladores de tecnologías de inteligencia artificial o aprendizaje automático —incluyendo modelos de lenguaje grandes o asistentes generalistas de IA— tienen prohibido acceder o usar la Solución de Negocio de WhatsApp para ofrecer esas tecnologías cuando esa es su funcionalidad principal, y no una función incidental o accesoria. Hay una excepción explícita: esas tecnologías sí pueden ofrecerse a usuarios de WhatsApp con números registrados en países del Área Económica Europea o en Brasil.
Esto es distinto de decir que "los chatbots generalistas están prohibidos en todo el mundo": lo que dicen los términos es una restricción contractual concreta sobre la Solución de Negocio, con excepciones geográficas explícitas, y no una prohibición absoluta y universal. Aun así, el efecto práctico para quien diseña un agente es claro: cuanto más se parezca tu agente a un asistente generalista que habla de cualquier tema, más riesgo corre tu cuenta.
Por eso, en la práctica, un agente de WhatsApp bien construido no debería:
Dar asesoramiento legal, médico o financiero como si fuera un profesional colegiado.
Tomar decisiones sensibles (aprobar un crédito, aceptar una reclamación grande, cancelar un contrato) sin pasar por una persona.
Prometer condiciones comerciales que nadie ha validado ("sí, te hago descuento del 30%").
Comportarse como un chat abierto que responde de todo, desde recetas de cocina hasta política, sin relación con el proceso de negocio para el que se contrató.
Un agente bien diseñado documenta explícitamente tres cosas: qué puede hacer (ventas, soporte, reservas, seguimiento de pedidos, cualificación de leads), qué no puede hacer (asesoramiento legal, médico o financiero, decisiones sensibles, promesas comerciales no validadas) y cuándo deriva a un humano (importes altos, cliente enfadado, reclamaciones, cambios de contrato, o cualquier pregunta que no esté en su catálogo de temas).
Esto no es solo por cumplir la norma de Meta. Es la diferencia entre un agente que un cliente real puede usar sin que se le vaya la conversación de las manos, y uno que en cuanto alguien le pregunta algo raro empieza a inventar respuestas.
Qué se puede configurar (y qué no inventamos nosotros)
Vale la pena aclarar una cosa: cuando hablamos de "lo que hace un agente de WhatsApp", estamos hablando de posibilidades de configuración sobre la API oficial, no de capacidades mágicas que Ardeiro.AI tenga resueltas en exclusiva. Por ejemplo, un agente se puede configurar para consultar el estado de un pedido en un sistema de gestión, pero eso requiere que ese sistema tenga una integración disponible; se puede configurar para agendar citas, pero requiere conectar con un calendario real; se puede configurar para escalar a un humano por horario o por tema, pero requiere definir esos criterios con quien conoce el negocio. Nada de esto viene "de serie": es trabajo de diseño e integración, caso por caso.
Esto importa porque es habitual que un cliente asuma que "poner un agente de WhatsApp" es activar un interruptor. En realidad es un proyecto pequeño pero real: definir el alcance, escribir y aprobar las plantillas necesarias, conectar las fuentes de datos que hagan falta, y probar los caminos de escalado antes de lanzarlo con clientes de verdad.
Cómo lo planteamos en Ardeiro.AI
Cuando diseñamos un agente de WhatsApp para un cliente, empezamos siempre por el mapa de lo que NO hace, antes que por lo que hace. Es un documento corto, de una página, que dice: estos son los temas que responde, estos son los que deriva a una persona, y este es el límite de lo que promete. Ese documento es el que evita sustos: reclamaciones que el bot no debería haber gestionado, descuentos inventados, o simplemente un cliente frustrado hablando con un muro de texto genérico.
Después viene la parte técnica: qué plantillas hacen falta para los mensajes fuera de ventana, cuáles son las integraciones reales disponibles (pedidos, calendario, CRM), y cómo se estima el coste mensual sumando las tres capas ya mencionadas: lo que cobra Meta por mensaje entregado, lo que cobra el proveedor de la API, y el coste del propio desarrollo y mantenimiento del agente. Recomendamos siempre calcular ese coste con un ejemplo hipotético basado en el volumen estimado real del negocio, y no con cifras genéricas encontradas en un blog cualquiera —incluido este.
Un agente de WhatsApp que funciona no es el que más cosas sabe hacer. Es el que tiene claro dónde para, y que en ese punto exacto pasa el testigo a una persona sin que el cliente note fricción.
Cuatro pruebas prácticas antes de confiarle la atención al cliente
Para evaluar una propuesta no hace falta empezar con una conversación espectacular. Resulta más útil preparar situaciones pequeñas, con un resultado que puedas comprobar. Los casos siguientes son ejemplos hipotéticos de diseño: no describen resultados medidos en un negocio ni funciones que cualquier agente tenga instaladas de serie. Sirven para concretar qué quieres delegar, qué permisos necesita el sistema y cómo sabrás si ha trabajado bien.
Una reserva que cambia mientras el cliente decide
Imagina una peluquería que ofrece dos huecos para el viernes. El cliente tarda unos minutos en responder y, durante ese intervalo, una persona del equipo ocupa uno de ellos desde el calendario. La prueba consiste en pedir precisamente ese horario. El comportamiento deseado es volver a consultar la disponibilidad antes de guardar, detectar el cambio y ofrecer una alternativa. Una conversación fluida no compensa una reserva que el calendario no puede aceptar.
Después conviene probar el caso contrario: el calendario guarda la cita, pero la respuesta tarda en llegar. Decide de antemano cómo se comprobará si la operación se completó antes de repetirla. Pide ver la cita en la herramienta que usa el equipo y la confirmación que recibe el cliente. Para esta prueba, el criterio de aceptación puede ser sencillo: una petición debe producir una sola reserva y el mensaje de confirmación debe coincidir con lo que realmente está guardado.
Una consulta cuya respuesta depende de una condición
Supongamos ahora un taller que cobra importes distintos según el trabajo y el vehículo. Un cliente pregunta cuánto cuesta «hacer la revisión». En lugar de valorar únicamente si el agente responde rápido, comprueba si distingue un precio publicado de un presupuesto que requiere diagnóstico. Puedes facilitarle una tabla de servicios cerrados y una instrucción expresa para derivar los casos que quedan fuera. La prueba debe incluir una pregunta ambigua y otra sobre un servicio que no figura en esa tabla.
El objetivo de diseño sería que el agente explicase qué información falta, recogiese los datos necesarios y propusiese el siguiente paso. No debería convertir un ejemplo de precio en una oferta vinculante ni inventar un descuento para cerrar la conversación. Revisa también qué ocurre cuando el cliente insiste: la misma condición comercial debería mantenerse aunque reformule la pregunta o diga que otra persona le prometió algo distinto. La respuesta puede ser amable sin alterar las reglas que has fijado.
Una persona que pide dejar de recibir mensajes
En un tercer escenario, una academia tiene un proceso de seguimiento de solicitudes de información. Una persona responde que ya no le interesa y que no quiere más mensajes. Diseña la prueba para que esa petición llegue justo antes de un seguimiento previsto. Lo que debes comprobar es el recorrido completo: cómo se registra la preferencia, qué automatización consulta ese registro y qué verá una persona del equipo cuando abra la conversación.
Como criterio interno, puedes exigir que el responsable identifique qué seguimiento habría salido y por qué ha quedado detenido. Esa comprobación es más útil que una respuesta automática que diga «anotado» sin modificar ningún estado. Si varias herramientas mantienen listas distintas, incluye todas en la prueba. La política de mensajería de WhatsApp exige respetar las solicitudes de baja; este ejemplo propone una manera práctica de comprobar que tu integración lo hace.
Una incidencia que necesita una decisión humana
Piensa, por último, en una persona que reclama un cobro y pide una devolución. Puedes decidir que el agente recopile la referencia del pedido y una explicación breve, pero que la autorización del abono corresponda al equipo. Prepara una conversación de prueba en la que falte información y otra en la que la persona se muestre enfadada. Evalúa si el sistema mantiene esa separación de responsabilidades y transmite al responsable lo necesario para continuar.
Define también qué significa «derivar». Puede consistir en asignar la conversación, crear una tarea o facilitar un canal atendido por una persona. Escoge una opción que el negocio pueda sostener y comprueba quién la recibe. Si no hay nadie disponible en ese momento, el mensaje debería describir el siguiente paso previsto sin prometer una respuesta inmediata que nadie ha confirmado. Para evaluar el resultado, revisa tanto la conversación con el cliente como la tarea que llega al equipo.
Qué dejar por escrito al terminar esas pruebas
Una propuesta de trabajo puede cerrar estas pruebas con una ficha breve por proceso: objetivo, datos consultados, operaciones permitidas, responsable humano y señal de que la tarea se ha completado. Añade ejemplos de situaciones que deben detener el proceso. Este documento no necesita describir toda la tecnología; tiene que permitir que tú y tu equipo sepáis qué esperar de la integración y a quién acudir cuando el comportamiento sea distinto.
Para el seguimiento, elige unas pocas medidas que puedas obtener de tus propias herramientas: reservas realmente guardadas, consultas derivadas, conversaciones pendientes y correcciones que tuvo que hacer el equipo. No fijes una mejora porcentual como si ya estuviera demostrada. Primero registra cómo funciona el proceso actual y después compara periodos y situaciones similares. Así podrás decidir con tus datos si ampliar el alcance, ajustar las instrucciones o mantener determinadas tareas en manos de una persona.
Fuentes
Imagen de portada: Anton en Pexels
¿Quieres hablar de esto?
No hay comentarios públicos. Pero sí mi correo. Si algo te resuena o te chirría, escríbeme.
Escríbeme directo →