Cómo conectar Hotelgest con Zapier para automatizar tareas del hotel

En lugar de copiar reservas a una lista de tareas cada día, puedes conectar Hotelgest con Zapier mediante una vía de integración verificada y convertir cada evento admitido en una acción operativa. Esta guía de 2026 explica cómo preparar el enlace, filtrar reservas, evitar duplicados y probar el circuito antes de activarlo.

TL;DR

• Para conectar Hotelgest con Zapier, confirma primero el mecanismo de integración y los eventos admitidos.
• Zapier conecta un disparador con una acción; no sustituye al PMS ni al channel manager.
• Usa el identificador de reserva y el alojamiento para evitar tareas duplicadas.
• Prueba altas, modificaciones y cancelaciones antes de activar la automatización del hotel.

Por qué importa este flujo

Hotelgest es un PMS para hoteles y apartamentos que necesitan centralizar reservas y automatizar el check-in. El trabajo externo al PMS necesita una regla distinta: decidir qué cambio genera una tarea, quién la recibe y cómo se corrige cuando cambia la reserva. Puedes revisar el alcance del sistema en Hotelgest.

Un aviso de llegada no equivale a una confirmación de reserva. Tampoco una modificación equivale a una reserva nueva. Si tratas todos esos eventos como altas, recepción termina con tareas repetidas y fechas desactualizadas.

En 2026, diseña la automatización alrededor del estado de la reserva, no solo de la recepción de datos. Empieza con una tarea interna reversible, como preparar una llegada; deja los mensajes al huésped, los cobros y los accesos fuera del primer circuito.

Antes de empezar

• Accesos: necesitas una cuenta de Zapier, autorización para configurar integraciones del PMS y acceso a la aplicación donde crearás las tareas. Comprueba también los permisos para consultar y modificar el registro de destino.
• Mecanismo de conexión: confirma con Hotelgest la existencia de un conector, una API o una salida de eventos autorizada para tu cuenta. Solicita documentación sobre autenticación, campos, estados y pruebas; no deduzcas estas capacidades por el nombre del producto.
• El obstáculo que debes resolver antes: confirma si recibes altas, modificaciones y cancelaciones, y si cada evento incluye un identificador estable. Sin ese dato, no puedes distinguir una reserva nueva de una repetición del mismo aviso.

La receta con Webhooks by Zapier que sigue requiere que el origen pueda enviar eventos a una dirección autorizada. Si la vía disponible es una API de consulta, necesitas otro diseño de disparador. No pegues una dirección de webhook en un campo que no esté documentado para ese uso.

Qué vía de conexión encaja con tu caso

Estas son vías posibles de integración, no una lista de funciones garantizadas en tu cuenta. Elige únicamente la vía confirmada por la documentación del origen. Un webhook recibe lo que se le envía; no consulta por sí solo todas las reservas.

Captura del evento

Define primero el contrato del flujo. Para esta receta, el evento será una reserva confirmada y la acción será crear una tarea interna de preparación. La salida esperada es una tarea asociada a una reserva concreta, no una copia de toda la ficha del huésped.

1. Confirma el evento de origen. Pide el significado exacto del estado que identifica una reserva confirmada. No equipares una solicitud pendiente con una confirmación ni uses un texto libre como único criterio.
2. Crea el disparador en Zapier. Si tienes una salida de webhooks autorizada, selecciona Webhooks by Zapier y el evento Catch Hook. Copia la dirección generada y entrégala a quien administra el envío de eventos del PMS.
3. Envía una reserva ficticia. Utiliza datos de prueba sin documentos de identidad, información bancaria ni datos reales de huéspedes. Ejecuta Test trigger y revisa que el ejemplo recibido corresponde al alojamiento y al evento previstos.

Resultado esperado: Zapier recibe un ejemplo con el identificador de reserva, el alojamiento, el estado y las fechas necesarias para la tarea. Si falta un campo obligatorio, corrige el origen antes de continuar; no lo sustituyas por un valor fijo.

No inventes nombres de campos del PMS. Registra los nombres exactos que entregue la integración y su significado. Un campo denominado fecha de creación no sirve como fecha de llegada, aunque ambos contengan una fecha válida.

Filtro de reservas

El filtro separa los avisos útiles del ruido. Define qué reservas entran y cuáles deben detenerse antes de crear trabajo para recepción. Para un flujo inicial, incluye solo el alojamiento elegido y el estado confirmado que hayas validado.

1. Añade la condición. Incorpora Filter by Zapier y configura Only continue if con el estado de confirmación documentado. Añade el identificador del alojamiento cuando la cuenta incluya varias propiedades.
2. Exige los datos mínimos. Comprueba que exista el identificador de reserva y una fecha de llegada válida. Si tu proceso depende de una unidad concreta, exige también ese dato; no asignes una habitación por defecto.
3. Prueba los casos excluidos. Envía una reserva pendiente y otra cancelada como ejemplos separados. Ambas deben detenerse si el flujo está diseñado exclusivamente para preparar reservas confirmadas.

Resultado esperado: el filtro deja pasar la reserva correcta y bloquea los estados ajenos al proceso. Usa 3 reservas ficticias para esta comprobación: una confirmada, una pendiente y una cancelada. Es un conjunto de prueba, no una medida de rendimiento del sistema.

En tu configuración de 2026, documenta también la zona horaria utilizada para interpretar las fechas. Una llegada es una fecha operativa del alojamiento; un momento de actualización es una marca temporal. No los intercambies al calcular el vencimiento de la tarea.

Registro de destino

La aplicación de tareas debe conservar la relación con la reserva original. Escribe una descripción operativa corta y añade solo los campos que el equipo necesita para actuar. El correo del huésped no es necesario para una tarea interna de preparación si el identificador permite consultar la reserva en el sistema autorizado.

1. Conecta la aplicación receptora. Selecciona la acción de búsqueda disponible y busca por una clave formada con el alojamiento y el identificador de reserva. Confirma el comportamiento de esa búsqueda cuando no encuentra resultados.
2. Define creación y actualización. Si no existe el registro, crea la tarea; si existe, actualiza los campos operativos que correspondan. Usa únicamente acciones que la aplicación receptora admita y verifica cómo encadena Zapier ambas situaciones.
3. Mapea los campos. Asocia la llegada con la fecha operativa, el identificador con la referencia y el alojamiento con la propiedad. Ejecuta Test step y abre la tarea creada para revisar el contenido real.

Resultado esperado: obtienes 1 tarea por reserva y alojamiento en esta receta. Reenviar el mismo evento debe conservar esa relación, no producir una tarea adicional. El diseño necesita una búsqueda y una regla de actualización; cambiar el título de la tarea no elimina duplicados.

No presentes una búsqueda previa como garantía absoluta contra duplicados. Dos ejecuciones simultáneas pueden buscar antes de que exista el registro. Para procesos sensibles, exige una clave única en el destino o un control técnico de idempotencia.

Prueba y activación

La conexión funciona cuando el circuito completo responde correctamente, no cuando el disparador recibe un ejemplo. Comprueba recepción, filtro y destino como una única secuencia. No actives el flujo con un ejemplo antiguo que ya no contiene los campos definitivos.

1. Repite el evento de confirmación. Comprueba que conserva la tarea existente. Revisa también que el filtro detiene un evento que carece del identificador obligatorio.
2. Modifica una fecha de llegada. Ejecuta el mecanismo de actualización que hayas preparado y verifica el resultado en destino. Si solo has configurado altas, registra esa limitación y no esperes que la tarea se actualice sola.
3. Activa el circuito validado. Usa Publish cuando las pruebas hayan pasado. Asigna una persona responsable de revisar errores y deja escrito cómo detener el flujo sin interrumpir la operativa del PMS.

Resultado esperado: cada evento admitido produce la acción prevista, y cada evento excluido se detiene. Conserva una tabla de pruebas con caso, resultado esperado, resultado obtenido y responsable; evita guardar cargas completas con datos personales innecesarios.

La prueba valida el circuito completo, no solo la recepción del evento.

Variante: actualizar la tarea cuando cambia la reserva

Una segunda automatización resuelve el problema contiguo: la reserva ya existe, pero cambia la llegada o se cancela. Este flujo exige un evento de modificación o una consulta documentada que permita identificar cambios; no se obtiene automáticamente por haber configurado una alta.

1. Configura el disparador de modificación admitido por el origen.
2. Busca la tarea mediante la misma clave de alojamiento e identificador de reserva.
3. Compara los campos que afectan al trabajo: estado, llegada y unidad, cuando corresponda.
4. Actualiza la tarea existente. Ante una cancelación, aplica la regla acordada con recepción: cancelar la tarea o marcarla para revisión.

Resultado esperado: un cambio en la reserva corrige el trabajo asociado sin crear otra preparación. Mantén 2 estados de prueba para esta variante: reserva modificada y reserva cancelada. Confirma por separado qué debe ocurrir si la tarea todavía no existe.

No compares todos los campos del evento. Una modificación administrativa sin efecto operativo no debería generar otro aviso de preparación. Limita las notificaciones a cambios que obliguen al equipo a actuar.

Problemas habituales y su corrección

El disparador no recibe el evento

Comprueba que el envío utiliza la dirección del webhook correspondiente al flujo y que el evento elegido se produce realmente en el origen. Revisa el registro de envío autorizado. Crear una reserva no demuestra que exista una salida de eventos configurada.

Aparecen tareas duplicadas

Revisa la clave de búsqueda y confirma que incluye el alojamiento. Después, repite exactamente el mismo ejemplo: si crea otra tarea, corrige la búsqueda o la regla de creación. Si el problema ocurre con ejecuciones simultáneas, necesitas un control de unicidad en destino.

La llegada queda en una fecha incorrecta

Comprueba el campo mapeado, el formato recibido y la zona horaria de cada aplicación. No conviertas una fecha sin hora como si fuera un instante universal. Incluye este caso en la revisión de 2026 y repítelo tras cambiar la configuración temporal.

La reserva cancelada mantiene una tarea activa

Añade una ruta de modificación o cancelación respaldada por el origen. El filtro de altas evita nuevas tareas para reservas canceladas, pero no elimina las creadas anteriormente. Busca el registro existente y aplica la regla de cierre acordada.

La acción deja de ejecutarse

Revisa el error concreto en el historial de ejecuciones y comprueba permisos, conexión y campos obligatorios del destino. Corrige la causa antes de repetir el evento. Reenviar sin revisar la búsqueda puede convertir un fallo de conexión en un duplicado.

Amplía el flujo sin copiar toda la ficha

Después de validar las tareas internas, considera procesos como coordinación entre propiedades o seguimiento tras la salida. Para cada ampliación, define un evento, un destinatario y una regla de cancelación. Si el PMS ya resuelve una función, evita construir un segundo circuito con reglas contradictorias.

La automatización no justifica exportar más datos. Separa la información operativa de los documentos de identidad y revisa la finalidad, los accesos y la conservación de datos. La guía de privacidad de datos en hoteles y RGPD permite ampliar ese criterio.

No confundas una tarea enviada por Zapier con un registro oficial de viajeros. Mantén SES Hospedajes y los demás procesos de cumplimiento dentro del procedimiento autorizado que corresponda al alojamiento. Una ejecución correcta del flujo no acredita un envío administrativo.

Un último detalle

Prueba una cancelación antes que una confirmación en la siguiente ampliación de 2026. Crear trabajo es fácil de comprobar; retirarlo cuando deja de ser necesario revela si el proceso tiene un ciclo completo. Mantén Hotelgest como referencia de la reserva y trata la tarea externa como una consecuencia operativa, no como otra reserva independiente.

Guías relacionadas

• Automatizar la recogida de opiniones de huéspedes tras la salida
• Gestionar varios alojamientos desde un único PMS
• Configurar encuestas automáticas tras la salida