Autor: AltioraIA

Cinco cosas que aprendes conectando un bot a las reservas

La documentación de un motor de reservas describe el camino feliz en dos páginas y parece que la integración es cosa de una tarde. En AltioraIA las tenemos en producción, y estas son las cinco cosas que solo aparecen cuando ya hay clientes reales escribiéndole al bot.

Respuesta directa. Conectar un bot a un motor de reservas de hostelería falla en sitios que la documentación no menciona: crear una reserva son dos llamadas y no una, el borrado por API puede fallar siempre, la fecha no viene en el recurso que la nombra, y el identificador del local acaba incrustado en el código.

1. Crear una reserva son dos llamadas, no una

Lo primero que rompe el esquema mental. En los motores de reservas de hostelería —CoverManager o Eveve, por poner dos que un restaurante español usa a diario— reservar no es un POST y ya está. Si lo que buscas es antes el mapa de qué se conecta con qué, empieza por ahí y vuelve luego.

Son dos pasos: primero se crea una retención de la mesa, y después se confirma. Entre uno y otro la mesa está bloqueada pero la reserva no existe todavía observado en producción, 2026.

Para una web con formulario esto da igual: los dos pasos ocurren con medio segundo de diferencia. Para un bot conversacional lo cambia todo. Tu usuario está escribiendo por WhatsApp, y entre que retienes la mesa y le preguntas «¿te confirmo?» pueden pasar tres minutos, o puede no contestar nunca.

Así que el bot necesita algo que la documentación no te va a dar: una política de retenciones huérfanas. Nosotros la fijamos antes de escribir una línea de código —cuánto aguanta una retención sin confirmar y qué la libera— porque añadirla después obliga a rehacer la conversación entera. Qué pasa con la mesa bloqueada cuando la conversación se muere. Si no la tienes, vas bloqueando mesas que nadie ocupa, y un viernes por la noche eso es dinero del restaurante. Es el mismo problema que hay detrás de reducir los no-shows: una mesa reservada que no se ocupa cuesta igual.

2. El borrado por API puede fallar siempre

Este es el que más horas cuesta, porque el error no parece un error de diseño.

Nos encontramos con un motor de reservas cuyo endpoint de borrado devolvía error de servidor de forma sistemática, en todas las llamadas y con todos los parámetros observado en producción, 2026. No intermitente, no según el estado de la reserva: siempre.

La reacción natural es asumir que lo estás llamando mal, y ahí se van las horas. No lo estás llamando mal: esa vía no funciona. La cancelación va por otro sitio, normalmente un enlace de cancelación que la propia plataforma te devuelve en la respuesta cuando creas la reserva.

Y de ahí sale la consecuencia cara: ese enlace te lo dan una sola vez, en la creación. Si tu integración no lo guardó, no puedes cancelar esa reserva por medios automáticos. Punto. Toca entrar al panel a mano.

Nosotros persistimos el enlace de cancelación en el primer paso, junto al resto de la respuesta de creación, precisamente porque te lo dan una sola vez y sin él no puedes cancelar. Es una línea de código y un campo en base de datos; descubrir que falta son seis meses de reservas que hay que cancelar a mano.

3. El dato que no viene donde lo buscas

Uno esperaría que consultar una reserva devuelva, entre otras cosas, el día de la reserva. No siempre.

Nos encontramos con que el recurso que devuelve las reservas de un cliente no incluía la fecha; estaba solo en el historial del comensal, que es otro recurso distinto observado en producción, 2026.

El efecto práctico es que una operación que suena trivial —comprobar si el cliente ha cambiado su reserva de día— exige cruzar dos llamadas a dos recursos distintos y casar los registros entre ellas. Eso multiplica la latencia del bot y mete un punto de fallo donde no lo habías presupuestado.

Antes de dar un plazo, haz una cosa: coge los cinco mensajes que tu bot va a recibir más veces y comprueba, uno a uno, si los datos que necesitas para responderlos están en una sola llamada. Normalmente no lo están.

4. El identificador que parece configuración y es producción

Este es el más silencioso y el que más miedo da.

En una auditoría de una integración de reservas encontramos el identificador del local incrustado en el código de las llamadas, y en dos generaciones distintas del mismo flujo: una versión antigua con un identificador y una corregida con el bueno observado en producción, 2026. Lo grave no es el error, es cómo se comporta: las llamadas contra el local equivocado no fallan. Devuelven 200. La API existe, el identificador existe, la respuesta es válida. Simplemente es de otro restaurante.

