Widget de reservas para restaurantes: qué es y cómo funciona

La mayoría de los hosteleros se topa con la expresión «widget de reservas» comparando sistemas y asiente sin que nadie le explique qué es en realidad. Merece la pena dedicarle diez minutos, porque la diferencia entre un widget y la alternativa decide quién es el dueño de los datos de sus clientes, quién controla el correo de confirmación y si un cliente que estaba en su página de inicio vuelve alguna vez a ella.

Está escrito para quien lleva el restaurante, no para quien construye la web. No necesita programar para entender nada de esto y, casi con total seguridad, no necesita un desarrollador para instalarlo.

Un widget es un proceso de reserva que corre en su propia páginaCopy link to section: Un widget es un proceso de reserva que corre en su propia página

Hay dos maneras de que una web acepte reservas. La primera es un enlace: el cliente pulsa «Reservar mesa», sale de su web y aterriza en otro sitio: una ficha de un portal, una página de reservas alojada por un tercero, otro dominio. La segunda es un widget: el proceso de reserva se dibuja dentro de su propia página, bajo su propia cabecera, en su propio dominio, y el cliente no se va a ninguna parte.

Técnicamente, un widget es una pequeña pieza de software que su sistema de reservas inserta en un espacio que usted le reserva en la página. En la práctica, significa que todo el recorrido desde «¿a qué hora abren?» hasta «su reserva está confirmada» ocurre entre su barra de navegación y su pie de página.

La anatomía de un widget de reservasCopy link to section: La anatomía de un widget de reservas

Todo widget de reservas solvente hace las mismas cinco cosas en el mismo orden. Si las entiende, puede evaluar la demo de cualquier proveedor en unos noventa segundos.

1. 1Consulta de disponibilidad. Antes de mostrar nada, el widget pregunta a su sistema de reservas qué es realmente reservable: su horario, sus turnos de servicio, su inventario de mesas y lo que ya está en la agenda.
2. 2Número de comensales. Se pide primero, porque cambia todo lo que viene después. Una mesa de dos y una mesa de ocho tienen disponibilidades distintas y, a menudo, tiempos de rotación distintos.
3. 3Fecha y hora. El cliente ve franjas reales, no un campo de texto libre. Las horas no disponibles deben estar ausentes o visiblemente desactivadas, nunca aceptadas y después rechazadas.
4. 4Datos del cliente. Nombre, teléfono, correo y cualquier nota que usted permita. Breve: cada campo que añade le cuesta reservas completadas.
5. 5Confirmación. Una confirmación en pantalla al instante y un mensaje al cliente con los datos y una forma de cancelar o modificar.

Ese último mensaje trabaja más de lo que la mayoría de los hosteleros le reconoce: es la única comunicación que un cliente con reserva abre de forma fiable. Qué incluir en la confirmación de reserva de un restaurante repasa qué debe contener.

Integrado, emergente, botón o página completaCopy link to section: Integrado, emergente, botón o página completa

El mismo proceso de reserva puede presentarse de varias formas, y la elección es una decisión de maquetación más que técnica. La mayoría de los sistemas permite cambiar entre ellas sin tocar nada en su web.

El formato integrado es la opción más segura por defecto en la portada de un restaurante. Los emergentes convierten bien cuando el botón es evidente, pero es fácil abusar de ellos: un punto de entrada claro gana a tres compitiendo entre sí.

Qué hace realmente el código de inserciónCopy link to section: Qué hace realmente el código de inserción

Le darán un fragmento de código para pegar en su web. Suelen ser dos líneas, y conviene saber para qué sirve cada una para poder distinguir un problema real de instalación de un problema de configuración.

<div data-booking-widget="SU_WIDGET_ID"></div>
<script async src="https://example.com/widget/v1.js"></script>

• El div es un contenedor vacío. No contiene nada y marca el punto de la página donde debe dibujarse el proceso de reserva.
• El script carga el software de reservas de su proveedor, encuentra el contenedor y lo rellena. Al estar marcado como async, se carga en paralelo con el resto de la página en lugar de bloquearla.
• El identificador del widget es un dato público, no una contraseña. Indica al script qué restaurante debe cargar, y por eso el fragmento se puede enviar sin riesgo a quien lleve su web.
• El script se pone una sola vez por página, aunque coloque dos contenedores en ella.

Cómo se mantiene sincronizado con su disponibilidad realCopy link to section: Cómo se mantiene sincronizado con su disponibilidad real

La única pregunta que merece la pena hacer a cualquier proveedor es dónde se calcula la disponibilidad. En un widget bien construido, la respuesta siempre es «en el servidor, en el instante en que el cliente mira». El widget no guarda ninguna copia de su agenda. Pregunta cada vez y muestra lo que le contesten.

