Prețul hotelului s-a schimbat. Ce face motorul de rezervări înainte și după rezervare.

Așa funcționează motorul ăsta de rezervări. Agentul poate vedea comparația, și agentul decide. Aplicația nu schimbă un tarif de una singură și nu anulează o rezervare de una singură.

Un preț mai bun când agentul apasă Book

Când un agent apasă Book pe un tarif, pagina de rezervare confirmă prețul la furnizorul acelui tarif. În același timp îi întreabă pe ceilalți furnizori despre același hotel.

Caută doar un tarif echivalent. Camera trebuie să fie de același fel: un double nu se compară niciodată cu un suite. Regimul trebuie să fie același. Rambursabilitatea trebuie să fie aceeași, iar condițiile de anulare cel puțin la fel de bune. Un număr mai mic fără mic dejun, sau cu o regulă de anulare mai strânsă, e o altă ofertă.

Dacă un tarif echivalent e mai ieftin, sub prețul confirmat apare o notă verde. Sumele de mai jos sunt un exemplu de ce poate arăta nota.

Exemplu de notăLiteAPI has the same room, also room only and refundable, for €18 less (€212.40 instead of €230.90).

Agentul poate deschide o vedere alăturată a ce e identic și ce diferă: formularea camerei, termenul de anulare gratuită și furnizorul. Alegerea de pe ecranul ăla e Switch to this offer sau Keep the current one.

Schimbarea confirmă noul tarif la furnizorul lui, înainte de pasul cu datele oaspetelui. Nu se rezervă nimic pe un preț care n-a fost verificat. Aplicația nu schimbă niciodată singură.

Ce furnizori sunt întrebați

Simulatoarele intră mereu în căutarea aia. Hotelbeds și LiteAPI nu. Cei doi furnizori sunt interogați doar când cineva pornește deliberat o verificare live. În aplicație, asta înseamnă presenter mode cu comutatorul pe Live. O verificare automată, sau o vizită care nu e verificarea aia live, nu îi apelează. Fiecare căutare Hotelbeds sau LiteAPI se numără pe pagina de utilizare a API-ului.

Când nu apare nimic mai bun, pagina spune că s-a făcut căutarea. O astfel de linie este „Checked 3 other suppliers: this is still the best price.”

După confirmare, o urmărire pentru un preț mai mic

Odată ce rezervarea e confirmată, și cât timp mai poate fi anulată gratuit, aplicația continuă să caute același sejur la un preț mai mic, la furnizorul de pe rezervare și la ceilalți.

Verificările automate urmează programul din Admin, la Suppliers & checks. Caută în simulatoare pentru fiecare rezervare urmărită. Un tarif contează doar când e strict echivalent, în același sens ca la rezervare, și doar când economia bate un prag pe care îl setează agenția. Implicit, pragul e €15 și 5% din preț.

Hotelbeds și LiteAPI nu intră niciodată în verificările astea automate. Asta le protejează limitele. O rezervare ținută la unul dintre ei arată un buton Check for a lower price now. Butonul e disponibil pentru aceeași verificare live deliberată, presenter mode cu Live pornit. Înainte să ruleze, spune că va fi o căutare numărată pentru fiecare furnizor real.

Fiecare rezervare arată o linie mică Price watch: când a fost verificată ultima dată, cel mai bun preț echivalent găsit și când se oprește urmărirea. Urmărirea se oprește mereu la sfârșitul ferestrei de anulare gratuită, pentru că după aceea o schimbare ar costa o penalizare.

Cum vede agenția o scădere

O scădere apare în trei locuri.

• Un badge pe lista de rezervări. Un exemplu de badge este „€42 cheaper.”
• O intrare la clopoțelul de alerte, și un email de alertă când emailul e configurat.
• Un card Price drop pe pagina rezervării.

Cardul pune rezervarea curentă lângă oferta nouă. Arată:

• cele două oferte, una lângă alta
• economia după orice diferență de taxe
• că rezervarea curentă mai poate fi anulată gratuit până la o dată și o oră date, în ora locală a hotelului
• pașii exacți pe care i-ar face o schimbare

Cifrele folosesc prețuri de vânzare pentru client și costuri de furnizor pentru agenție. Agentul poate vedea economia clientului și cum se schimbă marja agenției, și poate pasa economia mai departe sau păstra o parte, după regulile de marjă.

O schimbare ghidată, cu camera originală încă ținută

Alegerea Switch pornește o rerezervare ghidată. Agentul confirmă fiecare pas. Ordinea e fixă, ca clientul să nu rămână fără cameră.

1. Noul tarif e verificat la preț.
2. Noua rezervare se face cu aceiași călători.
3. Abia după ce noul furnizor confirmă i se cere agentului să anuleze rezervarea originală. Starea de anulare gratuită se verifică din nou chiar înainte.

Dacă noua rezervare eșuează, nu se anulează nimic și originalul rămâne. Dacă anularea eșuează, aplicația o spune clar și listează ambele rezervări, ca agentul să poată termina de mână. Nu anulează niciodată nimic automat.

Ambele rezervări păstrează o intrare în cronologie care le leagă. Un exemplu de intrare, inclusiv un id de rezervare de exemplu, este „Rebooked to WH-1102 for €42 less.” Documentele noi de confirmare și voucher sunt gata pentru rezervarea nouă, iar agentul e amintit să le trimită clientului.

Ce trebuie să rămână adevărat la ofertă

Un rezultat de căutare nu e o rezervare confirmată. Cifra de pe pagina de rezultate e o ofertă la un moment dat. Pagina de rezervare e locul unde furnizorul tarifului confirmă prețul.

Compară toată oferta, nu doar numărul. Un tarif mai ieftin cu un regim mai slab, sau cu o anulare mai slabă, nu e aceeași ofertă. Verificările de mai sus lasă tariful ăla pe dinafară.

Un timeout nu e dovada că rezervarea a eșuat. Documentația Rapid de la Expedia descrie un timeout sau un răspuns 5xx care poate apărea după ce o rezervare a fost creată, și recomandă să recuperezi încercarea aia înainte să trimiți o altă rezervare. Asta e starea de rezervare a unui furnizor, separată de comparația de preț din WebbingHUB Travel. Un text mai lung despre timeout-uri la furnizor și recuperare e publicat separat.

Concluzia practică

Tariful pe care agentul a dat clic prima dată e verificat la furnizorul lui înainte să fie rezervat cineva. Un preț mai ieftin se arată doar când camera, regimul și anularea se potrivesc în continuare. După confirmare, urmărirea se termină când se termină anularea gratuită. Agentul confirmă fiecare pas al unei schimbări, iar rezervarea originală rămâne până când noul furnizor a confirmat.

Pentru echipele care lucrează la sisteme de rezervări și conexiuni cu furnizori, WebbingHUB Travel se ocupă de stratul de integrare și de realitățile operaționale din spatele distribuției hoteliere.

Sursă

• Expedia Group, Rapid API common error responsesUn timeout sau un 5xx poate urma unei rezervări care există deja. Recupereaz-o înainte să rezervi din nou. Asta descrie furnizorul, nu WebbingHUB Travel.