VDA Studio · Historia · Hospitality

Felipe y la Habitación que no Vuelve

Una historia sobre lo que pasa cuando una cadena hotelera decide dejar de gestionar la ocupación — y empieza a predecirla.

14 min de lectura

* Las historias presentadas en este glosario son obras de ficción con fines educativos. Los personajes, empresas y situaciones descritos son hipotéticos y han sido diseñados para ilustrar conceptos de la Era Agéntica en contextos empresariales reales. Cualquier similitud con personas, organizaciones o eventos reales es coincidencia.

Los términos subrayados llevan a su definición.

Prólogo

Un domingo, a las once de la noche, Felipe tenía el lunes encima y cuatro sistemas que no se hablaban entre sí.

A las nueve de la mañana siguiente vencía el reporte semanal de la franquicia internacional — ocupación por segmento, RevPAR por canal, índice de satisfacción por categoría de habitación, en el formato correcto, en el sistema correcto, a tiempo. Su equipo lo armaba a mano desde cuatro plataformas que no se comunicaban. Llegaba tarde. Con errores. Y a veces, simplemente no llegaba. Esta vez no era un regaño: la franquiciadora amenazaba con revocarle la licencia de una de sus propiedades por incumplir los estándares de reportería. No porque el hotel funcionara mal — sino porque no podía probar, a tiempo, que funcionaba bien.

Y encima, la pregunta que no lograba explicarle bien a nadie. Cada semana llegaba el reporte de con los números del , y cada semana mostraba la misma brecha: su competidor más cercano —un hotel boutique con la mitad de sus habitaciones— tenía un RevPAR 23% superior al de su mejor propiedad. Mismos canales de distribución. Mismo mercado. Estructura de costos similar. La diferencia no era visible en ningún reporte que Felipe pudiera generar. Pero estaba ahí.

Felipe llevaba doce años en la industria hotelera. Seis propiedades, 420 empleados, una mezcla de marcas propias y esa franquicia internacional que había costado años de negociación conseguir — y que ahora amenazaba con quitarle.

Algo tenía que cambiar.

ACTO 1 — DESMITIFICAR

Capítulo 1 — El Diagnóstico

El consultor que contrató Felipe no llegó con una demo. Llegó con una pregunta.

"¿Cuánto tardas en saber que una noche va a cerrar mal?"

Felipe pensó. "Generalmente lo sabemos al día siguiente, cuando cerramos el reporte de ocupación."

El consultor asintió. "Ahí está el problema. En hospitality, cuando sabes que la noche cerró mal, ya no hay nada que hacer. La habitación vacía de anoche es ingreso perdido para siempre. No se recupera."

Le explicó la diferencia entre lo que una empresa de crédito tenía — un modelo de ML que predecía basado en patrones históricos — y lo que Felipe necesitaba: un ecosistema de Agentes que percibieran señales en tiempo real, razonaran sobre el contexto y actuaran sobre las tarifas, los canales y la distribución antes de que la noche cerrara.

"¿Y eso es diferente a lo que hace mi revenue manager?"

"Tu revenue manager toma entre 200 y 400 decisiones de tarifa por semana. Un ecosistema agéntico toma 200.000. No porque sea más inteligente — sino porque puede procesar señales que ningún humano puede monitorear simultáneamente: clima, eventos locales, tarifas de competidores en tiempo real, comportamiento de búsqueda en OTAs, patrones de cancelación por segmento, histórico de demanda por día de la semana y temporada."

Felipe pensó en las noches de Feria de las Flores — y en el megaconcierto del Atanasio Girardot que había saturado el mercado en 72 horas — cuando el sistema de tarifas seguía cargando precios de temporada normal porque nadie había actualizado el calendario de eventos.

"¿Y por qué no me ha funcionado la tecnología que ya tenemos? Tenemos un PMS, un channel manager, un RMS..."

"Porque tienes herramientas — no arquitectura. Eso tiene nombre: Vibe-based Spending. Inviertes en tecnología basado en lo que el mercado vende, no en lo que tu operación necesita. Cada sistema resuelve una pieza. Ninguno conversa con los otros. El resultado es que tienes datos en cuatro lugares y ninguno te dice qué hacer en los próximos 90 minutos."

La pregunta que Felipe se llevó a casa esa noche:

¿Cuántas habitaciones vacías podría haber evitado si hubiera sabido, días antes — dentro de la ventana de reserva — que esa noche iba a cerrar mal?

ACTO 2 — ARQUITECTURA

Capítulo 2 — La Arquitectura

El diagnóstico técnico fue revelador.

