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 by Amadeus is a Service Operation software platform used by hotels to automate and track preventive maintenance, service orders, and guest requests.

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.
​ 

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.

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

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.

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:

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:

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

If the request status is changed via HotSOS:

If the request status is changed via Loop:

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

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.

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.

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.

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”.

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.

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

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

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:

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

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.

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

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

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

Related HotSOS product images have been provided for reference.

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:

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:

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: