Orari e prenotazioni nel sito che hai già, senza rifarlo

Sì, puoi aggiungere orari, prossime partenze e ricerca delle prenotazioni al sito che hai già, senza rifarlo. La strada più pulita è un widget sviluppato come web component: un piccolo componente che si inserisce in una pagina WordPress, o di un altro CMS, con poche righe di codice, legge i dati da un sistema esterno e manda il cliente al motore di prenotazione. Il sito resta com’è, con i suoi testi, il suo design e il suo posizionamento sui motori di ricerca; cambia solo ciò che il visitatore può fare dentro quelle pagine.

Perché non serve rifare il sito

Quando un operatore vuole vendere meglio online, la prima proposta che riceve spesso è «rifacciamo il sito». A volte ha senso. Molte altre volte il sito funziona: è indicizzato, è stato pagato, chi lo aggiorna sa usarlo. Quello che manca è una funzione precisa: far vedere gli orari, le prossime partenze, i prezzi e permettere di iniziare una prenotazione senza uscire dalla pagina.

Rifare tutto per aggiungere una funzione comporta costi e rischi che si possono evitare:

• si rischia di perdere posizionamento se cambiano indirizzi e struttura delle pagine;
• chi gestisce i contenuti deve imparare uno strumento nuovo;
• i tempi si allungano, perché insieme alla funzione nuova si rifà anche tutto il resto.

Un widget separa i due problemi: il sito resta il contenitore, il widget porta i dati e la prenotazione.

Come funziona un widget come web component

Un web component è un elemento personalizzato che il browser riconosce come un tag qualsiasi. Nel sito si inserisce un tag e uno script; da quel momento, in quel punto della pagina compare il widget, con la sua logica e i suoi dati.

Rispetto alle alternative più comuni:

Il vantaggio pratico è che lo stesso widget si inserisce in siti costruiti con strumenti diversi. Se gestisci più siti, o se il tuo sito cambierà piattaforma in futuro, il widget si sposta con poche righe.

Gli orari li gestisci tu, da un pannello

Un widget che mostra orari sbagliati fa più danni di nessun widget. Per questo la domanda chiave non è «come lo inserisco», ma «chi aggiorna i dati e dove».

La soluzione che preferisco è un CMS headless, cioè un pannello di gestione dei contenuti separato dal sito, che espone i dati al widget. Con Strapi, per esempio, chi lavora in ufficio aggiorna orari stagionali e tariffe da un’interfaccia semplice, e il widget li legge in automatico. Niente più tabelle incollate a mano nelle pagine, niente PDF degli orari da ricaricare a ogni cambio di stagione.

In questo modo:

• l’orario esiste in un solo posto e ogni pagina che lo mostra è sempre aggiornata;
• le tariffe possono avere categorie diverse (per esempio adulti, bambini, senior, gruppi);
• il sito resta gestito come prima, da chi lo gestiva già.

Cosa può fare il widget

Dipende da cosa vendi, ma per un operatore di corse e partenze le funzioni più utili sono queste:

• ricerca della tratta, con partenza, arrivo, numero di passeggeri e calendario per andata e ritorno;
• prossime partenze, aggiornate da sole: le corse già passate o sospese spariscono, e quando le corse del giorno sono finite il widget passa al giorno dopo;
• orari e tariffe stagionali, filtrabili per porto o punto di partenza;
• passaggio al motore di prenotazione, con la ricerca già compilata e nella lingua giusta.

Se la prenotazione vera e propria avviene in un booking engine, il widget è la porta d’ingresso: raccoglie la scelta del cliente nel punto della pagina in cui l’interesse è più alto e lo porta al passo successivo senza fargli ripetere la ricerca.

Convivere con il sito che lo ospita

Questo è il punto in cui si vede la differenza tra un widget fatto bene e uno che «a volte si rompe». Il sito ospite ha i suoi stili, i suoi menu, i suoi script. Il widget deve funzionare dentro quel contesto senza disturbarlo e senza esserne disturbato.

