Dos números de WhatsApp: el catálogo es de la cuenta, no del negocio

Si atiendes clientes por WhatsApp y vas a conectar un segundo número, esta nota te dice qué se rompe. Un negocio con un solo WhatsApp es el caso fácil, el que todo el mundo programa primero.

El segundo número llega con el primer cliente mediano. Puede ser Ventas y Posventa, o dos sedes. Rompe más cosas de las que uno imagina. Estas son las cinco que rompió en nuestro CRM y cómo quedó cada una.

1. La regla de la base de datos era UNIQUE (negocio, tipo de canal). Un negocio, un WhatsApp. Impedía el segundo número por diseño.
2. El hilo se elegía por tipo de canal. Cuando se forzó el segundo número, un mensaje a Ventas se enganchaba al hilo de Posventa. Los dos eran «whatsapp» y el sistema no los distinguía. En silencio.
3. El catálogo de plantillas se mostraba mezclado. Elegir la plantilla del otro número producía el error 132001.
4. El filtro «canal = WhatsApp» devolvía las dos bandejas juntas. Para un negocio que las separa a propósito, eso no es un filtro.
5. La visibilidad por rol no existía: todo el equipo veía todo. El asesor de Ventas leía las reclamaciones de Posventa.

Las plantillas son los mensajes que Meta aprueba de antemano. Pertenecen a la cuenta de WhatsApp Business, la WABA, y no al negocio que la usa. Dos números de dos cuentas tienen dos catálogos. Ofrecer en un número la plantilla del otro es prometer un envío que Meta rechaza con el error 132001: la plantilla existe, pero no para el número que va a mandarla.

El catálogo se filtra por la cuenta de la conexión del hilo. Y la sincronización con Meta recorre todas las bandejas de WhatsApp del negocio, cada una con su cuenta. El identificador de la cuenta se guarda en un campo legible de la conexión, no dentro de las credenciales cifradas. Descifrar un token solo para leer un identificador a la vista es trabajo y riesgo de más.

«Negocio» es una idea nuestra. Para Meta hay cuentas y números, y las plantillas cuelgan de la cuenta. El CRM tiene que hablar los dos idiomas.

Con dos números, «canal» y «bandeja» dejan de ser lo mismo. El canal es el medio: WhatsApp, Instagram, Messenger. La bandeja es un número concreto. El filtro de bandeja se apoya en la conexión por la que llegó la conversación, no en el contacto, que no sabe de qué bandeja vino.

La forma de combinarlos importa. Varias bandejas marcadas a la vez se suman: sale quien escribió a cualquiera de ellas. Cruzarlas dejaría solo a quien escribió a las dos, y eso no lo pide nadie. Los otros filtros, estado o canal, sí se cruzan: pasa lo que cumple las dos condiciones. Lo comprobamos con siete casos de prueba en SQL contra datos reales. Es la clase de lógica que parece obvia y se escribe al revés.

La regla correcta es otra. Cada conexión es única por el identificador real del número, el phone_number_id de Meta. La acompaña un índice parcial, una excepción que admite una sola conexión «sin número» por canal mientras alguien la configura.

Con eso, el webhook, la dirección a la que Meta entrega cada mensaje, resuelve la bandeja por ese identificador exacto. Y un INSERT … ON CONFLICT, la instrucción que guarda una fila y la actualiza si ya estaba, distingue dos casos. El mismo número con el token renovado actualiza su fila. Un número distinto crea una bandeja nueva. Reconectar deja de ser un misterio.

La visibilidad, por último, pasó a ser por rol y bandeja. Sin una asignación explícita, ninguna bandeja se ve. Eso trajo su propio fallo, el del negocio nuevo cuya primera bandeja nadie sembraba, y lo contamos aparte.

• Modelar «bandeja» como entidad desde el principio, con su identificador de Meta, aunque hoy haya una sola.
• Resolver cada mensaje por el identificador del número que lo recibió, nunca por tipo de canal.
• Mantener un catálogo por cuenta de WhatsApp Business y filtrarlo por la bandeja del hilo.
• Sumar las bandejas y cruzar los demás filtros. Escribir los casos.
• Preguntarle a un CRM, antes de contratarlo: «si conecto un segundo número, ¿qué ve cada vendedor y qué plantillas le ofrece?».