Colección Andina Hotels tenía 12 años de datos de ocupación, patrones de demanda por segmento, histórico de cancelaciones, comportamiento de clientes por nacionalidad y canal. Información valiosa. Pero vivía distribuida entre el PMS de cada propiedad, el channel manager, las exportaciones manuales a Excel del equipo de revenue y los reportes descargados de las OTAs.

"Sin una Vector Database", explicó el consultor, "tu conocimiento histórico no es recuperable en tiempo real. El agente no puede preguntarle a tus datos: '¿qué pasó la última vez que hubo un evento de este tipo en esta ciudad, con este nivel de competencia, en este canal?' Puede buscar por fecha exacta. No puede buscar por contexto."

"¿Y cómo hace el agente para conocer la historia de nuestro hotel?"

"Con lo que en el sector llamamos RAG, le das al agente la memoria institucional de Colección Andina. No opera con patrones generales de hospitality — opera con los patrones específicos de tus seis propiedades, tus segmentos de clientes, tus canales de distribución. La diferencia entre un revenue manager que lleva dos semanas en el cargo y uno que lleva doce años."

Había también una fuente de datos que Colección Andina tenía pero no procesaba en tiempo real: el reporte semanal de STR con el desempeño del compset. El agente podía leer esos datos, correlacionarlos con el pace propio y ajustar la estrategia tarifaria antes de que la semana terminara — no después de que el reporte llegara el miércoles siguiente.

"¿Y cómo logras que el agente hable como alguien de la casa y no como un externo?"

"Con lo que en el sector llamamos Fine-tuning. Es la diferencia entre un agente que sabe de hospitality en general — y uno que habla el idioma específico de Colección Andina. Tu mezcla de segmentos, tu política de precios por canal, tus estándares de la franquiciadora, las particularidades de cada propiedad. Es el proceso de re-entrenar el modelo con esa información para que opere como un experto de la casa — no como un consultor externo que leyó tu website."

Felipe pensó en cuántas veces había tenido que explicarle a un nuevo revenue manager las particularidades de cada propiedad. El hotel de Cartagena tenía un comportamiento completamente distinto al de Bogotá. El segmento corporativo de Medellín respondía diferente al de Cali. Ese conocimiento tardaba meses en transferirse. Con fine-tuning, podía transferirse una vez — y el agente lo tendría desde el primer día.

"¿Y cómo conecta todo esto con el PMS, el channel manager, las OTAs?"

"Con MCP. El protocolo que conecta el agente con tus sistemas operativos sin integraciones frágiles. El agente lee el PMS, actualiza el channel manager, monitorea las OTAs y carga los reportes en la plataforma de la franquiciadora — en tiempo real, sin que nadie tenga que exportar un Excel."

"¿Y cómo logran que todos esos agentes trabajen coordinados?"

"Con lo que en el sector llamamos Orquestación Agéntica. Es lo que hace que el ecosistema funcione como sistema nervioso y no como colección de agentes independientes. El agente de revenue detecta una señal de demanda alta para el fin de semana. Lo comunica al agente de distribución, que ajusta las tarifas en todos los canales simultáneamente. El agente de operaciones recibe la señal y prepara al equipo de housekeeping para el aumento de ocupación esperado. Todo coordinado. Todo en minutos."

La pregunta que Felipe se llevó a casa esa noche:

¿Cuánto del conocimiento de mi mejor revenue manager vive solo en su cabeza — y qué pasa cuando se va?

ACTO 3 — EL PODER OPERATIVO

Capítulo 3 — El Primer Agente

Tres meses después, Colección Andina tenía su primer agente en producción en su propiedad de Medellín.

Se llamaba internamente "el Revenue" — y monitoreaba en tiempo real las señales de demanda, ajustaba recomendaciones de tarifa por canal y generaba alertas cuando el pace de reservas — la velocidad a la que se acumulan reservas para una fecha futura versus el histórico — se desviaba del forecast. La señal más temprana de cómo va a cerrar una noche, disponible 21 días antes.

No tomaba decisiones solo — recomendaba. El revenue manager aprobaba, rechazaba o modificaba. Pero en lugar de revisar 400 variables manualmente, revisaba 12 alertas priorizadas.

La diferencia no estaba solo en la velocidad. Estaba en la naturaleza de las decisiones.

Felipe entendió algo que nadie le había explicado claramente antes: la diferencia entre Automatización y Autonomía.

"Tu channel manager es automatización", dijo el consultor. "Ejecuta reglas fijas que tú programaste — si la ocupación supera el 80%, sube la tarifa un 15%. Siempre igual. Sin importar el contexto. El Revenue es autonomía — percibe el contexto completo, razona sobre las variables disponibles y elige la acción más inteligente para ese momento específico. No hay dos noches iguales. La automatización las trata igual. La autonomía no."

