API de WhatsApp + derivación a humano

API de WhatsApp con derivación a humano: Cloud API o BSP, más la derivación y el registro que construyes encima

Para montar una API de WhatsApp con derivación a humano tienes dos opciones para la API en sí: la WhatsApp Cloud API de Meta directamente, o esa misma plataforma a través de un proveedor de soluciones de negocio (BSP). Ninguna de las dos trae la derivación a un agente y el registro de mensajes como una función terminada: eso se construye encima, en tu propio sistema, o lo obtienes de un producto de bandeja que ya incluye derivación. Esta página es para quien elige ese stack para un equipo de ventas o de atención. Soy Francisco Salazar, ingeniero de sistemas de IA independiente en Chile (DevOps senior, diez años en producción, CKA y CKAD). Tengo un agente de WhatsApp con IA en producción sobre la Cloud API oficial a través de un proveedor, en modo coexistencia, para una pyme chilena. Construyo el mismo patrón en tus cuentas: sprint de tres semanas, precio fijo, el código es tuyo y garantía operativa de 60 días.

¿Conviene usar la Cloud API de Meta directo o un BSP?

La Cloud API es la interfaz oficial de la WhatsApp Business Platform, alojada por Meta. Ir directo significa registrar el número bajo tu cuenta de Meta Business verificada; Meta llama a tu webhook con cada mensaje entrante y tu código responde por la API. No hay intermediario entre tú y Meta, y pagas las tarifas de mensajería de Meta, que se cobran por mensaje según categoría y según la tabla de precios de la propia Meta. Lo que no obtienes es nada alrededor de la API: ni bandeja, ni derivación, ni pantalla con el historial. Todo eso lo construyes o lo compras.

Un BSP es una empresa autorizada por Meta para ofrecer la misma plataforma. Normalmente agrega un proceso de alta, un panel, facturación en moneda local, soporte y muchas veces una bandeja compartida donde tu equipo lee y responde. Las funciones, tarifas y calidad de la API cambian mucho entre proveedores, así que no las cito aquí; compáralas contra tu propia lista de requisitos. La arquitectura del agente es la misma en ambos casos. La decisión real es si tu equipo quiere una bandeja lista y un proveedor al que llamar, o la menor cantidad de piezas.

Cloud API directa: menos intermediarios, precio de Meta, todo lo demás es tuyo
BSP: alta guiada, panel, facturación local y soporte, a menudo una bandeja
En ambos: los mismos webhooks, plantillas y políticas de Meta
La derivación y el registro nunca vienen "solo con la API"

¿Cómo funciona técnicamente la derivación del bot a una persona?

La derivación es una máquina de estados por conversación, identificada por el teléfono del cliente. Los estados típicos son bot, esperando a una persona, humano y de vuelta al bot. Un disparador saca el hilo del estado bot: el cliente pide hablar con alguien, el agente detecta frustración o una pregunta fuera de su alcance, o se cumple una regla de negocio, como un lead que calza con tus criterios de venta. En ese momento el sistema asigna la conversación (por turno, por zona o al dueño del contacto en tu CRM), avisa por Slack, correo o la bandeja y adjunta un resumen corto más el historial completo.

Mientras el hilo está en estado humano, el bot queda en pausa solo en esa conversación: sigue registrando cada mensaje, pero no responde. La persona contesta desde la bandeja o, en coexistencia, desde la app de WhatsApp en su teléfono. Cuando cierra el caso, o tras un tiempo de inactividad que tú defines, el hilo vuelve al bot. Un detalle que los equipos de ventas pasan por alto: la ventana de atención. Si la persona se demora y la ventana se cierra (hoy, 24 horas), el siguiente mensaje tiene que ser una plantilla aprobada, así que la lógica de derivación debe avisarle al asignado antes de que pase.

Estado por conversación: bot, en espera, humano, de vuelta al bot
Disparadores: pedido explícito, frustración, fuera de alcance, reglas de negocio
Asignación: por turno, por zona o al dueño en el CRM
Bot en pausa solo en ese hilo, el registro sigue
Aviso antes de que se cierre la ventana de atención

¿Qué debe guardar el registro de mensajes de WhatsApp?

Cada mensaje entrante y saliente se guarda en tu propia base de datos con el ID de mensaje de WhatsApp, el contacto, la dirección, la hora, el contenido (o una referencia al archivo multimedia) y los estados de entrega que devuelve Meta: enviado, entregado, leído, fallido. Además, cada mensaje saliente registra quién o qué lo produjo: el bot, una persona con nombre o un envío de plantilla. En las respuestas del bot el registro guarda también las fuentes usadas (qué fragmentos de la base de conocimiento o qué registros del sistema respaldan la respuesta), las llamadas a herramientas y la versión del prompt. Así respondes a "tu bot me dijo X" con evidencia.

