Volver al blog

Agente nativo de WhatsApp o agente conectado: cómo saber cuál necesita tu empresa

Meta incorporó un agente IA nativo en WhatsApp Business. Resuelve bien un tipo de conversación y se detiene en otro. La guía para saber de qué lado de esa línea está tu operación.

Meta incorporó un agente de IA nativo en WhatsApp Business, y con eso cambió la pregunta que muchas empresas venían haciéndose. Ya no es "¿conviene automatizar WhatsApp?", sino otra más incómoda: si la plataforma ya trae un agente incluido, ¿en qué caso tiene sentido montar uno propio?

Este post es una guía de decisión, no un argumento de venta. Si al terminar concluyes que el agente nativo te alcanza, habremos hecho bien nuestro trabajo.

La línea divisoria: ¿dónde vive la respuesta?

Toda conversación de negocio por WhatsApp se clasifica con una sola pregunta: ¿la respuesta ya existe escrita en algún lado, o hay que ir a buscarla a un sistema?

"¿Qué horario tienen?" ya existe escrita. Está en el perfil del negocio.

"¿Cuánto debo?" no está escrita en ningún lado. Vive en una tabla de cuentas por cobrar, cambia cuando entra un pago, y es distinta para cada persona que pregunta.

Esa es la línea. De un lado, las conversaciones que se resuelven con información publicada. Del otro, las que exigen consultar el estado real de la operación en el momento en que alguien pregunta.

El test de las cuatro preguntas

Sirve para ubicarse sin llamar a nadie. Responde las cuatro sobre las conversaciones que tu empresa recibe por WhatsApp en una semana normal:

  1. ¿La mayoría se responde con catálogo, horario y datos del negocio? El agente nativo te alcanza.
  2. ¿Una parte relevante requiere mirar el saldo, el pedido o el historial de esa persona? Estás en el escalón de consulta a datos.
  3. ¿Lo que se conversa termina transcribiéndose a mano a un sistema? Estás en el escalón de escritura.
  4. ¿Hay procesos que involucran sistemas propios o servicios de terceros? Estás en el escalón de API.

Si respondiste que sí solo a la primera, no necesitas contratar nada. Es un resultado válido y conviene saberlo antes de sentarse en una demostración. El resto del post es para quienes respondieron que sí de la segunda en adelante.

Qué resuelve el agente nativo y dónde se detiene

Según el anuncio de Meta, el agente responde preguntas sobre el negocio, recomienda productos del catálogo, agenda citas, califica leads y le pasa la conversación a una persona cuando hace falta. Su conocimiento sale del historial de chats, el perfil del negocio y el catálogo. Se activa en minutos, sin proyecto de implementación.

Para un porcentaje enorme de negocios, eso es todo lo que necesitaban: un restaurante que responde horarios y carta, una tienda que muestra productos del catálogo, un consultorio que agenda turnos.

Donde se detiene es en tus sistemas. Las fuentes coinciden: el agente nativo no lee ni escribe en tu ERP ni en tu base de datos interna, y las integraciones externas no están disponibles en el nivel de autoservicio. Meta desarrolla una plataforma para que empresas grandes conecten sistemas como Shopify, Zendesk y Shopee, pero según TechCrunch ese despliegue es limitado.

Vale detenerse en esos nombres: son plataformas de comercio electrónico y de mesa de ayuda. Ninguna es el sistema donde una empresa mediana o grande de la región lleva su cartera, su facturación y su inventario. Ese sistema suele ser un ERP —de mercado o a medida— corriendo on-premise o en un servidor propio. Ahí no llega el conector de nadie por defecto.

Escalón 1 — Consultar un dato en la base

Aparece cuando la respuesta depende de quién pregunta. Un cliente escribe "¿cuál es mi saldo?" y el agente tiene que identificarlo por su número, buscar su cuenta, sumar facturas pendientes, restar pagos aplicados y devolver una cifra correcta. Nada de eso está en un catálogo.

Los casos típicos se repiten en casi toda empresa mediana: estado de cuenta y saldo vencido, situación de un pedido o despacho, historial de compras del cliente, disponibilidad real de inventario —no la del catálogo publicado.

Técnicamente es el escalón más accesible. El agente se conecta con un usuario de solo lectura y consulta vistas construidas sobre las tablas críticas. El riesgo es bajo: en modo lectura, el peor error posible es una respuesta incorrecta que se detecta y se corrige. No se rompe nada.

Escalón 2 — Ejecutar un proceso en el ERP

Distinto en naturaleza, no en dificultad. Aquí el agente deja de informar y empieza a producir efectos.