Un panel de monitorización que mire códigos de error te dice que todo va bien. Y va bien: está consultando perfectamente el sitio que no es.

Y hay un segundo nivel, que es el que lo convierte en artículo: alguien ya había detectado el problema y había construido la versión corregida. Pero esa versión vivía en una rama del sistema que ningún disparador llamaba. El diagnóstico estaba hecho, la corrección estaba escrita, y aun así producción seguía ejecutando la versión vieja.

Si sacas una sola cosa de este artículo: un identificador de local no es configuración, es la clave de multi-tenencia del sistema. Va en una variable de entorno, nunca escrito dentro de una llamada, y se comprueba en el arranque.

5. Las ramas que nadie ejecuta

Los flujos de automatización acumulan nodos huérfanos a una velocidad que sorprende a cualquiera que venga de programar en un repositorio con control de versiones.

En la misma auditoría, la mayoría de las llamadas que apuntaban al identificador equivocado estaban en ramas sin ninguna conexión de entrada: copias de nodos hechas al depurar, ramas de pruebas, versiones anteriores que nadie borró observado en producción, 2026. No las ejecutaba nada.

Esto tiene una consecuencia metodológica que cuesta cara si no la sabes: buscar por texto no sirve para auditar un flujo. Si buscas una cadena y te salen veinte resultados, no tienes veinte problemas: tienes veinte apariciones, de las cuales puede que tres se ejecuten. La pregunta correcta no es «¿dónde aparece esto?», sino «¿se llega hasta aquí desde algún disparador?».

Auditar bien es rastrear alcanzabilidad nodo a nodo hacia atrás, hasta un webhook o un disparador vivo. Es lento y no hay atajo, y es exactamente el trabajo que distingue una integración que aguanta de una que parece que funciona.

Qué preguntar antes de presupuestar una integración

Si estás pidiendo presupuesto para conectar tu motor de reservas con un bot, estas cinco preguntas te dicen en dos minutos si quien tienes delante ha hecho esto antes:

¿Crear una reserva es una llamada o son dos? Si te dicen que una, no han llegado a producción.

¿Qué pasa con una mesa retenida si el cliente deja de contestar? La respuesta tiene que ser una política concreta con un tiempo, no «eso lo gestiona la plataforma».

¿Cómo se cancela, y qué guardáis en el momento de crear? Si no mencionan guardar nada de la respuesta de creación, van a tener el problema del punto 2.

¿Dónde vive el identificador del local? Si la respuesta no es «en una variable de entorno», tienes el punto 4 esperándote. Y comprueba de paso que tu plataforma expone lo que hace falta: tanto CoverManager como Ágora publican su catálogo de integraciones por categorías.

¿Cómo comprobáis que una rama del flujo se ejecuta de verdad? Aquí se separa quien ha auditado un sistema en producción de quien solo ha construido uno.

Y si todavía estás antes de esa fase, decidiendo por dónde entrar, el orden lo da el mapa de las tres capas de un restaurante: reservas, sala y TPV no se automatizan igual ni a la vez.

Ninguna de las cinco va sobre tecnología. Van sobre si alguien ha estado delante de un restaurante un viernes por la noche con el bot parado. Que es, al final, lo único que se paga.

Nosotros las contestamos así: son dos llamadas; la retención tiene política y tiempo desde el primer día; guardamos toda la respuesta de creación, enlace de cancelación incluido; el identificador del local va en variable de entorno y se comprueba al arrancar; y la alcanzabilidad se audita rastreando hacia atrás desde cada disparador, nodo a nodo.

Si quieres que miremos tu integración —la que tienes o la que te han presupuestado—, escríbenos desde nuestra página de servicios. Si está bien montada, te lo diremos igual.

Quién firma esto

AltioraIA. Montamos y operamos automatizaciones para restaurantes y pymes: reservas integradas con las plataformas que ya usan, atención por WhatsApp y agentes de voz. Lo que se cuenta aquí sale de sistemas funcionando con clientes delante, no de documentación.

Fuentes

Consultadas el 22 de septiembre de 2026.

