Sábado 13:42. Una persona te escribe por WhatsApp. No vas a ver su número.
Sábado, primer turno terminando. Entra un mensaje al WhatsApp del restaurante: "Quería preguntar si tenéis mesa para dos esta noche, ventana si puede ser". Tu equipo abre la conversación. Donde antes aparecía un número de teléfono, ahora aparece esto:
@anabarcelo · 13.7849263
El @anabarcelo es el nuevo username de WhatsApp. El 13.7849263 es un Business-Scoped User ID: un identificador único que Meta te asigna por cada cliente, exclusivo para tu negocio, sin teléfono asociado. Tu equipo confirma la reserva. CoverManager te pide el teléfono. No lo tienes. La clienta no ha querido dárselo todavía. La reserva entra al sistema con un campo vacío. El día de la cena, la confirmación por SMS no sale porque el SMS necesita un teléfono. La persona no aparece. No tienes forma de llamar.
Esto no es ciencia ficción. Es lo que Meta está empezando a entregar este verano a través de su API de WhatsApp Business. La documentación oficial está aquí. Quien gestiona reservas por WhatsApp tiene entre cuatro y seis semanas para rediseñar el flujo. Quien no lo haga, perderá cubiertos sin entender por qué.
Esta guía explica qué está cambiando, qué no está cambiando, dónde se rompe el flujo de reservas y qué hacer un lunes por la mañana para llegar listos antes de julio.
Qué está cambiando exactamente en WhatsApp en 2026
Meta está introduciendo dos piezas, una cara al usuario y otra cara al negocio.
Usernames de WhatsApp (cara al usuario): el cliente puede crearse un alias público tipo @anabarcelo y escribir a un negocio sin compartir su número de teléfono. La función empieza a aparecer entre junio y julio de 2026 y se generaliza al resto del año.
Business-Scoped User IDs o BSUID (cara al negocio): cuando un cliente te escribe usando su username, tu webhook no recibe el teléfono. Recibe un identificador con formato XX.<dígitos>, único por negocio, estable mientras el cliente no resetee su cuenta, y no compartido con otros negocios. Si la misma persona escribe a tu restaurante y al de la competencia, cada uno recibe un BSUID distinto. Si escribe a dos sedes de tu propio grupo, cada sede recibe un BSUID distinto, porque cada cuenta business es un negocio separado para Meta. Este punto importa más de lo que parece y lo retomo abajo.
Los BSUIDs ya están llegando a los webhooks de algunas cuentas business desde mayo de 2026. Los usernames empiezan a verse cara al usuario entre junio y julio. El resto del despliegue ocupa el segundo semestre.
Dos matices importantes que ahorran malentendidos:
- El teléfono no desaparece para todos los casos. Si el cliente ha interactuado contigo en los últimos 30 días o tienes su número guardado en agenda, sigues viendo el teléfono. La capa BSUID solo se activa para conversaciones nuevas con clientes que han activado username y no han hablado contigo recientemente.
- Las plantillas de autenticación (OTP) no funcionan con BSUID. Si tu flujo manda un código de un solo uso por WhatsApp para verificar al cliente, ese flujo sigue exigiendo número de teléfono. La excepción es deliberada de Meta y no parece que vaya a cambiar.
A partir de aquí, el resto del artículo es la traducción a "y a mi restaurante qué".
Por qué esto importa en restauración, no en el resto de sectores
La mayoría de análisis del cambio están escritos pensando en e-commerce, banca o atención cliente genérica. La restauración es un caso distinto por tres razones operativas:
- WhatsApp es ya el canal número uno de captación de reservas en muchos grupos. No es un canal accesorio. Es donde entran las reservas que no pasan por TheFork ni por tu web.
- Tu sistema de reservas (CoverManager, SevenRooms, TheFork, Resmio) está construido alrededor del teléfono como identificador principal del cliente. El campo teléfono no es opcional. Es la clave de la ficha.
- Tu ficha de cliente VIP y tu CRM unificado del grupo dependen del teléfono para fusionar visitas a través del tiempo. Sin teléfono, no sabes que la persona que te escribió hoy ya estuvo cuatro veces el año pasado, dos veces en Madrid y dos en Marbella.
Cuando una persona te escribe sin compartir el número, no es un problema técnico. Es un problema operativo: tu sistema de reservas no acepta el campo, tu CRM no fusiona la visita, tu equipo de sala pierde el contexto. Y todo esto pasa sin que el cliente perciba nada raro, porque para él la experiencia es más cómoda. La fricción solo aparece en la trastienda.
La intersección que casi nadie está mirando: reservas + BSUID
Voy a ser concreto con un caso, porque es la pieza diferencial del análisis y la razón por la que escribimos este artículo nosotros y no Meta.
El flujo típico de reserva por WhatsApp en un grupo bien gestionado es así:
- Cliente escribe pidiendo mesa.
- El equipo (o el bot) consulta disponibilidad y propone hora.
- Cliente acepta.
- Se pasa la reserva a CoverManager con: nombre, teléfono, número de comensales, fecha y hora, observaciones.
- CoverManager dispara confirmación al cliente por SMS o WhatsApp.
- El día del servicio, recordatorio automático cuatro horas antes.
- Tras la visita, el CRM cruza el ticket de venta con la ficha del cliente usando el teléfono como pivote.
Este flujo se rompe en cuatro puntos cuando el cliente solo te da su username:
- Punto 4: CoverManager y la mayoría de PMS de restauración exigen teléfono como campo obligatorio o casi obligatorio. Si no lo tienes, la reserva entra mal o no entra.
- Punto 5: el SMS de confirmación no existe sin teléfono. Te queda el mensaje por WhatsApp, que sí funciona porque ya hay conversación abierta. Pero pierdes el SMS como canal de fallback.
- Punto 6: igual que el 5. El recordatorio del día del servicio depende del mismo canal y se debilita.
- Punto 7: el CRM no fusiona la visita con visitas anteriores porque no hay teléfono que cruzar. La persona aparece como cliente nuevo aunque sea recurrente. El trato VIP no se dispara.
La solución no es esperar a que tu PMS te lo arregle. La solución son tres decisiones operativas que el grupo puede tomar este mes:
Decisión 1. El BSUID se guarda en el CRM como identificador secundario, no como reemplazo del teléfono. La ficha del cliente acepta ambos campos como paralelos. Si solo tienes BSUID, la ficha existe. Si más adelante el cliente da el teléfono, fusionas. Esto exige que tu CRM (o tu integración entre WhatsApp y CRM) sepa leer el BSUID del webhook y escribirlo en la ficha. Si lo lleva un proveedor, pídele el roadmap por escrito. Si lo llevas tú, son entre cuatro y ocho horas de desarrollo en el peor caso.
Decisión 2. Pides el teléfono explícitamente en el flujo de reserva, una sola vez, con motivo claro. Cuando un cliente te escribe sin teléfono y le confirmas la mesa, el bot o el equipo pregunta una vez: "Para mandarte el recordatorio el día de la cena y poder avisarte si hay cualquier cambio, ¿me puedes compartir tu número? Solo lo usamos para esta reserva". La mayoría dice que sí. A los que no, los gestionas con un campo de "no consiente teléfono" en la ficha y les mandas el recordatorio por WhatsApp en lugar de SMS. El opt-in explícito tiene la ventaja añadida de que te alinea con RGPD: pides el dato con propósito declarado.
Decisión 3. El equipo de sala cambia la mentalidad de "teléfono igual a cliente" a "teléfono o nombre o username igual a cliente". Esto suena trivial, es el cambio más difícil. El protocolo de identificación del comensal al entrar deja de ser "dame el teléfono y te busco en CoverManager" y pasa a ser "dame el teléfono o el nombre con el que reservaste". El maître tiene que poder identificar al cliente con cualquiera de los dos campos sin fricción visible.
El bug operativo número uno: confundir BSUIDs entre sedes del grupo
Si tu grupo tiene cinco restaurantes, cada uno con su propia cuenta business de WhatsApp, cada uno recibe un BSUID distinto para la misma persona. Si tu CRM no unifica esos BSUIDs contra una sola ficha cliente, lo que vas a ver es esto:
- Cliente VIP Marta cena en tu sede de Madrid. Ficha creada con BSUID
45.78492611. - Tres meses después, Marta cena en tu sede de Marbella. Ficha creada con BSUID
45.91038477. - Tres meses después, Marta cena en tu sede de Sevilla. Ficha creada con BSUID
45.20183442.
Para tu CRM, son tres clientes nuevos. Para Marta, es su tercera, cuarta y quinta visita al grupo. La consecuencia operativa es que el trato VIP que la ficha del cliente premium debería disparar no se dispara, porque la ficha no acumula histórico. El sumiller no sabe lo que bebió la última vez. El maître no sabe que celebra aniversario. La cocina no sabe la intolerancia.
El fix no es técnico de WhatsApp. Es técnico de CRM. Tu sistema necesita una capa de identidad que mantenga una ficha maestra por cliente con una lista de BSUIDs asociada. Cuando entra una conversación nueva con BSUID, el CRM busca primero si hay match (por nombre completo más teléfono histórico, por email si lo capturaste, por pistas en la conversación) antes de crear ficha nueva. Este es trabajo de CRM. Pero el cambio en WhatsApp lo convierte en urgente.
OTP y autenticación: la parte que no cambia, y por qué importa
Las plantillas de autenticación de WhatsApp Business, las que se usan para mandar códigos de verificación al cliente, siguen requiriendo número de teléfono. Esta excepción es deliberada de Meta y no parece que vaya a cambiar.
Qué significa esto en práctica: si tu flujo de "identifica al cliente recurrente" depende de mandarle un OTP por WhatsApp para que confirme que es él, ese flujo no funciona con clientes que solo te han dado su username. Tienes dos opciones:
- Opción A. Pides el teléfono explícitamente en el primer contacto, como en la Decisión 2 de arriba. El OTP funciona desde la segunda visita.
- Opción B. Identificas al cliente recurrente por el BSUID directamente, sin OTP. El BSUID es estable por cliente y por negocio, así que sirve como identificador pasivo siempre que el CRM lo guarde bien. Es más ligero que el OTP pero exige confianza en el flujo de captación.
La mayoría de grupos van a acabar con un mix: BSUID para identificación pasiva en sala, teléfono más OTP para acciones críticas (cobro, pre-pago, cancelación tardía, validación de identidad por motivos legales).
El plan operativo: cinco pasos para llegar listo antes de julio
Si hoy es junio de 2026 y los usernames empiezan a llegar a usuarios este mismo mes, tienes entre cuatro y seis semanas. El plan operativo es este.
Paso 1. Inventario. Saca una lista de todos los procesos que dependen del teléfono del cliente: alta de reserva, confirmación, recordatorio, gestión de no-show, cobro, identificación en sala, fusión de visita en CRM, campañas de marketing. Marca cada proceso con un sí o un no a la pregunta: si mañana no tengo teléfono, ¿se rompe? La lista de los que se rompen es la lista de prioridades del rediseño.
Paso 2. Auditoría de proveedores por escrito. A cada proveedor en la lista (CoverManager u otro PMS, tu CRM, tu pasarela de cobro, tu proveedor de bot o concierge, tu plataforma de marketing) le pides por escrito: ¿Vais a soportar BSUID como identificador secundario? ¿En qué versión? ¿Con qué fecha estimada? Las respuestas se anotan. Las ausencias también: un proveedor sin roadmap BSUID en junio de 2026 es un proveedor que vas a tener que parchear desde tu lado en julio.
Paso 3. Cambio del flujo de captación. Decide cuándo y cómo pides el teléfono. Recomendación: lo pides una vez, en la confirmación de la primera reserva, con un mensaje claro de para qué. No lo conviertes en barrera de entrada. El cliente entiende que tu restaurante lo necesita para mandarle el recordatorio y avisarle si hay cambios. Lo da.
Paso 4. Refuerzo de la identidad del CRM. Asegúrate de que tu ficha cliente acepta BSUID y teléfono como campos paralelos, ninguno obligatorio, y que la fusión de fichas tiene en cuenta los dos. Si tu CRM es construido en casa, son cambios de schema y de lógica de match. Si es de tercero, lo exiges al proveedor con fecha cerrada. Este es probablemente el paso más técnico del plan, y también el que más impacto tiene en el LTV del cliente VIP entre sedes.
Paso 5. Plan B para los proveedores que no estén listos en julio. Si CoverManager u otro PMS crítico no soporta BSUID y la mitad de tus reservas WhatsApp llegan sin teléfono, necesitas una capa intermedia: tu propio sistema acepta la reserva con BSUID, pide el teléfono al cliente en una segunda interacción, y solo cuando lo tiene la empuja al PMS. Es un parche temporal, pero te evita perder reservas hasta que el proveedor se ponga al día. La capa intermedia la construye tu equipo técnico interno o el proveedor de tu bot o concierge, según quién tenga la integración WhatsApp más cerca.
Cuándo NO tienes que tocar nada todavía
No todos los restaurantes tienen que mover ficha. Hay tres perfiles donde el cambio no muerde, y los dejamos por escrito para que el grupo no sobre-reaccione.
Perfil 1: el WhatsApp del restaurante no se usa para reservas. Si tu canal principal es teléfono fijo, web propia o TheFork, y WhatsApp solo se usa para responder dudas puntuales, el cambio te afecta poco. Vas a ver BSUIDs de vez en cuando, los miras con curiosidad, sigues con tu flujo.
Perfil 2: el equipo gestiona WhatsApp manualmente, sin automatización. Si una persona del equipo lee y responde cada mensaje y todo lo demás pasa por teléfono, tienes margen. La identificación la hace el humano, y el humano puede preguntar el teléfono cuando lo necesita. La fricción de no tener BSUID gestionado en el CRM es un coste de gestión, no de pérdida de cubiertos.
Perfil 3: cubierto medio bajo y volumen alto donde el cliente es transaccional. Si tu modelo de negocio no depende de la recurrencia identificada del cliente (no le mandas mailing, no le ofreces trato VIP, no necesitas conocerle entre visitas), no necesitas mantener identidad estable a través del tiempo. El BSUID te basta para esta visita. La siguiente, otra vez, sin problema.
Si tu grupo no encaja en ninguno de estos tres perfiles, sí tienes que mover ficha antes de julio. La buena noticia es que el plan de cinco pasos está acotado en tiempo y en alcance.
Cómo lo gestiona HIRO Concierge
HIRO Concierge guarda BSUID y teléfono como dos campos separados en la ficha del cliente, fusiona BSUIDs distintos del mismo cliente entre sedes del grupo cuando hay match de identidad, y pide el teléfono al cliente con un mensaje opt-in en la confirmación de reserva cuando no lo tiene. La integración con CoverManager y otros PMS se mantiene activa: si CoverManager exige teléfono y todavía no se ha capturado, el Concierge no empuja la reserva hasta que el dato existe, y avisa al equipo de sala para que el maître lo gestione si el cliente no responde al opt-in.
No es una promesa para 2027. Es lo que está en el roadmap de este trimestre porque vimos el cambio venir en abril y empezamos a trabajarlo.
Si tu casa toma reservas por WhatsApp y necesitas no perder cubiertos este verano, hablamos.