Cuándo construir tu propio motor de reservas sale más barato que pagarlo

El software de gestión de propiedades casi nunca se cobra por usuario. Se cobra por inmueble, por reserva, por conexión de canal, o por alguna combinación: es decir, la curva de coste está deliberadamente atada a aquello que el operador intenta aumentar. Duplica la cartera y la factura de software se duplica, mientras que el trabajo que hace ese software apenas cambia.

Para un operador pequeño esto es correcto y eficiente: unos cientos al mes compran un sistema que costaría seis cifras construir. La economía se invierte en algún punto, y ese punto llega mucho antes de lo que la mayoría supone, porque la comparación que se hace es contra el precio de tarifa y no contra la factura completa. Las comisiones de canal, las comisiones de pago, los módulos adicionales, la integración que nadie usa pero no se puede cancelar y la subida anual forman parte del número que se está comparando.

Suelen llegar empaquetados tres productos distintos, y separarlos es el primer paso útil, porque un operador rara vez necesita construir los tres.

El motor de reservas es lo que toca el huésped: búsqueda, disponibilidad, tarifas, checkout. El gestor de canales mantiene disponibilidad y precios sincronizados con las OTA por las que se vende. El sistema de gestión es la trastienda: propietarios, contratos, limpiezas, liquidaciones, contabilidad. Muchos operadores descubren que su cara suscripción paga sobre todo una trastienda que además han reconstruido a medias en hojas de cálculo, mientras que la parte que de verdad genera ingresos es el motor de reservas sobre el que menos control tienen.

• Motor de reservas: búsqueda, disponibilidad y pago de cara al huésped.
• Gestor de canales: sincronización bidireccional con las OTA.
• Gestión de propiedades: propietarios, contratos, limpieza, liquidaciones.
• Pregúntate cuál de los tres reemplazarías de verdad, y presupuesta solo ese.

Un motor de reservas parece un buscador y un calendario. Por debajo, la disponibilidad es un modelo de datos sorprendentemente implacable, y equivocarse ahí es lo que hunde a los sistemas propios, no la falta de funcionalidades.

Una noche no está simplemente libre u ocupada. Lleva una tarifa que varía por temporada, por duración de la estancia y por antelación de la reserva. Lleva una estancia mínima que puede cambiar según el día de llegada, una regla de cambio que en temporada alta solo permite entradas en sábado, una antelación mínima, una estancia máxima y un indicador de cerrado a la llegada que no es lo mismo que estar reservado. Una búsqueda de «cuatro noches en agosto para seis personas por menos de 300 la noche» tiene que resolver todo eso sobre la cartera completa, y lo bastante rápido como para que el huésped no se vaya.

Por eso las implementaciones ingenuas se arrastran a partir de unos cientos de inmuebles: calculan la disponibilidad por inmueble en cada petición. Los sistemas que siguen siendo rápidos la precalculan, y esa decisión de diseño se toma la primera semana, no cuando la búsqueda ya va lenta.

Todo inmueble vendido en más de un canal tiene el mismo modo de fallo: dos huéspedes reservan la misma noche en los segundos que van desde que un canal la vende hasta que los demás se enteran. El coste lo asume el operador, al huésped hay que reubicarlo o devolverle el dinero, y la OTA anota una cancelación contra el inmueble.

Existen dos mecanismos y no son equivalentes. Los ficheros de calendario son simples, universalmente soportados y funcionan por consulta: la otra parte comprueba cada cierto tiempo, lo que deja una ventana de minutos u horas en la que la doble reserva es posible, y no permiten enviar nada más que fechas bloqueadas. Las integraciones directas envían el cambio, transportan tarifas y restricciones además de bloqueos, y confirman lo que han recibido; también son trabajo por canal, con las manías y los límites de cada canal.

El diseño honesto no es uno ni otro, sino una frontera: una única fuente de verdad interna para la disponibilidad, una cola que empuja los cambios hacia fuera, y una reconciliación que relee periódicamente cada canal y repara la deriva. La deriva ocurre con cualquier mecanismo. Un sistema que da por hecho que no ocurrirá es un sistema que se entera en plena temporada alta.

Una reserva cobra, y cobrar implica un calendario de señales, una fecha de pago del resto, una política de cancelación que determina las devoluciones, una fianza que puede ser una retención y no un cargo, tasas turísticas que varían por municipio, y una liquidación al propietario con la comisión descontada.

Nada de eso es técnicamente difícil y todo ello es implacable, porque un error es el dinero de alguien en una fecha que ya pasó. Es la parte de la construcción que hay que proteger con pruebas antes que ninguna otra, y aquella en la que usar el producto de marketplace o de depósito de una pasarela gana a escribir la lógica de liquidación desde cero.

La comparación que importa no es la cuota mensual contra el coste de construir. Es el coste anual total de la pila actual - suscripciones, comisiones por reserva, módulos, la diferencia de comisión entre una reserva directa y una de OTA - contra la construcción más su operación y mantenimiento, a tres o cinco años.

Suelen decidirlo dos cosas. La primera es el porcentaje de reserva directa: un operador que consigue mover reservas desde las OTA a su propia web ahorra una comisión que empequeñece cualquier suscripción, y un motor de reservas propio es justamente cómo se produce ese movimiento. La segunda es la trayectoria de la cartera, porque la curva de la suscripción es la que no deja de subir.

El argumento en contra de construir es real y conviene decirlo. Por debajo de cierto tamaño de cartera los números no salen. Sin alguien interno que sea dueño del producto, un sistema a medida se degrada. Y un operador cuya ventaja competitiva es el servicio y no la distribución probablemente hace mejor comprando y gastando la diferencia en personal.

Un cliente de gestión de propiedades llegó con exactamente esta aritmética. Sostenía suscripciones mensuales considerables por el software que hace funcionar su cartera y sus alquileres, y llegó a la conclusión de que ese mismo dinero, gastado una vez, compra un activo dentro de su propia empresa en lugar de un permiso para seguir operando.

El trabajo está en curso, no terminado, y preferimos decirlo antes que presentarlo como un caso de éxito que todavía no es. Estamos construyendo el motor de reservas, la búsqueda y el filtrado conscientes de la disponibilidad, y la sincronización que mantiene coherentes los datos de los inmuebles y los calendarios en los sitios donde se venden.

El orden es el descrito arriba: primero el modelo de disponibilidad, porque todo lo demás lee de él; después el flujo de cara al huésped; después la sincronización hacia fuera, con la reconciliación asumida desde el principio y no añadida tras la primera doble reserva.

Empieza por sacar el gasto real de doce meses en lugar de la cuota actual: suscripciones, cargos por reserva, comisiones de pago y la comisión de cada reserva de OTA. La mayoría de operadores no ha visto nunca ese número junto, y con frecuencia resuelve la pregunta por sí solo.

Después decide cuál de los tres productos reemplazarías de verdad. Construir el motor de reservas y quedarse con una trastienda comprada es una respuesta habitual y sensata, y un proyecto mucho más pequeño que sustituirlo todo.

Hemos hecho este tipo de trabajo y lo estamos asumiendo para otros operadores. Si quieres las cuentas bien hechas antes de comprometerte a nada, para eso está la auditoría gratuita.