Apakah itu set tempahan gabungan?

Satu tempahan yang memuatkan banyak penginapan: tarikh daftar masuk dan keluar berbeza bagi setiap bilik, kadar dan pakej berbeza bagi setiap baris, item venue dan bankuet dalam set yang sama, serta peruntukan tetamu bernama bagi setiap bilik — semuanya diurus, dipinda dan dibilkan sebagai satu konteks tempahan, bukan timbunan nombor pengesahan yang tidak berkaitan.

Bagaimana pengebilan berfungsi merentas satu tempahan dengan banyak penginapan?

Melalui struktur pengebilan langsung WinX: folio induk untuk set itu, dengan caj dihalakan, dipecah atau dipindahkan antara folio secara masa nyata. Syarikat membayar bilik, tetamu membayar minibar sendiri, penganjur membayar venue — diputuskan semasa penginapan berjalan, bukan dileraikan semasa daftar keluar. Tiada tunggu audit malam untuk semua itu.

Bolehkah satu tempahan merangkumi venue dan acara, bukan sekadar bilik?

Boleh. Majlis kahwin atau persidangan boleh memuatkan blok biliknya, dewan atau bilik mesyuarat, dan item bankuet/katering dalam konteks tempahan yang sama, dengan pengebilan acara terikat pada struktur yang sama. Satu penganjur, satu konteks, satu bil — bukan sistem bilik dan sistem acara yang bertemu dalam hamparan.

Insights

Satu tempahan, banyak penginapan: tempahan kumpulan tanpa teka-teki

Tempahan sebenar jarang satu tetamu, satu bilik, satu julat tarikh. Sekeluarga tiba Selasa, datuk dan nenek menyusul Khamis. Pasukan projek menempah lapan bilik dengan ketibaan berperingkat, satu bilik mesyuarat, dan makan malam perpisahan. Majlis kahwin ialah blok bilik, dewan, dan tiga perjanjian kadar berbeza. Kebanyakan sistem menjawab semuanya dengan cara yang sama: pecahkan kepada tempahan berasingan dan biarkan kakitangan memegang cebisan-cebisannya.

Masalahnya: timbunan nombor pengesahan yang tidak saling mengenali

Sebaik tempahan sebenar dipecahkan, setiap langkah selepasnya mewarisi kerapuhan itu. Penganjur menelefon untuk menganjak seluruh kumpulan sehari — seseorang mesti mencari dan meminda enam tempahan tanpa tertinggal satu pun. Deposit tercatat pada cebisan yang salah. Seorang tetamu melanjutkan penginapan, dan malam barunya jatuh di luar kadar kumpulan. Semasa daftar keluar, kaunter hadapan menjadi detektif: folio mana kepunyaan siapa, dan siapa sebenarnya membayar apa?

Pengalaman tetamu turut menampakkan jahitannya — orang yang menempah segalanya menerima enam e-mel pengesahan dan masih perlu menerangkan aturan itu di kaunter.

Kenapa ia berlaku: tempahan ialah atom sistem

Dalam kebanyakan PMS, tempahan ialah unit yang tidak boleh dipecahkan: satu tempoh penginapan, satu kadar, satu bilik. Apa-apa yang lebih kompleks tiada tempat tinggal, jadi ia diuraikan semasa menempah dan dipasang semula dengan tangan semasa pengebilan. Modul kumpulan menambah satu blok di atasnya — tetapi blok ialah pagar mengelilingi inventori, bukan tempahan: ia memuatkan bilangan bilik, bukan struktur tarikh-kadar-venue-orang dalam aturan sebenar.

Bagaimana WinX menyelesaikannya: set tempahan gabungan

Dalam WinX, satu tempahan boleh memuatkan seluruh aturan — ini keupayaan teras platform sejak hari pertama, bukan modul tambahan:

Tarikh bercampur dalam satu tempahan — setiap baris bilik membawa tarikh daftar masuk dan keluar sendiri; ketibaan berperingkat dan lanjutan kekal di dalam set, bukan terkeluar daripadanya.
Kadar dan pakej mengikut baris — pasangan berbulan madu dengan pakejnya, pasukan dengan kadar korporat, yang menyertai lewat dengan kadar terbaik semasa: satu konteks, harga peringkat baris.
Venue dalam set yang sama — dewan, bilik mesyuarat, item bankuet duduk bersebelahan baris bilik, dengan pengebilan acara terikat pada struktur yang sama.
Peruntukan tetamu bernama — siapa tidur di mana bukan lagi nota lekat; setiap baris membawa tetamunya, jadi pendaftaran, pengemasan dan senarai dalam-hotel betul secara automatik.
Satu struktur pengebilan, langsung — folio induk dengan caj dihalakan, dipecah atau dipindahkan masa nyata: bilik kepada syarikat, minibar kepada tetamu, venue kepada penganjur. Diputuskan semasa penginapan, bukan dileraikan semasa daftar keluar.
Pindaan menyentuh set, bukan enam cebisan — anjak kumpulan sehari, dan ia satu operasi pada satu konteks tempahan.

Perubahannya: model data sistem akhirnya sepadan dengan bentuk sebenar tempahan — kerumitan tinggal dalam perisian, bukan dalam ingatan pasukan kaunter hadapan anda.

Terbukti di tempat tempahan benar-benar rumit

Set tempahan gabungan telah memikul kerumitan sebenar bertahun-tahun: Manila Ocean Park + Hotel H2O, di mana penginapan hotel dan lawatan taman milik satu aturan; Petronas Pengerang, dengan 1,000+ bilik corak penginapan panjang dan giliran; I'M Hotel, mencampurkan penginapan hotel, spa dan kediaman berservis; serta operasi konvensyen di mana blok bilik dan dewan akhirnya duduk pada tempahan yang sama. Penghalaan dan pemecahan langsung yang menjadikan pengebilan ini berfungsi ialah enjin yang sama di sebalik satu bil merentas hotel, taman dan spa.

Soalan lazim

Apakah itu set tempahan gabungan?: Satu tempahan memuatkan banyak penginapan — tarikh berbeza setiap bilik, kadar dan pakej berbeza setiap baris, venue dalam set yang sama, tetamu bernama setiap bilik — diurus, dipinda dan dibilkan sebagai satu konteks.
Bagaimana pengebilan berfungsi merentas satu tempahan dengan banyak penginapan?: Folio induk dengan penghalaan, pemecahan dan pemindahan langsung antara folio: syarikat bayar bilik, tetamu bayar tambahan sendiri, penganjur bayar venue — diputuskan semasa penginapan berjalan, bukan semasa daftar keluar.
Bolehkah satu tempahan merangkumi venue dan acara?: Boleh — blok bilik, dewan dan item bankuet dalam satu konteks tempahan dengan pengebilan acara pada struktur yang sama. Satu penganjur, satu bil.

Bawa tempahan paling rumit anda — lihat ia muat dalam satu tempahan.

Minta demo WinX