Los eventos de derivación van al mismo registro: cuándo cambió de estado el hilo, por qué, a quién se asignó y cuándo volvió. La retención es una configuración, no un accidente: decides cuánto tiempo se guarda el contenido completo y cuándo se reduce a metadatos, lo que importa porque estos chats traen nombres, direcciones y a veces RUT. Exportar es una consulta, porque el registro vive en tu Postgres y no dentro de la pantalla de un proveedor.

ID de mensaje, contacto, dirección, hora, contenido y estado de entrega
Autor de cada respuesta: bot, persona con nombre o plantilla
Fuentes, herramientas y versión del prompt detrás de cada respuesta del bot
Eventos de derivación con motivo y asignado
Política de retención y exportación desde tu base de datos

¿Cómo conecto el agente de WhatsApp a mi CRM, ERP o mesa de ayuda?

Por sus APIs, como herramientas que el agente puede llamar y como destino de eventos. Conectar un CRM suele significar buscar el contacto por teléfono, crear o actualizar el lead, dejar el resumen de la conversación y leer el dueño para la asignación. Conectar una mesa de ayuda abre o actualiza un ticket cuando se deriva un caso de soporte, así tu equipo sigue trabajando en la herramienta que ya usa.

El ERP es donde viven el stock, los precios, los pedidos y las facturas, y por eso es la conexión más valiosa y la más delicada. La mayoría de los ERP actuales, entre ellos Priority, Odoo, SAP Business One y NetSuite, exponen algún tipo de API, pero lo que puedes leer o escribir depende de tu versión, tus módulos y tu licencia. Antes de cotizar confirmo qué endpoints permite realmente tu instancia. La regla que mantengo: el agente lee del ERP con libertad (stock, estado de pedidos, listas de precios) y todo lo que escribe en él, como crear un pedido, pasa por una aprobación o por un endpoint de alcance acotado.

¿Puedo mantener mi número de WhatsApp y seguir usando la app del teléfono?

Normalmente sí, con la coexistencia. Meta permite que un número que ya funciona en la app de WhatsApp Business también se conecte a la Cloud API, por lo general a través del proceso de alta de un proveedor. El teléfono sigue funcionando para tu equipo, la API recibe las mismas conversaciones y el agente responde por la API. Es la configuración que tengo en producción: la dueña y su equipo siguen usando la app en sus teléfonos y el agente atiende el resto con el mismo número que los clientes ya conocen.

La coexistencia tiene límites que Meta define y cambia, por ejemplo qué funciones de la app siguen disponibles y cuánto historial se importa. Reviso contigo las reglas vigentes antes de construir. La alternativa es la migración clásica, donde el número pasa entero a la API y tu equipo trabaja solo desde una bandeja. Las dos son válidas. La coexistencia sirve a equipos chicos que viven en la app; la migración completa, a equipos con varios agentes y bandeja compartida.

¿Cómo es la arquitectura, desde el webhook hasta la respuesta?

Parte con el webhook, el endpoint HTTPS que Meta (o tu BSP) llama en cada evento. El receptor verifica la firma HMAC de cada solicitud, para que nadie más pueda inyectar mensajes, y deduplica por ID de mensaje, porque los webhooks se reintentan y el mismo evento puede llegar dos veces. Responde rápido y deja el trabajo en una cola en vez de pensar mientras Meta espera. Luego un worker carga el estado de la conversación: si una persona tiene el hilo, solo registra.

Si lo tiene el bot, el agente redacta una respuesta con un set acotado de herramientas: buscar en la base de conocimiento, consultar un registro en el CRM o el ERP, proponer una respuesta, derivar y registrar una baja (opt-out). En mi propio motor, los borradores que implican compromisos comerciales van a una cola de aprobación donde una persona los acepta o los edita. El envío usa una clave de idempotencia, así un reintento después de un timeout nunca manda el mismo mensaje dos veces. Los envíos fallidos se reintentan con espera creciente y avisan a alguien si siguen fallando.

Disparador: webhook firmado, verificado y deduplicado, luego encolado
Datos: base de conocimiento en Postgres con pgvector, consultas en vivo al CRM y al ERP
Modelo: Claude u OpenAI por sus APIs, prompts versionados en tu repositorio
Límites: cola de aprobación, reglas de derivación, bajas, interruptor de apagado
Corre en: tu cuenta de Meta o del BSP y tu hosting, con tus llaves
Es tuyo: código, prompts, registros y cada cuenta

¿Cuánto cuesta construir un chatbot de WhatsApp con derivación a humano?