Un cliente responde "te pago el viernes". Si el agente solo informa, esa promesa se pierde en el hilo y alguien la transcribe a mano. Si el agente escribe, queda registrada con fecha y monto, y dispara el seguimiento. Lo mismo aplica a generar un pedido desde una conversación de venta, actualizar datos de contacto que el cliente corrige en el chat, o marcar una gestión para que el equipo sepa qué se conversó sin leer el hilo completo.

Este escalón exige más cuidado, y conviene ser franco sobre por qué: un agente que escribe en el ERP puede escribir mal. Por eso el orden sensato es lectura primero, escritura después, con alcance acotado a operaciones específicas y auditables.

La pregunta que ordena la decisión no es técnica sino operativa: ¿cuánto trabajo manual de transcripción genera hoy lo que se conversa por WhatsApp? Si la respuesta es "una persona dedicada varias horas por semana", el escalón se paga solo.

Escalón 3 — Hablar con una API

Aparece cuando el dato o la acción no viven en una base a la que se pueda entrar directamente. Pasa con ERP en la nube que exponen una API REST y bloquean el acceso a su base. Pasa cuando el proceso involucra un servicio externo: consultar el estado de un despacho con el operador logístico, validar información contra un sistema del que tu empresa es cliente y no dueña.

También hacia adentro. Muchas empresas medianas y grandes tienen sistemas propios —un portal de clientes, un módulo de despachos, una herramienta que construyó el equipo TI hace años— que exponen endpoints internos.

La decisión entre base de datos y API rara vez es de preferencia: la impone el sistema. Si el ERP permite acceso a la base, ese camino es más directo. Si solo expone API, se va por API. Si hay varios sistemas y se proyecta sumar más agentes, conviene montar una capa intermedia con el protocolo MCP y construir la integración una sola vez. El detalle está en cómo conectar tu ERP con WhatsApp.

Por qué esto separa empresas por tamaño

No es cuestión de facturación sino de estructura, aunque las dos suelan ir juntas.

Un negocio pequeño concentra su información en pocos lugares y muchas veces en la cabeza de una o dos personas. Sus conversaciones se responden con lo que está publicado, y sumar una capa de integración le agrega complejidad sin resolverle un problema que tenga.

Una empresa mediana o grande tiene lo contrario: la información está repartida entre un ERP, alguna base propia y sistemas de terceros, y ninguna persona la tiene completa en la cabeza. Cuando un cliente pregunta por su saldo, responder exige entrar a un sistema. Ese es el trabajo que un agente conectado elimina.

Hay una segunda diferencia, menos visible y más determinante: en una empresa con volumen, cada conversación que termina en transcripción manual se multiplica por cientos al mes. El costo no está en la conversación individual sino en el trabajo administrativo acumulado. Por eso el mismo agente que sería un lujo innecesario en un negocio pequeño se vuelve rentable en una operación con volumen. No cambia lo que hace: cambia por cuánto se multiplica.

Cómo lo hace Pacunex

Pacunex trabaja del lado derecho de la línea. Los agentes se conectan a los sistemas donde vive la información real y responden por WhatsApp con datos del momento, no con contenido publicado.

Conviene ser explícitos sobre el estado de las integraciones, porque en este terreno la exageración se paga cara. Pacunex tiene una sola integración en producción: AS2 de Asinfo, resuelta por lectura de su base de datos, que corre sobre MS SQL Server, PostgreSQL o MySQL según la instalación. Con cualquier otro ERP la respuesta honesta es que se puede conectar por alguno de los tres caminos descritos, y que el conector específico lo construye el equipo durante el piloto. Lo que no vamos a decirte es que ya tenemos un conector probado para tu marca de ERP si no lo tenemos.

Los dos enfoques conviven sin conflicto: el agente nativo puede seguir atendiendo consultas generales mientras el agente conectado se ocupa de las que requieren entrar a los sistemas.

La pregunta útil, entonces, no es cuál agente es mejor, sino qué porcentaje de tus conversaciones necesita un dato que hoy vive dentro de un sistema. Si ese porcentaje es bajo, el proyecto termina en el agente nativo. Si es alto, ninguna cantidad de configuración de catálogo va a cubrir esa brecha, porque el problema no es de configuración sino de acceso a los datos.

Si quieres revisar tu caso con alguien que va a decirte honestamente de qué lado de la línea estás, hablemos por WhatsApp. Sin formulario y sin tarjeta. Para empresas que evalúan montar su primer agente conectado con acompañamiento directo del equipo, el Programa Pioneros tiene condiciones especiales.