HotSOS-Loop Integration

Status: GA Scope: Loop OnDemand Beta Release: 6 June 2016

Loop Overview

Loop is a suite of mobile dialog & insight products designed to improve guest engagement and support data-driven business decisions. In hospitality, guests use loop to request, compliment or raise concerns while on-property from their personal mobile device(s) through web, app, text messaging or email.

HotSOS Overview

HotSOS by Amadeus is a Service Operation software platform used by hotels to automate and track preventive maintenance, service orders, and guest requests.

Integration Overview

Using Loop with HotSOS integration, a hotel guest can directly request services from their personal device and have those requests automatically (or manually in some cases, with the action of a hotel associate) routed to the HotSOS platform for fulfillment by hotel staff. Loop can be categorized as a ‘Guest System’ in the diagram above.

 

Guests receive convenience and expedited service.
Hotel reduces staff workload, increases guest satisfaction and gains revenue opportunities.

Integration Overview

In short, by ‘requesting’ a service item using Loop, a corresponding Service Order (also referred to as “Issue”) is created and fulfilled by staff through the HotSOS system. The guest and associates is kept informed by Loop:

Technically, Loop engages the HotSOS platform for all interactions and updates; unlike other systems HotSOS does not push events. Loop connects to HotSOS via REST API over a secure HTTPS connection. The integration is depicted below:

Several interactions are supported and described following.

 

Integration Workflows

The following integration workflows are supported, each with decreasing levels of automation:

1) Guest: New OnDemand Request

Status: Beta Scope: Loop OnDemand Beta Release: 6 June 2016

Through Loop’s OnDemand menu (see doc 4101 Loop® OnDemand Feature Sheet), request items are directly mapped to HotSOS issues for an immediate workflow:

Left:        An example ‘Bath Towel’ menu in Loop’s OnDemand Interface.
Right:     The integration sequence between the guest, Loop and HotSOS to trigger action on an example request.

The OnDemand menu is designed for 1:1 mapping between menu items and HotSOS-fulfilled issues. Associates are not involved in ‘routing’ or ‘triaging’ such requests before they are actioned to staff by HotSOS.

 

 

2) Hotel Staff: Status Update via HotSOS

Status: Beta Scope: Loop OnDemand Beta Release: 6 June 2016

With an open SO, Loop periodically checks HotSOS at a polling interval of 10-seconds for service order status updates. When a status update is received on an open SO, the Loop thread is updated and all Loop users (guest and hotel staff) are notified:

3) Associate: Status Update via Loop

Status: Beta Scope: Loop OnDemand Beta Release: 6 June 2016

With an open Request and linked SO, through the Loop system the associate updates the request status. The Loop thread is updated and all Loop users (guest and hotel staff) are notified, plus the new status is pushed to the HotSOS system and the SO is updated accordingly:

Base Integration Functions

The following describe the base integration functions provided in workflows 1) and 2) above:

Guest Creates a Request

1. Guest creates a new request using the OnDemand menu.
2. If configured, Loop automatically creates a HotSOS service order (SO) via API.

HotSOS status update

If the request status is changed via HotSOS:

3. Office staff member updates the SO status within the HotSOS system, e.g. closed.
4. Loop, via active polling, receives the updated status and performs the following:

• propagates the fulfilled status to the guest and all staff with visibility.
• notifies each party via their preferred communication channels (email, sms)

Loop status update

If the request status is changed via Loop:

5. Office staff member updates the Request status within the Loop system, e.g. closed.
6. Loop pushes the updated state to the HotSOS system and performs updates as above.

 

Administration

HotSOS integration requires that Messenger and OnDemand are set up correctly for the account and for the specific location.

HotSOS-Loop Mapping

A single HotSOS instance must be deployed for each hotel property (location). HotSOS does not support Multi-tenanted configurations:

Note: No validation is provided by Loop to overlapping LocationßàHotSOS mappings. Administrators should take care to not configure two different Loop locations to point to the same HotSOS server.

Location Configuration

Enter the HotSOS server URL and access credentials on the Loop Admin Locations page in the corresponding fields:

Note: These configuration fields do not appear on the Locations page unless OnDemand is enabled.

Request-Issue Mapping

Mapping of the HotSOS Service Orders to Loop requests is done via the CSV import file at the time when the OnDemand menu is created. The file needs to reference HotSOS SO codes from the target integration server in a column labeled “code” (here Luggage Assistance and Bedding & Pillows is mapped). 

In this example the OnDemand menu item "Luggage Assistance" is mapped to HotSOS Service Order (internal code) 1521. If a guest were to create a new OnDemand requests of this type, the result would be an automatically created SO in HotSOS.

