Hotelbeds

Hotelbeds es una empresa de distribución hotelera business-to-business, es decir, un intermediario (bedbank) que vende alojamiento y otros servicios turísticos a mayoristas y distribuidores: agencias de viajes, tour operadores, compañías aéreas y otros intermediarios, no directamente al viajero final.

Según la fuente disponible (Wikipedia), la empresa consta como activa. Los datos del corpus la califican como "startup" del sector "Software y SaaS" con sede en Barcelona; estas calificaciones no se pueden verificar con la fuente facilitada y, por tanto, no las puedo confirmar. Tampoco consta en la fuente cuál es la sede social ni la forma jurídica exacta.

No consta en la fuente facilitada el año de fundación, los fundadores ni las circunstancias de la creación de la empresa. Esta información no se puede afirmar con los datos disponibles.

De acuerdo con la fuente, Hotelbeds opera como distribuidor hotelero B2B: pone en contacto la oferta de alojamiento con intermediarios turísticos que después la revenden al cliente final. El modelo de negocio es, por tanto, el de una plataforma de distribución (bedbank) que cobra por la intermediación y el acceso a inventario hotelero.

No consta en la fuente el detalle de la cartera de productos, los mercados en los que opera ni la dimensión de su red de clientes.

No consta en la fuente facilitada información sobre la evolución de la empresa, sus resultados, etapas de crecimiento o hitos relevantes. No puedo describir ningún periodo de bonanza sin datos que lo sostengan.

No aplica: según la fuente disponible, la empresa consta como activa. No hay constancia de cierre ni de transformación societaria en la información facilitada.

No consta en la fuente ninguna información sobre el impacto, la huella o el legado de la empresa. Dado que la empresa consta activa, no se puede hablar de herencia en el sentido de continuidad post-cierre.

No consta en la fuente facilitada la identidad de los fundadores ni su situación actual. Para intentarlo, se podría consultar el registro mercantil (BORME) para identificar administradores y socios, y notas de prensa económica especializada en turismo y tecnología.

Con la información disponible no se pueden extraer lecciones operativas específicas y verificadas sobre esta empresa. Cualquier conclusión sobre su modelo, su gestión o su evolución requeriría fuentes adicionales (registrales, financieras o periodísticas especializadas) que no se han facilitado. Recomiendo ampliar el corpus antes de hacer cualquier análisis.

La font disponible (Wikipedia) situa Hotelbeds com una empresa de Barcelona dedicada a la distribució d'allotjament hoteler en l'àmbit B2B. La seva essència no és "vendre habitacions al consumidor final", sinó fer de pont tècnic i comercial entre qui té places i qui les ven: hotels, agències, tour operadors i plataformes.

Avui, aquesta essència es podria reconstruir en una versió més lleugera i enfocada: una plataforma de connectivitat (API-first) per a allotjaments independents i petits grups hotelers que els permeti publicar disponibilitat i preus en múltiples canals B2B (agències, corporatius, OTAs, gestors de viatges) amb una sola integració.

