Una camera può risultare disponibile sul sito dell’hotel, essere proposta su più portali e venire richiesta telefonicamente nello stesso momento. Se prenotazioni, tariffe e disponibilità non vengono aggiornate in modo coerente, il problema non resta confinato nel software: arriva alla reception con un ospite che si aspetta una camera già venduta.
Per questo un gestionale alberghi non può essere valutato soltanto per la semplicità dell’interfaccia o per le funzioni amministrative. Deve inserirsi in un’architettura che colleghi PMS, channel manager, booking engine, reception, reparti interni, pagamenti e relazione con l’ospite.
Prima di scegliere una piattaforma bisogna quindi stabilire quale sistema governi ogni dato, quali strumenti possano modificarlo e quali integrazioni siano davvero necessarie.
Una camera può essere venduta una sola volta
Nel commercio tradizionale un prodotto esaurito può essere riordinato. In albergo la disponibilità ha anche una dimensione temporale: una determinata camera, o tipologia di camera, per una determinata notte.
Una prenotazione modifica contemporaneamente:
- date di arrivo e partenza;
- disponibilità residua;
- tipologia o camera assegnata;
- numero di ospiti;
- trattamento;
- tariffa e condizioni;
- canale di provenienza;
- importo e garanzie;
- eventuali richieste speciali.
Quando queste informazioni vengono inserite o modificate manualmente in più sistemi, ogni variazione aumenta il rischio di incoerenza.
Uno scenario di overbooking
Una camera viene prenotata telefonicamente per tre notti. La reception registra la richiesta nel calendario interno, ma la disponibilità rimane aperta su un portale OTA.
Poco dopo arriva una prenotazione online per una delle stesse notti. Il sistema accetta entrambe perché i due strumenti non condividono correttamente l’inventario.
La struttura deve ora trovare una sistemazione alternativa, contattare uno degli ospiti, sostenere eventuali costi e ricostruire dove si sia interrotto il flusso.
L’overbooking non nasce sempre da una disattenzione. Può dipendere da:
- mapping errati tra camere e tariffe;
- allotment incoerenti;
- cancellazioni o modifiche non recepite;
- aggiornamenti falliti;
- inserimenti manuali;
- più calendari considerati contemporaneamente attendibili.
La documentazione delle Connectivity APIs di Booking.com distingue disponibilità, prezzi, restrizioni, prenotazioni e altre aree di collegamento. La semplice dicitura “integrato con Booking.com” non chiarisce quindi quali dati vengano realmente scambiati.
Durante la valutazione bisogna verificare:
- se vengono ricevute nuove prenotazioni, modifiche e cancellazioni;
- se vengono aggiornati inventario, tariffe e restrizioni;
- quali flussi rimangono gestiti nell’Extranet;
- con quali tempi avvengono gli aggiornamenti;
- come vengono segnalati gli errori;
- se esiste un registro delle trasmissioni non riuscite;
- chi interviene quando il collegamento si interrompe.
Segnali di un’architettura fragile
- prenotazioni copiate dalle email al gestionale;
- disponibilità aggiornata manualmente sui portali;
- tariffe modificate in più strumenti;
- camere fuori servizio ancora vendibili;
- cancellazioni registrate in ritardo;
- errori di sincronizzazione non segnalati;
- più calendari utilizzati come fonte ufficiale.
In MediaStrategies la valutazione parte dalla mappa dei dati e dei sistemi esistenti. Prima di proporre Dolibarr bisogna capire quale piattaforma governi la camera-notte, come le prenotazioni raggiungano la reception, dove vengano prodotti i documenti e quali attività richiedano ancora inserimenti duplicati.
Quale sistema deve governare ogni dato
PMS, channel manager, booking engine e CRM non sono nomi diversi per lo stesso software. Possono appartenere a un’unica suite oppure essere strumenti separati, ma svolgono funzioni differenti.
| Dato o processo | Sistema normalmente responsabile |
| Inventario camera-notte | PMS o CRS |
| Prenotazioni e soggiorno | PMS |
| Distribuzione sulle OTA | Channel manager |
| Prenotazione diretta dal sito | Booking engine |
| Tariffe e revenue management | PMS o RMS |
| Profilo e relazione con l’ospite | PMS e CRM, con responsabilità definite |
| Housekeeping e stato camere | PMS o applicazione operativa integrata |
| Fatture, fornitori e back office | ERP o sistema contabile |
PMS
Il Property Management System governa normalmente planning, prenotazioni, assegnazione delle camere, arrivi, partenze, conti e operazioni di reception.
In una struttura semplice può coincidere con il centro quasi completo dell’operatività. In un hotel con ristorante, SPA, sale meeting o più reparti deve invece ricevere e distribuire informazioni provenienti da sistemi differenti.
Channel manager
Il channel manager sincronizza disponibilità, tariffe e restrizioni con i canali di vendita.
Non tutti i collegamenti hanno la stessa profondità. Un’integrazione può ricevere prenotazioni senza aggiornare tutte le restrizioni, oppure gestire inventario e prezzi lasciando messaggistica e pagamenti in strumenti separati.
Booking engine
Il booking engine permette all’ospite di verificare disponibilità e prenotare dal sito ufficiale.
Non è soltanto un elemento grafico. Deve interrogare dati attendibili, applicare tariffe e condizioni corrette, gestire eventuali pagamenti e restituire la prenotazione al PMS senza richiedere una nuova registrazione manuale.
Il sito e il motore di prenotazione devono essere progettati come parti dello stesso percorso. Una buona visibilità online produce poco valore se il booking engine mostra disponibilità incoerenti o rende difficile completare l’acquisto.
CRM
Il PMS registra il soggiorno. Il CRM organizza la relazione con l’ospite prima e dopo la permanenza.
Può raccogliere richieste, preferenze, comunicazioni e storico commerciale, ma deve evitare di creare un secondo profilo in contraddizione con quello presente nel PMS.
RMS e CRS
Un Revenue Management System aiuta a definire tariffe sulla base di domanda, disponibilità e regole commerciali.
Un Central Reservation System può invece diventare rilevante per gruppi e strutture multisede, perché centralizza disponibilità e prenotazioni tra più proprietà.
Non tutte le strutture hanno bisogno di ogni componente. La domanda corretta non è quale software faccia tutto, ma:
Quale sistema è responsabile di ciascun dato e quali altri strumenti sono autorizzati a modificarlo?
Il soggiorno è una catena di passaggi tra reparti
La prenotazione è soltanto l’inizio. Il gestionale deve accompagnare l’ospite dal primo contatto al check-out senza costringere reception e reparti a ricostruire continuamente le informazioni.
1. Dalla richiesta alla prenotazione
Preventivo, disponibilità, condizioni, caparra e richieste particolari dovrebbero trasformarsi in una prenotazione senza dover ricopiare l’anagrafica.
Una richiesta ricevuta dal sito, dal telefono o da un’azienda cliente deve mantenere una provenienza riconoscibile e arrivare al PMS con i dati necessari.
2. Dalla prenotazione alla camera pronta
Prima dell’arrivo bisogna collegare:
- data e orario previsti;
- camera assegnata;
- richieste dell’ospite;
- stato della pulizia;
- eventuali guasti;
- priorità della reception.
Una camera liberata non diventa automaticamente vendibile. Deve essere pulita, controllata e, quando necessario, interessata da un intervento di manutenzione.
Housekeeping e reception devono quindi lavorare sullo stesso stato operativo, evitando note sparse o comunicazioni esclusivamente verbali.
3. Dalla camera agli altri reparti
Durante il soggiorno possono essere aggiunti ristorante, bar, SPA, parcheggio, transfer o altri servizi.
Gli extra devono essere associati alla camera e all’ospite corretti, con indicazione del reparto e dell’operatore che li ha registrati. In caso contrario, il check-out diventa una fase di riconciliazione manuale.
4. Dal soggiorno al documento
Prima della partenza bisogna conoscere:
- importi già incassati;
- caparre o preautorizzazioni;
- addebiti ancora aperti;
- eventuale suddivisione del conto;
- soggetto al quale intestare il documento;
- servizi da addebitare separatamente.
La fatturazione è importante, ma funziona soltanto se riceve informazioni attendibili dal PMS e dagli altri reparti.
5. Dal check-out alla relazione successiva
Dopo la partenza, CRM e strumenti di comunicazione possono utilizzare storico, preferenze e provenienza della prenotazione.
Anche qui deve essere definito quale sistema conservi il profilo principale, evitando duplicati e messaggi scollegati dall’esperienza realmente vissuta dall’ospite.
Adempimenti e documenti non possono essere dati per scontati
Il software deve sostenere le procedure richieste alla struttura, ma non basta che una funzione compaia in una scheda commerciale.
Il portale Alloggiati Web della Polizia di Stato indica che le generalità delle persone alloggiate devono essere comunicate entro 24 ore dall’arrivo e, per soggiorni inferiori alle 24 ore, all’arrivo stesso.
Il gestionale può:
- generare il file richiesto;
- inviare i dati tramite un collegamento supportato;
- oppure richiedere un’esportazione e un caricamento separato.
Bisogna quindi verificare il funzionamento effettivo e la gestione delle ricevute.
L’ISTAT rileva mensilmente arrivi e presenze nelle strutture ricettive. Modalità e canali operativi possono però dipendere dal territorio e dall’ente intermediario competente. Non è sufficiente dichiarare una generica “integrazione ISTAT”: occorre controllare formato, portale e procedura previsti per la singola struttura.
Lo stesso principio vale per:
- imposta di soggiorno;
- rilevazioni regionali;
- procedure comunali;
- comunicazioni statistiche;
- conservazione delle ricevute;
- aggiornamenti normativi.
Le copie dei documenti non devono diventare un archivio permanente
Il 29 aprile 2026 il Garante per la protezione dei dati personali ha chiarito che alberghi e altre strutture ricettive non possono conservare copie o fotografie dei documenti d’identità oltre il tempo strettamente necessario alla comunicazione alle autorità.
La procedura di acquisizione, trasmissione e cancellazione deve quindi essere definita prima di configurare il check-in.
Il gestionale non dovrebbe trasformarsi in un archivio permanente di scansioni o fotografie, né lasciare copie in:
- cartelle condivise;
- caselle email;
- dispositivi personali;
- applicazioni di messaggistica;
- sistemi non collegati a una politica di cancellazione.
Devono invece essere conservate le evidenze e le ricevute previste per documentare l’avvenuta comunicazione.
Le sei prove che l’architettura deve superare
Una demo ordinata mostra l’interfaccia. Una prova realistica mostra come il sistema si comporta quando i dati cambiano o qualcosa non funziona.
1. Prenotazione diretta
L’ospite prenota attraverso il booking engine. Bisogna verificare che tariffa, condizioni, pagamento e disponibilità arrivino correttamente al PMS.
2. Prenotazione OTA con modifica
Una prenotazione proveniente da un portale viene successivamente modificata nelle date o nel numero degli ospiti.
La modifica deve raggiungere reception, planning e disponibilità senza creare una seconda prenotazione o lasciare aperte notti non più vendibili.
3. Cancellazione o no-show
Il sistema deve distinguere cancellazione, no-show, eventuale penale e rilascio della disponibilità.
4. Camera fuori servizio
Una camera viene bloccata per manutenzione. La modifica deve ridurre correttamente la disponibilità e impedire nuove vendite incompatibili.
5. Cambio camera, extra e conto diviso
Durante il soggiorno l’ospite cambia camera, utilizza servizi aggiuntivi e chiede che il conto venga diviso tra persona e azienda.
La prova deve mostrare se movimenti, addebiti e documenti rimangono leggibili.
6. Errore di sincronizzazione
Un aggiornamento non raggiunge un canale.
La demo deve far vedere:
- dove compare l’errore;
- chi riceve l’avviso;
- se la disponibilità viene protetta;
- come si ripete l’operazione;
- quale traccia rimane dell’anomalia.
Il comportamento nei guasti è spesso più importante della velocità dimostrata in condizioni ideali.
PMS, Dolibarr o architettura integrata?
Dolibarr è un ERP e CRM open source modulare. La sua documentazione ufficiale comprende clienti, contatti, preventivi, ordini, contratti, fatture, pagamenti, fornitori, progetti, interventi e magazzino.
Queste funzioni possono essere utili a un albergo per:
- aziende clienti e agenzie;
- preventivi per gruppi ed eventi;
- fornitori e acquisti;
- manutenzioni;
- fatture e pagamenti;
- contratti;
- attività commerciali;
- opportunità e storico delle relazioni.
Dolibarr non è però automaticamente un PMS. I moduli core non equivalgono a planning camera-notte, channel manager, booking engine, housekeeping o collegamenti OTA già certificati.
1. PMS verticale centrale e Dolibarr nel back office
È generalmente lo scenario più prudente.
Il PMS governa:
- camere;
- prenotazioni;
- tariffe;
- soggiorni;
- housekeeping;
- distribuzione hospitality.
Dolibarr può gestire:
- amministrazione;
- fornitori;
- manutenzioni;
- CRM commerciale;
- preventivi per aziende e gruppi;
- processi interni non coperti adeguatamente dal PMS.
Questa architettura ha senso quando i ruoli sono separati e non vengono creati due archivi concorrenti.
2. PMS collegato a Dolibarr
I sistemi possono scambiare clienti, documenti, attività o dati economici attraverso API o procedure dedicate.
Dolibarr dispone di servizi REST, ma la disponibilità tecnica di un’API non dimostra che esista già un connettore per il PMS utilizzato.
L’integrazione deve quindi essere valutata su:
- dati da scambiare;
- direzione del flusso;
- frequenza;
- gestione dei duplicati;
- trattamento degli errori;
- manutenzione;
- responsabilità del supporto.
3. Dolibarr con modulo hospitality esterno
Nel marketplace Dolibarr sono presenti estensioni sviluppate da terze parti per prenotazioni e strutture ricettive.
Questa ipotesi deve essere trattata come un proof of concept, soprattutto per strutture semplici. La presenza del modulo non garantisce:
- compatibilità con la versione installata;
- continuità degli aggiornamenti;
- copertura delle procedure italiane;
- collegamenti OTA;
- assistenza;
- sicurezza;
- adeguatezza al processo dell’hotel.
Prima di proporre questa architettura bisogna provare almeno:
- inventario camera-notte;
- tipologie e camere fisiche;
- modifiche e cancellazioni;
- restrizioni;
- pagamenti;
- housekeeping;
- adempimenti;
- migrazione;
- assistenza;
- eventuale distribuzione sui canali.
Il criterio corretto
Dolibarr non deve essere introdotto perché è open source o modulare. Deve essere scelto soltanto quando il suo ruolo è definito e riduce realmente inserimenti duplicati, frammentazione e perdita di informazioni.
La mappa hospitality di MediaStrategies
Una demo non dovrebbe essere il primo passaggio.
Per una valutazione preliminare sono utili:
- numero di camere e strutture;
- stagionalità;
- PMS utilizzato;
- channel manager;
- booking engine;
- OTA collegate;
- sito;
- sistemi di pagamento;
- reparti interni;
- contabilità;
- procedure obbligatorie;
- attività ancora manuali;
- problema operativo più frequente.
MediaStrategies può utilizzare queste informazioni per costruire una mappa che chiarisca:
- quale sistema governa ogni dato;
- quali archivi sono duplicati;
- quali collegamenti devono essere verificati;
- quali strumenti conviene mantenere;
- quali attività richiedono un PMS verticale;
- quale ruolo può avere Dolibarr;
- quali casi devono essere testati prima della migrazione.
Dall’analisi possono emergere esiti differenti:
- mantenere il PMS e utilizzare Dolibarr per il back office;
- integrare i due sistemi;
- sostituire uno strumento non più sostenibile;
- mantenere l’ecosistema attuale intervenendo soltanto sui collegamenti;
- svolgere un proof of concept su un modulo hospitality;
- escludere Dolibarr quando non offre un vantaggio proporzionato.
Quando il ruolo della piattaforma è chiaro, una valutazione e una demo di Dolibarr possono essere costruite sui processi reali del back office, evitando di presentare un ambiente standard come PMS alberghiero già completo.
La qualità della consulenza non consiste nel sostituire ogni sistema con un unico software, ma nel progettare un’architettura nella quale ciascun dato abbia un responsabile e ogni integrazione produca un vantaggio concreto.
