Métrica clave del revenue management que mide los ingresos generados por cada habitación disponible del hotel, esté ocupada o no. Se calcula multiplicando ADR x Ocupación, o dividiendo los ingresos totales de habitaciones entre el número total de habitaciones disponibles.
Es el indicador más importante para evaluar la salud financiera del hotel y compararse con la competencia. Un RevPAR alto indica buena combinación de precio y ocupación. Se usa para reporting diario, semanal, mensual y anual, y para comparativas con el compset.
Un hotel de 100 habitaciones con 70% de ocupación y ADR de 120 € tiene un RevPAR de 84 €. Los directores comparan su RevPAR con el del año anterior, con el presupuesto y con los competidores.
Nuestro equipo automatiza la extracción de RevPAR desde el PMS y lo cruzamos con datos del compset (vía STR o scraping autorizado), enviando reports diarios por email o a Looker Studio sin intervención humana.
Precio medio pagado por habitación ocupada en un periodo determinado. Se calcula dividiendo los ingresos totales de habitaciones entre el número de habitaciones ocupadas (sin contar cortesías).
Indica el poder de venta del hotel. Es la palanca principal para subir RevPAR cuando la ocupación está cerca del techo. Los revenue managers ajustan el ADR diariamente según demanda, eventos y competencia.
Un hotel urbano en Madrid en abril puede tener un ADR de 180 €, mientras que un hotel vacacional en Mallorca en agosto puede subir a 250 €. Es la métrica más visible en negociaciones con tour operadores.
Automatizamos alertas cuando el ADR cae por debajo de un umbral, integrando datos del PMS con Slack/Telegram, y creamos dashboards que comparan ADR por segmento, canal y tipología de habitación.
Beneficio operativo bruto por habitación disponible. Mide la rentabilidad real del hotel descontando costes operativos (no solo ingresos), incluyendo F&B, eventos, spa y otros departamentos.
Es la métrica preferida por inversores y propietarios porque refleja la eficiencia operativa global, no solo la capacidad de vender habitaciones. Un hotel puede tener buen RevPAR pero mal GOPPAR si los costes están descontrolados.
Un director general se mide por GOPPAR, no por RevPAR. Es la métrica que aparece en los consejos de administración y en los informes a fondos como Blackstone, Brookfield o KKR.
Nuestro equipo cruza datos del PMS, del POS de F&B y del software contable para calcular GOPPAR automáticamente, eliminando el trabajo manual del controller financiero.
Porcentaje de habitaciones ocupadas respecto al total de habitaciones disponibles en un periodo. Se calcula como habitaciones vendidas / habitaciones disponibles x 100.
Es la métrica más básica y visible. Determina la presión sobre operaciones (housekeeping, recepción, F&B). Influye directamente en decisiones de pricing y staffing.
Un hotel urbano de negocios busca ocupaciones del 70-85% de media anual. Un hotel vacacional puede llegar al 95% en alta temporada y 30% en baja. La ocupación se mira por noches (room nights) y por personas (guest nights).
Automatizamos alertas de ocupación crítica (por debajo del forecast) para activar campañas de last-minute, y conectamos la ocupación prevista con el cuadrante de Skello para ajustar turnos.
Beneficio antes de intereses, impuestos, depreciación y amortización. Mide la rentabilidad operativa pura del negocio sin tener en cuenta cómo está financiado ni la fiscalidad.
Es la métrica financiera de referencia para valorar hoteles en compraventas. Las cadenas y fondos compran hoteles aplicando un múltiplo sobre el EBITDA (típicamente 10-15x en España para hoteles vacacionales premium).
En las due diligence hoteleras, el EBITDA ajustado (normalizado) es la cifra clave. Un hotel con 5M€ de EBITDA puede valorarse en 60-75M€ según ubicación y categoría.
Conectamos los datos operativos del PMS con la contabilidad para calcular EBITDA en tiempo real, con desglose por departamento y comparativa contra presupuesto.
La mejor tarifa pública disponible en cada momento, sin restricciones especiales. Es la tarifa de referencia que se publica en la web del hotel y en las OTAs.
Sirve como ancla de pricing. Sobre la BAR se construyen otras tarifas (BAR + breakfast, BAR no reembolsable con descuento, BAR para socios, etc.). Es la tarifa que normalmente se compara entre canales para verificar rate parity.
Un hotel puede tener BAR dinámica que cambia varias veces al día según demanda. Los revenue managers ajustan BAR mediante reglas en el RMS o manualmente en el channel manager.
Automatizamos la verificación diaria de rate parity, comparando BAR entre web directa, Booking.com, Expedia y metabuscadores, alertando cuando hay disparidad.
Tarifa oficial máxima publicada del hotel, sin descuentos ni promociones. Es la tarifa "de catálogo" que aparece por ley en la información oficial registrada ante la administración turística.
En España es obligatorio comunicar la rack rate a la consejería de turismo correspondiente. En la práctica casi nadie paga rack; sirve como techo legal y referencia. Se exhibe en recepción y en la web institucional.
Un walk-in sin reserva puede ver aplicada la rack rate. También se usa para descuentos contractuales (ej. "20% sobre rack").
Mantenemos sincronizadas las rack rates publicadas en distintos canales y avisamos cuando la rack registrada legalmente no coincide con la del PMS.
Ingreso total por habitación disponible, incluyendo no solo habitaciones sino también F&B, spa, eventos, parking, lavandería y cualquier otro ingreso del hotel.
Refleja la capacidad real de monetización del huésped. Hoteles vacacionales y resorts lo siguen muy de cerca porque sus ingresos accesorios pueden representar el 50% del total.
Un resort all-inclusive en Canarias mide TRevPAR como métrica principal. Un hotel solo alojamiento en aeropuerto se centra más en RevPAR.
Consolidamos automáticamente datos de habitaciones, restaurantes (Ágora, Gestionalia), spa y eventos en un solo dashboard de TRevPAR.
RevPAR neto, descontando comisiones de distribución (OTAs, GDS), impuestos turísticos y costes directos de la venta. Es el RevPAR "real" que entra en caja.
Permite ver el coste real de cada canal. Una venta directa con ADR 100 € genera más NRevPAR que una venta por Booking.com con ADR 110 € pero comisión del 18%.
Es la métrica que justifica las inversiones en venta directa: campañas SEM, programas de fidelización, motor de reservas optimizado.
Calculamos NRevPAR por canal automáticamente, restando comisiones de OTA, costes de Adwords y comisiones de pasarela, mostrando rentabilidad real de cada fuente de negocio.
Coste medio variable por cada habitación ocupada. Incluye amenities, lavandería, agua, electricidad atribuible, productos de limpieza y mano de obra de housekeeping.
Permite calcular el margen real de cada habitación vendida. Si el ADR neto es 80 € y el CPOR es 25 €, el margen contributivo es 55 €.
Negociaciones con tour operadores se hacen contrastando net rate vs CPOR. Si el net rate baja del CPOR, vender genera pérdidas.
Cruzamos datos de housekeeping, lavandería, consumos energéticos y compras para calcular CPOR real, no estimado.
Número medio de noches por reserva. Se calcula dividiendo el total de room nights entre el número de reservas/estancias.
Estancias largas reducen costes operativos (menos check-ins, menos limpiezas a fondo) y mejoran predictibilidad. Estancias cortas dan flexibilidad de pricing pero suben costes.
Un hotel urbano de negocios puede tener ALOS de 1,8 noches; un resort vacacional, 5-7 noches; un apartamento turístico, 3-4 noches.
Configuramos restricciones automáticas de estancia mínima (MinLOS) en el channel manager según forecast, y avisamos cuando el ALOS cae por debajo del objetivo.
Variación de reservas entre dos fechas concretas. Mide cuántas reservas nuevas se han incorporado para una fecha futura desde el último corte (ayer, semana pasada, etc.).
Es la métrica diaria del revenue manager. Se mira pickup a 7, 30, 60, 90 días. Un pickup débil para una fecha futura activa acciones de pricing o promoción.
"El pickup de la semana santa va por debajo del año pasado" significa que se está vendiendo más despacio que el año anterior para esas mismas fechas.
Generamos reports automáticos de pickup diarios y semanales, comparando con el mismo día del año anterior y con el pace presupuestado.
Ritmo acumulado de reservas para una fecha futura, comparado con el mismo punto temporal del año anterior o con el budget. Mide cómo va el llenado vs lo esperado.
Si a 60 días vista tienes 200 reservas y el año pasado tenías 250 a esa misma altura, vas con un pace negativo. Es la métrica que dispara decisiones tácticas.
"Vamos en pace" significa que las reservas evolucionan según lo previsto. "Pace negativo en agosto" dispara campañas de marketing y revisión de pricing.
Construimos curvas de pace automáticas en Looker Studio o Power BI, conectadas al PMS, sin que el revenue manager tenga que descargar Excel.
Previsión de ocupación, ADR, RevPAR e ingresos para periodos futuros. Se construye combinando reservas en libros (on-the-books), pickup esperado e histórico.
Guía la operativa diaria: cuántos camareros contratar, cuánta materia prima comprar, cuántas habitaciones bloquear para grupos. Se actualiza semanalmente y mensualmente.
El forecast a 30 días manda en planificación de turnos. El forecast a 90 días manda en pricing. El forecast anual se usa para budget.
Automatizamos forecasts mediante modelos predictivos (ARIMA, Prophet, IA) alimentados por datos históricos del PMS, eventos y meteorología.
Plan financiero anual aprobado por la propiedad. Incluye objetivos de ingresos por departamento, costes, EBITDA y CAPEX.
Es la referencia oficial. Todos los reports comparan "Actual vs Budget vs Last Year". Se elabora típicamente entre septiembre y noviembre del año anterior.
El director general se evalúa por cumplimiento de budget. Las desviaciones >5% generan reuniones con la propiedad.
Cargamos el budget en sistemas de BI y generamos alertas automáticas cuando una métrica se desvía más de un X% del presupuesto.
Disciplina de gestión que ajusta dinámicamente precios y disponibilidad para maximizar ingresos según demanda, capacidad y comportamiento del cliente. Es el origen del actual revenue management.
Aplica reglas como cerrar tarifas bajas cuando hay alta demanda, abrir restricciones de estancia, o subir precios escalonadamente. Históricamente ligado a aerolíneas y luego trasladado a hoteles.
"Hacemos yield" significa subir precios de fechas de alta demanda y cerrar tarifas baratas. El yield manager y el revenue manager suelen ser la misma persona en hoteles medianos.
Implementamos reglas de yield automáticas conectando el RMS con el channel manager, ajustando tarifas según ocupación on-the-books.
Medida de cuánto cambia la demanda cuando cambia el precio. Si subir un 10% el precio reduce la demanda un 5%, la elasticidad es -0,5 (inelástico). Si la reduce un 15%, es elástico.
Permite saber hasta dónde se puede subir el precio sin perder ingresos totales. RMS modernos (IDeaS, Duetto) calculan elasticidad por segmento, fecha y canal.
Clientes corporate suelen ser inelásticos (pagan lo que sea por estar en el centro). Clientes leisure son más elásticos. Es clave en decisiones de overbooking y displacement.
Analizamos histórico de pricing vs ocupación para detectar puntos de elasticidad y proponer ajustes automáticos.
Práctica controlada de aceptar más reservas que habitaciones disponibles, anticipando cancelaciones y no-shows. Es legal y habitual en hotelería profesional.
Se calcula con datos históricos de cancelaciones y no-shows. Si históricamente el 5% no aparece, se puede aceptar un 5% más de reservas. Si todos aparecen, hay que reubicar (relocate) en hotel similar pagando la diferencia.
Es una práctica delicada que mal gestionada genera reputación negativa. Las cadenas tienen políticas estrictas y compensaciones tasadas para overbookings forzados.
Calculamos niveles óptimos de overbooking por tipología de habitación y canal, y disparamos alertas cuando el riesgo de walk supera un umbral.
Demanda real que existiría si no hubiera limitación de capacidad ni restricciones de pricing. Es la demanda "verdadera" del mercado para un hotel.
Permite saber cuánta demanda se está rechazando (denied) cuando el hotel está completo. Si en agosto se rechazan 500 reservas, hay margen para subir precios.
Los RMS la calculan analizando búsquedas, denials y regrets. Es la base para subir tarifas en fechas de alta demanda.
Capturamos datos de denials del booking engine y de las OTAs para reconstruir la demanda real, no solo la demanda materializada.
Cálculo del coste de oportunidad de aceptar un grupo o un cliente concreto. Compara el ingreso del grupo vs el ingreso que se hubiera obtenido vendiendo esas mismas habitaciones a clientes individuales (transient).
Si un grupo paga 80 €/noche y la BAR esperada es 150 €, hay desplazamiento negativo. Solo se acepta el grupo si genera ingresos accesorios (banquetes, salones) que compensen.
Decisión clave en hoteles MICE y resorts. Un grupo grande puede desplazar clientes leisure más rentables.
Automatizamos análisis de displacement para cada solicitud de grupo, integrando datos de forecast y producción media histórica.
Clasificación de los clientes según origen, tipo, motivo de viaje y canal. Permite analizar ingresos por categorías estratégicas, no solo agregados.
Segmentos típicos: Corporate, Leisure transient, Group, MICE, Tour Operator, OTA, Wholesaler, Walk-in, Loyalty. Cada uno tiene ADR, ALOS y rentabilidad distinta.
Reportes mensuales del PMS muestran "production by segment". Es la base de la estrategia comercial del hotel.
Limpiamos y normalizamos la segmentación que llega del PMS (a menudo desordenada) y construimos dashboards consolidados por segmento.
Plataformas digitales que venden alojamiento, vuelos y servicios turísticos en nombre del proveedor a cambio de una comisión. Las principales en España son Booking.com, Expedia, Hotelbeds, Airbnb y eDreams.
El hotel carga inventario y tarifas en la extranet de la OTA (o vía channel manager). Cuando se produce una reserva, el hotel cobra al cliente o la OTA cobra y paga al hotel posteriormente. La comisión típica oscila entre 15% (Booking modelo agencia) y 25-30% (modelo merchant).
Booking.com domina el mercado español con cuotas del 60-80% en muchas plazas. La dependencia de OTAs es uno de los grandes problemas estratégicos del sector.
Extraemos automáticamente reservas de Booking.com, Expedia y Airbnb, las normalizamos y las inyectamos en el PMS o en sistemas internos vía API o webhooks.
Redes mayoristas que conectan agencias de viajes tradicionales con proveedores hoteleros, aéreos y de car rental. Los principales son Amadeus, Sabre, Travelport (Galileo, Worldspan) y Pegasus.
Las agencias corporate buscan disponibilidad y reservan a través del GDS. El hotel se conecta vía un switch (Sabre Hospitality, Pegasus, Travelclick). Sigue siendo crítico para clientes corporate y MICE.
Hoteles urbanos de 4-5 estrellas con clientela corporativa internacional dependen del GDS. Hoteles vacacionales lo usan menos.
Nos integramos con switches GDS vía channel manager para automatizar reportes de producción GDS y conciliación de comisiones.
Software intermediario que centraliza la gestión de tarifas, disponibilidad y restricciones, distribuyéndolas en tiempo real a múltiples canales (OTAs, GDS, web). Los principales son SiteMinder, D-EDGE, Cubilis, Travelclick, RoomCloud.
Conexión bidireccional con el PMS (vía API o XML). Cuando el hotel cambia tarifa o cierra fechas, el channel manager lo distribuye en segundos a todos los canales. Recibe reservas y las inyecta en el PMS.
Es una herramienta imprescindible. Sin channel manager hay que actualizar canales manualmente (impensable hoy). Cuesta 50-300 €/mes según tamaño y canales.
Si el channel manager no tiene la integración deseada, nuestro equipo construye conectores vía n8n entre PMS, channel manager y herramientas externas (CRM, BI, pricing tools).
Software que se integra en la web del hotel y permite a los clientes consultar disponibilidad, ver tarifas y reservar directamente sin pasar por OTAs. Los principales en España son Mirai, Paraty Tech, Hotetec, Profitroom, Vertical Booking.
Sincroniza con el PMS y el channel manager. Convierte tráfico web en reservas directas. Es la pieza central de la estrategia de venta directa.
Un buen motor convierte 2-4% del tráfico. Los hoteles con marca propia fuerte (cadenas, hoteles boutique) buscan elevar la cuota directa al 30-50%.
Conectamos el motor de reservas con CRM, herramientas de email marketing, sistemas de upselling y el PMS para automatizar el ciclo completo del huésped directo.
Reserva realizada directamente con el hotel (web, teléfono, email, walk-in) sin intermediación de OTA o agencia. No paga comisión externa.
Es la reserva más rentable. La estrategia "Book Direct" busca incentivar la venta directa con beneficios (mejor precio, late check-out, upgrade) que ahorren la comisión OTA.
Hoteles independientes españoles bien gestionados tienen 25-40% de directo. Cadenas internacionales con programas de fidelización fuertes (Marriott Bonvoy, Hilton Honors) llegan al 50-60%.
Automatizamos el envío de ofertas exclusivas a clientes que vuelven, integramos CRM con motor de reservas y disparamos campañas de fidelización tras estancia.
Compromiso (o exigencia contractual) de mantener la misma tarifa pública en todos los canales de distribución para una misma habitación y condiciones. Es exigida típicamente por OTAs en sus contratos.
Si Booking detecta que la web del hotel ofrece la misma habitación más barata, puede penalizar bajando ranking. Las cláusulas de paridad están parcialmente prohibidas en Francia, Alemania, Italia y otros países; en España hay debate jurídico.
Es un campo de batalla constante. Los hoteles intentan ofrecer beneficios "no-rate" en directo (desayuno, parking) para esquivar la paridad sin romperla.
Monitorizamos paridad de tarifas automáticamente cada hora, alertando de disparidades y permitiendo reaccionar antes de que la OTA penalice.
Situación en la que una misma habitación se vende en distintos canales a precios diferentes. Puede ser intencional (estrategia) o accidental (error en wholesaler).
Disparidades positivas para directo (mismo o más barato) son deseables. Disparidades negativas (más caro en directo) destruyen la conversión. La causa más habitual son los wholesalers que filtran tarifas netas a OTAs no autorizadas.
Es un problema crónico. Los hoteles persiguen leakage de wholesalers vía monitorización constante de metabuscadores.
Hacemos scraping autorizado de metabuscadores y reportamos disparidades por canal, fecha y origen, con identificación del leak source.
Bloque de habitaciones reservado contractualmente para un canal, agencia o tour operador durante un periodo determinado. El operador puede vender libremente dentro de ese cupo sin consultar disponibilidad.
Habitual en contratos con tour operadores tradicionales (TUI, Jet2, Iberostar Tour Operator). Tiene "release" (fecha tope para devolver lo no vendido), "stop sale" y condiciones de pago.
Hoteles vacacionales en Baleares y Canarias trabajan masivamente con allotments. La gestión de release date es crítica.
Automatizamos avisos de release próximas y calculamos cuánto cupo está pendiente de devolución por cada operador.
Versión española del contrato de allotment. Acuerdo entre hotel y agencia/tour operador donde se pactan habitaciones reservadas, tarifas netas, condiciones de release y pago.
Es la fórmula contractual estándar para venta a través de touroperación tradicional en España. Suele firmarse anualmente con renegociación.
Los directores comerciales pasan parte del año negociando cupos para la temporada siguiente. Es habitual en costa española.
Digitalizamos contratos de cupo, sus condiciones y release dates, y generamos alertas automáticas para evitar overbookings y penalizaciones.
Instrucción que cierra completamente la venta de un canal o tipología de habitación para una fecha o periodo. El canal no puede aceptar más reservas hasta que se levante.
Se usa cuando el hotel está lleno, cuando hay sobreocupación de un tipo concreto, o cuando se quiere forzar la venta hacia canales más rentables.
Los revenue managers cierran y abren ventas varias veces al día en alta temporada. El channel manager distribuye la orden a todos los canales.
Programamos stop sale automáticos basados en reglas (por ejemplo, cerrar OTAs cuando ocupación >85%, dejando solo directo).
Instrucción contraria al stop sale, reactivando la venta de un canal o tipología cerrada anteriormente.
Se aplica cuando entran cancelaciones y vuelve a haber inventario disponible, o cuando estratégicamente se decide volver a abrir el canal.
Operación rutinaria del revenue manager. La rapidez en abrir tras cancelaciones impacta directamente en ingresos.
Automatizamos la apertura inmediata cuando llega una cancelación, evitando que el inventario quede cerrado innecesariamente.
Compromiso por el cual el hotel garantiza al canal contratado disponibilidad hasta la última habitación, incluso en alta demanda. Es habitual en contratos corporate y con cadenas.
El hotel se compromete a no cerrar el canal por motivos de yield. A cambio, suele negociar tarifas algo más altas.
Contratos corporate de grandes empresas (Telefónica, BBVA, Repsol) suelen exigir LRA. Es un compromiso fuerte que limita el yield management.
Marcamos canales con LRA en los sistemas para evitar cerrarlos por error en stop sales automáticos.
Tarifa que recibe efectivamente el hotel después de comisiones y descuentos. Es la cifra "que entra en caja". Diferente de la "gross rate" o tarifa pública.
En el modelo merchant (Expedia, Hotelbeds), el hotel pacta directamente net rates y la OTA decide qué markup aplicar al cliente final. En el modelo agencia (Booking), la net rate es la BAR menos la comisión.
Negociaciones con tour operadores y wholesalers se hacen en net rates. Los descuentos sobre BAR del 25-35% son habituales.
Calculamos net rate efectiva por canal y reserva, descontando comisiones reales (no las teóricas), y reconciliamos con extractos bancarios.
Porcentaje del importe de la reserva que se queda el canal de distribución como pago por la venta. Varía según canal, modelo y volumen.
Booking.com modelo agencia: 15-22%. Expedia merchant: 18-25%. GDS: 10-18% más fees. Wholesalers: 25-35% de descuento sobre BAR. La comisión es el principal coste variable de distribución.
Reducir el % global de comisión es uno de los grandes objetivos. Cadenas con marca fuerte negocian comisiones más bajas con Booking (incluso 12%).
Conciliamos comisiones de OTAs automáticamente, comparando lo facturado por la OTA contra lo que debería ser según las reservas en el PMS.
Sobrecoste que aplica un intermediario (típicamente wholesaler u OTA merchant) sobre la tarifa neta del hotel para vender al cliente final. Es el margen del intermediario.
Si el hotel da al wholesaler una net rate de 70 € y la OTA vende a 100 €, el mark-up es 30 € (43%). El hotel solo controla la net rate; el mark-up lo decide el intermediario.
Mark-ups excesivos provocan rate disparity y dañan la marca. Los hoteles vigilan mark-ups en metabuscadores.
Detectamos automáticamente mark-ups anómalos comparando net rate contractual con el precio público del intermediario.
Plataformas que comparan precios y disponibilidad de hoteles entre múltiples canales sin vender directamente. Los principales son Google Hotels, Trivago, TripAdvisor, Kayak, Skyscanner Hotels.
El hotel y los canales pujan por aparecer destacados (modelo CPC o comisión). El cliente compara y hace clic al canal elegido. Es un campo de batalla entre web directa y OTAs.
Google Hotels es ya el metabuscador dominante. Aparecer en directo en Google Hotels al mismo precio que Booking es clave para captar reserva directa.
Conectamos el motor de reservas con Google Hotels y Trivago, gestionamos campañas y monitorizamos posicionamiento y CTR.
Capacidad técnica de un sistema (PMS, channel manager) para conectarse con otros sistemas mediante APIs, XML o protocolos estándar. Es un atributo crítico al elegir software hotelero.
Determina con qué OTAs, GDSs, motores y herramientas puede conectarse el sistema. Sin conectividad bidireccional hay que duplicar trabajos manualmente.
PMS legacy con conectividad pobre obligan a usar middleware o "conectores" externos.
Nuestro equipo construye conectores a medida cuando la conectividad nativa no existe, usando n8n + APIs o scraping autorizado.
Integración en la que la información fluye en ambos sentidos entre dos sistemas. Por ejemplo, el PMS envía tarifas al channel manager, y el channel manager envía reservas al PMS.
Es el estándar mínimo deseable hoy. La conectividad unidireccional (solo "push" de tarifas) obliga a importar reservas manualmente.
"¿Tu PMS tiene two-way con Mews/Cloudbeds/Opera?" es la primera pregunta en cualquier proyecto de digitalización.
Cuando una conectividad oficial no es bidireccional, completamos el otro sentido con flujos en n8n que sincronizan reservas, modificaciones y cancelaciones.
Panel web de cada OTA o canal donde el hotel gestiona inventario, tarifas, contenido y reservas si no usa channel manager. Cada OTA tiene la suya: Booking Extranet, Expedia Partner Central, Airbnb Host Dashboard.
Acceso con credenciales por canal. Sin channel manager, el revenue manager debe entrar a cada extranet para actualizar tarifas y disponibilidad. Inviable para hoteles con varios canales activos.
Para tareas no automatizables (responder mensajes huésped, gestionar reclamaciones, descargar reportes específicos) sigue siendo imprescindible entrar.
Automatizamos extracciones desde extranets vía RPA o scraping autorizado cuando no hay API disponible (ej. ciertos reportes financieros de Booking).
Software central del hotel donde se gestionan reservas, check-ins, check-outs, facturación, housekeeping, asignación de habitaciones y datos del huésped. Es el "cerebro operativo" del hotel.
Todo el día a día del hotel pasa por el PMS: reservas que entran de OTAs, asignaciones de habitación, partes de viajeros, cargos en cuenta, cierre del día (night audit). Los principales en España son Mews, Cloudbeds, Opera (Oracle), Tesipro, Sihot, Noovy, Protel.
Cambiar de PMS es una decisión estratégica grande. Implica formación, migración de datos y reconfiguración de todas las integraciones.
Construimos integraciones con cualquier PMS vía API (Mews, Cloudbeds), webhook (Cloudbeds, Mews) o conectores específicos cuando el PMS es legacy.
Proceso de registro de entrada del huésped en el hotel. Implica identificación, asignación de habitación, entrega de llave, cobro de garantías y cumplimiento legal (parte de viajeros).
Hora estándar de check-in en España: 14:00-15:00. Puede hacerse en mostrador, mediante kioskos o vía online (online check-in). Se generan datos para SES.HOSPEDAJES.
El check-in es el primer punto de contacto físico. Su agilidad impacta directamente en satisfacción y reviews.
Automatizamos el envío de online check-in al cliente días antes de la llegada, recogemos datos legales y los enviamos a SES.HOSPEDAJES, integrándolo con el PMS.
Proceso de salida del huésped: revisión de cargos, facturación final, devolución de llave, validación de daños. Hora estándar en España: 11:00-12:00.
Cierra el ciclo de la estancia. Genera la factura definitiva. Tras check-out, la habitación pasa a estado "dirty" para housekeeping.
El check-out express o automático evita colas. Es un punto crítico para upselling de late check-out o de servicios pendientes.
Automatizamos email post-check-out con factura, encuesta NPS y enlace a reviews, sincronizado con la salida real registrada en el PMS.
Entrada anticipada respecto a la hora estándar. Suele ofrecerse como cortesía si la habitación está disponible o como upgrade de pago.
Si la habitación ya está limpia, se permite el acceso antes (típicamente desde las 11:00). Si no, se ofrece guardar maletas y esperar.
Es un beneficio típico de programas de fidelización o de reserva directa. Puede tarificarse (15-50 €).
Cruzamos hora prevista de llegada con estado de housekeeping en tiempo real para ofrecer early check-in automatizado a clientes elegibles.
Salida posterior a la hora estándar. Se ofrece como cortesía, beneficio fidelidad o upgrade de pago.
Late check-out hasta las 14:00 suele ser cortesía. Hasta las 18:00 se cobra el 50%. Después, día completo. Depende de ocupación del día siguiente.
Argumento clásico del "Book Direct": late check-out garantizado al reservar en directo.
Disparamos ofertas automáticas de late check-out en función de la ocupación de la noche siguiente, monetizando inventario que estaría parado.
Reserva confirmada en la que el huésped no se presenta y no avisa. Genera un cargo (típicamente la primera noche o el total) según la política de cancelación.
Tras el no-show, se carga la tarjeta de garantía. La habitación queda libre desde el primer día. Es un dato clave para calcular overbooking.
En España no es habitual cancelaciones gratuitas en última hora; los no-shows están en el 2-5% típico. Bookings con tarjeta no validada generan más no-shows.
Automatizamos el cobro de no-shows cuando son detectados en night audit, generamos factura y disparamos comunicación al huésped.
Cliente que llega al hotel sin reserva previa y solicita habitación en el momento. Se le aplica habitualmente la rack rate o una tarifa walk-in específica.
Aporta margen alto (sin comisión) pero impredecible. Su volumen depende de la ubicación (hoteles cerca de aeropuertos, estaciones).
En urbanos son frecuentes; en vacacionales casi inexistentes. Permiten "cerrar agujeros" de última hora.
Reportamos producción walk-in dentro del análisis de channel mix y aportamos pricing dinámico para walk-ins basado en ocupación residual.
Uso de la habitación por horas durante el día sin pernocta. Habitual en hoteles de aeropuertos, estaciones o urbanos para tránsito.
Tarifa típica: 30-50% de la BAR completa. Permite generar ingresos sin "consumir" inventario noche.
Hoteles de aeropuerto (Madrid Barajas, Barcelona-El Prat) lo monetizan con plataformas tipo Dayuse.com.
Conectamos plataformas day use con el PMS para evitar conflictos con reservas pernocta.
Huésped que se queda más noches de las reservadas, ocupando la habitación más allá de la fecha de check-out prevista.
Puede ser autorizado (extensión de estancia) o no autorizado (genera incidencia). Impacta directamente en housekeeping y en la siguiente reserva.
Un overstay no detectado puede generar overbooking real cuando entra el siguiente huésped. Es objeto del night audit.
Alertamos automáticamente de overstays detectados al pasar de las 12:00 sin check-out, notificando a recepción y a housekeeping.
Huésped que abandona el hotel antes de la fecha de check-out prevista. La estancia es más corta de lo reservado.
Suele cobrarse el total reservado salvo política especial. Libera inventario inesperado que puede revenderse.
En tour operación es común que se cobre todo. En reservas directas con tarifa flexible se prorratea.
Detectamos understays en tiempo real para reabrir inventario en canales y intentar revender la noche liberada.
Huésped que abandona el hotel sin pagar la cuenta. Es una incidencia operativa y económica.
Puede deberse a fraude o a malentendido. Se mitiga con preautorización de tarjeta a la entrada.
Recepción debe seguir protocolos para evitar skippers (preautorización, control de salidas).
Disparamos alertas si una cuenta no se ha cerrado al detectar salida del huésped (devolución de llave, etc.).
Huésped que continúa alojado en la misma habitación una noche más. La habitación no entra ni sale, solo recibe servicio de housekeeping intermedio.
Es el estado más común durante una estancia de varias noches. La limpieza es más ligera (turn-down, reposición).
Es una clasificación operativa de housekeeping. "Hoy tenemos 40 stayovers, 15 due-outs y 20 due-ins".
Calculamos automáticamente la carga de housekeeping según mix stayover/due-out/due-in para optimizar plantilla.
Habitación con check-out previsto para hoy. Tras la salida del huésped, la habitación pasa a estado "dirty" hasta que housekeeping la limpie a fondo.
Es información clave para housekeeping y recepción. Las habitaciones due-out tras salida tienen prioridad si hay due-in para la misma noche.
El reporte de due-outs sale del PMS cada mañana. Es la base del orden de limpieza.
Generamos automáticamente la asignación óptima de limpiezas según due-outs, prioridades de check-in y plantilla disponible.
Habitación con check-in previsto para hoy. Debe estar inspeccionada y lista antes de la hora de llegada del huésped.
Determina el ritmo del día de housekeeping. Si hay 50 due-ins, 50 habitaciones tienen que estar listas para esa tarde.
El control de "habitaciones listas vs due-ins" es métrica diaria de la gobernanta.
Cruzamos due-ins con horarios reales de llegada (de online check-in) para priorizar limpieza por orden de llegada esperada.
Clasificación operativa de cada habitación según su estado: ocupada, vacía limpia, vacía sucia, fuera de servicio, etc. Se gestiona en el PMS y en el módulo de housekeeping.
Permite a recepción saber qué habitaciones puede asignar inmediatamente. Es información crítica en horas pico de check-in.
Estados típicos: Vacant Clean (VC), Vacant Dirty (VD), Occupied Clean (OC), Occupied Dirty (OD), Inspected (I), Out of Order (OOO), Out of Service (OOS).
Sincronizamos room status entre el PMS y apps móviles de housekeeping para que las camareras actualicen estados desde su móvil sin pasar por recepción.
Estados específicos de housekeeping. **Dirty:** habitación pendiente de limpieza. **Clean:** limpia, lista para inspección. **Inspected:** revisada por gobernanta, lista para entregar. **Out of Order (OOO):** fuera de servicio por avería que impide venderla (no entra en disponibilidad). **Out of Service (OOS):** fuera de servicio temporal (incidencia menor que sí entra en inventario).
OOO se descuenta del inventario disponible, OOS no. Diferenciarlos bien afecta a cálculo de RevPAR y disponibilidad real.
Una habitación con avería de aire acondicionado en agosto: OOO. Una habitación con bombilla fundida: OOS.
Conectamos partes de mantenimiento con cambios automáticos de estado (OOO/OOS) y avisamos cuando una OOO se prolonga demasiado.
Departamento responsable de la limpieza, mantenimiento de habitaciones y zonas comunes. Liderado por la gobernanta (housekeeper).
Trabaja con cuadrante diario asignando habitaciones por camarera. Se mide por habitaciones/turno (típico: 14-18 habitaciones por camarera y turno).
Es el departamento con más plantilla en hoteles vacacionales. La productividad de housekeeping impacta directamente en rentabilidad.
Digitalizamos el cuadrante de housekeeping, automatizando la asignación de habitaciones según ocupación, due-outs y bloqueos, conectando con apps móviles para las camareras.
Servicio de noche en el que la camarera prepara la habitación para el descanso: retira colcha, deja amenities de noche, ajusta luces y cortinas. Habitual en 5 estrellas.
Se realiza entre 18:00 y 21:00. Refuerza la sensación de servicio premium. No se hace si el huésped tiene DND.
Diferenciador en hoteles de alta gama (Ritz, Mandarin Oriental, Four Seasons).
Coordinamos turn-down con preferencias del huésped (registradas en CRM) y con su DND status detectado vía sensor o app.
Indicación del huésped, mediante cartel físico o sistema digital, de que no quiere ser molestado. Implica saltar la limpieza y servicios programados.
Recepción y housekeeping respetan el DND. Si se prolonga >24h, suele activarse protocolo de seguridad (verificación bienestar).
Hoteles modernos lo gestionan vía app móvil del huésped o sensores en puerta.
Conectamos sensores DND y apps del huésped con el sistema de housekeeping para que no se asigne la habitación si está activo.
Clasificación de habitaciones por características: Single, Double, Twin, Triple, Suite, Junior Suite, Family, Connecting. Es la base del inventario.
Cada tipo tiene tarifa propia, capacidad y atributos. Las restricciones de venta (stop sale, MinLOS) se aplican por tipología.
Mezclar tipologías (room category) genera flexibilidad pero complica yield. Hoteles boutique con muchas tipologías son más complejos de gestionar.
Optimizamos asignaciones automáticas por tipología y detectamos oportunidades de upgrade entre tipos similares.
Subdivisión dentro de una tipología por atributos comerciales: Standard, Superior, Deluxe, Premium, Vista Mar, Vista Piscina, Planta alta, etc.
Permite escalar pricing dentro de la misma tipología (Doble Standard 100 €, Doble Vista Mar 130 €). Es la base del upselling.
Una mala definición de categorías deja dinero sobre la mesa. Hoteles vacacionales suelen tener 5-8 categorías.
Construimos automatismos de upselling pre-llegada ofreciendo upgrade a categoría superior con precio dinámico según ocupación.
Habitaciones contiguas conectadas por puerta interior, permitiendo combinarlas para familias o grupos. Se venden como unidad o por separado.
Suelen tener tarifa especial cuando se reservan juntas. Limitan flexibilidad de yield (no puedes vender solo una si la otra ya está vendida y comparten puerta).
Muy demandadas por familias. Hoteles familiares las promueven en su web directa.
Gestionamos lógica de bloqueo automático: cuando se vende una interconnecting individual, marcamos la otra como "puerta sellada".
Asignación al huésped de una habitación de categoría superior a la que reservó, sin coste adicional. Se hace por cortesía, fidelidad o disponibilidad.
Buena práctica si la categoría reservada está sobrevendida o como detalle a clientes VIP/leyales. Genera satisfacción y reseñas positivas.
Programas de loyalty (Marriott Bonvoy, Iberostar Horizons) garantizan upgrade según disponibilidad.
Automatizamos sugerencia de upgrade tanto gratuito (a clientes VIP) como de pago (vía email pre-llegada con precio dinámico).
Asignación al huésped de una habitación de categoría inferior a la reservada. Se evita y, si ocurre, debe compensarse económicamente.
Resultado típico de overbooking en categoría alta. Genera reclamaciones y debe gestionarse con compensación (descuento, amenity, refund parcial).
Es una incidencia que afecta a reputación. Se reporta como "downgrade incidents" en algunas cadenas.
Reportamos automáticamente downgrades detectados y disparamos workflow de compensación al cliente.
Técnica comercial de ofrecer al cliente una versión superior del producto reservado a cambio de un precio adicional. En hotel: upgrade de categoría, late check-out, parking, desayuno premium.
Se realiza pre-llegada (email, motor de upselling tipo Oaky, Nuevohotel) o en check-in. ROI alto, conversión típica 8-15%.
Genera ingreso accesorio sin coste de adquisición. Cadenas como Iberostar y Meliá tienen procesos sistemáticos de upselling.
Construimos motor de upselling pre-llegada propio o conectamos con Oaky/Nuevohotel, automatizando emails segmentados con precio dinámico.
Técnica comercial de ofrecer productos complementarios a la habitación: spa, restaurantes, excursiones, parking, transfer.
Mismo canal que upselling pero ofreciendo otros departamentos. Multiplica TRevPAR.
Resort vacacional es donde más oportunidad hay (cenas temáticas, spa, kids club premium).
Conectamos histórico de gasto del huésped con CRM para personalizar ofertas de cross-selling automáticas pre-llegada y durante la estancia.
Visión gráfica del inventario de habitaciones a lo largo del tiempo (calendario de habitaciones). Muestra qué habitaciones están ocupadas, libres, bloqueadas, etc.
Es la vista clásica del PMS para asignación. Muestra cada habitación en filas y los días en columnas, con colores según estado.
Recepción asigna habitaciones desde el rack. Es la "pantalla principal" del front office.
Generamos vistas de rack consolidadas para multipropiedad cuando hay varios PMS, vía dashboards web.
Cuenta abierta en el PMS donde se registran todos los cargos de la estancia: alojamiento, F&B, minibar, lavandería, spa, extras. Se cierra al check-out con la factura.
Cada huésped tiene su folio. Cargos se transfieren automáticamente desde POS, spa, minibar (PMS-POS integration). El folio se concilia en night audit.
Errores de cargos en folio generan reclamaciones en check-out. La integración POS-PMS reduce errores manuales.
Conciliamos folios automáticamente cruzando datos del PMS con POS de F&B y spa, detectando cargos faltantes o duplicados.
Cuenta de cliente con crédito (empresa, agencia, tour operador) a la que se cargan estancias para facturación posterior. No se cobra al huésped al check-out.
Empresas con convenio: el huésped firma al salir y la factura va a la empresa. Tour operadores con allotment: la operación va a city ledger del operador.
Requiere control financiero estricto. Plazos de cobro a 30-60 días. Es donde se acumula riesgo de impago.
Automatizamos seguimiento de city ledger, conciliación de pagos y disparamos avisos automáticos de facturas vencidas.
Reserva pagada anticipadamente, total o parcialmente, antes de la llegada. Habitual en tarifas no reembolsables y reservas de OTA modelo merchant.
Garantiza ingreso, reduce riesgo de no-show. En España es habitual en alta temporada y eventos especiales.
Tarifas prepago suelen tener 10-15% de descuento sobre flexible. No reembolsables aún más.
Cobramos prepagos automáticamente al confirmar la reserva, generamos factura proforma y enviamos al cliente.
Pago realizado después del check-out, típicamente vía city ledger a empresa o agencia. Contrario al prepaid.
Habitual en corporate y tour operación. Riesgo de impago controlado por contrato y línea de crédito.
Empresas con convenio anual pagan a 30-60 días. Tour operadores grandes negocian condiciones específicas.
Generamos facturas y remesas automáticas a empresas, integradas con software contable y banco.
Proceso contable y operativo que cierra el día hotelero y prepara el siguiente. Concilia ingresos, posiciona cargos automáticos (rooming charge), genera reportes.
Se realiza típicamente entre las 02:00 y 04:00. Genera reportes de ocupación, ingresos, segmentación, no-shows. Marca el cambio de fecha hotelera.
Es realizado por el "night auditor" (recepcionista de noche con perfil contable). En PMS modernos es semiautomático.
Distribuimos automáticamente los reportes de night audit por email a dirección, revenue y propiedad nada más finalizar el cierre.
Sinónimo de night audit en algunos PMS. Marca el cierre de la jornada operativa y la consolidación contable.
Tras el EOD, los reportes son inmutables. La fecha hotelera se incrementa.
El EOD genera "el dato oficial" del día. Cualquier consulta posterior usa los datos cerrados.
Disparamos workflows tras EOD: backup de datos, envío a BI, alertas de KPIs, conciliación bancaria.
Departamento responsable de toda la oferta gastronómica del hotel: restaurantes, bares, room service, banquetes, eventos, minibar.
En hoteles vacacionales puede representar 40-60% del ingreso total. En urbanos solo desayunos puede ser 10-15%. Liderado por el F&B Manager.
Los hoteles all-inclusive viven del F&B. Los hoteles boutique con restaurante de chef diferenciador también.
Conectamos POS de F&B (Ágora, Gestionalia, Lightspeed) con PMS y BI, automatizando reportes de RevPASH, COGS y rentabilidad por punto de venta.
Sistema software/hardware donde se registran las ventas en restaurantes, bares y puntos de F&B. Los principales en España son Ágora (TPV Ágora), Gestionalia, Lightspeed, Revo, Glop.
Camareros toman comanda, envían a cocina/barra y cierran ticket. Datos viajan al PMS si está integrado, o se cargan manualmente al folio.
Integración POS-PMS evita errores manuales y agiliza check-out. Es una de las primeras integraciones que pide cualquier director.
Si la integración nativa POS-PMS no existe o es defectuosa, construimos puente vía n8n leyendo APIs/exportaciones del POS y empujando cargos al PMS.
Cliente que consume en un punto de F&B. Métrica de afluencia: covers por servicio (comida/cena), covers por día.
Permite medir productividad del restaurante: covers por camarero, ticket medio por cover, RevPASH.
Director de F&B revisa diariamente covers vs forecast, especialmente en hoteles con restaurante abierto a externos.
Reportamos covers en tiempo real desde el POS, comparamos con forecast y avisamos de desviaciones.
Importe medio gastado por cover en el restaurante. Se calcula como ingreso total / covers.
Indicador clave de la calidad de venta del equipo de sala. Se mide por servicio y por restaurante.
El ticket medio en restaurante hotel suele ser superior al externo por la mayor capacidad de gasto del huésped y los menús sugeridos.
Comparamos ticket medio por camarero, día, restaurante y disparamos formación o ajustes operativos al detectar bajadas.
Ingreso por silla disponible y hora de servicio en restaurantes. Es el equivalente de RevPAR aplicado a F&B.
Mide eficiencia real del restaurante. Combina rotación (turnos de mesa), ticket medio y ocupación.
Restaurantes de alta gama con pocas mesas pero alto ticket pueden tener mejor RevPASH que cantinas con mucha rotación.
Calculamos RevPASH automáticamente cruzando datos del POS y de table management para optimizar turnos y precios.
Régimen donde la tarifa cubre alojamiento, todas las comidas, snacks y bebidas (incluso alcohólicas) en los puntos del hotel. Hay variantes: AI, Premium All Inclusive, Ultra All Inclusive.
Simplifica la experiencia y permite previsibilidad de presupuesto al cliente. Para el hotel exige control estricto de costes y consumos.
Modelo dominante en Canarias, Caribe, Turquía, Egipto. Cadenas españolas como Iberostar, RIU, Barceló son referentes.
Controlamos consumos All Inclusive en POS por huésped, detectando consumos anómalos y midiendo COGS por estancia.
Régimen que incluye alojamiento, desayuno y una comida principal (cena habitualmente). Las bebidas suelen no estar incluidas.
Régimen tradicional en hoteles de costa. Más sencillo de gestionar que AI pero menos atractivo comercialmente hoy.
Aún muy presente en touroperación tradicional. Coexiste con AI en muchos hoteles.
Controlamos asistencias a comida/cena por huésped, evitando comidas no consumidas y permitiendo upsells a AI.
Régimen que incluye alojamiento, desayuno, comida y cena. Habitualmente sin bebidas.
Habitual en hoteles de salud, balnearios, montaña, congresos. Menos común que media pensión en costa.
Muy demandado en grupos senior, congresos cerrados y residencias temporales.
Mismo control de asistencias y upsells que en HB, con dashboards de ocupación de servicios.
Régimen que incluye alojamiento y desayuno. Es el régimen más habitual en hotelería urbana europea.
Permite al hotel monetizar al menos el desayuno (sale rentable comparado con coste). Cliente puede comer/cenar fuera del hotel.
Estándar en hoteles urbanos españoles. El precio del desayuno suele ser 15-25 €.
Disparamos upsells automáticos para añadir desayuno post-reserva, e identificamos huéspedes "solo room" para cross-sell.
Servicio de F&B llevado directamente a la habitación del huésped. Incluye desayunos, snacks, comidas y bebidas.
Pedido vía teléfono, app, QR o tablet. Suplemento típico 10-25% sobre carta. Crítica eficiencia logística.
Diferenciador en hoteles 5*. Resort vacacional lo limita por viabilidad operativa. Crece la modalidad QR/app.
Implementamos pedidos por QR/Whatsapp con integración directa al POS y aviso a cocina.
Término francés que define la preparación previa al servicio en cocina y sala: ingredientes cortados, mesas montadas, productos listos. Literalmente "puesta en marcha".
Buena mise en place reduce tiempos de servicio y errores. Es el ritual previo al servicio.
Concepto cultural, no se automatiza, pero sí se planifica con datos de forecast de covers.
Aportamos forecasts precisos de covers para que cocina y sala dimensionen mise en place sin sobre/infraestimar.
Coste de las materias primas consumidas para generar las ventas de F&B. Es el principal coste variable del departamento.
COGS objetivo en restauración hotelera: 25-32% sobre ingresos en comida; 18-25% en bebidas. Se controla con escandallos y conteos de stock.
Un COGS desviado 5 puntos en un hotel de tamaño medio puede destruir 100.000 €/año.
Conectamos albaranes de proveedores, escandallos del POS y conteos de stock para calcular COGS real diario, no estimado.
Análisis de cada plato del menú según su popularidad (cuánto se vende) y rentabilidad (margen). Clasifica platos en Estrellas, Vacas, Puzzles y Perros.
Estrellas (alta venta, alto margen): destacar. Vacas (alta venta, bajo margen): subir precio o reducir coste. Puzzles (baja venta, alto margen): promocionar. Perros (baja venta, bajo margen): retirar.
Es la palanca clave para optimizar GOPPAR de F&B.
Analizamos automáticamente datos del POS y escandallos para clasificar platos y proponer cambios de carta.
Software que gestiona reservas de mesa, asignación, rotación y comunicación con cocina. Los principales son TheFork Manager, Cover Manager, ResDiary, OpenTable.
Permite optimizar ocupación del restaurante, ajustar duración estimada por mesa y vincular reservas a huéspedes hotel.
Esencial en restaurantes con alta demanda. Reduce no-shows con políticas de garantía/penalización.
Conectamos table management con CRM y PMS para identificar huésped del hotel vs externo y personalizar el servicio.
Software de TPV (POS) muy extendido en hostelería española de hotel y restauración. Permite gestión de comandas, escandallos, stocks y reporting.
Estándar de facto en muchos hoteles independientes españoles, especialmente en costa. Tiene módulos específicos para hostelería hotelera.
Cuando un cliente dice "uso Ágora", suele referirse a este TPV o al equivalente "Ágora Plus".
Tenemos integraciones específicas con Ágora vía API o exportaciones para automatizar reporting de F&B y conciliación con PMS.
Otro POS hotelero/hostelero muy común en España, con módulos para restauración, bares, eventos y banquetes.
Competencia directa de Ágora, con clientela similar (hoteles independientes, cadenas medianas).
Decisión "Ágora vs Gestionalia" depende del proveedor histórico y cercanía soporte técnico.
Conectores específicos disponibles. Trabajamos con ambos indistintamente.
Jornada laboral dividida en dos bloques con un descanso intermedio (típicamente 2-4 horas). Habitual en restauración (servicio comida y servicio cena).
Permite cubrir picos de servicio sin contratar más gente. Está regulado por el convenio: el descanso intermedio no se computa como tiempo trabajado salvo excepciones.
Es objeto de tensión laboral. Se busca eliminar en convenios modernos por calidad de vida del trabajador.
Optimizamos cuadrantes para minimizar turnos partidos cuando sea posible, conectando con Skello.
Jornada continuada sin interrupción intermedia, con descanso solo para comida (15-30 min computables o no según convenio).
Más cómodo para el trabajador. Habitual en recepción y housekeeping. En restauración solo en hoteles que organizan turnos rotativos.
Es el modelo preferido por trabajadores. Compatible con servicios continuos (recepción 24h en turnos de 8h).
Generamos cuadrantes optimizados que maximizan turnos seguidos cuando la operativa lo permite.
Planificación visual de turnos que asigna a cada empleado sus días y horarios de trabajo durante un periodo (semanal, quincenal, mensual).
Lo elabora el responsable del departamento. Debe respetar convenio (descansos, festivos, jornada máxima). Se publica con antelación al equipo.
Hay cuadrante de recepción, housekeeping, F&B, mantenimiento. Coordinarlos es complejo, especialmente en hoteles 24h.
Automatizamos generación de cuadrantes según forecast de ocupación, conectando con Skello, y enviamos avisos automáticos a empleados.
Software SaaS de gestión de turnos y planificación de personal muy usado en hostelería y hotelería. Permite cuadrantes, fichajes, vacaciones y comunicación.
Empleados ven sus turnos en app, fichan vía móvil, solicitan cambios. Manager aprueba, monitoriza horas extra y costes laborales.
Especialmente popular en cadenas medianas y restauración hotelera. Compite con Bizneo, Sesame HR, Factorial.
Integramos Skello con PMS para que los cuadrantes se ajusten automáticamente a la ocupación prevista, y con la nómina.
Documento o sistema que recoge la planificación detallada de turnos del personal, con horarios, descansos, vacaciones y festivos.
Es la versión más estructurada del cuadrante. Incluye lógica de rotaciones (mañanas-tardes-noches) y compensaciones.
En hoteles grandes lo gestiona el área de RRHH con software específico.
Generamos planning automatizado integrado con previsión de demanda y condiciones de convenio.
Acuerdo laboral sectorial que regula condiciones de trabajo en hoteles y hostelería: salarios mínimos, jornada, descansos, complementos, vacaciones, antigüedad.
En España hay convenios provinciales (Madrid, Baleares, Canarias, etc.) que se actualizan periódicamente. Es de obligado cumplimiento.
Cualquier cambio de horarios o salarios debe respetar el convenio aplicable. Las inspecciones de trabajo verifican cumplimiento.
Programamos validaciones automáticas en cuadrantes que detecten incumplimientos potenciales (jornada excedida, descansos insuficientes).
Complemento salarial obligatorio por trabajar en horario nocturno (habitualmente 22:00-06:00). Cantidad fijada por convenio.
Suma sobre el salario base las horas nocturnas trabajadas. Suele ser 25% sobre salario por hora nocturna en hostelería.
Recepción de noche, mantenimiento de noche, security, restauración con cierre tardío.
Cálculo automático de plus de nocturnidad mensual integrado con cuadrante real (no solo planificado) y con la gestoría.
Horas trabajadas por encima de la jornada ordinaria pactada. Pueden compensarse con descanso o pagarse con suplemento.
Limitadas por ley a 80 horas/año por trabajador. Deben registrarse y comunicarse a la inspección de trabajo (registro horario).
En picos de temporada se acumulan rápidamente. Mal control genera sanciones.
Detectamos y reportamos horas extra automáticamente desde sistema de fichaje, alertando antes de exceder topes legales.
Empresa externa que gestiona nóminas, contrataciones, despidos, finiquitos y obligaciones laborales/fiscales del hotel.
Recibe mensualmente datos de horas trabajadas, variables, altas/bajas y devuelve nóminas, TC1/TC2 y modelos fiscales. Coste típico: 15-30 €/empleado/mes.
Casi todos los hoteles independientes externalizan a gestoría. Cadenas grandes tienen RRHH propio.
Automatizamos el envío mensual de datos de fichaje y nómina a la gestoría en formato compatible (Excel estructurado o API si la gestoría tiene).
Documento mensual que detalla las cotizaciones de cada trabajador a la Seguridad Social. Sustituido en gran medida por el sistema RED Directo / SILTRA, pero el término sigue usándose coloquialmente.
Lo presenta la gestoría a la Seguridad Social. Recoge bases de cotización, días trabajados, contingencias.
Documento de auditoría laboral. Inspección puede pedirlo.
Automatizamos generación de inputs para gestoría con datos de fichaje, evitando errores manuales.
Declaración trimestral de retenciones e ingresos a cuenta del IRPF de los trabajadores y profesionales. Lo presenta la gestoría a Hacienda.
Recoge las retenciones practicadas en nóminas y facturas de profesionales. Plazos: 1-20 abril, julio, octubre, enero.
Obligación trimestral. Errores generan recargos y sanciones.
Recopilamos automáticamente datos de retenciones de nóminas y proveedores para preparar el modelo trimestral.
Documento que recoge la liquidación final tras la baja de un trabajador. Incluye salario pendiente, vacaciones no disfrutadas, parte proporcional pagas extra y, si aplica, indemnización.
Se firma en el momento de la baja. Es práctica recomendada hacerlo con asesoramiento jurídico para evitar reclamaciones futuras.
Alta rotación de personal en hostelería genera finiquitos constantes.
Calculamos importes de finiquitos a partir de datos de fichaje y contrato, integrando con gestoría.
Mecanismo legal por el que la empresa suspende temporalmente contratos o reduce jornadas por causas económicas, técnicas, organizativas o productivas, o por fuerza mayor.
Trabajador cobra prestación SEPE, empresa ahorra costes laborales temporalmente. Habitual en hoteles estacionales fuera de temporada.
Pandemia COVID disparó ERTEs en hotelería. Hoteles vacacionales de invierno los usan recurrentemente.
Gestionamos comunicaciones masivas a trabajadores afectados y digitalizamos documentación.
Plataforma del Ministerio del Interior español (operativa desde 2024) para el envío obligatorio de datos de viajeros que se hospedan en cualquier alojamiento turístico (hoteles, VUTs, campings, etc.). Sustituye/complementa el sistema antiguo de partes de viajeros.
El alojamiento debe enviar antes de 24h tras la entrada los datos de cada huésped (nombre, DNI/pasaporte, fecha nacimiento, dirección, etc.) más datos de pago. Tiene API SOAP/REST oficial.
Es obligación legal con sanciones (hasta 30.000 €). Generó polémica por la carga administrativa adicional.
Integramos SES.HOSPEDAJES directamente con el PMS, automatizando el envío sin intervención manual y generando logs de auditoría.
Documento histórico que los hoteles debían rellenar y enviar a la Guardia Civil/Policía Nacional con datos de cada huésped. Reemplazado por SES.HOSPEDAJES en gran medida.
Históricamente se enviaba en papel o vía Hospederías Web. Hoy se envía digitalmente vía SES.HOSPEDAJES.
Sigue siendo el término coloquial usado por recepcionistas españoles para referirse al envío legal de datos.
Automatizamos el "parte" en su nueva forma electrónica vía SES.HOSPEDAJES.
Libro o sistema (hoy digital) donde se registran todos los huéspedes alojados, con datos personales y fechas. Obligación legal española.
Se conserva durante un periodo legal (3 años en muchos casos). Puede ser inspeccionado por autoridades.
El PMS genera el registro automáticamente. Antes era un libro físico.
Garantizamos integridad del registro digital con copias de seguridad y cumplimiento RGPD.
Documento oficial obligatorio en hoteles españoles donde los clientes pueden formalizar quejas. Hay versiones autonómicas. Existe versión digital en algunas comunidades.
El cliente rellena su reclamación en hojas oficiales (3 copias: cliente, hotel, administración). El hotel debe responder en plazo (10-15 días).
Aunque es obligatorio tenerlo disponible, su uso real ha bajado por las reseñas online.
Digitalizamos la gestión de reclamaciones con flujo automatizado de respuesta dentro de plazo legal.
Autorización administrativa que permite operar como alojamiento turístico. Otorgada por la consejería de turismo de la comunidad autónoma correspondiente.
Requiere cumplir requisitos técnicos (m², instalaciones, salidas emergencia) y administrativos. Licencia de hotel difiere de licencia de VUT.
Sin licencia, operar es infracción muy grave. Las VUTs sin licencia son foco de inspección.
Gestionamos vencimientos y renovaciones con alertas automáticas.
Vivienda residencial cedida temporalmente con fines turísticos a cambio de precio. Está regulada por las CCAA: Cataluña, Baleares, Madrid, Andalucía tienen normativas estrictas.
Requiere licencia específica diferente a hotel. Limitada en zonas saturadas (centro Barcelona, Palma, Madrid). Compite con hotelería tradicional vía Airbnb, Booking.
Tema políticamente sensible. Cadenas hoteleras presionan por mayor regulación.
Para gestores de VUTs construimos automatizaciones similares a hotel: PMS para VUT, sincronización Airbnb-Booking, SES.HOSPEDAJES.
Clasificación oficial del hotel por estrellas (1-5 estrellas) o categorías especiales (gran lujo). Otorgada por la administración turística autonómica.
Determina obligaciones (m² mínimos, servicios, plantilla, instalaciones). En España hay diferencias por CCAA: Andalucía, Baleares, Canarias, Madrid, Cataluña tienen criterios distintos.
Subir de categoría requiere reformas e inversión, pero permite cobrar más y posicionarse distinto.
Mantenemos documentación digital de cumplimiento de requisitos categoriales con alertas de revisiones.
Visita oficial de inspectores autonómicos para verificar cumplimiento normativo (categoría, libro reclamaciones, registro viajeros, accesibilidad, etc.).
Pueden ser programadas o sorpresa. Sanciones desde apercibimiento hasta cierre del establecimiento.
Más frecuentes en zonas de turismo masivo. La preparación documental es crítica.
Mantenemos un "expediente digital de cumplimiento" siempre listo para inspección.
Reglamento General de Protección de Datos (UE) y Ley Orgánica de Protección de Datos (España, LOPDGDD 3/2018) aplicado al tratamiento de datos personales de huéspedes, empleados y proveedores.
Obliga a registrar tratamientos, tener bases jurídicas, informar a interesados, gestionar derechos (acceso, rectificación, supresión), nombrar DPO si aplica, notificar brechas en 72h.
Hoteles tratan datos especialmente sensibles (DNI, pasaporte, biometría en check-in digital). Cualquier brecha es muy grave.
Diseñamos automatizaciones RGPD-compliant desde diseño: minimización de datos, encriptación, registros de acceso, gestión automática de derechos ARCO.
Manifestación de voluntad libre, específica, informada e inequívoca del huésped autorizando el tratamiento de sus datos personales (marketing, perfilado, etc.).
Debe recogerse de forma granular (no global). Para marketing post-estancia hace falta consentimiento explícito separado del de la reserva.
Habitual recoger consentimiento en check-in digital o en formulario. La AEPD ha sancionado a hoteles por mala gestión.
Integramos recogida de consentimientos en flujos de check-in, mantenemos registro auditable y propagamos retiradas de consentimiento a todos los sistemas.
PMS cloud all-in-one que integra PMS, channel manager y motor de reservas en una plataforma. Origen americano, muy usado en hoteles independientes y small chains.
SaaS por habitación/mes. Incluye conectividad nativa con OTAs principales. Ideal para hoteles 20-150 habitaciones.
Crece rápidamente en España, especialmente boutique y rural. Compite con Mews y Cloudbeds.
Tenemos integraciones avanzadas con Cloudbeds vía su API REST y webhooks. Es uno de los PMS con los que mejor trabajamos.
PMS cloud moderno de origen checo, muy bien valorado por su diseño UX y API potente. Apuesta por automatización, kioskos y experiencia digital.
Modular: PMS + booking engine + channel manager + payments + Mews Marketplace (apps integradas). API REST muy completa.
Hoteles boutique y cadenas medianas modernas (Generator, Oasis, etc.). Crece fuerte en España.
Mews tiene una de las mejores APIs del sector. Construimos integraciones complejas con Mews para automatizar procesos a medida.
PMS líder histórico, propiedad de Oracle. Estándar de facto en grandes cadenas internacionales (Marriott, Hilton, Accor). Versiones: Opera 5 (legacy), Opera Cloud.
Producto enterprise, complejo y caro pero potente. Implantaciones largas (6-12 meses). Conectividad amplia vía OXI/OEDS.
Si el hotel es de cadena internacional grande, casi seguro usa Opera. La migración Opera 5 a Opera Cloud está en curso.
Trabajamos con Opera vía conectores específicos y APIs OXI. Las automatizaciones son más complejas pero el ROI alto.
PMS cloud español/europeo, popular en hoteles independientes pequeños y medianos. Asequible y sencillo.
SaaS con módulos integrados. Conectividad con channel managers principales.
Habitual en hoteles boutique y rurales españoles.
Disponemos de integraciones para Noovy vía API y aportamos automatizaciones que el PMS no cubre nativamente.
PMS español muy implantado en hoteles independientes y cadenas medianas españolas. Cuenta con módulo de POS, channel manager (Tesipro CM) y reportes.
Modelo on-premise tradicional o cloud. Muy arraigado en costa española y hoteles familiares.
Cliente típico: hotel familiar costa con larga trayectoria.
Cuando Tesipro no tiene API moderna, construimos conectores leyendo bases de datos o exportaciones, garantizando datos accesibles.
PMS alemán muy presente en cadenas españolas e hispanas (RIU, Iberostar parcialmente, Sandos). Robusto, orientado a resorts grandes.
Modular, on-premise/cloud. Fuerte en gestión de resorts grandes con miles de habitaciones.
Estándar en cadenas vacacionales españolas. Conectividad a través de su API y módulos propios.
Tenemos experiencia integrando Sihot, especialmente con datos de F&B, spa y eventos.
PMS de origen alemán, ahora propiedad de Planet Hospitality. Implantado en hoteles independientes y cadenas medianas europeas.
Modelo on-premise/cloud. Fortaleza en gestión completa front+back office.
Presente en cadenas españolas medianas. En proceso de modernización por Planet.
Conectividad vía API y SQL para automatizaciones específicas.
PMS+channel manager+motor cloud holandés especializado en hoteles pequeños/medianos europeos. Muy intuitivo.
All-in-one por suscripción. Targeting boutique e independiente.
Crece en España en boutique urbano e hostales de calidad.
API REST disponible para integraciones a medida.
Channel manager líder mundial de origen australiano. Muy implantado globalmente, con conectividad a 450+ canales.
Distribuye tarifas/disponibilidad y centraliza reservas. Tiene también motor de reservas (TheBookingButton).
Channel manager más usado en España junto con D-EDGE.
Integramos SiteMinder vía API para extraer datos consolidados de canales y enviar reglas de pricing automatizadas.
Channel manager económico y flexible muy popular en hoteles pequeños y VUTs. Se diferencia por su precio bajo y configurabilidad.
Permite gestionar múltiples propiedades, conectividad con OTAs principales, scripts personalizados, motor de reservas básico.
Habitual en gestores de VUTs y hoteles muy pequeños.
API muy abierta, ideal para automatizaciones a medida con n8n.
Marca histórica integrada en D-EDGE, channel manager europeo (Francia) ampliamente usado en cadenas y hoteles independientes.
Channel manager + motor + CRS + reputation. Ofrece RMS también. Solución integral francesa.
Muy fuerte en España e Italia, especialmente cadenas medianas.
Integraciones vía API y EDI. Automatizamos sincronización con sistemas externos al ecosistema D-EDGE.
Antiguo Travelclick, ahora Amadeus Hospitality. Suite que incluye CRS, channel manager (iHotelier), business intelligence (Demand360, Rate360).
Solución para cadenas y hoteles GDS-dependientes. Conectividad fuerte con GDS y OTAs.
Hoteles urbanos 4-5 estrellas con cliente corporate.
Trabajamos con datos Demand360 vía exportaciones y APIs.
RMS (Revenue Management System) líder mundial. Algoritmos avanzados de pricing dinámico para hoteles grandes y cadenas.
Conectado al PMS, calcula tarifas óptimas por fecha y canal, considera demanda no restringida, elasticidad y compset. Caro (5.000-50.000 €/año).
Cadenas grandes (Marriott, Hilton, Meliá) lo usan masivamente.
Conectamos outputs de IDeaS con channel manager y dashboards consolidados de revenue.
RMS cloud moderno, californiano. Competencia directa de IDeaS, con UX más moderna y enfoque cloud-first.
Modular: GameChanger (pricing), ScoreBoard (intelligence), BlockBuster (group). Muy adoptado por cadenas modernas.
Cadenas como Generator, Pestana, NH lo usan en parte.
API moderna permite integraciones limpias con BI y otros sistemas.
RMS español, basado en Salamanca. Crecimiento fuerte en hoteles medianos y cadenas españolas/portuguesas. Ahora rebranded como Beonx.
Pricing automatizado, business intelligence, reputation integrada. Foco en mercado europeo.
Opción competitiva para hoteles que no pueden permitirse IDeaS o Duetto.
Integraciones nativas con Beonx muy posibles vía API.
Plataforma de gestión de reputación online y feedback de huéspedes. Centraliza reviews de OTAs, redes sociales, encuestas internas.
Calcula GRI (Global Review Index), permite responder reviews, hace análisis sentiment con IA. Fundada en Barcelona.
Estándar en cadenas medianas y grandes españolas.
Integramos ReviewPro con CRM y disparamos workflows automáticos según sentiment (alertas a dirección, ofertas de recuperación).
Competidor de ReviewPro, alemán. Plataforma de reputación online y CDP (Customer Data Platform) hotelero.
Score, semantic analysis, encuestas, CDP. Muy adoptado en cadenas internacionales.
Alternativa a ReviewPro. Cadenas grandes evalúan ambas.
API disponible, integraciones con BI y CRM.
Herramienta de business intelligence de Google. Looker Studio (antes Google Data Studio) es la versión gratuita más adoptada en hotelería para dashboards.
Conecta múltiples fuentes de datos (Google Sheets, BigQuery, MySQL, APIs) y genera dashboards interactivos compartibles.
Cada vez más hoteles consolidan KPIs en Looker Studio. Es la opción coste cero más versátil.
Construimos pipelines n8n que llenan Google Sheets/BigQuery automáticamente, alimentando Looker Studio en tiempo cuasi-real.
Puntuación numérica que un huésped da al hotel tras la estancia, en una escala (típicamente 1-10 en Booking, 1-5 en TripAdvisor y Google).
Es la métrica más visible. Influye en ranking de OTAs y decisión de compra. Hoteles 4 estrellas españoles bien gestionados están en 8.5-9.2 en Booking.
Una bajada de 0.2 puntos en Booking puede impactar 5-10% en reservas.
Monitorizamos review score en tiempo real, alertando ante bajadas y identificando causas en el análisis textual.
Métrica interna de satisfacción medida por encuestas propias del hotel (post-stay survey). Suele ser más detallada que reviews públicas.
Permite medir aspectos específicos (limpieza, F&B, recepción, etc.) y detectar problemas antes de que aparezcan en reviews públicas.
Cadenas grandes lo usan como KPI interno. Encuestas se integran con CRM.
Automatizamos envío de encuesta post-stay y disparamos alertas a dirección ante puntuaciones bajas, permitiendo recuperar al cliente antes de que escriba review pública.
Métrica de lealtad basada en una pregunta única: "¿Recomendarías este hotel? (0-10)". Promotores (9-10), Pasivos (7-8), Detractores (0-6). NPS = % Promotores - % Detractores.
Indicador robusto y comparable entre sectores. Hoteles excelentes tienen NPS >50; medios 20-40.
Cadenas grandes usan NPS como KPI principal de experiencia.
Calculamos NPS automáticamente desde encuestas y lo integramos en dashboards directivos.
Porcentaje de reviews públicas que el hotel responde. Indicador de engagement con clientes.
Booking, TripAdvisor y Google valoran positivamente alta response rate. Recomendado responder >90% de reviews, especialmente las negativas.
Cadenas grandes tienen equipos dedicados. Hoteles independientes suelen retrasarlo.
Asistimos las respuestas con IA generativa (borrador automático) que el director solo revisa y publica, multiplicando capacidad de respuesta.
Score consolidado creado por ReviewPro (ahora Shiji) que agrega y normaliza reviews de múltiples plataformas en un solo índice 0-100.
Permite comparar reputación independientemente de la plataforma. Hoteles excelentes están en 85+.
Métrica estándar en cadenas que usan ReviewPro/Shiji.
Integramos GRI en dashboards consolidados con KPIs operativos.
Posición del hotel dentro del ranking de hoteles de su ciudad/destino en TripAdvisor. Basado en reviews, recencia y otras señales.
Aparecer en top 10 de una ciudad mediana genera tráfico significativo. Algoritmo no transparente, evoluciona constantemente.
Influye en marketing y en bookings indirectos.
Monitorizamos posición diariamente y alertamos ante caídas sustanciales.
Score específico que Booking calcula para cada hotel, base de su ranking. Influye en visibilidad en la plataforma.
Se basa en reviews de huéspedes recientes (más peso a recientes). Nivel típico hoteles buenos: 8.0-9.2.
El score más mirado por hoteleros españoles dada cuota de Booking.
Monitorizamos Booking score, identificamos drivers de bajadas y disparamos acciones correctivas.
Puntuación 1-5 en Google Business Profile (antes Google My Business), basada en reviews de Google.
Aparece en búsquedas Google, Maps, Google Hotels. Cada vez más relevante por adopción de Google Hotels.
Crítico para tráfico orgánico Google. Buena gestión SEO local + Google Hotels = más reservas directas.
Integramos respuestas a reviews Google, optimización de Google Business Profile y campañas Google Hotels.
Disciplina de gestión integral de la reputación digital del hotel: monitorización de reviews, respuestas, análisis de sentiment, identificación de áreas de mejora.
Implica herramientas (ReviewPro, TrustYou) + procesos + equipo dedicado o externalizado. ROI alto: cada décima en review score impacta en RevPAR.
Cadenas grandes tienen director de ORM. Independientes lo gestiona el director general o se externaliza.
Externalizamos parcialmente ORM con IA: borradores de respuestas, alertas inteligentes, análisis temático automatizado.
Conexión técnica que permite que los cargos de F&B (POS) se trasladen automáticamente al folio del huésped en el PMS. Elimina cargos manuales y errores.
Integración bidireccional vía API o middleware. POS consulta huésped en PMS al cargar (interface de "post charge"). PMS consolida en folio.
Es una integración básica imprescindible. Si falla, recepción tiene que cargar manualmente al check-out.
Cuando la integración nativa no existe o falla, construimos puente vía n8n leyendo APIs del POS y empujando cargos al PMS.
Sinónimo de Yield Management en uso coloquial. "Hacer yield" significa subir/cerrar tarifas dinámicamente.
"Esto es un día de mucho yield" indica fechas de alta demanda donde se está optimizando agresivamente el precio.
Término coloquial entre revenue managers.
Automatizamos reglas de yield basadas en pickup, ocupación y elasticidad histórica.
Reportes mensuales que comparan el rendimiento del hotel con un compset definido (compset). Estándar mundial de benchmarking hotelero.
El hotel envía datos a STR; STR los anonimiza y los devuelve agregados con compset. Genera índices RGI, ARI, MPI.
Hoteles de cadena participan masivamente. Independientes pueden contratar acceso.
Automatizamos envío mensual de datos a STR y generamos dashboards internos con resultados.
Conjunto de hoteles competidores definidos por el propio hotel para comparar su rendimiento. Suele ser 4-6 hoteles similares en categoría, ubicación y tipo de cliente.
Base para comparativas STR, análisis de pricing y posicionamiento. La elección del compset es estratégica.
Director comercial/revenue revisa compset trimestralmente.
Monitorizamos pricing y disponibilidad del compset diariamente y reportamos cambios.
Índice de penetración de ocupación. Compara la ocupación del hotel con la del compset. MPI = (Ocupación hotel / Ocupación compset) x 100.
MPI = 100: cuota justa. MPI > 100: el hotel capta más cuota de demanda. MPI < 100: el hotel está perdiendo cuota.
Indicador de fortaleza comercial y de pricing relativo.
Calculamos MPI desde STR data y dashboards internos.
Índice de generación de ingresos. RGI = (RevPAR hotel / RevPAR compset) x 100. Es el índice más completo del trio (combina ocupación y ADR).
RGI > 100: el hotel genera más ingreso por habitación que el compset. Es el KPI relativo más usado.
Director revenue presenta RGI mensual al consejo.
Calculamos RGI consolidado y lo integramos en dashboards directivos.
Índice de tarifa media. ARI = (ADR hotel / ADR compset) x 100. Mide pricing relativo.
ARI > 100: el hotel cobra más que el compset. Combinado con MPI da imagen completa.
Permite ver si el hotel "regala" margen o si está sobre-precio.
Cálculo automático y comparativa histórica.
Reservas de grupos (>10 habitaciones típicamente) con condiciones contractuales específicas: tarifa de grupo, allotment, condiciones de pago, F&B asociado.
Generan ingresos predictibles pero pueden desplazar reservas individuales (transient) más rentables. Requieren displacement analysis.
Hoteles MICE viven del group business. Hoteles vacacionales también, especialmente off-peak.
Automatizamos cotizaciones de grupos con análisis de displacement integrado.
Segmento de negocio de turismo corporativo basado en reuniones, incentivos, congresos y eventos. Genera ingresos múltiples (alojamiento + salones + F&B).
Hoteles MICE tienen salones grandes, equipamiento técnico, equipo comercial especializado. Madrid, Barcelona y Valencia son top en MICE España.
Hoteles 4-5 estrellas urbanos compiten por MICE. Es uno de los segmentos más rentables.
Construimos motor de cotización de eventos automatizado con cálculo de displacement, F&B mínimo y condiciones contractuales.
Ingresos generados por spa, wellness, tratamientos, fitness, beauty. Componente clave del Total Revenue Management en resorts y urbanos premium.
Suele tener su propio software (booking de tratamientos), POS y operativa. Margen alto si hay buena ocupación.
Resorts canarios y baleares tienen spas grandes (1.500-3.000 m²) con ingresos millonarios.
Conectamos software de spa (Tidal, Book4Time) con PMS y CRM para cross-selling y reporting unificado.
Ingresos no provenientes del alojamiento: F&B, spa, parking, transfers, excursiones, lavandería, minibar, late check-out, upgrades pagados.
Permiten incrementar ingreso medio por huésped sin necesidad de subir ADR. Foco creciente en hotelería moderna.
En resorts puede representar 50-60% del total revenue. En urbanos 15-30%.
Sistematizamos cross-selling y upselling en cada touch-point del huésped (pre-llegada, check-in, estancia, check-out).
Evolución del revenue management tradicional (centrado en habitaciones) hacia la gestión holística de todos los ingresos del hotel: habitaciones + F&B + spa + eventos.
Considera el "lifetime value" del huésped en su estancia, no solo el ADR. Optimiza ofertas combinadas para maximizar TRevPAR y GOPPAR.
Cadenas modernas han evolucionado hacia este paradigma. Requiere datos integrados y herramientas avanzadas.
Construimos data warehouses hoteleros que consolidan datos de todos los puntos de ingreso, base imprescindible del Total Revenue Management.
Conjunto de reglas y protocolos que permite a dos sistemas software comunicarse entre sí. Es el "contrato" mediante el cual una aplicación pide datos o acciones a otra.
Un sistema (cliente) envía una petición (request) a otro sistema (servidor) por un canal definido (típicamente HTTP). El servidor procesa y devuelve una respuesta (response). El formato del intercambio está definido por la documentación de la API.
Casi todos los workflows que construimos utilizan APIs: extraer reservas de Booking.com, enviar partes a SES.HOSPEDAJES, leer datos de Skello, escribir en Google Sheets. n8n tiene cientos de nodos pre-construidos para APIs comunes y un nodo HTTP Request para cualquier API arbitraria.
Estilo arquitectónico para diseñar APIs basado en HTTP. Las REST APIs usan recursos identificados por URLs y operan sobre ellos con verbos HTTP estándar (GET, POST, PUT, PATCH, DELETE).
Cada recurso tiene una URL única (ej. `/reservas/12345`). Las operaciones sobre el recurso se hacen con verbos HTTP. Los datos se intercambian normalmente en JSON. Es el estilo más popular en APIs modernas.
El 95% de las APIs que usamos son REST. Configuramos el nodo HTTP Request indicando método, URL, headers y body. n8n maneja paginación, autenticación y reintentos automáticamente.
Protocolo más antiguo de APIs basado en XML. Es más rígido y verboso que REST, pero se sigue usando en sistemas enterprise legacy.
Las peticiones se envían como sobres XML (envelopes) con estructura predefinida. Suele usar WSDL (Web Services Description Language) para describir la API. Más complejo de manejar.
Cuando un cliente usa sistema legacy con SOAP (común en SES.HOSPEDAJES, Tesipro, Sihot), construimos el sobre XML manualmente en el nodo HTTP Request o usamos community nodes. Es más laborioso pero perfectamente viable.
Lenguaje de consultas para APIs creado por Facebook. Permite al cliente pedir exactamente los datos que necesita en una sola query, evitando over-fetching y under-fetching típicos de REST.
Un único endpoint (`/graphql`) recibe queries con la estructura de datos requerida. El servidor devuelve solo lo pedido. Tiene tipos (schema) estricto.
n8n tiene nodo GraphQL específico. Lo usamos cuando integramos con plataformas modernas que lo ofrecen, ahorrando llamadas y mejorando rendimiento.
URL específica donde una API expone una funcionalidad concreta. Cada endpoint corresponde a una acción o recurso accesible.
Un endpoint se define por una URL (ej. `https://api.cloudbeds.com/api/v1.2/getReservations`) y un método HTTP (GET, POST, etc.). Cada endpoint acepta unos parámetros y devuelve un formato concreto.
Cada nodo HTTP Request apunta a un endpoint. Mantenemos documentación interna de los endpoints más usados de cada PMS y channel manager.
El intercambio fundamental en una API. El cliente envía una request (petición) con datos al servidor; el servidor procesa y devuelve una response (respuesta).
La request incluye método HTTP, URL, headers, opcionalmente body. La response incluye status code, headers y body. Todo viaja por HTTP/HTTPS.
Cada ejecución de un nodo HTTP Request es un par request/response. n8n permite inspeccionar ambos en el editor visual durante el desarrollo.
Verbos estándar de HTTP que indican la acción a realizar sobre un recurso.
**GET** lee/consulta sin modificar. **POST** crea un recurso nuevo. **PUT** reemplaza completamente un recurso existente. **PATCH** modifica parcialmente. **DELETE** elimina.
En el nodo HTTP Request seleccionamos el método. La elección incorrecta es un error frecuente; la documentación de la API indica qué verbo usar para cada endpoint.
Códigos numéricos en la response HTTP que indican el resultado de la petición.
**2xx (éxito):** 200 OK (lectura ok), 201 Created (creación ok). **4xx (error cliente):** 400 Bad Request (petición mal formada), 401 Unauthorized (falta auth), 403 Forbidden (sin permisos), 404 Not Found (no existe), 429 Too Many Requests (rate limiting). **5xx (error servidor):** 500 Internal Server Error (fallo del servidor remoto).
Configuramos error handling según status code: reintentar en 5xx y 429, alertar en 401/403, notificar en 400.
Metadatos enviados en la request o la response, en forma de pares clave-valor. Aportan información sobre el contenido, autenticación, formato esperado, etc.
Headers comunes: `Content-Type` (formato del body, ej. application/json), `Authorization` (credenciales), `Accept` (formato esperado), `User-Agent` (cliente que llama), `X-API-Key` (API key custom).
En el nodo HTTP Request hay sección de Headers donde añadimos los necesarios. Las credentials de n8n suelen inyectar headers automáticamente.
Cuerpo de la petición o respuesta, donde van los datos. En requests POST/PUT/PATCH lleva los datos a enviar; en responses lleva los datos devueltos.
Formato definido por Content-Type. Más común: JSON. También XML, form-data, x-www-form-urlencoded.
En el nodo HTTP Request hay sección Body donde construimos el JSON, a menudo usando expresiones n8n para insertar valores dinámicos.
Formato ligero de intercambio de datos basado en sintaxis JavaScript. Es el formato dominante en APIs modernas. Estructura: objetos `{}`, arrays `[]`, strings, números, booleanos, null.
Datos en pares clave-valor. Anidamiento ilimitado. Texto plano legible.
Todo el flujo de datos en n8n es JSON internamente. Cada item del data flow es un objeto JSON. Lo manipulamos con expresiones, Set node, Code node.
Formato más antiguo de intercambio de datos, basado en etiquetas similares a HTML. Más verboso que JSON pero todavía estándar en sistemas legacy.
Datos envueltos en etiquetas anidadas. Tiene namespaces, atributos, validación con XSD.
Convertimos XML a JSON con el nodo XML de n8n, o construimos XML manualmente con expresiones cuando hay que enviar a sistemas legacy.
Mecanismos para identificar al cliente que llama a la API y verificar que tiene permisos.
**API Key**: clave única en header o query. **Bearer Token**: token (típicamente JWT) en header `Authorization: Bearer xyz`. **OAuth 2.0**: flujo que obtiene access token mediante intercambio (más complejo, soporta refresh). **Basic Auth**: usuario:contraseña codificados en Base64 en header.
n8n tiene "Credentials" donde almacenamos cifradas las credenciales por servicio. El nodo HTTP Request o el nodo específico las inyecta automáticamente. Para OAuth gestiona refresh de tokens.
Límite máximo de peticiones permitidas por unidad de tiempo. Impuesto por el servidor para evitar abuso.
Si el cliente excede el límite, recibe 429 Too Many Requests. El header `Retry-After` o `X-RateLimit-*` indica cuándo reintentar.
Configuramos delays entre llamadas, retry automático con backoff exponencial y monitorizamos tasa de errores 429. Es fundamental para automatizaciones robustas.
Técnica para devolver grandes conjuntos de datos en "páginas" más pequeñas, evitando respuestas masivas. La API devuelve un subconjunto y un puntero a la siguiente página.
Variantes: **Offset/Limit** (`?offset=100&limit=50`), **Page-based** (`?page=3&pageSize=50`), **Cursor-based** (`?cursor=xyz123`). El cliente itera hasta agotar páginas.
El nodo HTTP Request de n8n tiene opción de pagination automática. Si no, construimos loop con Split in Batches o Code node que itera hasta agotar.
Mecanismo "push" en el que un servidor llama a una URL nuestra cuando ocurre un evento, en lugar de que nosotros tengamos que preguntar (polling).
Registramos una URL pública en el servicio remoto. Cuando ocurre el evento (nueva reserva, cancelación), el servicio nos hace POST con los datos del evento.
El "Webhook trigger" de n8n genera una URL pública que registramos en el servicio remoto. Cada vez que llega un evento, dispara el workflow. Es el patrón más eficiente.
Estrategia opuesta al webhook: el cliente pregunta periódicamente al servidor si hay novedades. Es menos eficiente pero compatible con cualquier API.
Cada X minutos hacemos GET para ver si hay datos nuevos. Si no, esperamos al siguiente ciclo.
Schedule trigger ejecuta el workflow cada X minutos. Aceptable cuando no hay webhooks, pero debe optimizarse para no saturar la API ni perder eventos.
Carga útil de datos en una request o response. Sinónimo de body en muchos contextos, especialmente en webhooks donde "payload" es el JSON que llega al webhook.
Es el contenido relevante (no metadatos). Cuanto más limpio el payload, más fácil procesarlo.
Tras un webhook trigger, accedemos al payload con `$json` o `{{$json["campo"]}}`. Es la primera variable del workflow.
URL raíz común a todos los endpoints de una API. A ella se concatenan los paths específicos.
Suele variar entre entornos (production, sandbox). Ejemplo: `https://api.cloudbeds.com/api/v1.2`.
La almacenamos como Environment Variable y la concatenamos en el HTTP Request, facilitando cambios de entorno.
Parámetros enviados en la URL después del `?` en formato `clave=valor` separados por `&`. Habituales en GET requests.
Ejemplo `/reservations?from=2026-05-01&to=2026-05-31&status=confirmed`. Filtran o configuran la respuesta.
En el nodo HTTP Request hay sección "Query Parameters" donde añadimos pares dinámicamente con expresiones.
Parámetros embebidos en la URL como parte del path, típicamente IDs.
Ejemplo `/reservations/{reservationId}`. El ID se sustituye en la URL: `/reservations/12345`.
Construimos la URL con expresiones n8n: `https://api.x.com/reservations/{{$json["id"]}}`.
Datos enviados en el cuerpo de la petición, típicamente en POST/PUT/PATCH. Suele ser JSON.
El cliente serializa los datos y los envía. El servidor los deserializa y los procesa.
En HTTP Request, la sección "Body" donde construimos el JSON con expresiones para insertar valores del workflow.
Datos devueltos por el servidor en la respuesta. JSON en APIs modernas, XML en legacy.
El cliente lo parsea (n8n lo hace automáticamente para JSON) y lo procesa.
Tras HTTP Request, accedemos a la respuesta vía `$json`. Si es array, n8n divide automáticamente en items.
Definición estructural de los datos que acepta o devuelve una API. Define campos, tipos, obligatoriedad, validaciones.
Suele expresarse en JSON Schema u OpenAPI. Permite validar requests/responses programáticamente.
Consultamos schemas para entender APIs nuevas. n8n no valida esquemas automáticamente, pero podemos hacerlo en Code node.
Conjunto de información que explica cómo usar una API: endpoints, parámetros, ejemplos, autenticación, errores.
Suele estar en formato Swagger/OpenAPI, Postman collections, o páginas web (Stripe-style).
Antes de construir cualquier integración, leemos la documentación oficial. Es nuestra primera referencia.
Herramienta de escritorio/web para probar APIs. Permite construir requests, guardarlas en colecciones, automatizar tests.
Configuramos request (método, URL, headers, body), la enviamos y vemos la respuesta. Soporta variables, environments, scripts pre/post-request.
Lo usamos como herramienta de exploración inicial. Una vez validado, replicamos la lógica en n8n.
Especificación estándar para describir APIs REST. Genera documentación interactiva, SDKs, validación automática.
Archivo YAML/JSON describe endpoints, parámetros, schemas. Herramientas como Swagger UI lo convierten en docs navegables.
Si una API tiene OpenAPI, podemos importarla parcialmente y agilizar la integración.
Librería oficial proporcionada por el dueño de la API para facilitar su uso desde un lenguaje específico (Python, JavaScript, etc.).
El SDK abstrae llamadas HTTP en funciones del lenguaje (ej. `cloudbeds.getReservations()` en lugar de construir el HTTP Request manualmente).
En n8n usamos el HTTP Request directo o el nodo dedicado. Cuando hay SDK útil, lo usamos en Code node con `require()` (n8n self-hosted permite paquetes npm).
Entorno de pruebas paralelo a producción donde se puede experimentar sin afectar datos reales. Suele tener su propia URL y credenciales.
Datos ficticios o copia anonimizada. Permite testear integraciones sin riesgo.
Mantenemos credenciales separadas para sandbox y production. Probamos workflows en sandbox antes de promocionarlos a producción.
Conexión técnica entre dos o más sistemas para que compartan datos y funciones. Núcleo de cualquier proyecto de automatización.
Vía APIs, webhooks, archivos compartidos, base de datos común. Cada integración tiene direccionalidad y latencia.
Cada workflow que construimos es una integración. Diseñamos integraciones robustas con retry, error handling y monitoreo.
Sincronización de datos en ambas direcciones entre dos sistemas. Cambios en cualquiera de los dos se reflejan en el otro.
Requiere lógica para evitar bucles (cuando A actualiza B, B no debe re-actualizar A). Suele usar timestamps o flags.
Implementamos two-way con lógica IF que detecta el origen del cambio (vía metadatos o timestamps) y solo propaga si procede.
Datos fluyen solo en una dirección. Sistema A es la "fuente de verdad" y sistema B la copia.
Más simple que two-way. No requiere lógica anti-bucle.
Es el patrón más usado. Schedule trigger lee de origen, transforma, escribe en destino.
Sincronización con latencia mínima (segundos) entre el evento original y su replicación. Se logra con webhooks o streaming.
Cada cambio dispara inmediatamente el flujo de sincronización. Requiere infraestructura siempre activa.
Webhook trigger + workflow optimizado. Latencia típica: 1-3 segundos en n8n self-hosted.
Procesar grandes cantidades de datos agrupados en lotes en momentos puntuales (típicamente nocturnos), no en tiempo real.
Se programa una ejecución periódica (cada hora, cada día). Procesa todos los datos pendientes de una vez.
Schedule trigger + Split in Batches. Útil cuando el volumen es alto y la latencia no es crítica.
Patrón clásico de movimiento de datos: extraer del origen, transformar (limpiar, enriquecer, formatear), cargar en destino.
**Extract**: leer datos crudos. **Transform**: aplicar reglas, mapeos, validaciones. **Load**: escribir en sistema destino (BD, dashboard, etc.).
Cada workflow ETL es un workflow n8n con tres bloques: nodos de extracción, nodos de transformación (Set, Code, IF), nodos de carga.
Definición de correspondencias entre campos de dos sistemas distintos. "El campo X del sistema A equivale al campo Y del sistema B".
Documentado en una tabla. Es la pieza fundamental de cualquier integración.
Implementamos data mapping en Set nodes o Code nodes. Mantenemos documentación en Notion para cada cliente.
Modificación de los datos durante el flujo: cambio de formato, cálculos, agregaciones, normalización.
Aplicamos funciones (concatenación, división, parseo de fechas, etc.) entre extracción y carga.
Set node para mapeos simples. Code node (JavaScript) para lógica compleja. Function node legacy aún se usa.
Versión específica de data mapping centrada en correspondencia de campos individuales.
Ejemplo: campo "checkin" del PMS se llama "arrivalDate" en el channel manager.
Set node configurado con todos los campos a renombrar/reasignar.
Capa de software intermedia que conecta sistemas que no se hablan directamente. n8n es esencialmente middleware.
Recibe datos de un sistema, los transforma y los envía a otro. Puede orquestar múltiples sistemas a la vez.
n8n es nuestro middleware preferido. Versátil, observable, autogestionable.
Plataformas cloud para construir integraciones sin código. Ejemplos: Make (antes Integromat), Zapier, n8n cloud, Workato, MuleSoft.
Editor visual para diseñar workflows. Conectores predefinidos. Hosting gestionado.
n8n es un iPaaS. Lo elegimos sobre alternativas porque permite self-hosted, código JavaScript completo y comunidad open source.
Módulo pre-construido que encapsula la integración con un servicio específico (API + autenticación + acciones comunes).
El usuario solo configura credenciales y selecciona acciones; el connector gestiona la complejidad técnica.
Usamos connectores nativos cuando existen. Construimos "connectores custom" en HTTP Request + Set para servicios sin connector.
Conexión con sistemas antiguos que no tienen APIs modernas. Más complejo: requiere acceso a base de datos, lectura de archivos, scraping, etc.
Estrategias: leer base de datos directamente, parsear archivos exportados (CSV, XLS, XML), scraping web autorizado, RPA.
Combinamos n8n con scripts a medida cuando el legacy lo requiere. Nunca decimos "no se puede integrar" sin explorar todas las vías.
Capa de software que envuelve una API para añadir funcionalidades: caching, reintentos, normalización, autenticación gestionada.
Cliente llama al wrapper en lugar de a la API directa. El wrapper se encarga del resto.
Construimos sub-workflows reutilizables que actúan como wrappers. Se invocan desde otros workflows con Execute Workflow node.
Propiedad por la cual ejecutar una operación múltiples veces produce el mismo resultado que ejecutarla una sola vez. Crítico en sistemas distribuidos.
APIs idempotentes reciben un "idempotency key" único; si llega dos veces, solo procesan la primera.
Cuando la API destino soporta idempotency keys, los generamos con UUID. Cuando no, hacemos GET previo para verificar si ya existe.
Estrategia para reintentar peticiones que fallan por errores transitorios (red, 5xx, 429).
Tras error, esperar y reintentar con backoff exponencial (1s, 2s, 4s, 8s). Tope máximo de reintentos.
n8n tiene "Retry on Fail" en cada nodo. Configuramos backoff y enviamos a workflow de error si falla definitivamente.
Lógica que determina qué hacer cuando algo falla: reintentar, alertar, escalar, ignorar, ejecutar fallback.
Captura excepciones, decide ruta. Logging adecuado. Notificación a humanos si hace falta.
Cada workflow crítico tiene error workflow asociado que captura fallos y los notifica vía Slack/email.
Cola separada donde se guardan mensajes/eventos que no han podido procesarse tras todos los reintentos. Permite revisión manual.
Tras agotar reintentos, el mensaje se envía a la DLQ en lugar de descartarse. Operadores la revisan periódicamente.
Implementamos DLQ con tabla en PostgreSQL o Google Sheets, donde escribimos los items fallidos para revisión.
Verificación de que los datos cumplen reglas (formato, rangos, obligatoriedad) antes de procesarlos.
Reglas como: email tiene formato válido, fecha está en rango razonable, importe es numérico positivo.
Implementamos validaciones en Code node o IF node antes de la carga al destino.
Estandarización de datos a un formato común. Ejemplo: nombres siempre en mayúscula inicial, fechas en formato ISO, países en código ISO-2.
Aplicamos funciones de transformación a campos clave durante ETL.
Code node con funciones de normalización aplicadas sistemáticamente.
Detección y eliminación de registros duplicados. Crítico cuando varios sistemas alimentan el mismo destino.
Definimos clave única (email, ID externo). Antes de insertar, verificamos si ya existe.
Set node + IF + lookup en BD para verificar existencia antes de insertar. Postgres ON CONFLICT también funciona.
Plataforma open-source de automatización de workflows fundada en 2019 en Berlín. Permite conectar APIs y servicios visualmente, con extensibilidad mediante código JavaScript. Se pronuncia "n-eight-n" (nodemation). Existen versiones self-hosted (gratuita open-source) y cloud (suscripción).
Editor visual de nodos. Cada nodo es una acción (HTTP Request, transformación, condicional, integración con servicio). Los nodos se conectan formando un workflow. Datos viajan entre nodos como JSON.
Es nuestra herramienta principal. Trabajamos casi siempre en self-hosted (Docker en VPS), permitiendo control total de datos, paquetes npm, comunidad nodes y costes contenidos.
Cadena de nodos conectados que ejecuta una automatización completa. Es la unidad fundamental de trabajo en n8n.
Comienza con un trigger (webhook, schedule, manual). Cada nodo procesa los datos y los pasa al siguiente. Termina cuando todos los nodos finalizan o se interrumpe por error.
Construimos un workflow por automatización. Los organizamos por carpetas (folders) según cliente y proceso.
Bloque atómico de un workflow. Cada nodo realiza una tarea concreta: hacer una llamada HTTP, transformar datos, decidir un camino, integrar con un servicio externo.
Recibe datos del nodo anterior (input), los procesa y emite datos al siguiente (output). Tiene parámetros configurables.
Cada workflow tiene 5-50 nodos típicamente. Los nombramos descriptivamente para facilitar mantenimiento.
Nodo especial que inicia el workflow. Define cuándo se ejecuta: por evento externo, por programación o manualmente.
Tipos: Manual (botón en editor), Schedule (cron), Webhook (URL pública), service-specific (ej. Telegram, Email IMAP, Cloudbeds Trigger).
Cada workflow tiene exactamente un trigger node. Elegimos el más eficiente para el caso (preferimos webhook sobre polling).
Nodo que ejecuta una acción real: enviar email, escribir en BD, llamar API, transformar datos.
Recibe datos del nodo anterior, ejecuta su acción específica, devuelve resultado.
El grueso de un workflow son action nodes. Los combinamos con lógica (IF, Switch) para crear flujos complejos.
Conjunto cifrado de claves de autenticación (API keys, OAuth tokens, passwords) almacenado en n8n. Reutilizable entre workflows.
Se crean una vez, se asocian a nodos por nombre. n8n cifra y oculta valores sensibles. Soporta rotación.
Cada cliente tiene sus credenciales separadas, nombradas claramente. En self-hosted se cifran con clave maestra del entorno.
Sintaxis especial de n8n para insertar valores dinámicos en parámetros de nodos. Se escriben entre dobles llaves `{{ }}`.
Dentro de las llaves, JavaScript válido más variables especiales (`$json`, `$node`, `$workflow`). Se evalúa en cada ejecución.
Las usamos en cada workflow. Son la diferencia entre un workflow estático y uno dinámico.
Valores reutilizables dentro y entre workflows. n8n tiene varios tipos: variables de entorno, workflow static data, variables de instancia.
Variables de entorno: se cargan al iniciar n8n. Static data: persisten entre ejecuciones del mismo workflow. Instance variables (n8n Pro): compartidas entre todos los workflows.
Almacenamos URLs base, claves no sensibles y configuraciones en variables. Datos de estado en static data.
Movimiento y forma de los datos entre nodos. En n8n los datos siempre son arrays de objetos JSON ("items").
Cada nodo recibe items del anterior. Si son varios items, el nodo los procesa típicamente uno a uno (loop implícito). El output es la transformación.
Diseñar bien el data flow es la habilidad clave para hacer workflows eficientes.
Una corrida específica de un workflow, con sus datos, tiempos y resultados. Se almacena en el log de ejecuciones.
Cada vez que un trigger dispara el workflow, se crea una nueva execution. Se puede inspeccionar nodo a nodo.
Las revisamos para debugging. Configuramos retención (típico 30 días) para no saturar la BD.
Trigger que ejecuta el workflow al pulsar un botón en el editor. Útil para desarrollo y pruebas.
No requiere configuración. Al hacer "Execute Workflow", se inicia.
Solo para desarrollo. En producción usamos triggers automáticos.
Trigger que ejecuta el workflow en horarios programados (cada X minutos, días concretos, expresión cron).
Se configura con cron syntax o intervalo simple. n8n lanza el workflow según calendario.
Lo usamos para batch processing y polling cuando no hay webhooks disponibles.
Trigger que crea una URL pública. Cuando un servicio externo hace POST/GET a esa URL, el workflow se ejecuta con el payload recibido.
n8n genera URL única. La registramos en el servicio remoto. Latencia mínima entre evento y ejecución.
Es nuestro trigger preferido por eficiencia. Nginx con autenticación añadida si se requiere mayor seguridad.
Nodo de control de flujo que evalúa una condición y bifurca a una de dos rutas (true/false).
Configuramos condiciones (igual, mayor, contiene, regex). Items que cumplen van por "true"; el resto por "false".
Lo usamos en casi todos los workflows para lógica de negocio.
Versión avanzada del IF. Permite múltiples ramas según el valor de un campo.
Definimos N reglas; cada item se enruta a la rama que coincide con su valor.
Útil cuando el flujo depende de un valor categórico con muchas opciones.
Nodo que une múltiples ramas paralelas en una sola. Soporta varios modos: append, merge by index, merge by key, multiplex.
Recibe inputs de N nodos. Los combina según modo configurado y emite un único stream.
Útil cuando necesitamos cruzar datos de varias fuentes.
Nodo que divide un array grande en lotes pequeños y permite procesarlos iterativamente. Esencial para evitar timeouts y rate limits.
Configura tamaño de lote (ej. 50 items). El siguiente nodo se ejecuta una vez por lote. Combinado con loop back genera iteración completa.
Lo usamos siempre que procesamos volúmenes grandes contra APIs con rate limit.
Nodo que permite escribir JavaScript arbitrario para transformar datos o ejecutar lógica compleja. En n8n self-hosted también permite Python.
Recibe items, ejecuta código del usuario, devuelve items transformados. Acceso a librerías npm en self-hosted.
Lo usamos para todo lo que no se resuelve con nodos estándar. Mantiene workflows limpios.
Nodo universal para hacer cualquier llamada HTTP a APIs no soportadas nativamente. Cubre el 100% de las APIs REST.
Configuramos URL, método, headers, body, autenticación. Soporta paginación automática y retries.
Es uno de los nodos más usados. Lo combinamos con expresiones para hacer llamadas dinámicas.
Nodo para añadir, modificar o eliminar campos del item. Es la herramienta básica de mapeo de datos.
Definimos pares clave-valor (con expresiones si hace falta). El item resultante tiene los nuevos campos.
Casi todos los workflows tienen 2-5 Set nodes. Mantenibles y declarativos.
Nodo que filtra items según condiciones, descartando los que no cumplen.
Similar a IF pero sin rama "false": los items que no cumplen simplemente no continúan.
Útil para filtrado simple. Para lógica compleja preferimos IF con rama explícita.
Nodo de código antiguo, ya reemplazado por Code node. Aún aparece en workflows antiguos.
Permite JS pero con sintaxis distinta a Code node.
Lo evitamos en proyectos nuevos. Code node es superior.
Workflow especial que se ejecuta automáticamente cuando un workflow principal falla. Permite notificar y registrar fallos.
Configuramos en settings del workflow principal. Cuando hay error no manejado, se dispara el error workflow con datos del fallo.
Siempre asociamos error workflow a workflows de producción críticos.
Workflow llamado desde otro workflow, permitiendo modularización y reutilización. Se invoca con el nodo "Execute Workflow".
El workflow padre llama al hijo, le pasa datos y recibe resultado. Permite construir librerías de funciones.
Aplicamos DRY (Don't Repeat Yourself) con sub-workflows para lógica reutilizable.
Estado del workflow. Active: triggers automáticos funcionan. Inactive: solo ejecutable manualmente.
Toggle en el editor. Solo workflows active responden a webhooks o schedules.
Convención: prefijo `[DEV]` en workflows inactive, `[PROD]` en active.
Historial de todas las ejecuciones de workflows con sus datos, tiempos y resultados.
n8n almacena cada execution en BD. Se puede inspeccionar nodo a nodo, ver inputs/outputs.
Configuramos retención según importancia. Para workflows críticos: 90 días. Estándar: 30 días.
Datos no-JSON: archivos, imágenes, PDFs, audios. n8n los gestiona como "binary properties" separadas del JSON.
Los nodos los pasan adjuntos al item. Pueden manipularse con nodos específicos (extract, convert, attach).
Common para gestión documental hotelera (facturas, contratos, partes).
Sintaxis para acceder a campos anidados dentro de un JSON. n8n usa una versión simplificada con dot notation.
Ejemplo: `$json.guest.address.city` accede a la ciudad dentro de address dentro de guest.
Construimos paths en expresiones con autocompletado del editor n8n.
Forma de acceder a campos anidados con `.`. Ejemplo: `obj.subobj.field`.
Cada `.` desciende un nivel. Para arrays se usa `[index]`: `obj.array[0].field`.
Es la forma estándar de navegar JSON en expresiones.
Variable especial de n8n que referencia el JSON del item actual.
En cualquier expresión, `$json` es el objeto del item siendo procesado por el nodo actual.
La variable más usada. Aparece en cada workflow.
Variable especial que permite acceder al output de un nodo concreto del workflow, no solo al inmediatamente anterior.
Sintaxis: `$node["nombre del nodo"].json`. Útil cuando una rama lateral debe acceder a datos no presentes en su input directo.
Esencial en workflows complejos con múltiples ramas.
Variable especial con metadatos del workflow actual: ID, nombre, modo (manual/trigger).
Útil para logging, trazabilidad, condicionales basados en cómo se invocó.
Lo usamos en logs y mensajes de error para identificar la fuente.
Nodos creados por la comunidad (no oficiales) instalables en n8n self-hosted. Amplían enormemente la cobertura de servicios.
Se instalan vía npm o desde el panel de admin. Algunos requieren configuración adicional.
Los evaluamos según calidad, mantenimiento y seguridad antes de instalarlos en producción.
Lenguaje de expresiones de n8n basado en JavaScript, embebido en `{{ }}`.
Dentro de las llaves, JS válido + variables especiales + funciones built-in (DateTime, $jmespath, etc.).
Las usamos masivamente. Editor n8n tiene autocompletado y vista previa.
Variables del sistema operativo cargadas al iniciar n8n. Se usan para configuración y secretos.
Definidas en archivo `.env` o en variables de entorno del SO. Accesibles desde n8n con `$env`.
Estándar para configuración por entorno (dev/staging/prod). Nunca commiteamos `.env` a git.
Despliegue propio de n8n en infraestructura controlada (servidor propio, VPS, Kubernetes). Alternativa al n8n Cloud.
Imagen Docker oficial. PostgreSQL como BD recomendada. Reverse proxy (Nginx/Traefik) con SSL.
Es nuestra modalidad principal. Permite control total, mejores costes a escala, instalar community nodes, paquetes npm custom.
Ejecución de procesos sin intervención humana. En el contexto de software, sustituir tareas repetitivas manuales por workflows que las realizan automáticamente.
Identificación del proceso, mapeo de pasos, conexión de sistemas, validación, despliegue. Reduce errores y libera tiempo humano.
Es nuestro core business. Cada cliente tiene 5-30 workflows automatizados según necesidades.
Sub-disciplina de automatización centrada en orquestar pasos secuenciales o paralelos entre sistemas.
Visualización en flujos (BPMN-like). Lógica condicional. Manejo de errores. Es el paradigma de n8n, Zapier, Make.
El 90% de nuestro trabajo es construir workflow automation.
Automatización mediante "robots" software que imitan acciones humanas en interfaces (clicks, formularios, lectura pantalla). Útil cuando no hay APIs.
Tools como UiPath, Automation Anywhere, Blue Prism. Más frágil que API integration (cambios UI rompen el robot).
Solo cuando no hay API. Preferimos API/scraping ligero. Usamos Playwright/Puppeteer en Code nodes self-hosted para casos puntuales.
Integración de modelos de IA (LLMs, visión, voz) en workflows para tareas que requieren "inteligencia": comprensión texto, generación, decisión, clasificación.
APIs de IA (OpenAI, Anthropic Claude, Google Gemini, Mistral) se llaman desde n8n con HTTP Request o nodos específicos.
Cada vez más workflows incorporan IA. Es palanca clave para FlujoAI: combinamos n8n + IA donde la lógica programática no llega.
Modelo de IA entrenado con grandes cantidades de texto para entender y generar lenguaje natural. Ejemplos: GPT-4, Claude Sonnet/Opus, Gemini, LLaMA.
Se le da un prompt (texto de entrada) y devuelve texto generado. Capaz de seguir instrucciones, resumir, clasificar, extraer información, conversar.
Núcleo de muchas automatizaciones modernas. Llamamos a Claude o GPT desde nodos n8n con prompts diseñados.
Sistema que combina LLM con capacidad de tomar decisiones autónomas y ejecutar acciones (tool calling), iterando hasta resolver una tarea.
El agente recibe un objetivo, decide qué herramienta usar, la invoca, evalúa el resultado, decide siguiente paso. Bucle hasta completar.
n8n tiene nodos específicos de AI Agent (LangChain integrado). Construimos agentes con tools custom (consulta PMS, consulta disponibilidad, envío email).
Texto de instrucción enviado a un LLM para obtener una respuesta. Incluye el contexto, la tarea y posibles ejemplos.
El prompt define el comportamiento del modelo en esa interacción. Buena ingeniería de prompts marca la diferencia.
Mantenemos biblioteca de prompts probados por caso de uso. Los versiona y mejoramos iterativamente.
Instrucción inicial que establece comportamiento, personalidad y reglas del LLM antes de cualquier mensaje del usuario. Persiste durante toda la conversación.
Se envía con role "system" en la API. Define identidad, tono, restricciones, formato de respuesta esperado.
Lo configuramos en cada agente IA. Es la base de coherencia y seguridad.
Parámetro de los LLMs que controla aleatoriedad de respuestas. Rango típico: 0 a 1 (algunos hasta 2).
Temperature 0: respuestas deterministas, repetibles. Temperature alta: respuestas más creativas y variadas.
Configuramos temperature según el caso de uso. Mantenemos baja para procesos críticos.
Unidad mínima de procesamiento de un LLM. Aproximadamente 1 token = 0,75 palabras en español. La factura se cobra por tokens (input + output).
El texto se tokeniza al entrar y salir del modelo. Modelos tienen límite de contexto (ej. 200k tokens en Claude).
Monitorizamos consumo de tokens para optimizar costes. Usamos prompt caching donde es posible.
Técnica que combina LLM con búsqueda en una base de conocimiento. Antes de responder, el sistema busca información relevante y se la pasa al LLM como contexto.
Documentos se almacenan en vector database. La pregunta se convierte en embedding y se buscan documentos similares. Se incluyen en el prompt del LLM.
Construimos sistemas RAG con Pinecone, Weaviate o Qdrant + LLM. Habituales para chatbots de hotel.
BD especializada en almacenar y buscar vectores (embeddings). Permite búsqueda por similaridad semántica, no solo por palabras clave.
Cada documento se convierte en vector (embedding) y se guarda. Las queries también se convierten en vectores y se buscan los más cercanos.
Usamos Pinecone (cloud), Qdrant (self-hosted) o pgvector (PostgreSQL extension) según caso. n8n tiene nodos para los principales.
Representación numérica de un texto (vector de N dimensiones, típico 1.536) que captura su significado semántico. Textos similares tienen embeddings cercanos.
Generados por modelos especializados (OpenAI text-embedding-3, Voyage, Cohere). Se calculan una vez y se almacenan.
Calculamos embeddings con nodos OpenAI/HuggingFace en n8n y los almacenamos en vector DB.
Proceso de ajustar un LLM con datos específicos del cliente para mejorar su rendimiento en una tarea concreta. Requiere dataset y entrenamiento.
Se aporta dataset (entrada-salida deseada). El modelo se entrena adicionalmente. El resultado es un modelo especializado.
Casos puntuales. Generalmente prompt engineering + RAG resuelve sin necesidad de fine-tuning.
API de los modelos Claude de Anthropic (Sonnet, Opus, Haiku). Familia de modelos LLM con foco en seguridad y capacidad de razonamiento.
API REST con endpoints para chat completion. Soporta tool calling, prompt caching, vision, batch processing.
Es nuestra API de IA preferida para muchos casos por calidad de respuesta y prompt caching avanzado.
API de los modelos de OpenAI: GPT-4o, GPT-4 Turbo, embeddings, DALL-E, Whisper. La más establecida en el mercado.
API REST con muchos endpoints. Soporta chat, function calling, vision, audio, fine-tuning.
Combinamos OpenAI con Claude según fortalezas. n8n tiene nodos dedicados para ambas.
Misma definición que AI Agent (sección anterior). Sistema autónomo basado en LLM con capacidad de actuar.
Bucle observe-think-act. Usa tools, recibe feedback, decide. Puede ser orquestado con frameworks (LangChain, CrewAI).
Lo construimos con AI Agent node de n8n + tools custom + prompt cuidadoso.
Capacidad del LLM para invocar funciones predefinidas durante su razonamiento. Permite acceder a datos externos o ejecutar acciones.
Se le presenta al LLM la lista de tools disponibles con su schema. El LLM decide cuál llamar y con qué parámetros. El sistema ejecuta y devuelve resultado.
Definimos tools como sub-workflows. El AI Agent las invoca dinámicamente.
Forzar al LLM a devolver respuestas en formato JSON con schema definido, en lugar de texto libre. Garantiza parsability.
API recibe JSON Schema. El modelo devuelve JSON válido conforme al schema. Anthropic/OpenAI soportan modos específicos.
Usamos structured output para evitar parsing manual de respuestas.
Pedir al LLM que realice una tarea sin proporcionar ejemplos previos, solo con la instrucción.
Confía en el conocimiento general del modelo. Funciona bien para tareas comunes.
Primer intento siempre zero-shot por simplicidad. Si falla, escalamos a few-shot.
Pedir al LLM que realice una tarea aportando 2-5 ejemplos en el prompt. Mejora notablemente resultados en tareas específicas.
Los ejemplos enseñan al modelo el formato y estilo esperado.
Aplicamos few-shot cuando zero-shot no produce calidad suficiente. Los ejemplos viven en variables reusables.
Servidor virtualizado dentro de un servidor físico, con recursos dedicados (CPU, RAM, disco, IP). Más barato que servidor físico, más potente que shared hosting.
Proveedores (Hetzner, DigitalOcean, OVH, AWS Lightsail) ofrecen VPS desde 5 €/mes. Acceso SSH para administración.
Usamos VPS Hetzner principalmente para alojar n8n self-hosted, BD PostgreSQL y servicios auxiliares de clientes.
Plataforma de contenedores que permite empaquetar aplicaciones con todas sus dependencias en imágenes portátiles. Ejecuta en cualquier sistema con Docker instalado.
Imágenes contienen el software + dependencias + config. Contenedores son instancias en ejecución de imágenes. Aislamiento entre contenedores.
Es nuestra forma estándar de desplegar n8n y servicios auxiliares. Garantiza reproducibilidad y portabilidad.
Herramienta para definir y ejecutar múltiples contenedores Docker como una aplicación. Configuración en archivo `docker-compose.yml`.
El YAML define servicios, redes, volúmenes. Un solo `docker-compose up` levanta todo.
Cada cliente con n8n self-hosted tiene su docker-compose.yml versionado en git.
Instancia en ejecución de una imagen Docker. Aislada del host pero con acceso controlado a red, volúmenes, etc.
Más ligero que VM (virtual machine). Comparte kernel del host. Se inicia/detiene en segundos.
Trabajamos con contenedores como unidades de despliegue. Logs, métricas, recursos por contenedor.
Modalidad en la que el software se aloja en infraestructura propia del usuario (no en cloud del proveedor). Mayor control, responsabilidad y a menudo coste menor.
Usuario gestiona instalación, actualizaciones, backups, seguridad.
Es nuestra modalidad principal. Self-hosted ofrece flexibilidad superior y costes contenidos.
Alojamiento gestionado por un proveedor cloud (AWS, GCP, Azure, Vercel, Cloudflare). El usuario no gestiona infraestructura física.
Servicios gestionados (RDS, App Engine), serverless (Lambda, Workers), o infraestructura como servicio (EC2).
Usamos cloud hosting selectivamente: web Astro en Cloudflare Workers, BD en Supabase, etc.
Plataforma serverless de Cloudflare para ejecutar código JavaScript en su edge network global. Tiempos de respuesta milisegundo en cualquier parte del mundo.
Subimos código JS/TS. Cloudflare lo ejecuta en sus 300+ datacenters según el usuario que llama. Pricing por requests.
La web flujoai-astro se sirve desde Cloudflare. Para webhooks de alta carga, podemos pre-procesar en Workers antes de pasar a n8n.
Protocolos de cifrado que protegen comunicaciones de red. SSL es el nombre antiguo, TLS el actual. Indispensable hoy en cualquier servicio público.
Certificado emitido por una autoridad (Let's Encrypt gratuito, otros pago). Cliente y servidor negocian cifrado en cada conexión.
Configuramos TLS automático con Let's Encrypt + Traefik en nuestros despliegues. Nunca exponemos servicios sin HTTPS.
Protocolo HTTP cifrado con TLS. Convención: URLs `https://` están cifradas, `http://` no.
Mismo HTTP pero todo el tráfico encriptado. Verifica identidad del servidor con certificado.
Todos nuestros endpoints son HTTPS. Configuración automática en infraestructura.
Nombre legible que apunta a una IP de servidor. Se compra/renta a registradores (GoDaddy, Namecheap, Cloudflare Registrar).
Registros DNS asocian dominio (flujoai.com) con IPs y servicios. Renovación anual.
Cada cliente con automatizaciones tiene su subdominio (n8n.cliente.com) o usamos infrastructure compartida con paths.
Subdivisión de un dominio (`api.flujoai.com`, `n8n.flujoai.com`). Permite separar servicios.
Configurado en DNS del dominio principal. Apunta a IP/servicio específico.
Estructuramos servicios por subdominio para claridad y aislamiento de SSL.
Mismo concepto que en n8n: variables de configuración cargadas al iniciar un servicio. Almacenadas en archivo `.env` o variables del sistema.
Dotenv lee `.env` y expone variables. Permite cambiar config sin tocar código. Nunca se commitean a git (contienen secretos).
Estándar en cualquier proyecto. Mantenemos `.env.example` (sin secretos) en repos.
Base de datos relacional open-source robusta y popular. Usada masivamente en aplicaciones modernas, incluyendo n8n como BD subyacente.
Modelo SQL. Soporta transacciones ACID. Extensiones (pgvector para IA, PostGIS para geo). Gestionable con pgAdmin, DBeaver.
BD por defecto para n8n self-hosted. También la usamos para data warehouses pequeños/medianos.
Otra BD relacional popular, especialmente en aplicaciones PHP y CMS clásicos. Propiedad de Oracle.
Similar a PostgreSQL en muchos aspectos. Más extendida en hosting compartido tradicional.
Conectamos a MySQL de PMS con nodo MySQL de n8n cuando no hay API.
BD relacional ligera contenida en un solo archivo. No requiere servidor. Ideal para aplicaciones pequeñas y embebidas.
Un archivo `.sqlite` es la BD completa. Acceso por librería sin proceso adicional.
n8n soporta SQLite como BD; lo evitamos en producción multi-cliente porque PostgreSQL escala mejor.
BD en memoria ultrarrápida, usada para caching, queues y datos efímeros. Open source.
Almacena en RAM (con persistencia opcional). Latencia microsegundo. Estructuras de datos avanzadas.
Útil para colas de procesamiento masivo. n8n puede usar Redis para queue mode (escalado horizontal).
Tarea ejecutada automáticamente según calendario (sintaxis cron). Estándar Unix.
Sintaxis `* * * * *` (minuto, hora, día, mes, día semana). Ejemplo `0 3 * * *` = todos los días a las 03:00.
Schedule trigger de n8n usa sintaxis cron por debajo. También configuramos cron jobs externos para tareas críticas.
Prácticas de desarrollo que automatizan tests y despliegue. Cada cambio en código pasa pipelines automáticos.
Push a git → tests automáticos → si pasan, deploy a staging/production. Herramientas: GitHub Actions, GitLab CI, Jenkins.
Para nuestros productos usamos GitHub Actions. Para workflows n8n exportamos JSON a git y desplegamos vía API.
Sistema de control de versiones distribuido, estándar de la industria. Permite rastrear cambios en código colaborativamente.
Cada cambio es un "commit". Ramas (branches) para trabajar en paralelo. Merge para integrar.
Versionamos todo: configuraciones, scripts, documentación. Workflows n8n exportados como JSON.
Plataforma cloud para hospedar repositorios git. La más popular del mundo, propiedad de Microsoft.
Repositorios públicos/privados. Pull requests para review de código. Issues, projects, actions (CI/CD).
Nuestro hub central de código. Cada cliente tiene su repo privado.
Copia de seguridad de datos para recuperación ante fallos, errores o ataques. Imprescindible en cualquier sistema productivo.
Backup completo o incremental, automatizado, almacenado en ubicación distinta del original (off-site preferible).
Implementamos backups automatizados con cron + scripts. Verificamos restauraciones (un backup no probado no es backup).
Porcentaje de tiempo que un servicio está disponible. SLA típico: 99.9% (43 min downtime/mes), 99.99% (4 min/mes).
Monitoreado constantemente desde fuera (probes). Reportado en dashboards y alertas.
Monitoreamos uptime de servicios críticos con UptimeRobot, Better Stack o Healthchecks.io.
Observación continua de salud, rendimiento y comportamiento de sistemas. Métricas (CPU, RAM, latencia), logs, traces.
Herramientas (Prometheus, Grafana, Datadog, New Relic) recogen datos y los visualizan. Alertas si superan umbrales.
Implementamos monitoring básico para clientes (uptime, errores) y avanzado para proyectos críticos (Grafana + Prometheus).
Notificación automática cuando algo va mal o supera umbral. Puede ser email, Slack, SMS, llamada.
Reglas definidas por métricas/logs. Cuando se disparan, se notifica al equipo on-call.
Configuramos alertas en n8n y herramientas externas. Slack es nuestro canal principal.
Registro cronológico de eventos que ocurren en un sistema. Indispensable para debugging, auditoría, seguridad.
Aplicación escribe logs (JSON estructurado preferible). Se centralizan en herramientas (ELK, Loki, CloudWatch).
n8n almacena logs de ejecuciones. Para mayor profundidad, escribimos a sistema central (Loki, BetterStack).
Reglamento europeo de protección de datos. Aplica a cualquier procesamiento de datos personales, incluyendo automatizaciones que procesan datos de huéspedes.
Principios: licitud, minimización, limitación de finalidad, exactitud, plazos, integridad, responsabilidad proactiva. Sanciones: hasta 20M€ o 4% facturación.
Diseñamos workflows GDPR-compliant: minimizamos datos transferidos, encriptamos en tránsito y reposo, mantenemos audit trail, gestionamos derechos ARCO.
Contrato que obliga a las partes a no divulgar información confidencial intercambiada durante una relación comercial.
Define qué información es confidencial, plazos, excepciones, sanciones.
Firmamos NDA con cada cliente al inicio. Es estándar antes de auditoría técnica.
Lugar geográfico donde se almacenan y procesan los datos. Importante por leyes locales y compliance.
Datos de ciudadanos UE deben permanecer en UE preferiblemente, salvo transferencias con garantías. Schrems II afectó transferencias UE-USA.
Alojamos datos sensibles en VPS Hetzner (Alemania/Finlandia). APIs de IA elegimos versiones europeas cuando hay (Anthropic en Frankfurt).
Cifrado de datos cuando viajan por red. Implementado mediante TLS/HTTPS.
Datos cifrados antes de salir del emisor, descifrados al llegar. Sniffers no ven contenido legible.
Estándar en cualquier llamada. n8n no permite HTTP plano para webhooks productivos.
Cifrado de datos cuando están almacenados (disco, BD, backups). Protege ante acceso físico no autorizado.
Cifrado a nivel disco (LUKS, BitLocker), BD (TDE), aplicación (campo a campo).
Configuramos cifrado de disco en VPS. n8n cifra credenciales con clave maestra. Backups cifrados antes de subir a almacenamiento off-site.
Estándar de seguridad para sistemas que procesan tarjetas de crédito. Obligatorio si almacenas/procesas/transmites datos de tarjeta.
12 requisitos: red segura, protección de datos, gestión de vulnerabilidades, control de accesos, monitoreo, política. Auditoría periódica.
Nunca pasamos números de tarjeta en claro por nuestros workflows. Usamos tokens o pasarela. Cumplimiento delegado en proveedor certificado.
Sustitución de datos sensibles (tarjeta, DNI) por tokens irreversibles que solo tienen sentido en el sistema que los emitió.
Pasarela tokeniza la tarjeta. Hotel guarda solo token. Para cobrar, envía token a pasarela; ésta usa la tarjeta original.
Manejamos tokens, nunca PAN (Primary Account Number). PCI-DSS scope reducido drásticamente.
Principio GDPR: solo recolectar/procesar los datos estrictamente necesarios para la finalidad declarada.
Antes de pedir un dato, justificar por qué se necesita. Eliminar campos innecesarios.
Diseñamos workflows que solo extraen y procesan campos estrictamente necesarios. Filtros explícitos al inicio.
Registro inmutable de todas las acciones realizadas en un sistema, con quién, cuándo y qué. Crítico para compliance.
Cada acción genera entrada de log con timestamp, usuario, acción, datos. Almacenado en sistema separado, idealmente WORM (Write Once Read Many).
Implementamos audit trail en BD separada para acciones sensibles. Logs versionables y firmados criptográficamente cuando hace falta.
Mecanismos que restringen quién puede acceder a qué recursos. Principio de least privilege: cada usuario solo lo justo para su trabajo.
Autenticación (quién eres) + autorización (qué puedes). RBAC (Role-Based), ABAC (Attribute-Based). MFA recomendado.
Configuramos roles en n8n (Owner, Admin, Member, Viewer). MFA obligatorio para usuarios con permisos críticos.
Restricción de acceso a un servicio solo desde direcciones IP autorizadas explícitamente. Capa adicional de seguridad.
Firewall o configuración de la app rechazan conexiones de IPs no listadas.
Configuramos IP whitelist en webhooks de n8n cuando hace falta y en accesos administrativos a infraestructura.
No se encontraron términos para ""