Felipe también descubrió el valor de los Plugins — los módulos de capacidad que ampliaban lo que el Revenue podía hacer sin reescribir su arquitectura base. Un plugin de clima local. Un plugin de eventos de la ciudad. Un plugin de monitoreo de tarifas de competidores en tiempo real. Un plugin de STR para cruzar el pace propio con el del compset. Cada uno añadía una señal nueva al razonamiento del agente.

"Es como añadirle sentidos", dijo Felipe.

"Exacto. Cada plugin es un sentido nuevo. Pero cada plugin también es una superficie de riesgo — datos que entran al ecosistema desde afuera. Por eso cada uno pasa por auditoría antes de integrarse."

La pregunta más importante que Felipe hizo antes de expandir a las otras propiedades fue sobre Soberanía de Datos:

"Los datos de ocupación, los perfiles de clientes, los patrones de demanda de mis seis propiedades — ¿quién los tiene? ¿Dónde viven? ¿Qué pasa si termino el contrato?"

"Viven en tu infraestructura. Bajo tus políticas. El proveedor no los lee. El modelo fundacional no aprende de ellos. Y si terminas el contrato, te llevas todo — incluyendo la Vector Database con 12 años de historia hotelera propia."

Esa respuesta fue la que le permitió presentarle el proyecto al board con confianza.

La pregunta que Felipe se llevó a casa esa noche:

¿Mis datos de ocupación me pertenecen — o están viviendo en la plataforma de alguien más?

ACTO 4 — LA GOBERNANZA

Capítulo 4 — La Semana que el Agente Aprendió a Dudar

Dos meses después del lanzamiento en Medellín, Felipe decidió acelerar el rollout a las otras cinco propiedades.

El equipo técnico lo detuvo.

"¿Por qué no ahora?"

"Porque 'funcionó bien' en condiciones normales. No sabemos cómo funciona en un evento extraordinario — feria de Medellín con demanda 3 veces el promedio, un congreso cancelado de último minuto, una falla del PMS en temporada alta. Antes de expandir, necesitamos pasar por el Sandbox."

El Sandbox era el entorno donde el agente enfrentaba escenarios extremos sin tocar sistemas productivos. Ocupación al 20% por una crisis reputacional ficticia. Demanda explosiva por un evento no anticipado. Falla simultánea de dos canales de distribución. El Revenue enfrentaba cada escenario y el equipo observaba cómo razonaba, cómo escalaba, cómo fallaba.

Fallaba bien — eso era lo importante. Cuando llegaba a un escenario fuera de su rango de confianza, activaba su Fallback Strategy: pausaba las recomendaciones autónomas, notificaba al revenue manager con el contexto comprimido y esperaba instrucción humana antes de actuar. No improvisaba. Se detenía con elegancia.

Pero el Sandbox reveló algo más: Technical Debt acumulada en dos propiedades.

El hotel de Bogotá tenía un PMS de 2016 sin API moderna. No era un problema técnico menor — era la diferencia entre un agente que actúa sobre la demanda de hoy y uno que actúa sobre los datos de ayer. El sistema exportaba en un formato propietario que requería descarga manual cada 4 horas. En revenue management, esa latencia se mide en habitaciones vacías.

El hotel de Cartagena tenía datos de ocupación histórica con inconsistencias de criterio — tres años donde "habitación bloqueada" había sido registrada como "ocupada" por un error del equipo anterior. Un agente que aprende de datos incorrectos aprende incorrectamente. Con más velocidad y más confianza que cualquier humano.

"¿Cuánto cuesta limpiar eso?", preguntó Felipe.

"Menos de lo que cuesta no hacerlo."

Felipe pospuso el rollout de Bogotá y Cartagena hasta sanear la base. No era lo que quería escuchar. Pero era exactamente lo que necesitaba saber.

También estableció ese trimestre el AI Center of Excellence de Colección Andina — pequeño pero existente: el revenue manager senior, el director de TI y él mismo como Chief AI Officer de facto. Tres personas que decidían qué se desplegaba, cómo se medía y cuándo se expandía. Sin ese comité, cada propiedad hubiera tomado sus propias decisiones de IA — y en seis meses tendrían seis ecosistemas incompatibles.

La pregunta que Felipe se llevó a casa esa noche:

¿Cuánta deuda técnica tengo acumulada — y cuánto me está costando en decisiones de revenue que mi agente no puede tomar bien?

ACTO 5 — LA VISIÓN

Capítulo 5 — El Sistema Nervioso

Un año después, cuatro de las seis propiedades de Colección Andina operaban con el ecosistema completo.