La diferència respecte del model original: en lloc de competir per escala global des del primer dia, es comença per un nínxol (per exemple, allotjaments rurals i boutique de Catalunya i el sud d'Europa) i es creix per densitat de clients en una regió, no per abast mundial.

Nota: aquesta és una proposta de reconstrucció, no una descripció verificada del que Hotelbeds fa avui.

El mercat de la distribució B2B d'allotjament és real i gran: hi ha agències, tour operadors, plataformes de reserves i departaments de viatges corporatius que necessiten accés a inventari hoteler de forma programàtica. La mateixa existència i continuïtat de Hotelbeds (empresa activa segons la font) és evidència que aquest mercat sosté actors rellevants amb seu a Barcelona.

El segment que es proposa atacar és el dels allotjaments petits i mitjans (hotels independents, cases rurals, petits grups) que sovint no tenen equip tècnic propi ni accés fàcil als canals B2B. Aquest segment existeix i està poc digitalitzat en clau de distribució programàtica.

Advertiment: no disposo de dades verificades sobre la mida, quota o clients concrets de Hotelbeds; qualsevol quantificació del mercat hauria de validar-se amb estudis sectorials abans de prendre decisions.

Proposta (a validar):

• Subscripció SaaS per allotjament: quota mensual per accés a la plataforma de connectivitat i gestió de canals. Rang estimat: 50–300 €/mes segons mida i nombre de canals.
• Comissió per reserva distribuïda via API: un percentatge sobre el valor de la reserva. Rang estimat: 1–5%, a validar amb els primers clients.
• Setup i integració: pagament únic per connectar el PMS de l'allotjament. Rang estimat: 300–1.500 €.
• Mòdul opcional de revenue management (preus dinàmics) com a upsell.

El model combina ingressos recurrents (subscripció) amb ingressos variables (comissions), cosa que redueix el risc de dependre d'un sol tipus de client.

Proposta en fases (estimació temporal, a validar):

1. Fase 0 – Validació (mesos 0–3): entrevistes amb 20–30 allotjaments independents i 5–10 agències o gestors de viatges per confirmar el dolor i el preu disposat a pagar.
2. Fase 1 – MVP (mesos 3–9): API de disponibilitat i preus, connexió amb 2–3 PMS freqüents al segment, panell bàsic per a l'allotjament. Objectiu: 10–15 allotjaments pilots.
3. Fase 2 – Primers ingressos (mesos 9–18): incorporar 2–3 canals de demanda (una agència, un gestor corporatiu), cobrar les primeres subscripcions i comissions.
4. Fase 3 – Densitat regional (mesos 18–30): arribar a 100–200 allotjaments en una regió, mesurar retenció i marge per client.

El criteri d'èxit de cada fase hauria de ser la retenció i el volum de reserves distribuïdes, no el nombre de registres.

Totes les xifres són estimacions a validar, no dades de l'empresa original:

• Equip fundador i tècnic (12–18 mesos): 2–4 persones. Cost estimat: 120.000–300.000 € (salaris, autònoms, subcontractació puntual).
• Desenvolupament de la plataforma (MVP): 40.000–100.000 € si es combina equip intern i extern.
• Infraestructura cloud i eines: 500–1.500 €/mes, estimació.
• Legal, constitució i contractes: 5.000–15.000 €.
• Comercial i màrqueting inicial: 15.000–40.000 €.
• Total orientatiu d'arrencada: rang de 150.000 a 400.000 € per als primers 12–18 mesos, segons intensitat d'equip i velocitat de desenvolupament.

Aquest rang assumeix un equip petit i un abast regional; un intent de competir globalment des del primer dia multiplicaria la xifra diverses vegades.

• Risc de plataforma: els PMS i els grans distribuïdors poden tancar o obrir APIs i canviar les regles del joc.
• Risc d'escala: el valor de la distribució creix amb el nombre de canals i allotjaments; començar petit pot fer la proposta poc atractiva per a les agències.
• Risc de preu: els allotjaments petits són sensibles al preu i poden trigar a pagar per software.
• Risc de dependència de pocs clients: si els primers ingressos venen de 2–3 agències, la seva marxa pot trencar el model.
• Risc de comparació amb incumbents: competir contra actors consolidats exigeix un nínxol clar i no una imitació a petita escala.
• Risc d'execució tècnica: la integració amb sistemes hotelers és feina lenta i poc glamurosa; subestimar-la és habitual.

Lliçons que es poden extreure de l'experiència d'un actor com Hotelbeds (a partir de la informació pública disponible i de la naturalesa del seu sector):

1. La distribució és un negoci de xarxa: el valor no és el software en si, sinó el nombre de connexions actives entre oferta i demanda. Cal prioritzar densitat sobre abast.
2. Barcelona és una base viable per a un SaaS B2B de viatges: hi ha talent tècnic i ecosistema sectorial.
3. La integració tècnica és el producte: qui resol la connexió amb PMS i canals de forma fiable guanya; qui només fa interfície bonica, no.
4. Els ingressos recurrents i les comissions es complementen: no cal triar un sol model des del primer dia, però cal mesurar la retenció de cada un.
5. Començar regional i créixer per densitat és més defensable que intentar imitar un incumbent global amb menys recursos.

En resum: la reconstrucció viable avui no és "un altre Hotelbeds", sinó una capa de connectivitat B2B enfocada a allotjaments petits i mitjans, començant per una regió, amb un cost d'arrencada estimat de 150.000–400.000 € i el risc principal posat en la integració tècnica i la densitat de xarxa.

Una bedbank com Hotelbeds intermedia entre proveïdors d'allotjament (hotels, agències receptives) i distribuïdors (OTA, agències, tour operadors). El problema tècnic central no és "mostrar hotels": és que el preu d'una mateixa habitació depèn d'un contracte tarifari que canvia (temporades, allotjament mínim, política de cancel·lació, marge del distribuidor, moneda) i que sovint es reconfirma contra el proveïdor en el moment de reservar.

Els sistemes que fallen ho fan per tres motius concrets: (1) el preu mostrat en cerca i el preu confirmat en reserva divergeixen i ningú no pot explicar per què; (2) el marge del distribuidor es calcula en un lloc i es liquida en un altre, i les diferències no es poden conciliar; (3) els contractes tarifaris es despleguen sense versionat, de manera que una reserva feta ahir no es pot reproduir avui.

La solució ha de fer que cada preu sigui reproduïble: donat un identificador de cotització, s'ha de poder reconstruir exactament quin contracte, quina versió i quines regles el van generar.

Arquitectura de serveis amb un nucli síncron i dos processos asíncrons. El motiu de separar-los és que la cerca i la reserva tenen requisits de latència oposats a la ingesta de tarifes i a la liquidació.

``` [Distribuïdor] --HTTPS--> [API Gateway + auth per API key] | +---------------+----------------+ | | [Servei de Cerca] [Servei de Reserves] (read-only, cache) (escriptura, saga) | | [Motor de Preus] <---- contractes ----> [Servei de Contractes] | | [Cache Redis: disponibilitat+preu] [Postgres: reserves, contractes] | | +----------> [Cua d'esdeveniments] <--+ | +----------------+----------------+ | | [Ingesta de tarifes] [Liquidació de comissions] (batch, proveïdors) (batch diari, idempotent) ```

Decisions i motius:

• Postgres com a font de veritat dels contractes tarifaris, amb versionat per fila. Cada canvi de tarifa crea una versió nova immutable; la versió anterior es marca com a superada però no s'esborra. Motiu: una reserva ha de poder referenciar la versió exacta que la va originar.
• Redis per a disponibilitat i preu de cerca amb TTL curt (60–120 s). Motiu: la cerca és el 95% del tràfic i no pot tocar Postgres per cada petició; el TTL curt limita la divergència entre preu mostrat i preu real.
• Reconfirmació obligatòria contra el proveïdor en el moment de reservar. Motiu: la cache pot estar desactualitzada; la reserva és el punt on es paga el preu real. Si el preu reconfirmat difereix del cotitzat per sobre d'un llindar configurable, la reserva falla amb un codi explícit en lloc de cobrar en silenci.
• Patró saga per a la reserva multi-proveïdor. Una reserva pot tocar diversos proveïdors; cada pas té una compensació (cancel·lació) registrada. Motiu: no hi ha transaccions distribuïdes, i una reserva parcialment completada s'ha de poder desfer de forma determinista.
• Esdeveniments a una cua per a liquidació. Motiu: el càlcul de comissions no ha de bloquejar la reserva ni dependre de l'estat actual dels contractes, que pot haver canviat.

Entitats principals (Postgres):

``` contracte id, proveidor_id, hotel_id, moneda, estat, creat_el

contracte_versio -- immutable id, contracte_id, versio, vigent_des, vigent_fins, politica_cancelacio_id, allotjament_minim, creat_el UNIQUE(contracte_id, versio)

tarifa id, contracte_versio_id, tipus_habitacio, regim, preu_base, moneda, regles_json

regla_tarifaria -- temporada, estada mínima, edat nen, etc. id, tarifa_id, tipus, parametres_json

cotitzacio -- resultat de la cerca, reproduïble id, distribuidor_id, hotel_id, contracte_versio_id, tarifa_id, preu_mostrat, moneda, expira_el, hash_entrada

reserva id, distribuidor_id, cotitzacio_id, estat, preu_confirmat, moneda, referencia_proveidor, creat_el

reserva_linia id, reserva_id, tipus_habitacio, hostes, preu

pas_saga id, reserva_id, ordre, accio, estat, resposta_json

liquidacio id, reserva_id, distribuidor_id, marge, comissio, moneda, periode, estat, calculat_el ```

Punts clau:

• `contracte_versio` és immutable i `cotitzacio.contracte_versio_id` la referencia. Això fa que qualsevol cotització sigui reproduïble encara que el contracte hagi canviat després.
• `cotitzacio.hash_entrada` és un hash determinista de tots els paràmetres de la cerca (dates, hostes, distribuidor, filtres). Motiu: permet detectar si dues cotitzacions són realment la mateixa petició i auditar càlculs.
• `liquidacio` es calcula a partir de l'esdeveniment de reserva confirmada, no de l'estat actual del contracte. Motiu: el marge del distribuidor es fixa en el moment de la reserva.

API REST versionada (`/v1`), autenticació per API key + signatura HMAC per distribuïdor. Motiu: els distribuïdors són màquina-a-màquina i cal poder revocar i auditar per client.

Endpoints principals:

• `POST /v1/search` — cerca disponibilitat i preu. Retorna llista de `cotitzacio_id` amb `preu_mostrat` i `expira_el`.
• `POST /v1/quotes/{id}/confirm` — reconfirma contra el proveïdor i retorna el preu ferm o un error de divergència.
• `POST /v1/bookings` — crea la reserva a partir d'una cotització confirmada; executa la saga.
• `GET /v1/bookings/{id}` — estat i línies de la reserva.
• `POST /v1/bookings/{id}/cancel` — cancel·lació amb compensació.
• `GET /v1/settlements?periode=` — liquidacions del període per al distribuïdor.

Integracions de proveïdor: adaptadors per protocol (XML/OTA, REST propietari, fitxer batch). Cada adaptador implementa la mateixa interfície interna (`cercar`, `reconfirmar`, `reservar`, `cancel·lar`) i tradueix errors del proveïdor a un codi intern estable. Motiu: aïllar la lògica de negoci de la variabilitat dels proveïdors.

Esdeveniments publicats a la cua: `quote.created`, `booking.confirmed`, `booking.cancelled`, `settlement.computed`. Consumers idempotents per `id` d'esdeveniment.

Ordre deliberat, perquè cada peça desbloqueja la següent:

1. Model de contractes versionat + ingesta batch d'un sol proveïdor. Sense contractes reproduïbles, res més no és auditable. Un proveïdor n'hi ha prou per validar el model.
2. Motor de preus i endpoint `/v1/search` amb cache Redis. És el camí de més volum i el que permet provar la reproduïbilitat de la cotització.
3. Reconfirmació i `/v1/bookings` amb saga d'un sol pas. Valida el punt crític: divergència entre preu mostrat i confirmat.
4. Liquidació batch diari a partir d'esdeveniments. Tanca el cicle de marge i comissió.
5. Segon adaptador de proveïdor i cancel·lació amb compensació. Aquí es prova que l'arquitectura aguanta multi-proveïdor.

No construir abans d'hora: panell d'administració, multi-moneda avançada i motor de regles configurable per UI. El motor de regles comença com a codi amb tests, no com a configuració.

Mides orientatives per a una primera versió:

• Catàleg: 10^5–10^6 combinacions hotel × tipus d'habitació × temporada. Capaç en Postgres amb índexs per `(hotel_id, vigent_des, vigent_fins)`.
• Cerca: pic de 200–500 req/s; latència objectiu p95 < 300 ms servint des de cache.
• Reserves: ordres de magnitud inferiors (1–5 req/s de pic); latència objectiu p95 < 2 s incloent reconfirmació.

Riscos tècnics i mitigació:

• Divergència preu mostrat/confirmat. Risc principal. Mitigació: TTL curt, reconfirmació obligatòria i error explícit per sobre de llindar; mètrica de divergència per proveïdor.
• Proveïdors amb latència o caigudes. Mitigació: timeouts per adaptador, circuit breaker i degradació a "no disponible" en lloc de preu inventat.
• Explosió de versions de contracte. Mitigació: compactació de versions no referenciades per cap cotització ni reserva, amb període de retenció.
• Doble reserva per reintents. Mitigació: clau d'idempotència a `/v1/bookings` i estat de saga consultable.
• Liquidació incorrecta per esdeveniments duplicats. Mitigació: consum idempotent per `id` d'esdeveniment i recalcul nocturn de control.

• Reproduïbilitat de cotització: test que, donat un `cotitzacio_id`, reconstrueix el preu a partir de `contracte_versio_id` i `tarifa_id` i comprova que coincideix amb `preu_mostrat`. És el test que protegeix el nucli del producte.
• Divergència controlada: test d'integració amb un proveïdor simulat que canvia el preu entre cerca i reserva; ha de retornar l'error de divergència, no cobrar.
• Saga: test que força un error al segon pas i comprova que el primer pas es compensa i la reserva queda en estat `fallida_compensada`.
• Idempotència: dues crides idèntiques a `/v1/bookings` amb la mateixa clau han de produir una sola reserva.
• Liquidació: test que reprocessa el mateix esdeveniment dues vegades i comprova que `liquidacio` no es duplica.
• Càrrega: prova de cerca a 500 req/s amb p95 < 300 ms i taxa d'error < 0,1%.

Nota de fonts: la caracterització d'Hotelbeds com a distribuïdor B2B d'inventari hoteler es basa en la font disponible [Wikipedia] Hotelbeds