1. CoverManager — Integraciones. Catálogo por categorías: TPV, Channel Manager, pagos, CRM, centralita telefónica. https://www.covermanager.com/es/integraciones/
2. Ágora — Integraciones y alianzas. Catálogo desde el lado del TPV, con gestión de reservas y asistente telefónico de reservas entre sus categorías. https://www.agorapos.com/integraciones/
3. Observación propia en integraciones de producción, 2026. Los cinco hallazgos técnicos de este artículo proceden de integraciones reales entre motores de reservas de hostelería y bots conversacionales, y de auditorías sobre esos mismos sistemas. Van marcados uno a uno como [observado en producción, 2026].

No se identifica a ningún cliente, ni se publican identificadores, nombres de flujo ni credenciales. Los casos se describen por tipo y tamaño de negocio. El artículo describe clases de problema y qué preguntar, no una guía de implementación.

Automatizar reservas sin cambiar el sistema que ya tienes

Llevas dos años con tu sistema de reservas y tu TPV funcionando, y ahora te dicen que hay que automatizar con IA. En AltioraIA conectamos automatizaciones a las plataformas que los restaurantes ya usan, así que esta conversación la tenemos cada semana. La buena noticia es que casi nunca hay que cambiar nada: lo que hay que saber es por dónde entra la automatización en lo que ya tienes.

Respuesta directa. Un restaurante no tiene un sistema, tiene tres capas: reservas, sala y TPV. La automatización entra por sitios distintos en cada una y se apoya en las integraciones que las plataformas ya publican. No hace falta sustituir nada; hace falta saber qué expone cada capa y dónde se tocan entre sí.

Tu restaurante no tiene un sistema, tiene tres capas

Esta es la confusión que hace que las conversaciones sobre automatización acaben mal. «Mi sistema de reservas» y «mi programa del restaurante» no son lo mismo, y automatizarlos no se parece en nada.

La capa de reservas es la que recibe al cliente antes de que llegue: de dónde entran las reservas, quién las confirma, qué pasa si no aparece. CoverManager o Eveve viven aquí.

La capa de sala es la que reparte esas reservas entre mesas reales y controla la rotación durante el servicio. A veces va dentro del motor de reservas y a veces es un módulo aparte.

La capa de TPV es la que toma la comanda, manda a cocina y cobra. Ágora vive aquí, y no es un motor de reservas aunque tenga módulo de reservas de mesa.

Meter las tres en el mismo saco es el error que hace que alguien presupueste «automatizar el restaurante» sin saber de qué está hablando. Y es exactamente el error que este artículo existe para evitarte.

Qué se automatiza en la capa de reservas

Aquí está el grueso, y es la capa por la que casi siempre conviene empezar.

CoverManager organiza su propia oferta en bloques que dicen bastante de lo que se puede automatizar: gestión de reservas desde todos los canales, gestión de mesas y sala con rotación en tiempo real, protección contra no-shows con depósitos y recordatorios, CRM de clientes, marketing y campañas, y reseñas y reputación fuente: https://www.covermanager.com/es/integraciones/. Eveve, por su parte, es un sistema de reservas con gestión de mesas propia y conexión a TPV fuente: https://eveve.com/.

Traducido a automatización real, esta capa permite típicamente cuatro cosas:

Entrada de reservas por canales que no son la web. WhatsApp, Instagram, teléfono. El cliente escribe donde le apetece y la reserva acaba en el mismo sitio que las de siempre.

Confirmación y recordatorio automáticos, que es la palanca directa contra los no-shows y la que antes se nota.

Lista de espera y recolocación cuando se libera una mesa.

Ficha de cliente que se rellena sola, con lo que el cliente ya contó en la conversación.

Lo importante para ti: las cuatro se apoyan en cosas que la plataforma ya hace. No estás pidiéndole nada raro a tu sistema.

Qué se automatiza en la capa de TPV

Esta capa tiene mucho recorrido y casi nunca es por donde hay que empezar. Conviene saber por qué.

Ágora publica su catálogo de integraciones por categorías, y el listado dice solo qué tipo de cosa se conecta: agregadores de plataformas, plataformas de delivery, control de stock, control de costes, control de efectivo, CRM, ERP, fidelización, gestión de personal, PMS de hostelería, kioscos, balanzas, ticketing, reportes y alertas fuente: https://www.agorapos.com/integraciones/.

