Conversation Routing de WhatsApp: varios partners en el mismo número

Conversation Routing asigna cada conversación a un único responsable cuando hay más de una integración en la misma WhatsApp account. Por defecto, todas las integraciones conectadas reciben todos los mensajes entrantes: funciona con un solo proveedor, pero se rompe si una herramienta atiende ventas, otra soporte y además está Meta Business Agent.

No se activa por API. Empieza a aplicar cuando se cumplen dos condiciones: la cuenta tiene más de un responsable posible y la empresa tiene una configuración de routing en Meta Business Suite. Meta lo pide así:

• Una WhatsApp account elegible con al menos un número registrado en Cloud API.
• Más de un responsable: dos o más partners, o un partner y una herramienta propia de Meta, como un Business Agent.
• Una configuración, hecha por la empresa en Meta Business Suite, que asigne cada punto de entrada a un responsable. No hay API pública para configurarlo.

La configuración vive en la WhatsApp account: la empresa define un valor por defecto para toda la cuenta y puede sobrescribirlo para números puntuales. Por eso un partner no debe asumir que el responsable de un punto de entrada es el mismo en todos los números.

Cada mensaje entrante recibe un punto de entrada según cómo llegó la persona o qué está respondiendo. La empresa elige un responsable principal para cada uno de los cinco puntos de entrada.

Con el punto de entrada definido, la plataforma resuelve el destinatario en este orden:

1. ¿Hay routing? Si no hay configuración, todos reciben todo.
2. ¿Es un cambio de intención? Un clic en un anuncio CTWA o un postback sobre una plantilla de marketing o Utility (tocar un botón de respuesta rápida, elegir en una lista o enviar un Flow) reinicia el hilo y se enruta por punto de entrada, aunque otro lo tuviera. Una respuesta citada no es cambio de intención.
3. ¿El hilo ya tiene dueño? Si lo tiene, el mensaje le llega al dueño, sea cual sea el punto de entrada.
4. Hilo libre: el mensaje va al responsable principal de ese punto de entrada, que pasa a ser el dueño al recibirlo, antes de responder. Para las respuestas a Marketing y a Utility, la empresa puede elegir Route to Sender: la respuesta va a quien envió la plantilla.

El control del hilo son tres acciones de la API (pass, release y take) que cambian quién es el dueño de una conversación. Se envían al endpoint /<PHONE_NUMBER_ID>/thread_control e identifican a la persona por su teléfono o, mejor, por su BSUID, que no cambia aunque cambie el número.

• Webhook messaging_handovers. El nuevo dueño recibe control_passed, que puede incluir un resumen de la conversación generado por IA. El dueño anterior recibe control_taken cuando el socio de escalamiento toma el hilo. Un release no genera webhook.
• Standby. Recibe copias de los mensajes entrantes, de los mensajes que envían otros responsables y de sus confirmaciones de entrega y lectura. Está apagado por defecto y la empresa lo habilita partner por partner.
• Mensajes de servicio. Solo los puede enviar el dueño del hilo; si no lo eres, la API responde con el error 131070, incluso con el hilo libre. La excepción es el socio de escalamiento, cuyo mensaje de servicio equivale a un take.
• Plantillas. Las de Marketing, Utility y Authentication no requieren ser dueño del hilo y no cambian quién lo es.

No existe un endpoint para consultar quién es el dueño de un hilo. Cada integración tiene que llevar ese estado con los webhooks que recibe y reconciliarlo después de 24 horas de inactividad, cuando el hilo vuelve a quedar libre.

La empresa dueña de la WhatsApp account tiene que firmar los Meta Business Agents and Platform Terms of Service. Solo la empresa puede aceptarlos: un partner no puede hacerlo en su nombre. Hasta que los acepte, Conversation Routing en Meta Business Suite muestra solo los puntos de entrada. Los mensajes llegan al responsable principal de cada uno, pero no hay standby, socio de escalamiento ni control del hilo.

La configuración puede nacer por cinco caminos, y en todos la empresa debe revisarla antes de recibir tráfico real:

Los tres primeros caminos nunca pisan una configuración que ya exista; activar Meta Business Agent, en cambio, sí la modifica. Si se quita un partner y quedan menos de dos responsables, la configuración se borra y todos vuelven a recibir todo. Si quedan dos o más, Meta no elige reemplazos: la empresa debe reasignar a mano los puntos de entrada que quedaron vacíos.

Es el caso más común: Meta Business Agent responde preguntas frecuentes y la bandeja de un partner, como Cliengo, concentra el pipeline de ventas, el Agente IA de calificación y a los agentes humanos. Cuando la empresa activa Meta Business Agent en un número, el agente pasa a ser el responsable principal de las conversaciones nuevas en todos los puntos de entrada de mensajes. Las integraciones que antes eran principales pasan a standby y reciben el tráfico por el webhook standby, no por messages. El enrutamiento de llamadas se mantiene.

1. Antes de activar el agente, revisa en Conversation Routing si el número usa la configuración por defecto de la cuenta o una propia.
2. Avisa a cada partner afectado y pídele que confirme que se suscribió a standby y a messaging_handovers. Meta recomienda activar el agente recién cuando todos confirmen.
3. Acepta los términos de Meta Business Agents para habilitar standby y escalamiento.
4. Define el socio de escalamiento, por ejemplo la bandeja donde trabajan tus agentes humanos. Así, cuando el cliente pide una persona, el agente hace un pass y el hilo llega con contexto.
5. Decide qué puntos de entrada quedan para cada uno. Por ejemplo, los leads de Click-to-WhatsApp pueden ir al Agente IA del partner y el resto, a Meta Business Agent.
6. Prueba la entrega de mensajes, el traspaso y la vuelta del hilo antes de abrirlo a todo el tráfico.

El routing no cambia los precios. Los mensajes de Meta Business Agent se cobran por tokens (USD 2 por millón, unos 4–5 centavos por mensaje) incluso dentro del FEP. Los mensajes de servicio se cobran desde el 1.001 de cada mes en cada número, sin importar qué integración los envíe. El FEP de un anuncio Click-to-WhatsApp es del par empresa–usuario y lo comparten todas las integraciones que envían desde ese número. Lo mismo pasa con el límite de mensajería, que es del business portfolio, y con el throughput del número: los comparten todos los proveedores. El panorama completo está en Meta Business Agent.

Una integración preparada para Conversation Routing no da por hecho que recibir un mensaje significa poder responderlo. Este es el checklist mínimo que surge de la documentación de Meta:

1. Suscribir la app a messaging_handovers y, si actúa en standby, a standby.
2. Guardar el estado del hilo por persona (mejor indexado por BSUID) y actualizarlo con cada webhook.
3. Tratar el error 131070 como "no eres el dueño": no reintentar el mismo mensaje de servicio.
4. No responder nunca desde una copia de standby; esperar un pass o, si eres el socio de escalamiento, hacer take.
5. Liberar el hilo con release cuando terminas, para que el próximo mensaje se enrute por punto de entrada.
6. En llamadas, recordar que solo el responsable de Llamada puede iniciar, aceptar, rechazar o cortar; el resto recibe el error 138038.

Si estás cambiando de proveedor, Conversation Routing también permite que el anterior y el nuevo convivan un tiempo en el mismo número. Lo explicamos en cambiar de proveedor sin perder el número y en la guía del nuevo modelo de WhatsApp account y Messaging account.