Plan3 by AviLabs: riprotezioni e assistenza ai passeggeri con un click

[kenadams]

In questi giorni si è parlato (mea culpa) di ritardi, annullamenti e della difficoltà di gestire le irregolarità operative che inevitabilmente si verificano nel trasporto aereo. Ho deciso di approfondire per capire quanto insormontabili siano le complessità legate alla gestione di 10, 100, 1.000, 10.000 riprotezioni e assistenze nel giro di una giornata.

Una delle prime cose che ho scoperto è che qualcuno è già al lavoro e pare aver già commercializzato una soluzione.

L'azienda è islandese e si chiama AviLabs. Il prodotto si chiama Plan3.

Mi pare di capire che i soci siano tutti ex Wow Air e che l'unico cliente sia Play.

Un accordo con Sabre annunciato nel marzo scorso potrebbe portare a una maggiore adozione della tecnologia che propongono.

Ho scaricato una presentazione dal sito che trovate qui. Se mantengono le promesse mi pare che abbiano risolto buona parte delle complessità relative alla riprotezione e l'assistenza.

Feature interessanti che eliminano molte delle difficoltà che impediscono ai vettori in caso di IRROPS di prenotare voli alternativi, fornire assistenza, inviare email e comunicazioni ai passeggeri, ecc. E' chiaro che se uno atterra in emergenza in Groenlandia questo strumento non sarà utilissimo: ma magari a CDG risolve un bel po' di beghe.

 

[13900]

Praticamente fanno da 'middleware' tramite API connesse ai sistemi delle varie compagnie aeree. Sinceramente il problema non e' quello di aggregare i dati, il problema e' quello di ottenere i dati. Il reaccommodation tool di AA, in uso sulla JB Atlantica, funziona da quasi un decennio ma per colpa del modo con cui Sabre e Amadeus funzionano si deve andare a creare un 'doppione' per ogni PNR, uno per chi usa 1A e l'altro per chi usa Sabre...

 

[WB]

Sembra molto interessante, vedo però delle criticità nell'andare a lavorare in un ecosistema che, ricordo qualche vecchio thread, è molto antiquato da un punto di vista informatico con poca affidabilità ed eccessiva ridondanza di dati.
Ho anche i miei dubbi sull'effettiva "zero integration required", mi ricorda i commerciali di software house che di solito esordiscono con "basta schiacciare un bottone".

La direzione è però quella giusta e ricalca flussi implementati e ben rodati in molti altri settori.

 

[Seaking]

Grande Ken,

Ottimo spunto per una discussione ad ampio spettro sull’annosa questione.

Due osservazioni:

- una delle poche cose che funziona davvero bene in Sabre è un modulo chiamato Intelligence Exchange, capace di fare molte cose (tramite apposite business rules) con i dati provenienti sia da Sabre che da Amadeus. L’azienda che lo ha sviluppato è islandese ed è stata poi acquisita da Sabre stessa. Il fatto che questo applicativo sia stato sviluppato in Islanda e che stiamo collaborando con Sabre non è del tutto casuale

- uno dei motivi per i quali riproteggere è così complicato è per via della struttura dati e della coesistenza di PNR, Ticket e EMD. Se perdi la sincronizzazione di questi dati quando riproteggi, ecco li che scoppiano i casini, tipo check-in che va in errore perché il sistema si è perso il link del relativo biglietto.
Come ho scritto più volte io mi auguro che One Order riesca nel tempo a diventare il nuovo standard. Risolta alla radice la magagna della struttura dati anni 80, le riprotenzioni diventeranno tecnicamente molto più semplici e rapide.

 

[kenadams]

Il problema -- dunque -- sembra essere principalmente relativo alla gestione del PNR/e-ticket (con gli annessi e connessi sistemi).

