Skip to main content
KnowService Integration
Written by Aniko Villeneuve
Updated over a week ago

KNOW Service-Loop Integration

Loop Overview

Loop in hospitality allows guests to engage and make requests of the property from their personal mobile device(s) through web, app, text messaging or email. Requested items from the OnDemand menu are routed to KNOW Service for action and fulfilment in this integration.

KNOW Service Overview

Knowcross’ KNOW Service platform is a platform used by hotels to automate and track preventive maintenance, guest requests, and similar jobs.

Benefits include:

  • Reduce guest service time

  • Increase staff productivity

  • Minimize delays and wrong deliveries

  • Identify trends and analyze performances automatically

Integration Overview

Using Loop with KNOW Service 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 KNOW Service platform for fulfillment by hotel staff.

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 Job (also referred to as a “Job”) is created and fulfilled by staff through the KNOW Service system. The guest and associates is kept informed by Loop:

Loop connects to KNOW Service via a RESTful Webservices API over a secure HTTPS connection. The integration is depicted below:

Several interactions are supported and described following.


Concepts share different names between both systems:

Integration Workflows

The following integration workflows are supported:

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 Loop OnDemand menu.

  2. If configured, Loop automatically creates a KNOW Service Job via API.

KNOW Service status update

When the request status is changed via KNOW Service:

  1. Staff member updates the Job status within the KNOW Service system, e.g. closed.

  2. 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)

The following describe the base integration function is not currently supported:

Loop status update

If the request status is changed via Loop:

  1. Office staff member updates the Request status within the Loop system, e.g. closed.

  2. Loop pushes the updated state to the KNOW Service system and performs updates as above.

1) Guest: New OnDemand Request

Through Loop’s OnDemand menu, request items are directly mapped to KNOW Service Jobs for an immediate workflow:

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

The OnDemand menu is designed for 1:1 mapping between menu items and Jobs to be fulfilled on the KNOW Service platform. Associates are not involved in ‘routing’ or ‘triaging’ such requests on Loop before they are actioned to staff by KNOW Service.


2) Hotel Staff: Status Update via KNOW Service

With an open Job, Loop periodically checks KNOW Service at a polling interval (e.g. 30-seconds) for Job status updates. When a status update is received on an open Job, the Loop thread is updated and all Loop users (guest and hotel staff) are notified:

3) Associate: Status Update via Loop

The following feature is not currently supported by the KNOW Service API: With an open Request and linked Job, 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 KNOW Service system and the Job is updated accordingly:

State Mapping

Mapping between the Loop OnDemand states and KNOW Service’s states is as follows:

 1 – Open or Parked Job with the Requested Time field not set.
 2 – Open or Parked Job with the Requested Time field set (where the Job will happen in the future).

Loop Request Status

The following captures the statuses of a Loop request, and the relationship to KNOW Service (update…):

Additional Requirements

UI Requirements

All requirements are ‘musts’ unless stated otherwise. All requirements assume a configured KNOW Service integration is in place (versus the system ‘as without’ and operating standalone).

Guest Experience

  • Provide status updates for the following states:
    ​ Pending, In Progress, Closed and Scheduled.

  • Display ‘Remarks’ (request detail)

  • Only allow guests to Cancel in state Pending. (since cancellation is not supported via API – Guest must use Messenger and request cancellation via a staff member instead).

Associate Experience

For all requests mapped to KNOW Service:

  • Disable Status update affordance on Requests page (as is only handled via KNOW Service)

  • Visually distinguish Requests that are being actively managed by KNOW Service.

  • Display the status of the KNOW Service link (active & connected or warning)

Deployment Process

Deployment & Configuration

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

  1. The Hotel must obtain the necessary licensing:

  • KNOW Service integration license from KNOW Service (for integration to Loop)

  • Loop integration license from Benbria
     (included in OnDemand license package with KNOW Service integration)

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

  • Job codes for KNOW Service issues included in the OnDemand menu must be known (to be configured in the OnDemand CSV import file) and are available via the KNOW Service API.

  • The process for responding to any OnDemand items not mapped to KNOW Service issues must be clearly discussed with the customer (will be handled via the Loop interface).

  • New issue types may be created on KNOW Service to have mapping and tracking. Re-export to obtain any newly created IDs.

  1. Configure and test the Loop to KNOW Service connection:

  • The KNOW Service system URL and access credentials are required for Loop configuration.

  • Firewall configuration may be required for on-premise KNOW Service deployments.

  1. 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 KNOW Service.

  • As a KNOW Service user: For one open request, update its state to each of the seven possible KNOW Service workflow states (see Error! Reference source not found. on PError! Bookmark not defined.). 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 KNOW Service state is reflected.

Deployment Checklist


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

KNOW Service-Loop Mapping

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

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

Location Configuration

Enter the KNOW Service 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 KNOW Service Jobs to Loop requests is done via the CSV import file at the time when the OnDemand menu is created. The file needs to reference KNOW Service Job 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 KNOW Service Job (internal code) 1521. If a guest were to create a new OnDemand requests of this type, the result would be an automatically created Job in KNOW Service.

The codes for each Job type can be found in the KNOW Service system configuration.

Note: Job issue numbers may not be consistent across KNOW Service instances as each hotel may customize their own issues and issue numbers.

No Duplicates

Due to the implementation details of the KNOW Service platform, a room cannot have two Open jobs of the same code at any time. Therefore, all mapped OnDemand requests must have NODUPLICATES=TRUE.

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 KNOW Service 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.


E.g. KNOW Service UI:

Did this answer your question?