Que fai (e que NON fai) un axente de WhatsApp en 2026
Cando un cliente nos pregunta "¿móntanos un axente de WhatsApp?", o primeiro que facemos é preguntarlle que se imaxina que fai. Case sempre a resposta inclúe cousas que a política de Meta non permite, e case nunca inclúe as cousas que de verdade dan diñeiro: responder en segundos, non perder un pedido ás 23h e avisar a unha persoa cando toca. Este artigo é a versión sen fume do que un axente de WhatsApp pode e non pode facer en 2026, apoiado só en documentación oficial de Meta/WhatsApp Business: a política de mensaxaría, a páxina de prezos da plataforma e os termos da Solución de Negocio de WhatsApp.
A peza que o cambia todo: a fiestra de 24 horas
Boa parte do que fai ou deixa de facer un axente de WhatsApp xira arredor dun concepto: a fiestra de servizo de 24 horas. Segundo a Política de Mensaxaría de WhatsApp Business, unha conversa iniciada por un usuario ábrese cando se entrega a primeira mensaxe de resposta da empresa, e a empresa pode responder libremente dentro dese período. Fóra da fiestra de 24 horas, só se poden enviar Message Templates previamente aprobados por Meta; e a política aclara expresamente que "aplícase o prezo estándar para todas as categorías de conversa" cando se envían mensaxes fóra desa fiestra.
Isto ten unha consecuencia práctica que moita xente non calcula ben: se un cliente pregunta o prezo dun produto un luns ás 10h e non volve escribir, o negocio ten esas 24 horas para pechar a conversa con mensaxes libres, sen custo asociado a categoría de servizo. Pasado ese prazo, calquera lembranza ten que ir por unha plantilla aprobada, e as plantillas están suxeitas a revisión e aprobación por parte de Meta antes de poderse usar, tal e como recolle a propia política.
Foto de dumitru B en Pexels
Como se cobran realmente as mensaxes
A páxina oficial de prezos da WhatsApp Business Platform explica o modelo con bastante claridade: as empresas págano por mensaxe entregada (non por mensaxe enviada), e o custo depende de dous factores, o país de destino e a categoría da mensaxe (marketing, utilidade, autenticación ou servizo). Dous puntos importantes que se derivan directamente desa páxina:
As mensaxes de categoría servizo non se cobran nunca.
As mensaxes de categoría utilidade que a empresa envía en resposta a unha acción do usuario tampouco se cobran.
Ademais, cando un usuario che escribe a partir dun anuncio que leva a WhatsApp ou dun botón de chamada á acción na páxina de Facebook, ábrese unha fiestra de 72 horas na que todas as mensaxes quedan sen custo, sexa cal sexa a categoría.
Meta tamén describe "volume tiers" para as mensaxes de utilidade e autenticación: canto máis volume manda unha empresa, mellores tarifas pode desbloquear. A páxina non publica cifras universais de tramos válidas para todos os mercados —o desglose real varía por país e moeda, e Meta remite a unha calculadora propia para consultalo—, así que calquera cifra concreta de tramos que vexas noutro sitio hai que tratala como estimación, non como regra fixa.
O importante aquí é distinguir tres capas de custo que adoitan confundirse nunha soa factura mental:
O custo de Meta
O que Meta cobra por mensaxe entregada segundo categoría e país. É público e consultable na súa páxina de prezos.
O custo do provedor (BSP)
Se contratas un provedor para integrar ou manter o axente, pide que o seu orzamento separe ese servizo dos cargos de mensaxería de Meta. Non deas por feito que o custo da integración está incluído na tarifa de WhatsApp.
O custo do axente en si
O deseño, desenvolvemento e mantemento do axente (fluxos, plantillas, integracións, escalado a humano) é un proxecto á parte, independente do que cobren Meta e o BSP.
Cando un orzamento mestura estas tres capas nunha soa cifra, é moi fácil que o cliente pense que está pagando "por usar WhatsApp" cando en realidade está pagando tres cousas distintas con lóxicas de prezo distintas.
Foto de Amina Filkins en Pexels
O que un axente de WhatsApp SI pode facer
Dentro das regras da fiestra e das categorías de mensaxe, a lista de cousas permitidas é longa e cobre a maioría do que unha peme necesita. A propia política de mensaxaría permite explicitamente o uso de automatización dentro da fiestra de 24 horas, sempre que existan camiños de escalado claros a un humano (chat, teléfono, email, formulario web, tenda física). Sobre esa base, un axente pode configurarse, por exemplo, para:
Atención ao cliente e FAQ
Responder horarios, prezos, dispoñibilidade, políticas de devolución, dúbidas sobre o produto. É o uso máis común e o que menos fricción xera.
Seguimento de pedidos
Consultar o estado dun pedido, dar número de seguimento, avisar de incidencias no envío (todo isto encaixa na categoría de utilidade, que non se cobra cando é resposta a unha acción do usuario).
Reservas e quendas
Axendar citas en clínicas, restaurantes, peiteados ou estudios, con confirmación e lembranza dentro da fiestra.
Cualificación de leads
Facer preguntas de filtro antes de pasar o contacto a un comercial: orzamento, urxencia, tipo de necesidade.
Escalado a humano
Detectar cando o caso se sae do guión definido e pasar a conversa a unha persoa, coa vía de escalado que a política esixe ter dispoñible: transferencia en chat, teléfono, correo, formulario ou visita presencial.
O matiz importante en todos estes usos é que o axente ten que estar acotado a un proceso de negocio concreto, non ser un compañeiro de conversa xeral que responde de calquera tema.
Foto de Mikhail Nilov en Pexels
O que un axente de WhatsApp NON debería facer
Aquí hai algo que merece precisión, porque circulan versións esaxeradas: os Termos da Solución de Negocio de WhatsApp inclúen unha cláusula específica sobre "AI Providers". Segundo eses termos, os provedores e desenvolvedores de tecnoloxías de intelixencia artificial ou aprendizaxe automática —incluíndo modelos de linguaxe grandes ou asistentes xeneralistas de IA— teñen prohibido acceder ou usar a Solución de Negocio de WhatsApp para ofrecer esas tecnoloxías cando esa é a súa funcionalidade principal, e non unha función incidental ou accesoria. Hai unha excepción explícita: esas tecnoloxías si se poden ofrecer a usuarios de WhatsApp con números rexistrados en países da Área Económica Europea ou en Brasil.
Isto é distinto de dicir que "os chatbots xeneralistas están prohibidos en todo o mundo": o que din os termos é unha restrición contractual concreta sobre a Solución de Negocio, con excepcións xeográficas explícitas, e non unha prohibición absoluta e universal. Aínda así, o efecto práctico para quen deseña un axente é claro: canto máis se pareza o teu axente a un asistente xeneralista que fala de calquera tema, máis risco corre a túa conta.
Por iso, na práctica, un axente de WhatsApp ben construído non debería:
Dar asesoramento legal, médico ou financeiro como se fose un profesional colexiado.
Tomar decisións sensibles (aprobar un crédito, aceptar unha reclamación grande, cancelar un contrato) sen pasar por unha persoa.
Prometer condicións comerciais que ninguén validou ("si, fágoche desconto do 30%").
Comportarse como un chat aberto que responde de todo, desde receitas de cociña ata política, sen relación co proceso de negocio para o que se contratou.
Un axente ben deseñado documenta explicitamente tres cousas: que pode facer (vendas, soporte, reservas, seguimento de pedidos, cualificación de leads), que non pode facer (asesoramento legal, médico ou financeiro, decisións sensibles, promesas comerciais non validadas) e cando deriva a un humano (importes altos, cliente enfadado, reclamacións, cambios de contrato, ou calquera pregunta que non estea no seu catálogo de temas).
Isto non é só por cumprir a norma de Meta. É a diferenza entre un axente que un cliente real pode usar sen que se lle vaia a conversa das mans, e un que en canto alguén lle pregunta algo raro empeza a inventar respostas.
Que se pode configurar (e que non inventamos nós)
Vale a pena aclarar unha cousa: cando falamos de "o que fai un axente de WhatsApp", estamos a falar de posibilidades de configuración sobre a API oficial, non de capacidades máxicas que Ardeiro.AI teña resolto en exclusiva. Por exemplo, un axente pódese configurar para consultar o estado dun pedido nun sistema de xestión, pero iso require que ese sistema teña unha integración dispoñible; pódese configurar para axendar citas, pero require conectar cun calendario real; pódese configurar para escalar a un humano por horario ou por tema, pero require definir eses criterios con quen coñece o negocio. Nada disto vén "de serie": é traballo de deseño e integración, caso por caso.
Isto importa porque é habitual que un cliente asuma que "poñer un axente de WhatsApp" é activar un interruptor. En realidade é un proxecto pequeno pero real: definir o alcance, escribir e aprobar as plantillas necesarias, conectar as fontes de datos que fagan falta, e probar os camiños de escalado antes de lanzalo con clientes de verdade.
Como o formulamos en Ardeiro.AI
Cando deseñamos un axente de WhatsApp para un cliente, empezamos sempre polo mapa do que NON fai, antes que polo que fai. É un documento curto, dunha páxina, que di: estes son os temas que responde, estes son os que deriva a unha persoa, e este é o límite do que promete. Ese documento é o que evita sustos: reclamacións que o bot non debería ter xestionado, descontos inventados, ou simplemente un cliente frustrado falando cun muro de texto xenérico.
Despois vén a parte técnica: que plantillas fan falta para as mensaxes fóra de fiestra, cales son as integracións reais dispoñibles (pedidos, calendario, CRM), e como se estima o custo mensual sumando as tres capas que xa mencionamos: o que cobra Meta por mensaxe entregada, o que cobra o provedor da API, e o custo do propio desenvolvemento e mantemento do axente. Recomendamos sempre calcular ese custo cun exemplo hipotético baseado no volume estimado real do negocio, e non con cifras xenéricas atopadas nun blog calquera —incluído este.
Un axente de WhatsApp que funciona non é o que máis cousas sabe facer. É o que ten claro onde para, e que nese punto exacto pasa o testemuño a unha persoa sen que o cliente note fricción.
Catro probas prácticas antes de confiarlle a atención ao cliente
Para avaliar unha proposta non fai falta comezar cunha conversa espectacular. Resulta máis útil preparar situacións pequenas, cun resultado que poidas comprobar. Os casos seguintes son exemplos hipotéticos de deseño: non describen resultados medidos nun negocio nin funcións que calquera axente teña instaladas de serie. Serven para concretar que queres delegar, que permisos necesita o sistema e como saberás se traballou ben.
Unha reserva que cambia mentres o cliente decide
Imaxina unha peiteadoría que ofrece dous ocos para o venres. O cliente tarda uns minutos en responder e, durante ese intervalo, unha persoa do equipo ocupa un deles desde o calendario. A proba consiste en pedir precisamente ese horario. O comportamento desexado é volver consultar a dispoñibilidade antes de gardar, detectar o cambio e ofrecer unha alternativa. Unha conversa fluída non compensa unha reserva que o calendario non pode aceptar.
Despois convén probar o caso contrario: o calendario garda a cita, pero a resposta tarda en chegar. Decide de antemán como se comprobará se a operación se completou antes de repetila. Pide ver a cita na ferramenta que usa o equipo e a confirmación que recibe o cliente. Para esta proba, o criterio de aceptación pode ser sinxelo: unha petición debe producir unha soa reserva e a mensaxe de confirmación debe coincidir co que realmente está gardado.
Unha consulta cuxa resposta depende dunha condición
Supoñamos agora un obradoiro que cobra importes distintos segundo o traballo e o vehículo. Un cliente pregunta canto custa «facer a revisión». En vez de valorar unicamente se o axente responde rápido, comproba se distingue un prezo publicado dun orzamento que require diagnóstico. Podes facilitarlle unha táboa de servizos pechados e unha instrución expresa para derivar os casos que quedan fóra. A proba debe incluír unha pregunta ambigua e outra sobre un servizo que non figura nesa táboa.
O obxectivo de deseño sería que o axente explicase que información falta, recollese os datos necesarios e propuxese o seguinte paso. Non debería converter un exemplo de prezo nunha oferta vinculante nin inventar un desconto para pechar a conversa. Revisa tamén que ocorre cando o cliente insiste: a mesma condición comercial debería manterse aínda que reformule a pregunta ou diga que outra persoa lle prometeu algo distinto. A resposta pode ser amable sen alterar as regras que fixaches.
Unha persoa que pide deixar de recibir mensaxes
Nun terceiro escenario, unha academia ten un proceso de seguimento de solicitudes de información. Unha persoa responde que xa non lle interesa e que non quere máis mensaxes. Deseña a proba para que esa petición chegue xusto antes dun seguimento previsto. O que debes comprobar é o percorrido completo: como se rexistra a preferencia, que automatización consulta ese rexistro e que verá unha persoa do equipo cando abra a conversa.
Como criterio interno, podes esixir que o responsable identifique que seguimento tería saído e por que quedou detido. Esa comprobación é máis útil que unha resposta automática que diga «anotado» sen modificar ningún estado. Se varias ferramentas manteñen listas distintas, inclúeas todas na proba. A política de mensaxería de WhatsApp esixe respectar as solicitudes de baixa; este exemplo propón unha maneira práctica de comprobar que a túa integración o fai.
Unha incidencia que necesita unha decisión humana
Pensa, por último, nunha persoa que reclama un cobro e pide unha devolución. Podes decidir que o axente recolla a referencia do pedido e unha explicación breve, pero que a autorización do reembolso corresponda ao equipo. Prepara unha conversa de proba na que falte información e outra na que a persoa se mostre anoxada. Avalía se o sistema mantén esa separación de responsabilidades e transmite ao responsable o necesario para continuar.
Define tamén que significa «derivar». Pode consistir en asignar a conversa, crear unha tarefa ou facilitar unha canle atendida por unha persoa. Escolle unha opción que o negocio poida sostido e comproba quen a recibe. Se non hai ninguén dispoñible nese momento, a mensaxe debería describir o seguinte paso previsto sen prometer unha resposta inmediata que ninguén confirmou. Para avaliar o resultado, revisa tanto a conversa co cliente como a tarefa que chega ao equipo.
Que deixar por escrito ao rematar esas probas
Unha proposta de traballo pode pechar estas probas cunha ficha breve por proceso: obxectivo, datos consultados, operacións permitidas, responsable humano e sinal de que a tarefa se completou. Engade exemplos de situacións que deben deter o proceso. Este documento non necesita describir toda a tecnoloxía; ten que permitir que ti e o teu equipo saibades que esperar da integración e a quen acudir cando o comportamento sexa distinto.
Para o seguimento, escolle unhas poucas medidas que poidas obter das túas propias ferramentas: reservas realmente gardadas, consultas derivadas, conversas pendentes e correccións que tivo que facer o equipo. Non fixes unha mellora porcentual coma se xa estivese demostrada. Primeiro rexistra como funciona o proceso actual e despois compara períodos e situacións similares. Así poderás decidir cos teus datos se ampliar o alcance, axustar as instrucións ou manter determinadas tarefas en mans dunha persoa.
Fontes
Imaxe de portada: Anton en Pexels
Queres falar disto?
Non hai comentarios públicos. Pero si o meu correo. Se algo che resoa ou che chirría, escríbeme.
Escríbeme directo →