[PR045]

Capisco e condivido la tua argomentazione. Tuttavia credo che una feature del genere dia un aiuto notevole nella gestione di un planning complicato e con tante tariffe da seguire. Quindi credo che sia importante continuare la discussione e magari arriviamo ad un compromesso.
Pensavo che si potrebbe semplificare un pò (forse non per voi) il sistema lasciando decidere al cliente la condizione per far scattare l'alert?
Mi immagino una feature simile a quella avvisami quando ho l'ultima camera disponibile. Mi spiego: il cliente ha la possibilità di scegliere che tipo di alert inserire su tabla in base ad una serie di opzioni che riguardano le possibili condizioni che hai elencato. Naturalmente il sogno sarebbe riuscire a combinarne diverse :)

Spero di essere stato chiaro.
Buon lavoro e saluti a tutti!

Non sono un tecnico, ma dalle tue parole capisco che non è facile mettere in digitale qualcosa che il nostro cervello fa in automatico. Cionondimeno, questa caratteristica sarebbe veramente utile e vale la pena di perderci un pò di tempo.
Forse semplifico eccessivamente ma basterebbe che venisse segnalato ( alert) quando all'interno di un intervallo si trova un numero di minimum stay superiore al numero delle notti disponibili.
Esempio: |P|P|2|2|7|2|2|2|P|P|P| dove P sta per prenotato, il 7 è all'interno di 6 notti, quindi viene segnalato. Lo stesso dicasi per i casi più comuni: |P|P|3|P|P|P| quando rimane il minimum stay "dimenticato" di 3 notti è all'interno di 1 notte libera.

Non intendevo esattamente questo. Possiamo sviluppare facilmente un'algoritmo in grado di fare
il controllo che avete appena descritto.

Quello che mi rende poco convinto è la possibilità di spiegare questo algoritmo (o controllo) ai
nostri clienti. Giustamente un cliente vorrà sapere: quando esattamente viene attivato l'allert?
(O: come mai non mi è giunto l'allert? O: come mai l'allert mi è giunto quando posso comunque
prenotare questo soggiorno?)

Ora voi avete definito che l'allert debba partire quando una prenotazione forma (prima del'arrivo
o dopo la partenza), un'intervallo che contanga almeno un giorno con min.stay maggiore della
lungezza dell'intervallo.
Questo è già diverso dalla descrizione che avevo dato io: un intervallo che non possa contenere
nessun possibile soggiorno. (Nel vostro primo esempio esistono soggiorni prenotabili di 2 o 3 notti
all'interno dell'intervallo).
Vediamo che intendiamo logiche diverse su questa funzione (e siamo in pochi a parlarne).

WuBook ha ormai migliaia di clienti.
Un potrebbe aspettarsi che la logica sia come la intendo io (nessun soggiorno possibile).
Un'altro come la intendete voi (almeno un min.stay maggiore dell'intervallo).
Un'altro si aspetta che l'allert parta se tutti i giorni dell'intervallo hanno min.stay maggiore
dell'intervallo (non uno solo).
Un'altro si aspetta che venga controllato anche il min.stay arrival.
Un'altro si aspetta che venga controllato anche il close to departure o il close to arrival.
... e via dicendo.

Quando un cliente si rivolge alla nostra assistenza chiedendo come mai un'allert è partito
o come mai non è partito, i nostri account managers saranno costretti a verificare
un'intricata possibilità di restrizioni e a spiegare con esattezza la logica dell'allert.
Spiegare ad un cliente qualche cosa di così complesso potrebbe diventare davvero difficile.
(Considerate solo quanto è lunga e complessa questa risposta che stò scrivendo.
Se voi seguite facilmente questo tema, può non essere lo strsso per molti altri clienti.
I nostri clienti sono molto diversi l'uno dall'altro.).

Talvolta, se non si riuscisse a far capire la logica di una funzione, potrebbe nascere una
frustrazione (sia per il cliente che per l'operatore), frustrazione che può causare un danno
d'immagine per WuBook nonostante il lavoro svolto.

Resto apertissimo alle vostre obiezioni.

Saluto cordialmente
Michele