Volotea

Volotea és una companyia aèria amb seu a Barcelona. Segons la font disponible (Wikipedia), opera vols regionals. La classificació sectorial que consta a les dades rebudes ("Software i SaaS") no coincideix amb la descripció de la font, i no es pot verificar amb el material disponible.

Segons Wikipedia, Volotea es va fundar el 2011. La font disponible no detalla en el material subministrat els fundadors ni el capital inicial; aquestes dades no consten.

D'acord amb la font, Volotea és una aerolínia de vols regionals. El detall de rutes, bases i segments de clientela no consta a la informació disponible.

No consta informació sobre l'evolució financera, el creixement de flota o el volum de passatgers en el material subministrat.

No va tancar. Les dades registrals indiquen que l'empresa és activa. Per tant, aquesta secció no té contingut aplicable.

No aplicable en tant que empresa activa. No consta informació sobre el seu impacte en el sector a la font disponible.

No consta. La font disponible no identifica els fundadors en el material subministrat. Per obtenir aquesta informació caldria consultar el registre mercantil (BORME) i les notes de premsa corporatives de la companyia.

La lliçó operativa principal és de control de qualitat de les dades: quan la classificació sectorial d'una fitxa (en aquest cas "Software i SaaS") contradiu la font citada (que descriu una aerolínia), cal aturar l'anàlisi i verificar abans de redactar conclusions. En aquest cas, la discrepància afecta la mateixa naturalesa de l'empresa i invalida qualsevol lectura sobre el seu model de negoci. Addicionalment, incloure una empresa activa en una sèrie d'empreses tancades distorsiona l'anàlisi; cal filtrar per estat registral abans de començar.

El fet verificat és que Volotea és una aerolínia de vols punt a punt amb seu a Barcelona, fundada el 2011 i registralment activa [Wikipedia]. El brief, però, la classifica com a "startup de software i SaaS", cosa que contradiu la font disponible. Abans de dissenyar res, cal aclarir aquesta discrepància: o bé el brief es refereix a una altra empresa amb el mateix nom, o bé l'etiqueta sectorial és un error.

Si prenem com a base l'essència real de Volotea —connectar ciutats mitjanes europees amb vols directes, sense hub, amb una operació lleugera—, la pregunta "què es podria construir avui" té una resposta honesta: no una aerolínia nova (el capital i les llicències ho fan pràcticament inviable per a un emprenedor), sinó la capa de software que una aerolínia d'aquest tipus necessita. Això sí que encaixaria amb l'etiqueta "SaaS" del brief.

Proposta (no fet): un SaaS de gestió de rutes i revenue management per a aerolínies regionals i operadors punt a punt, venut com a subscripció a companyies petites que no poden pagar els sistemes grans. És una proposta, no una dada verificada.

El mercat verificable és el de les aerolínies regionals i de baix cost que operen punt a punt a Europa. Volotea n'és un exemple real i actiu [Wikipedia]. Aquest segment existeix i té necessitats operatives concretes: planificació de rutes, gestió d'ocupació, preus dinàmics i coordinació amb aeroports secundaris.

El que no podem afirmar amb la font disponible és la mida d'aquest mercat, el nombre d'operadors comparables ni el pressupost que dediquen a software. Qualsevol xifra aquí seria inventada. El que sí que és raonable com a hipòtesi a validar: el nombre d'aerolínies punt a punt europees és limitat (desenes, no milers), cosa que fa que el mercat sigui concentrat i que cada client compti molt.

Proposta, a validar: subscripció SaaS per operador, amb un component variable segons volum de vols gestionats. Model de dos nivells: un mòdul base de planificació de rutes i un mòdul avançat de preus i ocupació.

