El OTP es la única pieza que Meta dejó fuera del cambio
Cuando Meta anunció en 2026 los usernames de WhatsApp y los Business-Scoped User IDs, dejó una excepción técnica que no aparece en los titulares pero que importa mucho a quien construye integraciones serias:
Las plantillas de autenticación (OTP) siguen exigiendo número de teléfono. No funcionan con BSUID.
No es un olvido ni una limitación temporal. Es una decisión de seguridad explícita de Meta. Y la consecuencia operativa es que cualquier flujo de tu negocio que use OTP por WhatsApp para validar identidad necesita reaccionar. Algunos rediseños son ligeros, otros son estructurales. Este artículo te ayuda a decidir cuál te toca.
Qué dice la documentación oficial
La doc oficial de Meta sobre BSUID lo explica con literalidad: los webhooks y los mensajes normales pueden trabajar con BSUID en lugar de teléfono, pero las plantillas de tipo AUTHENTICATION (las que entregan códigos OTP de un solo uso) siguen requiriendo phone_number como destinatario. No hay forma de mandar un OTP a un BSUID.
Si tu integración intenta hacerlo, la API devuelve error de validación. No falla en silencio. Falla limpio, lo cual es bueno para el diseño de fallback.
Por qué Meta lo dejó así (no es arbitrariedad)
El OTP por WhatsApp es un canal de validación de identidad con peso legal y de protección al usuario. Sirve para:
- Confirmar cobros y operaciones financieras.
- Validar identidad en flujos sensibles (apertura de cuenta, modificación de datos personales).
- Cumplir requisitos de doble factor en sistemas regulados.
Para que el OTP cumpla esa función, Meta exige que el destinatario tenga un teléfono verificado. El username de WhatsApp es un identificador conversacional, no de identidad legal. Permitir OTP a BSUID rompería la garantía mínima del canal: cualquiera con un username sin teléfono verificado podría recibir códigos de validación, lo que abre puertas a abusos en cadena.
Esta decisión está alineada con lo que hacen otras plataformas en flujos de autenticación: Signal, Telegram y otros sistemas de mensajería siguen ligando el OTP al número, no al alias. La novedad no es de WhatsApp, es del patrón de la industria.
Qué flujos concretos se rompen en tu negocio
Por orden de criticidad operativa:
Flujo 1. Cobro o pre-cobro al confirmar una reserva o cita
Muchos restaurantes y servicios usan el OTP por WhatsApp para confirmar pre-cobros: cobrar una caución por reserva, dejar tarjeta para no-show, validar el método de pago antes del servicio. Si el cliente reservó por WhatsApp sin teléfono, el OTP no se puede mandar y el pre-cobro queda en suspenso.
Flujo 2. Identificación del cliente VIP en programas de fidelidad
Algunos grupos usan OTP para validar que un cliente que dice ser VIP lo es realmente cuando accede a códigos personalizados, descuentos exclusivos o reservas prioritarias. Sin teléfono, esa validación no se puede hacer por WhatsApp y hay que reconducir el flujo a otro canal o cambiar de mecanismo de prueba.
Flujo 3. Validación de cambios sensibles
Modificación de datos personales en la ficha del cliente, cambio de dirección de envío, actualización de método de pago. Cualquier acción donde necesitas una confirmación explícita "este es realmente él" antes de aplicar el cambio. Sin teléfono, el OTP no llega y el flujo de cambio se bloquea o requiere validación humana.
Lo que NO se rompe
Conviene precisar lo que sigue funcionando sin cambios para no rediseñar de más:
- Conversación normal de atención cliente (sin plantillas): funciona con BSUID sin problema.
- Mensajes de confirmación de reserva (no OTP, solo confirmación informativa): funcionan, vía WhatsApp normal.
- Recordatorios de servicio el día de la cita: funcionan, vía WhatsApp normal.
- Plantillas de tipo
UTILITY(notificaciones operativas no críticas): funcionan con BSUID. - Plantillas de tipo
MARKETING: funcionan con BSUID si el cliente ha dado opt-in para marketing por otra vía.
Solo las plantillas AUTHENTICATION quedan fuera. Es importante no confundir esto con que "WhatsApp Business no funciona sin teléfono". Funciona, salvo para la pieza de autenticación.
Patrón A: opt-in explícito de teléfono al primer contacto
Cuando tu negocio depende del OTP en el primer contacto (cobros inmediatos, validación al alta), la solución es pedir el teléfono explícitamente antes del flujo de autenticación.
La fórmula:
Para confirmar tu reserva necesito mandarte un código de verificación que me asegura que eres tú quien lo solicita. ¿Me pasas tu número de teléfono? Solo lo usamos para esta gestión y queda asociado a tu reserva.
Por qué funciona:
- Aporta valor primero (la reserva está casi confirmada, solo falta este paso).
- Declara el propósito (validación de identidad para esta operación).
- Acota el uso ("solo para esta gestión").
- Da control al cliente (puede decidir si la operación le compensa dar el dato).
La tasa de respuesta esperable en clientes con intención clara está entre el 80% y el 90%. Los que no responden, salen del flujo OTP y caen al patrón B o a gestión humana.
Cuándo conviene: servicios donde la primera interacción es transaccional con riesgo (pago, compromiso legal, datos sensibles). Hostelería con pre-cobro, comercio con pago anticipado, citas médicas con cobro al confirmar.
Patrón B: BSUID pasivo + OTP solo para acciones críticas
Cuando tu primer contacto es informativo y la validación OTP solo entra en juego para acciones específicas más adelante, el patrón es trabajar con BSUID pasivo hasta que aparezca la acción crítica.
El flujo:
- Cliente escribe con username, recibes BSUID.
- La conversación inicial usa BSUID como identificador (conversar, confirmar disponibilidad, responder dudas).
- Cuando aparece una acción que requiere OTP (cobro, cambio sensible, validación), el bot o el equipo pide el teléfono con motivo declarado en ese momento exacto.
- El cliente da el teléfono o no. Si lo da, el OTP funciona. Si no, la acción crítica se reconduce a gestión humana o se pospone.
Por qué funciona: el cliente no siente fricción innecesaria al principio. Si nunca llega a haber acción crítica (mucha atención cliente cae aquí), nunca le pides el teléfono. Solo lo pides cuando hay una razón visible para él, no por defecto.
Cuándo conviene: servicios donde la conversación inicial es informativa y solo una parte de los hilos llegan a acciones que requieren OTP. Atención cliente general, consultas, reservas sin pre-cobro, soporte.
La heurística para decidir entre Patrón A y Patrón B
Te quedas con Patrón A si en tu flujo el OTP es necesario en los primeros 30 minutos de conversación con la mayoría de clientes. Te quedas con Patrón B si el OTP solo aparece en una proporción minoritaria de las conversaciones, o más tarde.
En la práctica, la mayoría de negocios acaban con un híbrido: Patrón A para flujos con pre-cobro, Patrón B para todo lo demás. Lo importante es que esa decisión sea consciente y esté documentada en el flujo del bot, no que ocurra por inercia.
Implementación práctica
Tres detalles técnicos que ahorran semanas de iteración:
- El campo
phone_numberdel payload de la plantillaAUTHENTICATIONtiene que ir en formato E.164 (+país, código, número, sin espacios ni signos). Si lo guardas en otro formato en el CRM, normalízalo antes de mandarlo. - La política de retries del OTP no debería ser agresiva: si el primer intento falla porque el cliente no tiene teléfono, el sistema debe caer a Patrón A o a gestión humana, no reintentar el OTP automáticamente. Reintentar contra un BSUID sin teléfono solo genera errores en cadena.
- La trazabilidad operativa del OTP tiene que quedar logueada con: timestamp, identificador del cliente (BSUID si aplica, teléfono si aplica), motivo de la validación, resultado (entregado, fallido, no aplicable). Esto te sirve para auditar, para defenderte ante incidencias y para ajustar la política de OTP con datos.
Si construyes la integración desde cero, esto está cubierto. Si heredas un sistema antiguo, conviene auditar estos tres puntos antes de julio.
Cómo lo gestiona HIRO Concierge
HIRO Concierge trabaja por defecto en Patrón B (BSUID pasivo) y escala a Patrón A solo en flujos marcados como críticos por el grupo. Los flujos críticos se configuran por sede: una cadena de fine dining con pre-cobro de caución activa Patrón A; un restaurante de barrio con reserva sin cargo trabaja en Patrón B. El cambio se hace desde el panel de configuración del Concierge, sin tocar código.
La política de OTP queda trazada en el log de la conversación, con el motivo y el resultado, lo que permite auditar el comportamiento mensualmente con el equipo del grupo. Si tu casa tiene un flujo OTP por WhatsApp que necesita rediseño antes del rollout completo de usernames, hablamos.