Per fare un matrimonio ci vogliono due persone, e tutte e due devono essere d’accordo.
Sembra una banalità, ma è esattamente la metafora giusta per descrivere cosa succede quando un software gestionale prova a comunicare in automatico con i portali degli enti pubblici italiani.
Da una parte c’è il PMS, pronto a inviare i dati. Dall’altra c’è il portale dell’ente, che molto spesso non ha nessuna intenzione di rispondere. Niente API, niente integrazione, niente matrimonio. Inserimento manuale e via.
È partendo da questo scenario che nell’episodio 269 di Ospitalità 4.0, Marco Matarazzi ed Edoardo Ridolfi hanno aperto una discussione che riguarda ogni albergatore italiano.
Il punto di partenza è arrivato, come spesso accade, da un ticket di supporto: un cliente che si chiedeva perché, nel 2024, non fosse ancora possibile sincronizzare la tassa di soggiorno con un click.
La domanda sembra ingenua, ma in realtà fotografa benissimo il divario che esiste tra quello che la tecnologia potrebbe fare e quello che la pubblica amministrazione italiana permette di fare.
Dal fax al server-to-server: la lunga storia del Portale Alloggiati
Il Portale Alloggiati della Polizia di Stato è forse l’esempio più emblematico di come la digitalizzazione della pubblica amministrazione italiana proceda a step molto lenti, ma alla fine avanzi.
Si è partiti dal modulo cartaceo inviato via fax, una pratica che molti albergatori ricordano con una certa nostalgia mista a sollievo per essersela lasciata alle spalle. Poi è arrivato il portale web, con la possibilità di caricare manualmente i file CSV o TXT generati dai software gestionali, un miglioramento reale ma ancora lontano dall’automazione vera.
La comunicazione diretta server-to-server, quella in cui il gestionale parla direttamente con il portale della Polizia di Stato senza che l’albergatore debba toccare nulla, è diventata possibile solo nel 2022.
Per chi sviluppa software nel settore hospitality, il 2022 è abbastanza tardi.
Non è una critica alla buona volontà di chi ha lavorato al progetto, è semplicemente la constatazione che la domanda di automazione esisteva da anni e la risposta tecnica ha impiegato molto tempo ad arrivare.
Oggi quella risposta c’è, e consiste in un sistema di autenticazione tramite chiavi che permette al PMS di inviare i dati degli ospiti in modo automatico. Il processo per ottenere queste chiavi non è banale, richiede qualche passaggio burocratico che Edoardo ha definito un “volo funambolico”, ma una volta superato funziona.
Il Portale Alloggiati rimane però un sistema pensato per adempiere a un obbligo di legge, non per semplificare il lavoro dell’albergatore.
L’interfaccia è essenziale, la grafica non è priorità di nessuno, ed è giusto che sia così: un portale che nasce per una comunicazione unidirezionale con le forze dell’ordine non ha bisogno di essere bello. L’importante è che funzioni, e che funzioni in modo integrato con i software che gli hotel già usano.
La frammentazione è il vero problema: ISTAT, tassa di soggiorno e dati che scompaiono
Se il Portale Alloggiati ha almeno il vantaggio di essere un sistema nazionale unico, la situazione si complica significativamente quando si passa all’ISTAT e soprattutto alla tassa di soggiorno.
Qui non esiste un’unica controparte con cui dialogare.
Esistono regioni, province, comuni, ognuno con il proprio portale, spesso con le proprie regole, i propri formati, i propri tempi di aggiornamento. Alcune realtà hanno investito in sistemi moderni con API accessibili, altre funzionano ancora con upload manuali di file, altre ancora con form web che non permettono nessun tipo di automazione.
Per uno sviluppatore di software gestionale, questo significa dover costruire e mantenere decine di integrazioni diverse per coprire il territorio nazionale.
Non è impossibile, ma è un lavoro che assorbe risorse senza produrre valore per l’albergatore: ogni ora spesa a integrare un portale comunale è un’ora non spesa a migliorare le funzionalità che l’hotel usa ogni giorno. L’ottimismo di chi auspica una standardizzazione nazionale si scontra con il realismo di chi osserva come ogni comune tenda a muoversi come un’isola, con la sua autonomia, i suoi fornitori, i suoi tempi.
C’è però un aspetto di questa frammentazione che va al di là del semplice disagio operativo, ed è il danno al CRM.
Quando l’albergatore bypassa il gestionale e inserisce i dati degli ospiti direttamente sul portale dell’ente, quei dati non tornano mai nel database del PMS. L’ospite esiste per la questura o per il comune, ma non esiste per il sistema di marketing dell’hotel.
Il percorso verso una maggiore automazione del Portale Alloggiati c’è, e si vede.
Le API si diffondono, le integrazioni migliorano, i portali pubblici evolvono, anche se a un ritmo che chi lavora nel privato trova lento.
Le Extranet di Booking.com o Expedia sono pensate per essere strumenti di lavoro, con interfacce studiate, aggiornamenti frequenti, supporto dedicato.
I portali istituzionali sono pensati per raccogliere un adempimento, e la differenza si sente. Non è un problema di malafede, è una differenza di incentivi: il privato ha tutto l’interesse a rendere il suo strumento usabile, il pubblico ha come obiettivo primario la compliance normativa.
Slope lavora su queste integrazioni esattamente perché ogni dato dell’ospite che passa dal gestionale è un dato che alimenta il CRM, che rende possibile il marketing, che trasforma un adempimento burocratico in un’informazione utile per il futuro dell’hotel.
Non è un dettaglio tecnico, è la differenza tra un database che cresce e uno che resta fermo.
