The user experience of the Internet depends largely on whether the certification system has access to the PMS front desk. Ideally, the guest can access it without registration or passwords and exits automatically. Sounds simple, but the PMS docking is one of the easiest lock-ups in the whole hotel WIFI real name system. This piece describes the interface details we have stepped into the actual project for a hotel with similar needs.
Let's get to the point where PMS is going to match.
The ability of interfaces to be open to different PMS manufacturers varies considerably. Some provide standard HTTP interfaces that allow real-time check-ups; others open databases only for account numbers, allowing you to go through the table and do nothing but sync up with documents exported on a timed basis. These three ways have a completely different effect on the real-time nature of authentication systems. For those who walk interfaces, customers can access the Internet within seconds of their stay in the system; for those who go through database rotations, there may be dozens of seconds of delays; for those who do file synchronization, it may take minutes to delay and the guests can fail to access the Internet as soon as they complete their stay. The first thing to do with the docking is to ask what PMS can give and then set expectations for clients, and not to promise impracticable real-time.
What's the authentication certificate for?
If you use a cell number, you must have a cell number and a cell tail or a two-dimensional code on the card, which is compatible with the registration process at the front desk. If you add a room number to a name, you must record a name in the front desk, and there are no full names in the list, otherwise it cannot be certified as valid. If you use a cell phone number, the front desk will have to ensure that the number is collected when you are in the house. We have a project that certifies design with a mobile tail calibration, which results in a routine non-recording of the front desk, leading to a failure of a large number of customers.
The time to check out the net needs to be handled.
The customer should leave the house and then immediately break off the net to avoid continued use or ding-tao. But the breakup is done at a time when the person is forced to do so, and the exit is immediately suffocated. If the guest is still packing up his room and waiting for a bus, the network suddenly fails to experience it. It is more prudent to leave the house and give him a buffer time, such as a delay in leaving at noon or a few minutes later. This strategy has to be discussed with the hotel and written into the pyrotechnic logic.
We'll change rooms, add beds, get the team in these special scenes.
There are many non-standard scenarios in daily operations. Guests change rooms and the certification system has to be tied up with new rooms; several people live in one room, share an account or one for each person, and they have to be predefined; travel groups enter in a batch, front desk lot registers, and certification systems must be capable of being identified. These scenes usually do not appear during demos, but they do operate every day. The special scenes must be entered into when the interface is designed, one by one, to confirm whether PMS data changes will be synchronized to the authentication system. One missing would be a thunderstorm on a particular guest and the front desk would need to be saved manually.
The data field is checked for the matching
The room numbers in PMS, the names of guests, the time of stay, checkout times and cell number fields may not be the same format as the authentication system expected. The rooms have no prefixes, date formats are different, name names are called. The modulation phase is to pull each field used out, check the format one by one, and write the conversion rules. This activity is boring, but if it does not, there will be a situation where the certification system gets data but interprets them wrong, which is an uncalled-for failure of certification, which makes it difficult to identify because the interfaces are all used successfully and the problems are hidden in the data format.
The connection will take a while. Don't press until it starts.
PMS interfaces involve hotels, PMS manufacturers, certification system producers, and communication chains are long and frequent. One party changes the interface, the other follows it, and several rounds are normal. If you have to line up for a few days before the start of business, if there is no time to deal with problems, then you can only be downgraded to manual registration. It is more stable to leave at least two or three weeks of interlinking before the start of business, first running the main process and special scenes in the testing environment and then producing them. Triple alignments should best be organized so that everyone is accountable and when they deliver results, and avoid each other waiting.
Do the de-gradation when the docking fails.
A steady match will be possible one day with the PMS interface or a network break. At this point, customers cannot all access the Internet. The certification system should have a downgrade system that allows them to use mobile code self-service for their own use when they do not get data. Instead of giving up real names, it ensures that the Internet service is not interrupted while the logs are still available. This downgrading logic is designed and tested well in advance, and it does not go without the entire hotel being able to complain about it until the day when PMS fails.
The PMS is not technically sophisticated to handle the matter, and it is difficult to get a detailed, multi-participating, border scene. This practical detail is discussed at the pre-project stage, the interfaces are validated item by item, and the hotel WIFI authenticated access system can be truly uninvited.