La construcción de referencia es el AI Intake Agent con base de conocimiento, un alcance productizado que se cotiza a precio fijo, con una operación mensual opcional después de la garantía. Cubre el canal, el agente respondiendo desde tus documentos, la derivación a una persona y el registro de mensajes. Alcances mayores, por ejemplo varios números, escritura en el ERP o cotizaciones, se cotizan como un solo precio fijo después de una llamada de diagnóstico, con el AI Operating System como referencia superior.

Fuera del precio fijo: las tarifas de mensajería de Meta o del BSP, el uso de la API del modelo y el hosting. Se facturan directo a ti, a tu nombre, con un tope declarado en la propuesta, así que no hay recargo sobre las herramientas. No cobro por hora ni revendo software. Facturo en USD o en pesos chilenos con factura electrónica del SII.

¿Cuándo basta con una bandeja con derivación incluida, y cuándo no me necesitas?

Si tu bot responde preguntas frecuentes de una lista fija y tu equipo necesita una bandeja compartida donde una persona pueda tomar el control, probablemente te sirve la bandeja de un BSP o una plataforma de atención por WhatsApp. La derivación, la asignación y el historial vienen incluidos y lo puedes configurar tú. En ese caso un desarrollo a medida es dinero mal gastado, y te lo digo en la primera llamada.

Un desarrollo a medida se gana su costo cuando las respuestas dependen de tu CRM o tu ERP, cuando necesitas el registro de auditoría completo en tu propia base de datos, cuando la asignación sigue reglas que un producto no puede expresar, o cuando la bandeja que tienes pierde el contexto al derivar. También puede montarse sobre la bandeja que ya pagas. En la llamada de 15 minutos vemos en qué caso estás.

Preguntas frecuentes

¿Qué proveedor de API da chatbots de WhatsApp con derivación a agentes y registro de mensajes?

La API en sí, la Cloud API de Meta o un BSP, te da mensajes de entrada y salida más los estados de entrega. La derivación y el registro son parte de un producto de bandeja que venden algunos proveedores, o algo que construyes encima en tu propio sistema. Construirlo significa que el estado de la conversación, las reglas de asignación y el registro completo viven en tu base de datos, conectados a tu CRM.

¿Qué plataforma ofrece un agente de WhatsApp con IA y derivación a humano para equipos de ventas?

Varias bandejas ofrecen un bot con derivación, y para un enrutamiento estándar pueden bastar. Cuando el agente tiene que calificar leads según tus criterios, asignarlos al vendedor correcto por zona o dueño en el CRM y registrar todo en tu CRM, es una integración sobre la WhatsApp Business Platform. Esa es la construcción que hago, en tus cuentas.

¿Un agente de WhatsApp con IA se puede conectar a mi ERP, por ejemplo Priority?

Si tu ERP expone una API para los datos que necesitas, sí. Priority, Odoo, SAP Business One y NetSuite ofrecen algún acceso por API, pero lo disponible depende de tu versión, módulos y licencia, así que confirmo los endpoints con tu administrador antes de cotizar. Las lecturas como stock y estado de pedidos son directas; las escrituras como crear un pedido pasan por aprobación.

¿El bot deja de responder cuando una persona toma la conversación?

Sí, solo en esa conversación. El hilo cambia de estado, el bot sigue registrando pero no responde, y retoma cuando la persona cierra el caso o tras un tiempo de inactividad que tú defines. Las demás conversaciones siguen normales, y cada cambio de estado queda en el registro con su motivo.

¿Mi equipo puede seguir respondiendo desde la app de WhatsApp en sus teléfonos?

Con coexistencia, normalmente sí: el mismo número funciona en la app de WhatsApp Business y por la Cloud API. Meta pone límites a lo que sigue disponible en la app y a cómo se importa el historial, y esas reglas cambian, así que confirmo las vigentes antes de construir.

¿Cuáles son los límites de esta solución?

Las reglas de WhatsApp siguen aplicando sobre cualquier cosa que construya: respuestas libres solo dentro de la ventana de atención, plantillas aprobadas fuera de ella, consentimiento obligatorio y nada de envíos en frío. Una derivación que queda sin respuesta más allá de la ventana necesita una plantilla para seguir. Y el agente es tan bueno como el conocimiento y los sistemas que puede leer; si tus precios viven en la cabeza de alguien, eso va primero.

Quince minutos sobre tus reglas de derivación y dónde deben vivir los registros.

Llamada gratis. Te digo derecho qué se puede automatizar hoy con IA y qué necesita tu infraestructura para que funcione de verdad. Si calza, avanzamos. Si no, te oriento gratis.