The codes for each SO type can be found in the HotSOS system configuration.

Note: SO issue numbers may not be consistent across HotSOS instances as each hotel may customize their own issues and issue numbers.

No Duplicates

Certain requests are singular (e.g. “Make up Room”). Such requests are marked with a ‘No Duplicates’ flag which prevents more than one being queued in the system at any given time.

Mark ‘TRUE’ (or ‘true’) in column “NoDuplicates” to enable this feature:

Note: An item’s NoDuplicates setting of the Loop configuration must match the same of the HotSOS configuration.

Unless the NoDuplicates value is explicitly set to true, up to ten duplicate, open request items will be allowed for a room at a given time. With ten open requests, no new requests of the same type for the same room can be submitted. A request is considered open until marked as “fulfilled” or “cancelled”.

Handling Duplicates

If a guest attempts to submit a second (open) request where NoDuplicates=TRUE, rather than creating a new request in Loop Employee Inbox, the guest’s original request will be updated with the newly requested information.

 

 

Deployment Process

Deployment & Configuration

The following outlines the process to configure a Loop-HotSOS integration:

1. The Hotel must obtain the necessary licensing:

• HotSOS integration license from Amadeus (for integration to Loop)
• Loop integration license from Benbria
  (included in OnDemand license package with HotSOS integration)

2. The OnDemand menu must be designed with the following considerations:

• IDs for HotSOS issues included in the OnDemand menu must be known (configured in the OnDemand CSV import file). Configured IDs can be exported from the HotSOS system.
• The process for responding to any OnDemand items not mapped to HotSOS issues must be clearly discussed with the customer (will be handled via the Loop interface).
• New issue types may be created on HotSOS to have mapping and tracking. Re-export to obtain any newly created IDs.

3. Configure and test the LoopóHotSOS connection:

• The HotSOS system URL and access credentials are required for Loop configuration.
• Firewall configuration may be required for on-premise HotSOS deployments.

4. Configure the OnDemand menu and test as per the following:

• As a guest: Request one of every item from the OD menu. Ensure the corresponding issue is created in HotSOS.
• As a HotSOS user: For one open request, update its state to each of the seven possible HotSOS workflow states (see Service Order Status on P11). Test to ensure the appropriate Loop state is displayed to the Guest and is also visible in the Manager Inbox.
• As a Loop user: For one open request, change state via the Loop Requests page. Test to ensure the appropriate HotSOS state is reflected.

Deployment Checklist