Mirado desde la automatización, eso es casi todo gestión interna: escandallos, inventario, compras, personal, cuadre de caja. Son mejoras de margen, reales y a menudo grandes, pero ninguna las ve tu cliente.

Por eso el orden habitual es reservas primero y TPV después. No porque el TPV valga menos, sino porque el retorno de la capa de reservas se nota en semanas y el de la capa de TPV en trimestres, y cuando alguien automatiza por primera vez necesita ver que funciona.

¿Quieres saber qué se puede hacer con tu configuración concreta? Dinos qué tienes en cada capa y te decimos qué se automatiza y qué no, sin rodeos. Nuestros servicios.

Dónde se tocan las dos capas, que es donde está el trabajo

Y aquí viene lo que no vas a encontrar publicado en ningún sitio, porque exige mirar los dos catálogos a la vez.

CoverManager lista «TPV» entre las categorías a las que se conecta, junto a Channel Manager, pagos online, CRM, email marketing, reseñas, métricas de Google y centralita telefónica; declara más de 130 integraciones y nombra, entre otras, a Lightspeed y Oracle Simphony fuente: https://www.covermanager.com/es/integraciones/.

Ágora lista «Gestión de reservas» entre las categorías a las que se conecta, y dentro nombra a CoverManager, Restoo y Restaurantic fuente: https://www.agorapos.com/integraciones/.

O sea: se encuentran desde orillas opuestas. La misma unión, descrita dos veces en dos webs que el dueño del restaurante nunca lee seguidas. Ese punto de encuentro —la reserva que se convierte en una mesa sentada y acaba en un ticket— es donde vive el trabajo de integración de verdad, y es donde se decide si automatizar te da datos útiles o solo mensajes bonitos.

Un detalle que cambia las conversaciones de presupuesto, y que sale de mirar los catálogos con atención: las dos plataformas ya tienen categoría propia para el teléfono. Ágora tiene una categoría llamada «Asistente telefónico de reservas», donde describe soluciones basadas en IA que automatizan la reserva por teléfono y WhatsApp; CoverManager tiene «Centralita telefónica» fuente: https://www.agorapos.com/integraciones/, https://www.covermanager.com/es/integraciones/.

No hace falta convencer a nadie de que la voz encaja en un restaurante: las plataformas ya le han hecho sitio. Lo que cuesta esa pieza depende del volumen de llamadas que tengas, y es una cuenta que conviene hacer aparte.

Qué no se automatiza, y conviene saberlo antes de firmar

La parte honesta, que es la que te ahorra el disgusto.

No se automatiza lo que la plataforma no expone. Si una funcionalidad existe en el panel pero no sale por la integración, para un sistema automático no existe. Es la primera pregunta técnica de cualquier proyecto y la que más proyectos tumba.

No se automatiza el criterio. Encajar a seis personas un sábado a las 21:30 cuando solo quedan dos mesas de cuatro es una decisión de negocio, no una regla. Un sistema puede proponerla; quien decide es la sala.

No se automatiza sin política de excepciones. Qué pasa con una mesa retenida cuando el cliente deja de contestar a mitad de conversación, por ejemplo, es algo que ninguna documentación resuelve por ti y que hay que decidir antes de empezar observado en producción, 2026. Si nadie te pregunta eso, no han hecho esto antes.

Y no se automatiza igual de rápido en todas las plataformas. No porque unas sean mejores que otras —no va de eso—, sino porque cada una expone cosas distintas y con condiciones de acceso distintas. Lo tuyo se resuelve preguntando, no leyendo un ranking.

Cómo saber si tu configuración concreta se puede conectar

Tres preguntas, por este orden. Las dos primeras las contestas tú en cinco minutos.

Uno: ¿qué tienes exactamente en cada capa? Escríbelo: motor de reservas, cómo gestionas la sala, qué TPV. Si no sabes si tu sistema de reservas y tu TPV están ya conectados entre sí, esa es la primera cosa que averiguar.

Dos: ¿qué dice el catálogo de integraciones de cada una? Están publicados y son gratis de leer. Te dicen por categorías qué tipo de cosa se conecta, y eso ya descarta o confirma la mitad de las ideas.

