Hospitality Administration

The DV2000 provides several features and utilities that support using the system in a hospitality environment.

The guest mailbox type provides for easy management of guest room mailboxes, and also offers a simplified subscriber menu for the guests (including the ability to login without a password from the room phone). Automated wakeup calls can be scheduled by the guests themselves, as well as by the front desk. And the DV200 can even be integrated with a property management system (PMS), provided it uses a supported protocol.

There are three main applications you can use to configure, manage and monitor guest room mailboxes (and related information):

• Mailbox Administration – use this application to create and configure both guest and staff mailboxes.
• PMS Monitor – use this application to view the communication traffic between the PMS and the hospitality service.
• InnDesk – use this web application to review and manage guest rooms, groups and wakeup calls.

This section covers the following subjects:

• Guest Room Mailboxes – Overview of how guest mailboxes work and how to create them.
• Guest Directory – Overview of the optional guest spell-by-name directory and how it differs from the standard directory.
• Room Number Translation – Overview of the optional PMS translation table.
• Room Functions – Covers all of the guest- and room-related functions supported by the DV2000.
• PMS Link – Covers the configuration and use of a serial or TCP/IP link to a property management system.
• PBX Link – Covers the configuration and use of a serial or TCP/IP link to a PBX for hospitality services.
• Hospitality Service – Overview of the #@bandon@'s hospitality service, including configuration and logging.
• Wakeup Calls – Covers the configuration and use of the #@bandon@'s wakeup call feature.
• Administration by Phone – Overview of the hospitality administration options available via the telephony interface.

The DV2000 is primarily a room-based environment. Each guest mailbox represents a room, which may contain zero or more guests.

For example, a check-in command marks the mailbox as occupied and, depending on the data included in the command, may set the guest name and password and perform several other actions. A subsequent check-in would overwrite the old name and password with the new ones. In other words, if the PMS sends a check-in command for each guest in the room, the last guest to check in is the one whose name is stored in the mailbox (and, if relevant, sent to the PBX).

Likewise, the check-out command would clear the entire mailbox, regardless of how many guests may be in the room. Subsequent check-outs would perform all the same actions (clearing messages, resetting the password and text message count, clearing the name, etc.) except it would not archive any messages; archiving only happens when a check-out is sent to a room mailbox that is marked as occupied.

Room move is also handled on a per-room basis, not per-guest. That is, if a room move is received, then the wakeup call, messages, guest name, language selection, password, text message count, and any group membership are all copied to the new room. After that, the original room is checked out, unless the command sent by the PMS is one that expects the original room to remain checked in.

Other specialized PMS commands such as change name, change language, change phone class of service, set wakeup call, and so forth, are all handled on a room-oriented basis as well. For example, a command to change the name will change the name in the mailbox (and, if relevant, on the PBX) and the original name will be discarded.

When the DV2000 is configured to link with a Oracle Opera PMS over a TCP/IP connection, the Oracle FIAS 2.20 protocol is used. This protocol requires a guest-based approach to managing rooms and guests. Consequently, the 7.00 offers limited support for guest-based management for this case.

What this means in practice is that most commands sent from the PMS specify a unique guest ID in addition to the room (mailbox) number. So in the case of the check-in command, the Opera will send a check-in for each guest who will occupy the room. The 7.00 will store the name of the first guest in the mailbox (and, if relevant, will send it to the PBX). For each subsequent guest, the name, guest ID and any other data will be stored in a database table but will not be sent to the PBX or otherwise used, except to track whether the room is occupied.

When a check-out is received, if the guest ID is the primary guest (that is, the one stored in the mailbox), then the system will clear that guest out of the mailbox and the database and will then select one of the other guests in the database to become the primary guest. That guest's name will be placed in the mailbox and sent to the PBX (if relevant). When a guest is checked out and there are no more guests in the database, then the mailbox will be fully checked out and marked as vacant.

How a room move is handled depends on the status of the destination room. If it is occupied, then the guest is moved to the new room and the messages, text message count and wakeup calls are all moved over to the new room but no other changes are made (no change to the language, the phone class of service, the guest name in the mailbox or the mailbox password). If the room is vacant, then the guest will be checked into the room as the primary guest, and all relevant data is copied to the room: guest name, password, language, text message count, voice messages, and wakeup calls. In either case, if the original room is now vacant then it will be checked out. If it is not vacant but the guest who moved was the primary guest, then one of the remaining guests will be selected as the primary and his or her name will be set as the guest name and sent to the PBX (if relevant).