I problemi tipici sono pochi ma ricorrenti:

• gli stili si mescolano: un font, un margine o un colore del sito finisce nel widget, o viceversa;
• gli elementi si sovrappongono: un calendario o una finestra si apre sotto l’intestazione fissa del sito invece che sopra;
• sul telefono lo spazio non basta: una ricerca completa va aperta in una finestra a tutto schermo che copra anche l’intestazione del sito;
• la ricerca scompare scorrendo: in pagine lunghe conviene una barra di ricerca che resta visibile.

C’è anche un aspetto meno visibile: se l’API che fornisce i dati non accetta richieste da un altro dominio (il blocco CORS dei browser), il widget non riesce a leggerla. Si risolve con un piccolo proxy sullo stesso dominio del sito, che inoltra solo i percorsi autorizzati e nient’altro.

Misurare cosa succede

Un widget è utile se sai quanto viene usato. Collegandolo a Google Tag Manager, ogni azione importante (una ricerca, la scelta di una data, il passaggio alla prenotazione) diventa un evento che puoi leggere nei tuoi strumenti di analisi. Così si capisce dove le persone si fermano e quali pagine portano davvero verso la prenotazione.

Un esempio reale

In un progetto per operatori di trasporto via mare ho sviluppato più widget di orari, prossime partenze e prenotazione da inserire nei siti già esistenti, costruiti con WordPress e con altri CMS. I widget sono web component realizzati con Angular Elements; orari e tariffe stagionali sono gestiti da un back office dei contenuti su Strapi, con filtri per porto.

La ricerca ha partenza, arrivo, passeggeri e calendario per andata e ritorno, e porta al motore di prenotazione nella lingua giusta. Le prossime partenze si aggiornano da sole, escludono le corse passate o sospese e passano al giorno successivo; esistono in versione desktop e mobile, in italiano e in inglese. Su mobile la ricerca si apre in una finestra che nasconde l’intestazione del sito ospite, e nelle pagine lunghe resta disponibile una barra di ricerca fissa.

Le parti più delicate sono state quelle descritte sopra: far convivere i widget con stili e livelli di sovrapposizione dei siti ospiti, e passare da un proxy sullo stesso dominio, con percorsi in whitelist, dove l’API non consentiva richieste da altri domini. Ogni widget è distribuito come un unico file, con un meccanismo che costringe il browser a scaricare la versione nuova a ogni aggiornamento.

Quando conviene un widget e quando no

Un widget è la scelta giusta quando il sito funziona e manca una funzione precisa. È meno adatto quando:

• il sito è da rifare comunque, per altri motivi;
• il flusso di prenotazione deve stare tutto dentro la pagina, compreso il pagamento, e il sito ospite non è sotto il tuo controllo;
• i dati da mostrare non esistono ancora in nessun sistema e vanno prima organizzati.

In quest’ultimo caso il lavoro vero è a monte: decidere dove vivono orari, disponibilità e prezzi. Ne parlo nell’articolo su come funziona un booking engine per tour operator, escursioni e noleggi e, per il collegamento tra sistemi diversi, in quello su API e integrazioni tra software aziendali.

Domande frequenti

Il widget rallenta il mio sito?

Un widget ben fatto pesa poco e si carica come un normale script. Conviene distribuirlo come un unico file, con un sistema che forzi il browser a scaricare la versione nuova a ogni aggiornamento.

Funziona anche se il mio sito non è WordPress?

Sì. Un web component è uno standard del browser: si inserisce in qualsiasi CMS che permetta di aggiungere un tag e uno script alla pagina.

Chi aggiorna gli orari?

Tu o il tuo staff, da un pannello dei contenuti separato dal sito. Il widget li legge in automatico, quindi non serve toccare le pagine.

Da dove partire

Se il tuo sito funziona ma non vende quanto potrebbe, possiamo valutare insieme cosa aggiungere e dove. Puoi vedere come lavoro sulle integrazioni e sui booking engine, oppure raccontarmi il tuo caso: la prima analisi è gratuita.