Tres: ¿qué condiciones de acceso pone tu plataforma? Esta se la preguntas a ellos, y la respuesta no siempre es inmediata: algunas plataformas de hostelería no publican documentación técnica abierta y la dan solo a partners, así que el plazo real de tu proyecto puede depender de un trámite comercial y no de la programación. Mejor saberlo la primera semana que la quinta.

Por dónde empezar si solo vas a hacer una cosa

Nosotros empezamos siempre por lo mismo: confirmación automática de reservas y recordatorio previo. Sin excepciones, y da igual la plataforma.

Es lo que menos depende de integraciones profundas, lo que antes se nota en la cuenta y lo único de esta lista que se paga solo con las mesas que dejas de perder. Está detallado en reducir los no-shows.

Y si vas a pedir presupuesto, lleva escritas tus tres capas. La diferencia entre un proyecto que sale bien y uno que se atasca casi nunca es la herramienta: es si alguien se sentó a mirar qué había antes de prometer nada. Lo que suele salir mal está en lo que la documentación no cuenta.

Qué pasa el primer mes, que es lo que de verdad quieres saber

Supongamos que haces solo eso: conectar la confirmación automática y el recordatorio, sin tocar nada más. Así es como va ese primer mes, y lo contamos porque lo hemos hecho muchas veces.

La primera semana no cambia nada para ti. Se conecta la automatización a tu motor de reservas, tú sigues entrando al mismo panel de siempre y tu equipo sigue trabajando igual. Si en algún momento hay que cambiaros la forma de trabajar para que esto funcione, está mal montado.

A partir de la segunda semana empiezas a ver tres cosas que hoy no ves. Cuántas reservas confirman solas y cuántas ni contestan. A qué hora entran las reservas que antes se perdían porque no había nadie al teléfono. Y cuántas mesas se liberan con antelación suficiente para volver a venderlas, que es la que de verdad vale dinero.

Esos tres números no te los podemos dar nosotros: salen de tu local y de nadie más. Cualquiera que te prometa un porcentaje de mejora antes de medirlo te lo está inventando.

Al final del mes tienes una decisión, no una factura sorpresa. Y solo hay tres salidas posibles:

Si los números dicen que casi todo el mundo confirma y que apenas se liberaban mesas, ya has terminado: tenías un problema pequeño, lo has resuelto barato y no hace falta seguir. Te lo diremos nosotros.

Si dicen que se te caían reservas fuera de horario, el siguiente paso es abrir el canal por donde se caían —WhatsApp o el teléfono—, y entonces sí tiene sentido mirar lo que cuesta un agente de voz.

Y si dicen que el cuello de botella está en la sala y no en la entrada de reservas, el trabajo siguiente es la segunda capa, no más automatización de la primera.

Ese es el orden en el que trabajamos: una pieza, un mes, una decisión con datos tuyos delante. Nunca al revés.

Si quieres empezar por ahí, cuéntanos qué tienes en cada capa y te decimos qué se puede conectar y qué no, sin cambiar de plataforma: nuestros servicios.

Quién firma esto

AltioraIA. Montamos y operamos automatizaciones para restaurantes y pymes: reservas integradas con las plataformas que ya usan, atención por WhatsApp y agentes de voz. Lo que se cuenta aquí sale de sistemas funcionando con clientes delante, no de documentación.

Fuentes

Consultadas el 22 de septiembre de 2026.

1. CoverManager — Integraciones. Declara más de 130 integraciones, organizadas por categorías: Channel Manager, TPV, pagos online, CRM, email marketing, reseñas, centralita telefónica y métricas de Google. https://www.covermanager.com/es/integraciones/
2. Ágora — Integraciones y alianzas. Catálogo por categorías desde el lado del TPV, con gestión de reservas y asistente telefónico de reservas entre ellas. https://www.agorapos.com/integraciones/
3. Eveve — Reservation Systems. Sistema de reservas con gestión de mesas propia y conexión a TPV. https://eveve.com/
4. Observación propia en integraciones de producción, 2026, entre motores de reservas de hostelería y bots conversacionales.

Este artículo no puntúa ni recomienda plataformas: describe capas y las nombra como ejemplo. No hay enlaces de afiliado ni acuerdos comerciales con ninguna de las mencionadas. Las capacidades concretas de tu plataforma dependen de tu contrato y conviene confirmarlas con ella.