Alternativa a considerar: vendre el programari com a servei gestionat (l'operador externalitza la funció) en lloc de llicència pura. Això augmenta l'ingrés per client però també el cost d'operació.

Cap d'aquestes xifres és verificada. Els imports concrets de subscripció s'han de fixar amb entrevistes a operadors reals, no amb estimacions d'escriptori.

Fase 0 — aclarir el brief: confirmar si "Volotea" del brief és l'aerolínia o una altra empresa. Sense això, tot el pla és especulatiu.

Fase 1 — validació (estimació: 2-3 mesos): entrevistes amb 10-15 operadors punt a punt europeus per entendre quines eines fan servir i quant paguen.

Fase 2 — prototip (estimació: 3-4 mesos): un mòdul únic (planificació de rutes) amb un o dos clients pilot.

Fase 3 — primers contractes (estimació: mesos 6-12): convertir pilots en subscripcions de pagament.

Aquest calendari és una estimació de treball, no una dada.

Rang estimat, a validar, per als primers 12 mesos:

• Equip fundador i un o dos desenvolupadors: 150.000-250.000 € (estimació).
• Validació de mercat i viatges: 15.000-30.000 € (estimació).
• Infraestructura i eines: 10.000-20.000 € (estimació).
• Legal i constitució: 5.000-15.000 € (estimació).

Total orientatiu: 180.000-315.000 € per al primer any (estimació àmplia, a validar). Si la idea fos reconstruir una aerolínia real, el cost seria d'ordres de magnitud superiors i fora de l'abast d'una startup; no donem xifra perquè no tenim cap font que la sostingui.

• Risc de brief erroni: si l'etiqueta "SaaS" és incorrecta, tot el pla parteix d'una premissa falsa. És el risc número u.
• Mercat concentrat: pocs clients potencials; perdre'n un deu molt.
• Cicle de venda llarg: les aerolínies compren a poc a poc i amb exigències de seguretat i integració.
• Competència de sistemes grans ja instal·lats: cost de canvi alt per al client.
• Risc financer: un any de runway pot no bastar per tancar el primer contracte.

Lliçons de l'informe original, aplicables aquí:

1. Verificar les dades abans de construir: el brief contenia una contradicció (aerolínia vs. SaaS) que, si no es detecta, contamina tot el pla.
2. Separar sempre fet de proposta: les fonts disponibles eren mínimes (una entrada de Wikipedia), i això obliga a marcar cada afirmació.
3. Triar un nínxol concret i petit on l'equip pugui guanyar: el segment punt a punt europeu és limitat però real.
4. No confondre l'essència amb la forma: l'essència de Volotea és l'operació lleugera punt a punt; la forma (aerolínia) no és replicable avui per a un emprenedor.
5. Pressupostar amb rangs i dir-ho: tota xifra d'aquest informe és estimació a validar, no dada verificada.

Volotea és una aerolínia de baix cost fundada el 2011 amb seu a Barcelona, que opera vols punt a punt entre ciutats mitjanes europees, sovint sense connexió amb grans hubs [Wikipedia]. Aquest model —moltes rutes, baixa freqüència per ruta, flota homogènia d'Airbus A319/A320— genera necessitats tècniques molt particulars que els sistemes de reserva tradicionals (PSS de grans proveïdors) cobreixen malament i car:

• Inventari fragmentat per ruta: cada ruta és gairebé independent; no cal un motor de connexions complex, però sí un inventari de seients per vol amb control de sobrevenda i tarifació per demanda.
• Cost per transacció: els PSS heretats cobren per segment i per reserva, cosa que penalitza un model de molts vols curts i marge prim.
• Gestió de disrupcions: cancel·lacions i retards en rutes punt a punt sense hub fan que la reubicació sigui manual i costosa.
• Integració amb distribució: cal connectar amb GDS, OTAs i el canal directe sense dependre d'un únic proveïdor.

La solució proposada és un PSS lleuger modular (reserva, inventari, tarifació, operacions) que Volotea pugui posseir i evolucionar, amb APIs obertes i cost marginal baix per transacció.

Arquitectura de microserveis orientada a esdeveniments, desplegada en un núvol europeu (per residència de dades i latència cap a Barcelona i els aeroports on opera).

``` [Canals] Web/App | GDS/OTA (via NDC/EDIFACT) | Agències \ | / \ v / +------------------------------+ | API Gateway (auth, rate) | +------------------------------+ | | | +------v--+ +----v-----+ +--v-----------+ | Booking | | Pricing | | Inventory | | Service | | Engine | | Service | +---------+ +----------+ +--------------+ \ | / \ v / +--------------------------+ | Event Bus (Kafka) | +--------------------------+ | | | +------v--+ +----v-----+ +--v-----------+ | Check-in| | Ops/ | | Ancillaries | | Service | | Disrupt. | | Service | +---------+ +----------+ +--------------+ ```

Decisions i motius:

• Microserveis amb event bus (Kafka): la reserva, la tarifació i l'inventari tenen cicles de canvi diferents; desacoblar-los permet desplegar tarifació dinàmica sense tocar el booking. Els esdeveniments (`SeatSold`, `FlightCancelled`, `PriceChanged`) donen traçabilitat i permeten reconstruir l'estat.
• Inventari amb control optimista + compensació: per a rutes punt a punt amb poca freqüència, una reserva de seient es fa amb una transacció curta i un timeout; si falla, es compensa. Evita bloquejos llargs que serien costosos en pics de venda.
• Pricing com a servei separat amb regles versionades: les tarifes canvien per demanda i campanyes; versionar les regles permet auditar per què es va cobrar un preu.
• NDC com a interfície de distribució: adoptar NDC (New Distribution Capability) redueix dependència d'EDIFACT i permet oferir ancillaries a OTAs, alineat amb el model de baix cost.
• Residència de dades a la UE: compliment GDPR i latència baixa cap als canals europeus.

Model relacional per a la part transaccional (reserves, pagaments) i documental per a configuracions (regles de preu, catàleg d'ancillaries).

Entitats principals:

• `Route(id, origin_iata, destination_iata, distance_km, active)`
• `Flight(id, route_id, flight_number, departure_utc, arrival_utc, aircraft_id, status)`
• `Aircraft(id, type, registration, seat_map_id, seats_total)`
• `FareClass(id, code, cabin, refundable, change_fee)`
• `FareRule(id, fare_class_id, version, valid_from, valid_to, conditions_json)`
• `Inventory(flight_id, fare_class_id, seats_total, seats_sold, seats_held, overbooking_limit)`
• `Booking(id, pnr, channel, status, created_at, total_amount, currency)`
• `BookingSegment(id, booking_id, flight_id, fare_class_id, passenger_id, seat_no, status)`
• `Passenger(id, booking_id, full_name, doc_type, doc_number, dob)`
• `Payment(id, booking_id, method, amount, status, psp_ref)`
• `Ancillary(id, code, type, price_rule_id)`
• `DisruptionEvent(id, flight_id, type, detected_at, affected_bookings_json)`

Motius:

• `Inventory` separat de `Flight` permet ajustar capacitat i sobrevenda sense tocar el vol.
• `FareRule` versionat dona auditabilitat del preu aplicat.
• `pnr` com a clau de negoci externa (compatible amb GDS) però `id` intern com a clau primària.
• `DisruptionEvent` desa l'impacte per poder recalcular reubicacions.

APIs REST/JSON internes i externes, amb contracte OpenAPI versionat.

• Booking API (interna + canal directe):

- `POST /v1/bookings` — crea reserva (hold + confirmació en dos passos). - `GET /v1/bookings/{pnr}` — consulta. - `POST /v1/bookings/{pnr}/cancel`.

• Inventory API:

- `GET /v1/flights/{id}/availability` - `POST /v1/flights/{id}/holds` (TTL curt, compensació si expira).

• Pricing API:

- `POST /v1/pricing/quote` — retorna preu amb desglossament i `rule_version`.

• Check-in API:

- `POST /v1/checkin` — emet boarding pass (PDF/Apple Wallet).

• Ops API:

- `POST /v1/disruptions` — registra cancel·lació/retard i dispara esdeveniments.

• Integracions externes:

- GDS/OTA via NDC (schema XML/JSON NDC 21.x) — motiu: estàndard del sector, redueix desenvolupament per canal. - PSP (Stripe/Adyen) via API REST — motiu: no construir pagaments propis. - Proveïdor de dades meteorològiques i NOTAM per alimentar disrupcions. - Sistemes aeroportuaris (DCS) per a facturació de handling, via API o fitxers.

Ordre per valor i risc:

1. Inventory Service + Flight/Aircraft model — sense inventari fiable no hi ha res; és la base.
2. Pricing Engine amb regles versionades — permet vendre amb marge controlat.
3. Booking Service (hold + confirm) amb Payment — el flux de venda mínim viable.
4. Canal directe (web) sobre Booking API — primer canal, control total.
5. Check-in Service — necessari per operar.
6. Integració NDC amb un GDS/OTA pilot — amplia distribució.
7. Ops/Disruption Service — es pot iniciar amb un flux manual assistit i automatitzar després.

Motiu: cada pas desbloqueja el següent i permet validar amb vols reals progressivament.

• Volum: una aerolínia com Volotea opera desenes de rutes i centenars de vols setmanals; el pic de reserves es concentra en campanyes. Cal dimensionar per a pics de 10-50x la mitjana en esdeveniments de venda.
• Consistència d'inventari: el risc principal és la sobrevenda no controlada. Mitigació: holds amb TTL, control optimista i reconciliació periòdica.
• Latència de pricing: regles dinàmiques poden fer lenta la cotització; mitigació: caché de quotes per vol+classe amb invalidació per esdeveniment.
• Integració NDC: l'ecosistema NDC encara és heterogeni; risc d'adaptacions per canal. Mitigació: capa d'adaptació per proveïdor.
• Compliment: GDPR (dades de passatgers), PSD2 (pagaments), i requisits de facturació. Risc de multes si no es tracta des del disseny.
• Migració: si se substitueix un PSS existent, cal convivència i migració de PNRs; risc alt, planificar per fases.

• Proves de càrrega sobre Inventory i Booking amb pics simulats de campanya (objectiu: p95 < 300 ms en disponibilitat).
• Proves de consistència: injecció de fallades al event bus i verificació que l'inventari reconcilia (seats_sold + holds = seats_total dins tolerància).
• Auditoria de preus: per a una mostra de reserves, reproduir el preu amb `rule_version` i comprovar coincidència.
• Pilot amb rutes reals: desplegar en un subconjunt de rutes i comparar mètriques (conversió, sobrevenda, temps de check-in) amb el sistema anterior.
• Test de disrupcions: simular cancel·lació d'un vol i validar que les reubicacions proposades compleixen regles de negoci.
• Revisió de compliment: auditoria GDPR/PSD2 abans de posar en producció el canal directe.