þ	Required Item:	Source:	Process:
□	1. HotSOS Integration License	Newmarket / Amadeus	Hotel to purchase
□	2. HotSOS Integration Parameters	Newmarket / Amadeus	Amadeus to send
□	3. HotSOS Issue Export (with ID #s)	HotSOS System Instance	Hotel IT to send
□	4. Loop Integration License	Benbria	Benbria to provide
□	5. (task) OnDemand Menu Design	Hotel Leadership	(Collaborative)
□	6. (task) Creation of missing HotSOS Issues	HotSOS Administrator	Hotel IT to create
□	7. (task) Firewall configuration (if required)	Hotel IT	Hotel IT to implement
□	8. (task) Integration configuration	Benbria + Hotel IT	Benbria to lead
□	9. (task) Testing	(combined HotSOS+Loop)	Benbria to lead

 

 

OnDemand ó HotSOS Mapping

Service Orders

A service order is a request. Its key fields for Loop are an ‘Issue’ number, room number and status (state).

HotSOS Issues

HotSOS Issues are each uniquely numbered. This numbering scheme is maintained by HotSOS as a global registry (all HotSOS systems reference the same issue IDs). Approximately 1,600 issues are currently maintained. A hotel will implement HotSOS with a shorter, specific list of issues that correspond to the services offered at that property. Example issues are below:

Service Order Fields

The following is an excerpt from the HotSOS API specification. Items in bold are used in the Loop integration:

Field Name	Type	Description
ID	String	A unique numeric value that identifies the service order (defined in MTech systems).
ActionTime	DateTime (GMT)	Time when the service order should become active.
AssignedTo	User	The user assigned to this service order
CreatedBy	User	The user who created this service order
Inspectee	User	The user being inspected
Inspection	Inspection	List of Inspection objects associated to a service order.
Issue	Issue	The issue to be resolved.
ExtendedAttributes	ExtendedAttribute[]	Extra attributes associated to service order.
Labor	Labor[]	List of Labor objects associated to service order
LastEvent	ServiceOrderEventEnum	The last event that occured to this service order.
Location	Room	The location where the issue occurs.
NewRemark	String	The latest remark of this service order.
Parts	Parts[]	List of Parts objects associated to service order
Priority	int	The priority of the service order (1 to 5, 1 is highest priority).
Recoveries	Recovery[]	List of Recovery objects (e.g. rebate, etc) associated to service order.
RequestedBy	User	The user who requested the service order
RequestTime	DateTime (GMT)	The time this service order was requested
Reservation	Reservation	The guest associated with the service order
Status	ServiceOrderStatusEnum	The status of the service order.
Trade	String	The name of the trade (e.g. engineering, housekeeping, etc.) of the service order (defined in MTech systems).
Type	ServiceOrderTypeEnum	The type of service order.

Service Order Mapping Process

For a given deployment, Loop tags and OnDemand menu items must be ‘mapped’ to specific HotSOS issue codes. This process is done by a Loop administrator via the Loop Admin Interface.

Service Order Status

The following HotSOS enumeration captures statuses of a service order in the HotSOS system:

ID	Name	Description
0	CLOSED	The service order has been closed
1	COMPLETED	The service order has been completed
2	CREATED	The service order has been created
3	DEFERRED	The service order has been scheduled to become active at a later time
4	DIRECTED	The service order has been directed (sent) to a user
5	STARTED	The service order has been started by a user
6	STOPPED	The service order has been stopped and not currently being worked on.
7	VOIDED	The service order has been voided

Loop Request Status

The following captures the statuses of a Loop request, and the relationship to HotSOS:

Additional Content

UI Requirements

All requirements are ‘musts’ unless stated otherwise. All requirements assume: with a configured HotSOS integration (versus the system ‘as without’ and operating standalone).

Guest Experience

• (As without) Display on the guest UI the request statuses: Pending, In Progress, Closed and Canceled.
• Display also on the guest UI the request status: Scheduled.
• Display HotSOS Service Order field ‘NewRemark’ (or ‘Remarks’ overall if available)
• Should: Display a ‘history’ of states, e.g. (time, action, state):
  7:52AM Created, Pending
  7:54AM Acknowledged, In Progress
  8:02AM Completed, Closed

Associate Experience

• View all open requests for ‘my property(ies)’
• For each request, view the following information:
  • Requested Item Name (Loop field)
  • Requested Item Detail (Loop field e.g. quantity, time)
  • Requested Item Notes (Loop field e.g. special requests, detail)
  • Request State (See ‘With’ request states below)
  • Guest Room Number
  • Guest Name
  • HotSOS Issue Number (HotSOS field)
  • Original request time (HotSOS field)
  • Assigned to user name (HotSOS field)
• Overall, the status of the HotSOS link (active & connected or warning)
• Without an active HotSOS integration, in each of the following states have the following affordances:
  • Pending: Acknowledge | Cancel* | Update Notes
  • In Progress: Completed | Cancel* | Update Notes
  • Canceled: N/A
  • Closed: N/A
    *(with explicit confirmation to cancel)
• With an active HotSOS integration, in each of the following states have the following affordances:
  • Scheduled: Cancel* | Update Notes
  • Pending: Acknowledge | Cancel* | Update Notes
  • In Progress: Completed | Cancel* | Update Notes
  • Canceled: N/A
  • Closed: N/A
    *(with explicit confirmation to cancel)

 

HotSOS Examples

Related HotSOS product images have been provided for reference.

HotSOS UI Login

HotSOS “Issues” UI for Service Order Management

Additional Proposed Workflows

4) Guest: New Loop (free-form text, auto-tagging)

Status: Proposed Scope: Loop OnDemand

Should a guest submit a free-form text request (via Loop TnT flow or Loop Messenger plain text, for example), Loop’s auto-tagging capabilities can be used to auto-assign one or more tags based on specific keywords in the message. Based on tags and mapping rules, HotSOS service orders can then be automatically created:

5) Guest: New Loop (free-form text, manual-tagging)

Status: Proposed (previously available, discontinued)     Scope: Loop OnDemand             

Should a guest submit a free-form text request (via Loop TnT flow, for example), an associate using the Loop Inbox may manually tag a loop to invoke mapping rules and create a corresponding HotSOS service order based on the tag assigned. This workflow is depicted below:

6) Guest: Comment on Open SO

Status: Concept (previously available, discontinued)        Scope: Loop Messenger, Loop TnT

With an open SO, guest comments on TnT are pushed to HotSOS and added to the Remarks field on the SO. Hotel Staff are notified based on the active HotSOS configuration: