Hospitality

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

• Ability to connect to and communicate with a PMS
• Ability to connect to and communicate with a PBX
• Automated wakeup calls
• Room mailboxes with a simplified subscriber menu (optionally including allowing the guest to schedule a wakeup call)
• Group mailboxes which can be used to send a message to all members of a group

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

On check-in, the mailbox is marked 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, on check-out the entire mailbox is cleared, 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 PMS using the Oracle FIAS 2.20 protocol, a guest-based approach to managing rooms and guests is required. Consequently, the DV2000 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 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 DV2000 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).

The room mailbox type, which uses the Guest COS template by default, provides the following features:

• Plays a default greeting (shared by all guest mailboxes) that the guest cannot change.
• Uses a default password that the guest cannot change (but may be overridden by the PMS).
• Does not ask for a password when the guest logs in via the room phone.
• Does not allow the guest to send messages, recover deleted messages, record greetings, use distribution lists or archive folders, or have personal notifications.
• Allows the guest to schedule multiple wakeup calls (including recurring calls).
• Archives all guest messages (including deleted ones) at check-out, for a limited time.
• Allows the housekeeping staff to dial a special DTMF code to change the room clean status.

If you change the COS template to Extended Stay, the mailbox acts the same as above, but with the following exceptions:

• Allows the guest to record a personal greeting that will play in place of the default.
• Allows the guest to record his or her name.
• Allows the guest to change the password.
• Deletes all custom recordings and resets the password on check out.

Mailboxes can be created either by using the DV2000 Manager application on the DV2000 system or using the Web UI from with a web browser.

An alternate method that may work in some cases is to let the system auto-create the mailboxes based on input from the PMS. This method has the following requirements:

• All mailboxes will be created as room mailboxes using the Guest class of service.
• All mailboxes will have only the default notification templates for a guest mailbox: MWI Off, MWI On, Wakeup Call and Failed Wakeup.
• All mailboxes will be created with an extension number that matches the mailbox number.
• All mailboxes will be assigned to the same tenant and profile, as specified in the hospitality configuration for the server instance assigned to this PMS.
• The PMS must be able to perform a database swap (resynchronization) that will send check in and check out messages for all rooms.

To use this method, open DV2000 Manager and follow these steps:

1. Select Features | Hospitality.
2. If prompted, select the PMS instance and click Edit. This dialog is only displayed if the system is licensed for multiple PMS configurations.
3. Select the PMS page.
4. In the section Auto-create
   1. Check the Enable auto-create box.
   2. Select the tenant to assign to the mailboxes.
5. Click OK to save your changes.
6. If the Hospitality Selection dialog is displayed, click Close.
7. Perform a data swap with the PMS. Either:
   1. Manually initiate a swap on the PMS; or
   2. Use PMS Monitor to manually send a swap request from the DV2000 to the PMS (select Tools | Send message from the menu); this only works if the PMS protocol supports it.
8. Wait for the database swap to complete; this can take anywhere from several minutes to more than an hour, depending on the number of rooms you have. Creating the mailbox and performing the check in or check out functions can take several seconds per mailbox.
9. When the swap has completed on the DV2000, open DV2000 Manager or the Web UI to verify all the rooms are present.
10. Once all mailboxes are created and verified, use DV2000 Manager to disable the Auto-create setting.

The DV2000 provides the ability to translate from the room (or extension) numbers sent by the PMS to the mailbox numbers it uses, and vice-versa. This is done using a translation table that maps the room number directly to the mailbox number using simple substitution.

For sites with multiple PMS instances, there is a separate hospitality server instance for each PMS, each with its own configuration and translation table.

Configuration of PMS translation tables is done using the DV2000 Manager application, under Features / Hospitality / Translation.

On receipt of any message packet from the PMS, if the message contains a room number the system will perform a forward lookup in the translation table. If the given room number is found, it will be replaced with the associated mailbox number before the command specified by the message is processed.

The PMS translation table provides a many-to-one relationship for room numbers to mailbox numbers. This means that every room number maps to one and only one mailbox number, but multiple different room numbers can map to the same mailbox number.

For example, the following translation table is entirely valid:

In this case, the room numbers 71101, 81101 and 21101 all map to mailbox 1101. This is valid.

In some cases, a room may have multiple physical phones, each with its own extension, and the PMS may be sending commands with extension numbers rather than room numbers. This can be handled using a translation table similar to that shown above. In this case, 71101, 81101 and 21101 are all extensions in room 1101 and the PMS may send a check in for each extension rather than a single check in for the room number. Using a translation table like this allows the VMS to map all 3 extensions onto one mailbox.

If a PBX link is also being used to pass phone control states, name changes, and so forth to the PBX, you would need to assign each extension to the MWI address fields in the mailbox as well, because translations are not supported for the PBX link.

In the example above, you could assign 71101 to the address MWI 1, 81101 to MWI 2 and 21101 to MWI 3, all in mailbox 1101. If there is a hunt group associated with the room, say 1101, then you should assign it to the Extension field on the owner settings page (which will also assign it to MWI 0 automatically). The Extension field is used when dialing wakeup calls, so it should always be assigned the extension (or hunt group) that should be dialed for the wakeup calls.

Whenever the system needs to send a message to the PMS for a room, it will perform a reverse lookup in the translation table to get all room numbers associated with the given mailbox number. A message will then be generated and sent to the PMS for each room number found.

Using the example in the previous section, if the system needed to pass a housekeeping status change on to the PMS for mailbox 1101, it would look for 1101 in the translation table (searching on the mailbox number field). It would find 3 entries, for rooms (or extensions) 21101, 71101 and 81101. It would then send a maid status update message for each one. The same process would apply for voice message count updates.

If no translations are found for a given mailbox number, then a single message will be sent using the mailbox number as the room number.