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:
1) Guest: New OnDemand Request
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
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
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
Guest creates a new request using the OnDemand menu.
If configured, Loop automatically creates a HotSOS service order (SO) via API.
HotSOS status update
If the request status is changed via HotSOS:
Office staff member updates the SO status within the HotSOS system, e.g. closed.
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:
Office staff member updates the Request status within the Loop system, e.g. closed.
Loop pushes the updated state to the HotSOS system and performs updates as above.
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.
Deployment & Configuration
The following outlines the process to configure a Loop-HotSOS integration:
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)
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.
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.
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.
OnDemand - HotSOS Mapping
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:
Service Order Fields
The following is an excerpt from the HotSOS API specification. Items in bold are used in the Loop integration:
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:
Loop Request Status
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).
(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
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: