Cómo automatizar reservas, confirmaciones y no-shows en restaurantes

Que una mesa esté libre no significa que pueda reservarse

Cuando alguien llama para reservar, la pregunta parece sencilla: «¿Tenéis mesa a las nueve?». Para responder bien hay que comprobar si existe una mesa adecuada para ese grupo y si puede ocuparse durante el tiempo previsto sin afectar a otras reservas. También importa qué zonas están abiertas en ese servicio y si el restaurante permite juntar mesas para ese número de personas.

Al automatizar reservas en un restaurante, esa comprobación debe seguir existiendo. La petición del cliente se traduce en una consulta al software de reservas y la confirmación solo se envía cuando el programa devuelve una opción válida.

CoverManager permite configurar la asignación de mesas según el tamaño del grupo y la zona. Last.app permite definir turnos y duración de las reservas. Esas reglas condicionan la última hora de entrada y el momento en que una mesa vuelve a quedar disponible. En ambos casos, una mesa que aparece vacía ahora puede estar comprometida para otro cliente poco después. Por eso el plano por sí solo no sirve para decidir si una reserva cabe.

Un chatbot, un agente de voz o una conversación por WhatsApp pueden recoger la solicitud. La hora disponible debe salir del sistema de reservas, no de una estimación del asistente.

El problema aparece cuando dos canales trabajan con información distinta. Si una reserva telefónica tarda en registrarse y la web sigue ofreciendo la misma mesa, el restaurante puede aceptar dos reservas incompatibles.

En la guía sobre automatización para restaurantes abordamos también pedidos, atención al cliente y otras tareas habituales del restaurante. En este artículo nos centramos en las reservas y en las comprobaciones necesarias antes de confirmarlas.

Qué hay que comprobar antes de ofrecer una hora

La capacidad total del local no indica por sí sola si cabe una reserva concreta. Dos servicios con el mismo número de cubiertos libres pueden tener opciones distintas porque las mesas están ocupadas a horas diferentes o porque algunas no pueden combinarse. Una mesa de cuatro libre durante treinta minutos tampoco resuelve una reserva para cuatro si el tiempo previsto de ocupación es mayor.

Google Actions Center representa la disponibilidad mediante datos como la hora de inicio, la duración y las plazas disponibles. Ese enfoque obliga a trabajar con una capacidad asociada a un horario concreto, no con una cifra general de mesas libres. Para el restaurante, la conclusión es sencilla: antes de ofrecer una hora hay que saber cuánta capacidad queda realmente para esa petición.

Un software de gestión de reservas bien configurado evita que el equipo tenga que calcular manualmente cada hueco y reduce el riesgo de aceptar reservas que después no caben.

Todas las reservas deben actualizar la misma disponibilidad

Las reservas llegan por la web o por Google. También entran por teléfono, WhatsApp o directamente en el local. Todos esos canales son válidos si consultan información actualizada. El problema aparece cuando alguno trabaja con datos atrasados o registra los cambios con retraso.

Cuando se crea una reserva o se modifica una existente, el cambio debe llegar al lugar donde se calcula la disponibilidad. Puede haber un único programa o varias herramientas sincronizadas de forma controlada. En ambos casos, la información debe actualizarse a tiempo para que otro canal no ofrezca la misma capacidad.

CoverManager permite conectar la web y el perfil de Google con su gestión de reservas. Last.app también concentra reservas y comunicaciones en torno a la configuración del restaurante. En otros negocios puede haber varias herramientas conectadas entre sí. La solución concreta dependerá de lo que ya utilice cada restaurante y de qué sistema tenga la disponibilidad más fiable.

Las llamadas también pueden consultar la disponibilidad

Una parte importante de las llamadas a un restaurante son consultas repetitivas sobre horarios y mesas. Un agente de voz para empresas puede recoger la fecha y la hora solicitadas. Después pregunta cuántas personas son y consulta las opciones disponibles en el programa de reservas.

La IA se ocupa de mantener la conversación. La disponibilidad la devuelve el software de reservas.

Si cambia la reserva, hay que volver a comprobarla

Una reserva aceptada no siempre llega intacta al día del servicio. A veces cambia la hora o el número de personas. En algunos grupos también cambia el local o la zona solicitada. Cualquiera de esas modificaciones puede hacer que la mesa asignada deje de servir, aunque la reserva original fuera correcta cuando se creó.

