Manage by exception

Gestione per eccezioni · System override

Il modo di lavorare con un sistema di revenue management in cui si accettano per default le raccomandazioni automatiche e si interviene a mano solo sulle date che superano una soglia di scostamento fissata in anticipo.

S=A-FF×100
S = (A - F) / (F) × 100
Sscostamento della data, in percentualeAvalore effettivo rilevato per quella data, in camere o in ricavoFvalore previsto dal sistema per la stessa data, nella stessa unità
Una data diventa eccezione quando lo scostamento fra realtà e previsione supera in valore assoluto la soglia che hai deciso: la soglia si sceglie prima, non davanti al singolo caso.

Che cos’è

Un albergo con quattro tipologie di camera e un orizzonte di trecentosessantacinque giorni ha oltre millequattrocento decisioni di prezzo aperte in ogni momento. Nessuno le guarda tutte. Chi ci prova finisce per controllare bene i prossimi dieci giorni e per niente tutto il resto, che è esattamente dove si perde più denaro. La gestione per eccezioni ribalta il problema: il sistema decide ovunque, e la persona guarda solo dove qualcosa non torna.

Il presupposto è la fiducia calibrata. Un RMS ben alimentato produce raccomandazioni ragionevoli sulla stragrande maggioranza delle date, perché la stragrande maggioranza delle date è ordinaria: un mercoledì di ottobre assomiglia agli altri mercoledì di ottobre. Il valore aggiunto della persona non sta nel ricontrollare quei mercoledì, sta nel riconoscere le poche date in cui il modello non può sapere qualcosa che tu sai: uno sciopero, un congresso appena annunciato, un concorrente chiuso per lavori.

Il metodo si regge su due elementi tecnici. Le regole di eccezione, che decidono quando una data si accende. E il tracciamento degli override, cioè la registrazione di ogni intervento manuale con data, autore e motivo, che permette di verificare a posteriori se le persone hanno fatto meglio o peggio del sistema.

Come si calcola

Le regole utili sono poche e vanno scritte una volta sola. Le più comuni: scostamento fra pickup effettivo e previsto oltre una soglia; occupazione a un certo numero di giorni dall’arrivo sopra o sotto una banda; prezzo raccomandato che si discosta di oltre il 15% dal prezzo attuale; richiesta di gruppo in sospeso; disponibilità sotto un livello critico in tipologia; tariffa dei concorrenti che scavalca la tua in una direzione inattesa.

La taratura delle soglie è un compromesso: strette generano troppe eccezioni e si torna a guardare tutto, larghe lasciano passare date che avrebbero meritato attenzione. Un punto di partenza ragionevole per un albergo urbano è una soglia sul pickup del 25% e una banda di occupazione di dieci punti, che produce fra il 4% e l’8% delle date in eccezione ogni giorno.

Hotel 130 camere, sessione di lavoro del mattino

date aperte nell’orizzonte
365
tipologie gestite
4
raccomandazioni di prezzo generate
1.460
soglia di scostamento sul pickup
25%
banda di occupazione
10 punti
di cui gruppi in richiesta
3
di cui pickup anomalo
11
di cui prezzo fuori banda rispetto ai concorrenti
5
date segnalate come eccezione
19
tempo dedicato
25 minuti
raccomandazioni accettate senza intervento
94%

Come si usa

Il rituale è quotidiano e breve. Si apre la lista delle eccezioni, si decide su ciascuna, si scrive il motivo dell’eventuale override in una riga. Le date che non compaiono nella lista non si aprono: se il sistema non le segnala e tu vai a guardarle lo stesso, hai reintrodotto il lavoro che il metodo doveva eliminare.

Da fare lunedì: attiva il registro degli override e per un mese annota ogni intervento manuale con il motivo. A fine mese confronta il risultato delle date modificate con quello che avrebbe prodotto la raccomandazione del sistema. Nella maggior parte degli alberghi si scopre che circa metà degli override non ha aggiunto nulla, e che quelli utili si concentrano su due o tre situazioni ricorrenti: sono quelle che vanno trasformate in regole, non in interventi a mano.

L'errore tipico: l'override sistematico che spegne il sistema

Si vede negli alberghi che hanno comprato un RMS e non si fidano. Ogni mattina la persona cambia venti o trenta prezzi, sempre nella stessa direzione, di solito verso il basso, con la motivazione che il sistema non conosce il mercato locale. Dopo sei mesi succedono due cose: il modello ha imparato da una domanda che è stata prodotta dai prezzi manuali, quindi si è tarato sui prezzi bassi, e nessuno può più dire se l’RMS funziona, perché non ha mai lavorato. Se ti trovi a fare più del 10-15% di override sulle date attive, il problema non è la disciplina: sono i dati o la configurazione, e si risolve con il fornitore.

Da non confondere con

Non è l’automazione totale. Nella gestione per eccezioni le decisioni restano rivedibili e la responsabilità resta della persona; automatizzare significa lasciare che il prezzo vada in pubblicazione senza che nessuno lo veda. Le due cose convivono: si automatizza la pubblicazione e si mantiene il controllo per eccezioni.

E non è il pickup report. Quello è un rapporto che mostra come è cambiato l’on the books: lo leggi tutto. La gestione per eccezioni è un filtro che decide quali righe di quel rapporto meritano un’azione.

Torna al glossario