Motor de preus hoteler
Sis senyals de demanda decideixen la tarifa de cada habitació i cada nit.
Dades i BI · Python · Demo navegable
El problema
Una habitació és un producte que caduca cada nit: la que avui queda buida no es ven demà, es perd. Posar-hi preu alt la deixa sense ocupar i posar-lo baix regala marge, així que la decisió es repeteix cada dia i per cada tipus d’habitació.
Què fa
- Codifica la decisió de preu com a algorisme, a partir de sis factors de demanda.
- Un d’ells és l’antelació de la reserva: prima l’últim minut dins dels trenta dies.
- Projecta l’efecte sobre l’ingrés a seixanta dies vista.
- Calcula els indicadors del sector: tarifa mitjana diària, ingrés per habitació disponible i ocupació.
El que es va decidir en construir-lo
- Una banda de seguretat que el model no pot saltar-se
- La tarifa final s’acota entre el setanta per cent i el dos-cents vint per cent del preu base, passi el que passi amb els factors. Un model multiplicatiu sense sostre produeix, el dia que coincideixen temporada alta, cap de setmana, esdeveniment i última hora, un preu que cap director signaria. La banda és el que se signa, i hi ha una prova que no deixa sortir-se’n.
- El recàrrec d’última hora s’apaga als trenta dies
- Reservar amb molta antelació no porta cap recàrrec: la prima creix de manera lineal només dins dels trenta dies previs i arriba com a màxim a un vint-i-nou per cent. Cobrar antelació és cobrar per planificar, que és just el contrari del que interessa premiar.
- La pressió d’ocupació mira catorze dies, no el dia d’ahir
- Es fa la mitjana de l’ocupació de les dues últimes setmanes i es tradueix en tres esglaons: pressió alta, normal o fluixa. Reaccionar a la dada d’ahir converteix qualsevol soroll en un canvi de tarifa, i una tarifa que es mou cada dia deixa de ser una política de preus per ser una alarma.
- La llavor es declara, i també que no n’hi ha prou
- El generador sembra en importar-se, així que dues crides seguides donen números diferents: qui necessiti reproduir un conjunt ha de tornar a sembrar de manera explícita. Hi ha dues proves, una per cada costat, perquè prometre reproductibilitat i no provar-la és la manera més habitual de no tenir-la.
Fins on arriba
- Els sis factors actuen sobre la previsió. L’històric de dos anys sobre el qual es calculen tarifa mitjana i ocupació fa servir només tres: temporada, dia de la setmana i esdeveniment.
- No és un optimitzador. No hi ha corba de demanda ni elasticitat: l’ocupació esperada es calcula sense mirar el preu proposat, així que apujar la tarifa no la baixa. No demostra que el model augmenti l’ingrés.
- Quatre dels sis factors són calendari pur —mes, dia, data assenyalada i antelació—, taules escrites a mà. Només la pressió d’ocupació observa alguna cosa, i observa dades que el mateix script va generar.
- Les dades són sintètiques, el calendari d’esdeveniments és nord-americà i els imports van en dòlars. El panell que els pinta viu en un altre repositori.
- 6 factors de preu
- 730 dies d’històric
- 60 dies de previsió
Construït amb
- Python
- NumPy
- React
D’on surten les dades
Dades sintètiques generades pel mateix repositori: no hi ha informació de cap client.