El Revenue seguía siendo el núcleo. Pero ahora coordinaba con el Agente de Experiencia — que monitoreaba el sentimiento en reseñas en tiempo real y alertaba cuando un patrón de quejas comenzaba a afectar la reputación antes de que impactara la ocupación. Y con el Agente de Operaciones — que cruzaba el forecast de ocupación con la disponibilidad de housekeeping y mantenimiento, anticipando cuellos de botella antes de que el huésped los viviera.

No eran sistemas independientes. Era Orquestación Agéntica real — el Revenue detectaba demanda alta para el fin de semana, el Agente de Operaciones preparaba el plan de turno antes de que recursos humanos lo pidiera, el Agente de Experiencia monitoreaba que la promesa de calidad se cumpliera bajo la presión de alta ocupación.

Agency Transfer había ocurrido — no como un evento dramático, sino como una evolución gradual. Felipe había delegado formalmente el derecho de ajustar tarifas dentro de rangos definidos al Revenue. No porque confiara ciegamente — sino porque habían construido la confianza paso a paso. Primero recomendaciones que él aprobaba. Luego autonomía en rangos pequeños. Luego rangos más amplios respaldados por meses de datos de desempeño. La Trust Dynamics no era un concepto abstracto — era el historial de 1.240 decisiones correctas del agente antes de que Felipe le diera acceso autónomo a la tarifa rack.

El primer lunes después del lanzamiento completo en las cuatro propiedades, Felipe recibió la confirmación de carga en la plataforma de la franquiciadora a las 3:47am — sin que nadie en su equipo hubiera tocado nada. La amenaza de revocación de licencia desapareció ese trimestre.

La junta de fin de año tuvo números que Felipe no esperaba presentar tan pronto.

El RevPAR promedio de las cuatro propiedades con el ecosistema activo había crecido 31%. Pero el número que más sorprendió al board fue el , el número que el accionista del hotel lee para saber si la inversión en el activo genera retorno, no solo si el operador llena habitaciones. El ecosistema no solo había optimizado la tarifa de habitación: había detectado patrones de demanda en F&B y spa que el equipo nunca había correlacionado con los picos de ocupación. El ingreso total por huésped creció 18% adicional.

Y el número que más impactó al CFO no fue ninguno de esos. Fue el channel mix. Las reservas directas habían crecido del 23% al 41% del total — el agente había aprendido cuándo ofrecer beneficios de reserva directa para capturar demanda sin pagarle comisión a las OTAs. Las OTAs cobran entre el 15% y el 25% por reserva; en una cartera de seis propiedades, ese margen recuperado se traducía en $380.000 dólares anuales que antes se iban a Booking.com.

Las dos propiedades sin el ecosistema habían crecido 4%. La diferencia ya no era invisible.

"¿Cómo sabemos que el ecosistema es responsable y no el mercado?", preguntó uno de los socios.

Felipe respondió con el vocabulario que había aprendido:

"Porque medimos con Outcome Metrics y Trajectory Metrics. El resultado lo vemos en el RevPAR y el GOPPAR. Pero la trayectoria nos muestra exactamente cuántas decisiones tomó el agente, en qué condiciones, con qué nivel de confianza y cuántas hubiera tomado diferente un revenue manager humano. No es una correlación — es causalidad documentada."

Silencio. Luego:

El concierto llenó la ciudad un viernes. El hotel lo supo el lunes anterior — y para cuando los demás reaccionaban, la tarifa, el inventario y los turnos ya estaban resueltos. Mientras la cuadra improvisaba y remataba habitaciones a última hora, Felipe ya había cobrado la demanda antes de que cruzara la puerta.

Epílogo

El Ecosistema Agéntico en hospitality no reemplaza al revenue manager. Lo convierte en el arquitecto de decisiones que ningún sistema podía tomar solo.

La diferencia entre las cadenas hoteleras que lideran y las que sobreviven no es el tamaño. No es la marca. No es el mercado.

Es si el CEO entiende que, antes que operar el hotel, su trabajo es ser fiduciario del capital del accionista — y que cada noche que cierra con habitaciones vacías no es solo ingreso perdido para siempre: es retorno destruido sobre un activo que alguien le confió. La arquitectura agéntica no optimiza la ocupación. Custodia el retorno — detecta días antes, dentro de la ventana de reserva, lo que el operador tradicional solo confirma al día siguiente.

Felipe lo entendió cuando su competidor más pequeño tuvo un RevPAR 23% superior sin una razón visible. Y entendió que el GOPPAR de su cartera era, en el fondo, la única pregunta que su junta tenía derecho a hacerle.

VDA Studio
La biología es el backend del rendimiento corporativo.
vectordata.studio