White label o booking engine proprio: il conto vero

Il preventivo arriva e sembra sostenibile. Uno sviluppatore di cui ti fidi ha messo un prezzo su un booking engine — ricerca, risultati, checkout, una schermata di amministrazione, tre mesi — e la cifra non è assurda. È da due anni che vuoi un sistema tuo. È in questo momento che la scelta tra white label o sviluppare il proprio booking engine viene decisa davvero, e di solito viene decisa sulle prove sbagliate: il prezzo del primo mese invece della forma del secondo anno.

Il preventivo è onesto. Riguarda però solo la parte del lavoro che riesci a vedere.

Che cosa sta quotando davvero una stima di sviluppo

Quasi ogni stima che ti verrà messa in mano quota superfici: un form di ricerca, una lista di risultati, una pagina con i dati dei passeggeri, uno step di pagamento, una tabella delle prenotazioni nel pannello. È lavoro reale, e una squadra capace lo fa bene. È anche la metà indifferenziata — quella su cui due agenzie che vendono la stessa rotta non competono mai. Nessuno ha mai scelto un'agenzia perché la sua schermata di availability aveva una spaziatura migliore.

L'altra metà è il lato della connessione che dal browser non si vede. È lì che se ne vanno gli anni.

Il costo è il numero di integrazioni, non l'interfaccia

Chiedi l'accesso a un fornitore e non ricevi una chiave API per email di ritorno. Ricevi un ambiente di test, un processo di certificazione, credentials emesse per singola ragione sociale, un documento di regole e un referente che risponde con i suoi tempi. Poi incontri il dialetto particolare di quel fornitore: static rates da una parte e live availability dall'altra, allotment con release period accanto al free-sale, un cut-off che il tuo engine deve rispettare, fare rules che decidono se una modifica è a pagamento, un catalogo di ancillari che non si mappa su quello di nessun altro. Ora moltiplica per il numero di fornitori che i tuoi clienti si aspettano tu abbia.

Una integrazione è un progetto. Sei sono un reparto, e non finisce mai, perché nessuno di quei sei ha accettato di smettere di cambiare.

La stessa trappola sta dietro ogni schermata che il preventivo elenca. La ricerca sembra una funzione finché non ti trovi due compagnie che restituiscono lo stesso itinerario a prezzi diversi e devi decidere, nel codice, quale vede il cliente. Un rimborso sembra un bottone finché la fare rule dice penale, il fornitore dice voucher e il cliente dice carta. Il markup sembra un numero in una pagina di impostazioni fino al giorno in cui vuoi una regola per i clienti corporate, un'altra per un sub-agente a Palermo e una terza per il banco su quella stessa tariffa.

È questa aritmetica che il preventivo lascia fuori, e rispetto all'interfaccia non è un errore di arrotondamento: è il prodotto. Su una piattaforma white label il lavoro è già fatto e già presidiato — il contenuto dei fornitori arriva alla vetrina attraverso i supplier groups invece che attraverso contratti firmati uno alla volta, e un sito accende voli, hotel, pacchetti o attraction a seconda di ciò che vende davvero.

Il confronto che sopravvive al secondo anno

Leggi la tabella da operatore, non da compratore. La domanda in ogni riga è sempre la stessa: di chi è la responsabilità?

Due di quelle righe giocano a favore dello sviluppo interno. Non sono premi di consolazione. Se quello che vendi è abbastanza particolare, pesano più di tutto quello che sta sopra.

Quanto costa sbagliare

Il fallimento di un engine sviluppato in casa non è il progetto che crolla. Quelli si vedono, fanno male e si sopravvivono. La versione costosa è un sistema che funziona — e poi lentamente smette.

Lo sviluppatore che l'ha scritto passa ad altro, e il successivo quota ogni piccola modifica come un rischio perché nessuno dei vivi ha letto quel codice. Un fornitore deprecia un endpoint con i suoi tempi e le prenotazioni iniziano a fallire in un modo che i clienti notano prima del tuo monitoraggio. Una fare rule codificata correttamente il primo anno non viene più rivista, e l'ADM che arriva dopo viene addebitato al tuo numero IATA, non a quello del consulente. Le credentials di pagamento scadono. I certificati scadono. Un framework indietro di due versioni diventa una conversazione sulla sicurezza per cui non avevi previsto una settimana.

Niente di tutto questo arriva sotto forma di fattura, ed è per questo che non compare mai nel confronto che la gente fa davvero. Arriva sotto forma di attenzione. Un titolare che passa il martedì su un PNR rotto quel martedì non vende, e le agenzie che si spengono dopo essersi costruite il sistema raramente lo fanno perché il software si è rotto: si spengono perché la persona che portava clienti adesso è la persona che mantiene il software.

Quando sviluppare è davvero la scelta giusta

A volte lo è, e i casi sono abbastanza specifici da poterti misurare.

• Il software è il tuo elemento differenziante. Se vendi tecnologia ad altre aziende del turismo invece di vendere viaggi, non puoi dare in outsourcing la cosa per cui ti fai pagare.
• Hai già ingegneri, e hai messo a budget il secondo. Non lo sviluppatore che lo costruisce: il manutentore che lo eredita quando il primo se ne va. Uno sviluppo senza piano di successione è un affitto con passaggi in più.
• Gestisci un flusso che nessuno modella. Un operatore di pellegrinaggi che tiene i propri letti e cuce PNR di gruppo sulle scadenze dei visti sta facendo qualcosa che un engine generico non coprirà mai del tutto.

C'è anche una via che non è né l'una né l'altra: comprare la vetrina e sviluppare solo il pezzo che è davvero tuo. La piattaforma espone API voli e hotel proprio per questo, anche se l'accesso comincia con una conversazione e non con una chiave self-service. Valuta l'ibrido prima di impegnarti sull'intero sviluppo, perché la parte che volevi davvero controllare di solito è un flusso, non un engine intero.

E se il tuo modello vive sui sub-agenti, mettine a prezzo anche quello. Qui i credit limit e la fatturazione di settlement sono concetti di prima classe e non un foglio di calcolo che qualcuno riconcilia la domenica; in uno sviluppo interno sono un secondo progetto che nessuno ha messo nel primo preventivo.

Una domanda, fatta a entrambe le parti

Prima di firmare qualsiasi cosa, fai la stessa domanda allo sviluppatore e alla piattaforma: a marzo un fornitore cambia la certificazione — chi fa il lavoro, con la scadenza di chi, e io come lo vengo a sapere? Le risposte non si somiglieranno, e la differenza fra le due è ciò tra cui stai davvero scegliendo.

Confrontare una vetrina che gira con un preventivo è una prova più onesta che confrontare due documenti, quindi se vuoi vedere che cosa viene predisposto prima di impegnarti, avvia un sito nel wizard — non chiede una carta, e il sottodominio che ti dà resta per sempre, anche dopo che colleghi il tuo dominio.