Eso es lo que evita el fallo que hace desconfiar de las reservas online: dos clientes ocupando la misma mesa de las 21:00 porque ambos miraban una página que era exacta hace diez minutos. También significa que una reserva que su recepción toma por teléfono y registra en el sistema retira esa franja de la web en cuestión de segundos, y que una mesa que bloquee para un evento privado desaparece del widget sin que usted toque la web.

El corolario es que un solo sitio debe contener la verdad. Si su widget, su libreta de teléfono y una ficha en un portal tienen cada uno su propia foto de esta noche, tiene tres agendas y ningún sistema de reservas. Cómo organizar las reservas por teléfono, en persona y desde la web explica cómo unificarlas.

Cómo darle estilo para que no parezca añadido a la fuerzaCopy link to section: Cómo darle estilo para que no parezca añadido a la fuerza

Un widget que desentona con la web que lo rodea se lee como un anuncio de terceros, y los clientes lo tratan con la misma cautela con la que tratan los anuncios. Normalmente podrá controlar el color del botón principal, los colores de texto y de fondo, el color del borde, el radio de las esquinas, el texto del botón y el idioma. Configúrelos a partir de la paleta que ya tiene su web, en vez de elegir colores nuevos.

• Iguale el color del botón a la llamada a la acción más fuerte que ya exista en su web, para que el botón de reservar se lea como suyo.
• Iguale el radio de las esquinas al de sus botones y tarjetas. Un widget con forma de píldora dentro de una web de esquinas rectas es el detalle que casi todo el mundo nota sin saber nombrarlo.
• Use las palabras de sus clientes en el botón. «Reservar mesa» para un comedor, «Reservar» para algo más informal. Tres palabras o menos sobreviven en una pantalla pequeña.
• Compruebe el contraste a la luz del día en un móvil, no en el monitor de su despacho. El texto claro sobre fondo claro es el fallo de accesibilidad más habitual en los widgets personalizados.

El comportamiento en móvil es la prueba de verdadCopy link to section: El comportamiento en móvil es la prueba de verdad

La mayor parte del tráfico de reservas de restaurante llega desde un móvil, a menudo con una sola mano, a menudo en la calle y a veces con mala cobertura mientras el cliente está fuera decidiendo. Dé por hecho que ese es su usuario típico, no la excepción. El widget debe ocupar todo el ancho que se le dé, mantener zonas de pulsación grandes para acertar caminando, abrir el teclado numérico para el teléfono y no atrapar nunca al cliente en un desplazamiento horizontal. Pruebe el proceso con un solo pulgar en su propio móvil antes de dar por bueno que funciona.

Qué comprobar antes de publicarloCopy link to section: Qué comprobar antes de publicarlo

1. 1Abra la página publicada en una ventana normal del navegador, no en la vista previa del editor. Los editores bloquean scripts con frecuencia, lo que hace que un widget que funciona parezca roto.
2. 2Confirme que las horas mostradas coinciden con las que realmente da servicio, incluidos el último turno y cualquier día de cierre.
3. 3Pruebe con un grupo por encima de su límite online y compruebe que al cliente se le indica qué hacer en su lugar, en vez de encontrarse un callejón sin salida.
4. 4Haga una reserva real de principio a fin desde un móvil, con datos móviles y el wifi apagado.
5. 5Compruebe que el mensaje de confirmación llega, se lee bien, nombra al restaurante correcto y contiene un enlace de cancelación que funciona.
6. 6Compruebe que la reserva aparece en su sistema con la fecha, la hora, el número de comensales y los datos de contacto correctos.
7. 7Cancele la reserva de prueba para que no se quede en la agenda y confirme que la franja vuelve al widget.

Los errores de instalación más frecuentesCopy link to section: Los errores de instalación más frecuentes

• Guardado pero no publicado. Casi todos los sistemas mantienen un borrador y una configuración en vivo. Un borrador guardado es invisible para los clientes, y de ahí sale el clásico «lo cambié y no pasó nada».
• Pegado en un bloque de texto en vez de en un bloque de código. Los gestores de webs escapan el código pegado en contenido normal, así que el fragmento aparece en la página como texto visible. Use el bloque HTML o de código personalizado.
• El script pegado tres veces. Una vez por página es suficiente. Los duplicados ralentizan la página y pueden dibujar el widget dos veces.
• Enterrado al final de la página. Un widget al que nadie llega no convierte nada. Ponga un punto de entrada en la cabecera de todas las páginas.
• Convivir con el formulario antiguo. Un formulario de contacto huérfano que sigue recogiendo solicitudes de reserva significa que la mitad de sus reservas están en un sistema y la otra mitad en una bandeja de entrada.

Para la mecánica en una plataforma concreta, la guía de instalación del widget cubre el código de inserción y la guía de personalización cubre los ajustes de apariencia. Si todavía está decidiendo si integrarlo o no, Reservas directas vs portales de reservas es la versión honesta de ese debate.