Pasar de cuatro a seis personas puede obligar a cambiar de mesa. Adelantar la llegada quizá coincida con otra reserva y un retraso puede afectar a la siguiente. Por eso una modificación necesita una nueva consulta de disponibilidad.

TheFork Manager utiliza el término no-show para una reserva en la que el cliente no se presenta y no ha cancelado. Conviene distinguirlo de una cancelación porque el impacto sobre el servicio no es el mismo: en un caso el restaurante conoce el cambio con antelación y en el otro descubre la ausencia cuando la mesa ya estaba reservada.

Los recordatorios deben salir con la reserva actualizada

Un recordatorio programado varios días antes puede quedar desfasado si el cliente modifica la hora o el número de personas. Antes de enviarlo hay que consultar cómo figura la reserva en ese momento.

Last.app permite configurar mensajes y recordatorios por email, SMS o WhatsApp. CoverManager ofrece también recordatorios y reconfirmaciones. Si esas funciones ya cubren lo que necesita el restaurante, no hace falta añadir otra automatización.

Cuando el restaurante necesita mensajes diferentes según el tipo de reserva, la integración puede aplicar esa lógica sin perder de vista el dato actual. El mensaje debe prepararse con la reserva que figure vigente.

La frecuencia tampoco tiene que ser la misma para todas las reservas. Una reserva hecha con semanas de antelación suele necesitar una comunicación distinta de otra realizada esa misma tarde. La pauta también cambia según el tamaño del grupo o las condiciones de cancelación. Esa decisión depende de la política del restaurante y del tipo de servicio.

Cancelaciones y no-shows: aplicar la política que ya tenga el restaurante

Una ausencia deja una mesa sin ocupar después de haber reservado esa capacidad para un cliente. Para reducir ese riesgo, algunos restaurantes utilizan recordatorios o reconfirmaciones. Otros añaden garantías de tarjeta, depósitos o prepago en determinados servicios, especialmente cuando una cancelación tardía resulta difícil de cubrir.

CoverManager permite configurar políticas y garantías asociadas a las reservas. Last.app también contempla depósitos y condiciones de cancelación. El restaurante decide en qué casos utiliza cada medida.

No existe una cantidad o un plazo que sirva para todos. La decisión depende del tipo de servicio y de la política comercial del establecimiento. Tampoco tiene sentido convertir los porcentajes publicados por un proveedor en una previsión para cualquier restaurante.

Una vez definida la política, la automatización la aplica en los casos previstos. Puede solicitar una garantía cuando corresponda y registrar una cancelación con la fecha real en la que se produce. Los casos fuera de las reglas pasan al equipo.

Cuando no quedan mesas, la lista de espera evita perder la petición

Si el servicio está completo, el cliente tiene la opción de apuntarse a una lista de espera en lugar de abandonar la reserva. Así el restaurante conserva una petición que todavía podría encajar si se produce una cancelación. La lista recoge la franja que acepta el cliente y el tamaño del grupo para evitar avisos que no le sirvan.

Estar en la lista de espera no equivale a tener mesa. El cliente recibe una propuesta cuando se libera una opción y la reserva solo queda confirmada después de aceptarla y registrarla.

TheFork ha documentado este uso de la lista de espera. Google Actions Center también contempla integraciones de reservas y listas de espera con información de disponibilidad.

Cuando se libera una mesa, el sistema puede avisar al siguiente cliente según las reglas definidas. Si la oferta caduca o la mesa la reserva otra persona antes, debe comunicarse como no disponible.

Alergias y otras peticiones necesitan una confirmación clara

La reserva puede incluir una alergia, una necesidad de accesibilidad o una petición de trona. También puede incluir una preferencia de ubicación. Esos datos deben registrarse solo cuando sean necesarios para atender la reserva.

La AEPD recuerda que el tratamiento de datos personales debe respetar principios como la finalidad y la minimización. El restaurante debe saber qué información pide al cliente y quién puede consultarla. También debe definir cuánto tiempo la conserva. No hace falta pedir más datos de los necesarios para gestionar la reserva y atender correctamente la petición comunicada.

Si un cliente comunica una alergia, el asistente puede registrarla y trasladarla al restaurante. No debe asegurar que la petición está aceptada si todavía necesita confirmación del equipo.

Si un local está completo, se puede ofrecer otro del mismo grupo

En un grupo con varios establecimientos, una reserva que no cabe en un local puede tener una alternativa cercana. CoverManager contempla la consulta de disponibilidad en varios establecimientos. Para que la propuesta sea útil, el segundo local debe consultarse con la misma precisión que el primero y no ofrecerse solo porque pertenezca al grupo.