Il numero di edge cases sara' infinito ma suppongo che le variabili principali siano:
- Quale segmento dell'itinerario (inbound/outbound) sta percorrendo il pax.
- Quale coupon (si chiama cosi'?) dell'itinerario sta percorrendo. Cioe': se e' un volo che fa parte di un ritorno con scalo, il volo compromesso e' quello prima dello scalo oppure l'ultimo.
- Chi ha emesso il biglietto.
- Chi opera il volo.
- Se vi sia o meno bagaglio imbarcato.
- La classe di servizio.

Ci sono altre variabili importanti?

Lo dico perche' a naso ipotizzo che:
- Un passeggero all'ultimo volo di un itinerario non abbia bisogno di un PNR bensi' di un volo che lo conduca alla destinazione finale. E anche il vettore del vecchio PNR se ne fa poco.
- Un passeggero al primo volo di un itinerario non ha alcuna urgenza di avere un PNR per il volo di ritorno: ha urgenza di avere un volo che lo conduca alla destinazione finale. Se -- invece di fargli perdere ore in attesa che un umano modifichi manualmente l'itinerario associato al PNR -- gli si desse intanto il primo volo verso la destinazione finale (con uno due o anche trenta PNR nuovi) per poi (a passeggero riavviato in volo) mettersi a correggere manualmente il PNR originale... secondo me si farebbe una cosa giusta.

Lo dico perche' -- messa cosi' -- sembra che ai vettori interessi piu' il PNR del PAX.

@13900 Comprendo perfettamente il problema della sincronizzazione dei PNR in sistemi diversi ma non mi sembra un problema impossibile da risolvere. Anzi. Ho come il sospetto che Plan3 abbia nel proprio backend un ID Graph che serve a questo: associare vari PNR all'identita' che conta, quella del passeggero.

 

[imac72]

Secondo me bisogna fare un distinguo tra compagnie aeree point to point (LCCs) e network carriers (FSCs) in quanto le complessità sono totalmente differenti.

Le compagnie low cost - grazie a Navitaire e alle integrazioni di Navitaire con third parties ma anche easyJet che non utilizza Navitaire - in caso di cancellazioni/rescheduling/disruptions permettono di prenotare voli alternativi (sempre con la stessa compagnia), fornire assistenza, inviare comunicazioni ai passeggeri, voucher per pasti virtuali, etc. attraverso app o sito web della compagnia aerea X. Anche qui non è tutto perfetto per diversi motivi tipo: agenzia di viaggi che non inserisce i dati di contatto del passeggero, i bar/ristoranti che sono restii ad accettare voucher elettronici, etc ma rispetto a 10 anni fa sono stati fatti passi in avanti notevoli.

Per le compagnie full service le complessità aumentano esponenzialmente soprattutto nei casi di joint ventures, interlines, alleanze e code-shares in quanto non sempre si utilizzano gli stessi sistemi (PSS, DCS, etc.), ci sono accordi in essere più o meno vantaggiosi per re-routing, come anche un discorso di privacy verso il passeggero - questi sono i principali motivi perché ti fanno passare passare dai banchi transiti o dalle biglietterie.

Bisogna anche essere onesti nel dire che sviluppare un software che faccia tutto quello che desidera @kenadams - per quanto lecito dal punto di vista del passeggero e della customer experience/satisfaction - in realtà è un costo non indifferente per una compagnia aerea. Al momento le airlines focalizzano gli investimenti solo su tools che possono generare revenue e ROI, indubbiamente una visione molto limitata ma questo succede nella realtà, a parole tutti customer centric ma nella realtà non è proprio così, i pax tutelati maggiormente sono quelli alto spendenti, i.e.platinum card, Senator, etc...

Bisogna anche dire comunque che l'operatività delle compagnie aeree ha degli standard molto alti quindi disruptions importanti sono eventi straordinari, ovviamente nel picco delle operazioni con problemi di ATC, slots, off duty, meteo, handlers con personale al minimo, scioperi, staff OCC ai limiti, etc tutto diventa molto più complicato.

 

[Seaking]

Ken il PNR serve sempre perché è quell’oggetto che contiene i dati del passeggero e del o dei voli prenotati, mentre il biglietto prova che il pagamento è avvenuto.

Ed è questa la grande anomalia che nell’anno domini 2023 ancora affligge il settore: una struttura dati nata quando internet non c’era, il cui retaggio comporta complessità oggi pesantissime da gestire.

Per le LCC, discorso diverso perché loro sono nate ticketless e non hanno le complessità dei network carrier.

 

[kenadams]

Ken il PNR serve sempre perché è quell’oggetto che contiene i dati del passeggero e del o dei voli prenotati, mentre il biglietto prova che il pagamento è avvenuto.

Ed è questa la grande anomalia che nell’anno domini 2023 ancora affligge il settore: una struttura dati nata quando internet non c’era, il cui retaggio comporta complessità oggi pesantissime da gestire.

Per le LCC, discorso diverso perché loro sono nate ticketless e non hanno le complessità dei network carrier.

Questo mi e' abbastanza chiaro (posto che ho millemila curiosita' sui dettagli a me ignoti che inevitabilmente complicano ulteriormente le cose).

Detto questo, continuo a ritenere che sia questione di volonta' e non di difficolta' oggettive. Mi spiego meglio: che i sistemi di oggi siano una stratificazione pazzesca di decenni di mezze misure mi e' chiaro e non lo dubito. Che sia difficile, con questi sistemi, gestire i casini e' ovvio. Che sia davvero difficile superare questo sistema mi sembra invece incredibile: credo che -- come scrive @imac72 -- le linee aeree semplicemente abbiano zero voglia di investire in una soluzione.

L'azienda per la quale lavoro opera nel campo di assicurazioni mediche sponsorizzate dal governo americano. Assicuro che c'e' di mezzo un'obsolescenza tecnologica formidabile, condita da interazioni giurassiche fra pubblico e privato (assicuratori, governo e sistemi sanitari). Eppure in meno di anno un gruppo di tre (3) ingegneri con poche centinaia di migliaia di dollari di budget ha sviluppato una serie di processi che integrano tutti questi dati, li trasformano e li rendono perfettamente fruibili. Hanno durato fatica ma -- per loro stessa ammissione -- non hanno inventato niente. La sfida dell'integrazione di dati e sistemi e' stata perlopiu' superata negli ultimi anni del decennio scorso. E' ormai solo questione di volonta'.

 

[Seaking]

Ma per tutto questo ci sta pensando IATA con One Order, dopo anni di immobilismo.

Iniziativa complessa e dall’esito non certo, ma per ora è l’unica cosa che abbiamo per risolvere davvero il problema alla sua radice.