Gabay
Paano Maiiwasan ang Double Booking
Pinipigilan ng Kasura ang double booking sa pagtingin sa dates ng booking laban sa bawat ibang active booking sa parehong asset, at pagharang sa save kung mag-o-overlap.
Bakit nangyayari ang double booking
Nangyayari ang double booking kapag may dalawang customer na may overlapping claim sa parehong vehicle o room. Bihira itong iisang malinaw na pagkakamali — mas madalas, nagtatrabaho ang staff mula sa memorya sa abalang shift, nahuhuli na ang shared spreadsheet sa reality, o dalawang tao ang humahawak ng request para sa parehong asset sa parehong oras nang hindi nakikita ang trabaho ng isa't isa. Lumalaki ang risk kasama ang bilang ng taong puwedeng gumawa ng booking at ang bilang ng channel kung saan puwedeng pumasok ang request.
Paano pinipigilan ng Kasura ang known conflicts
Sa tuwing gumagawa ng booking o binabago ang dates nito, ikinukumpara ng Kasura ang hiniling na panahon sa ibang bookings ng asset bago payagan ang save. Nangyayari ito nang dalawang beses: minsan sa interface habang pinupunan ang form, para makita agad ng staff ang problema, at muli sa sandaling isinusulat ang save, para hindi makalusot ang conflicting booking ng pangalawang tao na kumilos ilang segundo mamaya. Ang save na mag-o-overlap sa existing booking ay tinatanggihan nang tuluyan, hindi lang minamarkahan bilang warning.
Mga availability check
Habang ginagawa ang booking, minamarkahan ng calendar para sa napiling asset ang bawat date bilang available, partially available, o unavailable, batay sa naka-book na. Ang period na nagtatapos exactly kapag nagsisimula ang isa pa ay tinatrato bilang available, dahil hindi talaga sila nag-o-overlap. Ito ang live check na nakikita ng staff bago sila magtangkang mag-save, para makapili sila ng ibang date kaysa matuklasan ang conflict pagkatapos isumite ang form.
Mga booking conflict
Ang booking conflict ang tawag ng Kasura sa dalawang booking sa parehong asset na nag-o-overlap ang periods. Tanging bookings na binibilang pa ring active — reserved, active, checked in, overdue, o hindi pa resolved — ang puwedeng magdulot ng conflict. Ang booking na cancelled, marked no-show, o completed na ay excluded sa check, kaya libre na ang dates para sa iba sa sandaling naitakda ang status. Kapag tinanggihan ang save dahil dito, nakikita ng staff ang direktang mensahe na naka-book na ang asset para sa napiling panahon, hindi generic failure.
Mga hangganan ng Workspace
Isinasaalang-alang lang ng conflict check ang bookings na naka-record sa parehong Workspace ng asset na bine-book, dahil ang bawat asset ay sa iisang Workspace lang. Walang visibility ito lampas sa talagang inilagay sa Kasura: ang request na kinuha sa telepono at hindi pa naka-log, hold sa papel, o booking sa hiwalay na spreadsheet ay hindi nakikita at hindi hahadlangan. Ang paglagay ng bawat booking sa loob ng Kasura, hindi bahagyang sa labas, ang nagpapabisa sa proteksyong ito.
Hindi ito ang ibig sabihin ng gabay na ito
- Hindi ito absolute guarantee na hindi kailanman puwedeng maganap ang double booking sa anumang sitwasyon — ito ay malakas, deterministic check laban sa bookings na talagang naka-exist sa Kasura.
- Hindi sine-sync ng Kasura ang availability sa online travel agency o anumang external booking channel; kailangan iyon ng channel manager, na hindi bahagi ng produkto.
- Walang AI o predictive model na kasali sa pag-detect ng conflict — ang comparison ay direktang check ng isang period laban sa isa pa.
- Ang booking na ginawa sa labas ng Kasura — sa telepono, sa papel, o sa hiwalay na spreadsheet — ay invisible sa check na ito at hindi hahadlangan.