El cambio debe proponerse al cliente, no hacerse de forma automática. Aunque pertenezcan al mismo grupo, dos restaurantes pueden tener otra dirección, carta o precio. La accesibilidad y el tipo de experiencia también pueden ser diferentes.

El asistente puede decir, por ejemplo: «A las 21:00 este local está completo. Aquí hay mesa a las 21:30 y en el establecimiento de X hay disponibilidad a las 21:00. ¿Qué prefieres?». La opción elegida se vuelve a consultar antes de confirmarla.

La gestión interna de varios locales requiere decisiones adicionales que quedan fuera de este artículo. Para una reserva concreta basta con ofrecer otra sede cuando el grupo lo permita y el cliente acepte el cambio.

Ejemplo: una reserva pasa de cuatro a seis personas

Un cliente escribe por WhatsApp y pregunta si hay mesa para cuatro «sobre las nueve». El asistente identifica el restaurante y la fecha antes de consultar. A las 21:00 no hay una opción compatible, pero sí a las 20:30 y a las 21:30. Esas dos horas proceden de la disponibilidad que devuelve el programa.

El cliente elige las 21:30. El asistente recoge los datos que faltan y crea la reserva. Solo después de recibir la confirmación del programa comunica al cliente que la mesa está reservada.

Dos horas más tarde el cliente pregunta si finalmente pueden ser seis. La reserva ya no puede tratarse como la misma petición. Hay que comprobar si el restaurante admite seis personas a las 21:30.

Si existe una mesa válida, se actualiza la reserva y se envía la nueva confirmación. Si no cabe el grupo, se ofrecen las alternativas que devuelva el sistema o se pasa el caso al equipo.

Qué hacer si no se puede consultar la disponibilidad

A veces la consulta falla porque la API no responde o porque hay una incidencia de conexión. También puede ocurrir que el programa tarde demasiado en devolver la información. En cualquiera de esos casos, el asistente no dispone de una hora confirmable y debe cambiar la respuesta al cliente.

Una opción es recoger la petición y explicar que el restaurante confirmará la disponibilidad. Si la reserva es para dentro de poco, la conversación también puede pasar a una persona según las reglas que haya definido el establecimiento.

Una solicitud pendiente no debe comunicarse como reserva confirmada. Si el cliente recibe una confirmación, la reserva debe aparecer registrada en el software que utiliza el restaurante. De lo contrario puede llegar al local convencido de que tiene mesa cuando el equipo no encuentra ninguna reserva.

Los fallos repetidos de integración también deben generar un aviso técnico. El personal de sala no debería descubrir el problema cuando empiezan a llegar clientes. La incidencia debe quedar registrada para que el responsable pueda revisarla y localizar las solicitudes que se hayan quedado pendientes durante el fallo.

Por dónde empezar a automatizar las reservas

El primer piloto debería limitarse a las reservas habituales que ya siguen reglas claras. Los eventos, los grupos grandes o los servicios con condiciones especiales pueden dejarse para una fase posterior.

Qué comprobar durante el piloto

El equipo puede revisar cuántas consultas terminan en una reserva sin intervención y cuántas necesitan ayuda. También interesa saber cuántas reservas requieren una corrección manual, qué tipos de cambio siguen dando problemas y en qué situaciones el asistente termina derivando la conversación. Esos datos permiten decidir qué ampliar después y qué conviene dejar en manos del equipo.

Hay que vigilar también los fallos de integración. Si el cliente recibe una confirmación y la reserva no aparece registrada, el error debe detectarse antes de la llegada. La monitorización de automatizaciones ayuda a identificar estas incidencias y avisar al responsable.

Qué dejar para una segunda fase

Los grupos, los eventos y los menús cerrados suelen requerir más información que una reserva estándar. A veces hay anticipos o propuestas que cambian varias veces. También intervienen varias personas del grupo y aparecen necesidades específicas. En esos casos es frecuente que comercial o eventos tenga que revisar condiciones antes de confirmar nada al cliente.

La gestión de varios locales también puede necesitar reglas propias. Ofrecer otro establecimiento como alternativa es sencillo cuando ya existe disponibilidad consultable, pero coordinar políticas y datos entre todos los locales requiere un trabajo adicional.

Para el primer piloto basta con un objetivo concreto: que una reserva habitual pueda recibirse por distintos canales y quedar registrada correctamente.

Preguntas frecuentes sobre reservas automatizadas en restaurantes