BOOKING ENGINE · PMS · API · 7 MIN ČITANJA
Prije implementacije trebaju biti jasne granice odgovornosti svakog sustava i poslovne posljedice svakog događaja.
1. Tko je izvor istine?
Za raspoloživost, cijenu, pravila boravka, gosta i status rezervacije treba odrediti sustav koji je autoritativan. Bez toga oba kraja mogu mijenjati isti podatak, a tim naknadno ručno traži koja je verzija točna.
2. Što se događa pri promjeni i grešci?
Promjena termina, otkaz, neuspjela naplata i privremeno nedostupan API nisu iznimni scenariji. Integracija treba evidentirati događaj, spriječiti duplu obradu i otvoriti razumljiv slučaj osobi kada automatski oporavak nije moguć.
3. Testirajte poslovne scenarije
Test nije dovršen potvrdom da API vraća odgovor. Potrebno je provjeriti cijeli tok od pretrage do statusa u operativi, uključujući izmjene i prekide veze.
Minimalni checklist prije puštanja integracije
Dokumentirajte mapiranje polja, pravilo za svaki status rezervacije, dopušteni smjer izmjene i način ponovne obrade poruke. Taj popis povezuje poslovni proces s tehničkim ugovorom između sustava te olakšava održavanje API integracije.
Prije produkcije prođite stvarne putanje gosta: pretragu, kreiranje i izmjenu rezervacije, otkaz, plaćanje te povratak sustava nakon prekida. Ako booking engine treba objediniti više izvora, korisna je i stranica o razvoju booking platforme; za širi kontekst pročitajte razliku između PMS-a i Channel Managera.
Česta pitanja
Može li jedan sustav mijenjati cijene, a drugi raspoloživost?
Može, ali samo ako se odgovornost po podatku izričito definira i testira za svaku promjenu. Inače se povećava mogućnost sukoba i ručnih korekcija.
Što se događa kada API privremeno nije dostupan?
Integracija treba zabilježiti pokušaj, kontrolirati ponovno slanje bez duplikata i dati timu vidljiv signal kada je potrebna intervencija.
Je li dovoljno testirati odgovor API-ja?
Nije. Potrebno je potvrditi poslovni ishod kroz cijeli tok, uključujući stanje u PMS-u, potvrdu prema gostu i operativni zadatak.