Viernes 17:00. La reserva del sábado no tiene teléfono.
Viernes a las cinco de la tarde. Tu jefe de sala revisa el listado de reservas del sábado en CoverManager para preparar las mesas. Ve una entrada nueva, la última, llegada por el WhatsApp del restaurante: una mesa de cuatro a las 21:30, a nombre de Ana, dos comensales con alergia documentada. El campo teléfono está vacío. CoverManager lo marca en rojo y le dice que esa reserva no se puede confirmar por SMS, ni le va a llegar recordatorio el sábado a las 17:30, ni va a aparecer cruzada con su histórico (Ana cenó aquí en marzo, pero el CRM no lo sabe porque no hay teléfono que cruzar). Tu sala tiene que decidir qué hacer con esa mesa. Y por si fuera poco, el equipo de cocina tiene una alergia documentada y nadie del restaurante puede llamar a Ana si surge algo.
Esto es lo que pasa cuando el cliente reserva por WhatsApp usando su nuevo username y no comparte el número. No es un fallo de CoverManager. No es un fallo de WhatsApp. Es la consecuencia de un cambio de Meta que afecta a un sistema de reservas construido con un modelo de datos anterior al cambio.
Este artículo documenta los cuatro puntos exactos donde el flujo se rompe, los tres fixes operativos que tu grupo puede aplicar este mes sin esperar al roadmap de CoverManager, y la conversación que tienes que tener con tu proveedor de PMS antes de julio.
Por qué CoverManager exige teléfono (y por qué SevenRooms, TheFork y Resmio también)
El campo teléfono es obligatorio en CoverManager porque cumple cinco funciones operativas, no una:
- Identificador principal del cliente. Es la clave por la que el CRM cruza visitas a través del tiempo. La ficha de Ana se construye sumando todas las reservas con el mismo teléfono.
- Disparador del SMS de confirmación automática que llega al cliente segundos después de crear la reserva.
- Disparador del recordatorio automático cuatro horas antes del servicio.
- Canal de contacto urgente si el equipo de sala necesita avisar de un cambio, una incidencia o una reasignación de mesa.
- Punto de unión con el ticket de venta después de la cena, para alimentar el CRM con el consumo histórico del cliente.
SevenRooms, TheFork y Resmio comparten el mismo diseño. No es una excentricidad de CoverManager. Es la lógica estándar del PMS de restauración desde hace 15 años. Cuando el campo teléfono está vacío, esas cinco funciones se debilitan o desaparecen.
El flujo que se rompe, paso por paso
Cuando la reserva llega por WhatsApp sin teléfono, el flujo estándar se rompe en cuatro puntos. Los documento por orden de impacto operativo.
Punto 1. El alta en el PMS
CoverManager (y los demás) marcan el campo teléfono como obligatorio o casi obligatorio. Hay dos comportamientos posibles según la versión:
- Rechazo duro: el formulario o la API devuelve error y la reserva no entra. El equipo de sala tiene que gestionarla manualmente desde fuera.
- Aceptación con flag de incompleta: la reserva entra pero queda marcada como incompleta, fuera del flujo automatizado normal.
Los dos casos son trabajo extra para el equipo de sala, multiplicado por el número de reservas WhatsApp diarias. En un grupo que recibe 40 reservas/día por WhatsApp con un 30% sin teléfono, son 12 reservas/día con fricción adicional.
Punto 2. La confirmación al cliente
El SMS de confirmación no se manda sin teléfono. WhatsApp sí sirve como canal de fallback porque ya hay conversación abierta, pero pierdes:
- El SMS como medio independiente, redundante respecto al canal de origen.
- El comprobante por SMS que algunos clientes esperan recibir para tener trazabilidad de la reserva fuera de la app de WhatsApp.
El impacto es menor que el del Punto 1 pero notable en clientes mayores o menos digitales.
Punto 3. El recordatorio del día del servicio
El recordatorio automático cuatro horas antes de la cena se manda por SMS por defecto en la mayoría de configuraciones de CoverManager. Sin teléfono, ese recordatorio no llega. Te queda mandarlo manualmente por WhatsApp, lo cual implica que alguien del equipo dispare un mensaje a cada reserva pendiente.
La consecuencia operativa es aumento de tasa de no-show en clientes nuevos que olvidan la reserva. Estimación conservadora: una subida de entre 2 y 4 puntos porcentuales de no-show en el segmento sin teléfono.
Punto 4. La fusión de la visita en el CRM
Aquí está el daño más sutil y el más caro a largo plazo. Cuando Ana cenó en marzo, su ficha quedó construida con su teléfono como identificador. Hoy reserva sin teléfono. Su CRM no fusiona la reserva de hoy con la ficha histórica, porque no hay teléfono que cruzar.
La consecuencia: Ana aparece como cliente nueva. Su histórico no se le suma. El trato VIP que su ficha del CRM debería disparar no se dispara. El sumiller no sabe lo que bebió la última vez. La cocina no sabe la alergia documentada (aunque venga apuntada en esta reserva, no cruza con la ficha histórica).
Multiplicado por miles de clientes a lo largo del año, el daño al LTV del grupo es real. No es un titular alarmista: es contabilidad operativa.
Tres fixes operativos que puedes aplicar este mes
No esperes al roadmap de CoverManager. Estos tres fixes los puede liderar tu equipo o tu proveedor de bot, sin depender del PMS.
Fix 1. Opt-in explícito de teléfono en la confirmación de la reserva
Cuando una reserva entra por WhatsApp sin teléfono, el bot o el equipo confirma la mesa primero y pide el teléfono después. En la misma conversación, con un mensaje claro:
Reserva confirmada para 4 personas el sábado a las 21:30. Una pregunta antes de cerrarlo: para mandarte el recordatorio el día de la cena y poder avisarte si hay cualquier cambio en la sala, ¿me puedes pasar tu número? Solo lo usamos para esta gestión.
La fórmula importa por tres razones:
- Confirma la mesa primero (valor aportado) antes de pedir nada.
- Declara el propósito del dato (recordatorio + cambios). Esto te alinea con RGPD y mejora la tasa de respuesta.
- Acota el uso ("solo para esta gestión"). El cliente entiende que no es para marketing.
La tasa de respuesta esperable en clientes nuevos está entre el 70% y el 85%. Los que no responden, los gestionas con el siguiente fix.
Fix 2. Capa intermedia entre WhatsApp y el PMS
Para las reservas que llegan sin teléfono y no lo dan en el opt-in, necesitas un buffer que evite el rechazo de CoverManager.
La capa funciona así:
- La reserva entra a tu sistema interno (CRM propio, base de datos del bot, lo que tengas en medio), no directamente a CoverManager.
- Si el cliente da teléfono en el opt-in, la capa empuja la reserva a CoverManager completa.
- Si no lo da, la reserva queda en tu sistema con flag de pendiente_de_telefono.
- El maître recibe un aviso al inicio del turno con la lista de reservas pendientes.
- El maître gestiona en sala: una llamada antes del servicio para confirmar (si hay teléfono en algún histórico), o asume el riesgo informado.
Esta capa la construye tu equipo técnico interno o el proveedor del bot. Para un equipo razonable, son entre 8 y 16 horas de desarrollo. Se amortiza el primer fin de semana que evita perder un par de cubiertos por reservas mal entradas.
Fix 3. Identidad de cliente entre sedes del grupo en el CRM (no en WhatsApp)
Si tu grupo tiene varias sedes business, el BSUID no sirve para fusionar al mismo cliente entre ellas. Cada sede recibe un BSUID distinto del mismo cliente. La unificación la tiene que hacer el CRM del grupo, no WhatsApp.
La lógica de deduplicación del CRM debería cruzar:
- Nombre completo + teléfono histórico (si existe en alguna sede).
- Email si lo capturaste alguna vez.
- Pistas conversacionales (la propia conversación contiene a veces direcciones, referencias a visitas previas, nombres de acompañantes).
Cuando el match es positivo, las dos fichas se fusionan. El BSUID de la sede actual se añade a la lista de identificadores de la ficha unificada. La próxima reserva en cualquier sede del grupo encuentra la ficha maestra.
Esta capa es trabajo del CRM o de tu integración, no de WhatsApp. Pero el cambio en WhatsApp es lo que la convierte en urgente.
La conversación que tienes que tener con tu proveedor de PMS
Antes de hacer nada interno, te ahorras trabajo si tu proveedor de PMS ya tiene roadmap. Pregúntale por escrito y con trazabilidad estas cuatro cosas:
- ¿Soportáis BSUID como identificador secundario del cliente?
- ¿En qué versión, con qué fecha estimada?
- ¿La integración con WhatsApp Business API leerá el BSUID del webhook automáticamente o tenemos que hacerlo desde nuestro lado?
- ¿La ficha de cliente del CRM acepta BSUID y teléfono como campos paralelos, o uno sustituye al otro?
Las respuestas las anotas. Una respuesta vaga ("estamos en ello", "lo veremos") es información: ese proveedor no va a estar listo en julio y necesitas plan B desde tu lado. Una respuesta con fecha cerrada y versión específica cambia tu cálculo y te puede ahorrar la capa intermedia.
Algunos proveedores responderán bien y otros no. La diferencia entre los dos grupos es la diferencia entre los que están conectados al ecosistema y los que no. Para el segundo grupo, el plan B que te he descrito en los tres fixes es independiente del proveedor y funciona desde el primer día.
Cómo lo resuelve HIRO Concierge
HIRO Concierge implementa los tres fixes de fábrica:
- Captura el BSUID del webhook y lo guarda como identificador secundario en la ficha cliente, junto al teléfono cuando exista.
- Dispara el opt-in de teléfono en la confirmación de reserva con el mensaje que hemos validado en producción, con plantilla editable por sede.
- Tiene capa intermedia integrada entre el flujo de WhatsApp y CoverManager (y otros PMS): no empuja la reserva al PMS hasta que tiene el teléfono o el equipo de sala marca explícitamente que la reserva se gestiona sin él.
- Fusiona BSUIDs distintos del mismo cliente entre sedes del grupo cuando hay match de identidad por nombre + teléfono histórico + email.
Es lo que pusimos en el roadmap de junio en cuanto vimos el cambio venir en abril. Si tu grupo está tomando reservas por WhatsApp y necesita no perder cubiertos este verano, hablamos.