Service Level Agreements for requests and corrective work orders

Requests

Service Level Agreements (SLAs) are (usually contractual) agreements with internal departments or external suppliers regarding the response and handling times of assigned requests based on the priority of the request. The department or contractor needs to respond to and handle the requests within a pre-determined period of time, depending on the priority, to comply with the SLA.

Service Level Agreements for requests can be enabled:

  • via the Requests module activation
  • via ‘Module settings’ → ‘Requests’ tab → ‘Use Service Level Agreements in requests’
image-20260910-134017.png

Once Service Level Agreements in requests is enabled, a new menu option becomes available under the 'Requests' menu header:

image-20260910-135913.png

The Service Level Agreements dashboard can now be used to manage all SLA related configurations and dashboards for requests:

image-20260910-142821.png
  • Regimes: Manage regimes to define different availability schedules, such as working hours. Regimes can be linked to contractors and are used to determine the correct planned handle date for the requests assigned to the respective contractor.
  • Priorities: By default, the following priorities are available: Critical, High, Medium, Low, and Very low. Additional priorities can be added through this option, allowing specific SLAs to be configured for these priorities.
  • Requests SLA dashboard response times: This dashboard shows, via a number of graphs, the distribution between the number of requests that have been responded to (response time) within versus outside SLA, broken down into different overviews (All requests, per service group, handler, location, service type, type and priority).
  • Requests SLA dashboard handle times: This dashboard shows, via a number of graphs, the distribution between the number of requests that have been handled within versus outside SLA (response time), broken down into different overviews (All requests, per service group, handler, location, service type, type and priority).

Manages Service Level Agreements per priority

For each of the five default priorities (very low, low, medium, high, critical) an SLA value for the response time and handle time can be set. These can be set in minutes, hours, days, weeks, or months. For hours or days, the planned times can also be set in ‘work’ hours or days. If used, the planned response and handle times of a request are calculated, taking the work hours regime into consideration. See: Managing regimes for more information about regimes.

The ‘Response times requests' and 'Handle times requests’ overviews are pre-filled with the default priorities and default response and handle times.

image-20260911-114618.png

If the client uses custom priorities, additional response times and handle times can be configured for these priorities.

Service Level Agreements in requests

The priority of a request is determined based on the service type, area, and asset. The highest priority among these three is automatically assigned as the request priority. The priority of the request will determine the planned response time and planned handle time of the request in combination with the submit date/time of the request. The submit date/time is automatically set based on the moment the requestor submits the request.

The planned response and handle dates are automatically determined for a request, and, as mentioned, if ‘work’ hours or days are used, the work hour regime is also taken into consideration. If, for instance, a request must be handled in 2 work hours, work hours are defined as weekdays 08:00 - 17:00, and a request is submitted at 16:00, the request must be handled at the latest at 09:00 the next day. If regular hours are used in the SLA, this would be 18:00 the same day.

If SLAs are enabled, the service desk dashboard also shows the planned handle date, time to handle/time to complete (and a related traffic sign (red, too late or green, on time):

image-20260911-115942.png

Additional fields are also shown in each request itself and via the Service Level Agreements tab:

image-20260911-122328.pngimage-20260911-122518.png

The ‘Response date' and 'Handle date’ fields are set via the following actions:

  • Response date: Automatically set if the service desk employee executes the first action in the request. This either indicates the request is (or is not) a duplicate request or assign the request to a service desk employee.
  • Handle date: Automatically set once the request is handled (manually or automatically via the corrective work order process). If the request is rejected after it is handled and it is handled again, the handle date is reset to this new handled date.

Changing the log date, response date, and handle date

The planned response and planned handle dates in a request cannot be changed, as these are based on priority. However, the service desk employee can change the actual dates (log, response, and handle dates) if an exception to the date/time the system has set for these fields is needed.

Info

It's possible that, for instance, the problem in the request was already handled before the request in the system itself was set to handled (thus a manual correction on the handle date is needed to represent the actual handle date), or the request was not submitted via Asset by the requestor, but create by the service desk employee based on an email sent a few hours before, thus officially requiring a log date based on the time the email from the requestor was received if SLAs are to be followed strictly.

The pencil icon behind the field can be used if any of these three dates must be changed. A new date/time can be set, and a reason must be added. If any of these date/time fields are altered, the date/time will be displayed in red, and a log of these changes will be shown in an include on the request page:

image-20260911-124837.pngimage-20260911-124928.png

The changes on any of the date fields are visible via the Service Level Agreements tab:

image-20260911-125018.png

Tasks that are deducted from the handle time

The time it takes to handle a request is not always fully in control of the employees handling it. If more information is needed from the requestor, the time it takes for the requestor to provide this information and re-submit the request should not be considered for the SLAs. Therefore, the time the request stays in this status ('Action requestor') is added to the planned handle date once the requestor re-submits the request. So if the requestor took 8 (work) hours to re-submit, 8 (work) hours are added to the planned handle date once the request is re-submitted.

Any other tasks between submitting the request and handling the request are not deducted from the handle time. This also includes the time a request is awaiting the handling of corrective work orders.

SLA dashboards

After the request is handled, the response time and handle time can be evaluated via several default reports on the Requests dashboard based on the SLA times:

image-20260911-130113.pngimage-20260911-130312.pngimage-20260911-130425.png

Corrective work orders

Service Level Agreements for corrective work orders can be enabled:

  • via the Corrective work order module activation
  • via ‘Module settings’ → ‘Corrective work orders’ tab → ‘Use Service Level Agreements in corrective work orders’
image-20260911-133636.png

Once Service Level Agreements in corrective work orders is enabled, a new menu option becomes available under the 'Requests' menu header:

image-20260910-135913.png

The Service Level Agreements dashboard can now be used to manage all SLA related configurations and dashboards for corrective work orders:

image-20260911-134052.png
  • Suppliers: Option to manage supplier organizations.

Info

The ‘Suppliers' button is only visible if ‘Use Service Level Agreements per supplier’ is enabled. In addition, several options shown in screenshots below, also depend on this setting being enabled (e.g. the button ’Add handle time for specific supplier').

More information on SLAs per suppliers can be found below.

  • Regimes: Manage regimes to define different availability schedules, such as working hours. Regimes can be linked to contractors and are used to determine the correct planned handle date for the requests assigned to the respective contractor.
  • Priorities: By default, the following priorities are available: Critical, High, Medium, Low, and Very low. Additional priorities can be added through this option, allowing specific SLAs to be configured for these priorities.
  • Requests SLA dashboard response times: This dashboard shows, via a number of graphs, the distribution between the number of requests that have been responded to (response time) within versus outside SLA, broken down into different overviews (all requests, per service group, handler, location, service type, type and priority).
  • Requests SLA dashboard handle times: This dashboard shows, via a number of graphs, the distribution between the number of requests that have been handled within versus outside SLA (response time), broken down into different overviews (all requests, per service group, handler, location, service type, type and priority).
  • Work orders SLA dashboard: The SLA dashboard provides an overview of corrective work orders that are approaching or have exceeded their SLA deadlines. It also includes graphs that provide insight into supplier performance against the agreed service levels, helping you monitor whether work orders are handled within the required time frames.

Manages Service Level Agreements per priority

For each of the five default priorities (very low, low, medium, high, critical) an SLA value for the handle time can be set. These can be set in minutes, hours, days, weeks, or months. For hours or days, the planned times can also be set in ‘work’ hours or days. If used, the handle times of a corrective work orders are calculated, taking the work hours regime of the contractor into consideration. See: Managing regimes for more information about regimes.

The 'Handle times requests’ overview is pre-filled with the default priorities and default handle times.

image-20260911-135332.png

If the client uses custom priorities, handle times can be configured for these priorities.

Service Level Agreements in corrective work orders

The priority of a request is determined based on the service type, area, and asset. The highest priority among these three is automatically assigned as the request priority. The priority of the request is automatically taken over to the corrective work order and will determine planned handle time of the corrective work order in combination with the send date of the corrective work order. The send date is automatically set based on the moment the corrective work order is forwarded to the contractor.

The handle date is automatically determined for a corrective work order, and, as mentioned, if ‘work’ hours or days are used, the work hours regime of the contractor is also taken into consideration. If, for instance, a corrective work order must be handled in 2 work hours, work hours are defined as weekdays 08:00 - 17:00, and a corrective work order is forwarded to the contractor at 16:00, the corrective work order must be handled at the latest at 09:00 the next day. If regular hours are used in the SLA, this would be 18:00 the same day.

If SLAs are enabled, the service desk dashboard also shows the planned handle date and time to complete (and a related traffic sign (red, too late or green, on time):

image-20260914-084830.png

Additional fields are also shown in each corrective work order itself and via the Service Level Agreements tab:

image-20260914-085159.png

image-20260914-085312.png

The 'Handle date’ fields is set via the following actions:

  • Handle date: Automatically set once the corrective work order is handled. If the corrective work order is rejected after it is handled and it is handled again, the handle date is reset to this new handled date.

Changing the log date, response date, and handle date

The planned handle date in a corrective work order cannot be changed, as this is based on priority. However, the service desk employee can change the actual dates (send date and handle date) if an exception to the date/time the system has set for these fields is needed.

Info

In some cases, the issue may have already been reported to the applicable contractor by phone before the work order is formally forwarded. In this situation, the send date can be manually corrected to reflect the actual date and time when the contractor was informed about the work. This manual correction is also taken into account when calculating the planned handle date and time, ensuring that the deadline reflects when the contractor was actually notified.

The pencil icon behind the field can be used if any of these dates must be changed. A new date/time can be set, and a reason must be added. If any of these date/time fields are altered, the date/time will be displayed in red, and a log of these changes will be shown in an include on the corrective work order page:

image-20260914-090703.pngimage-20260914-090909.png

The changes on any of the date fields are visible via the Service Level Agreements tab:

image-20260914-091018.png

Updated planned handle date after retract/reschedule

When a corrective work order is retracted or rescheduled by a service desk employee, the send date is reset. When the corrective work order is forwarded to the contractor again, the send date is updated and the planned handle date is automatically recalculated.

Service Level Agreements per supplier

It is possible to configure generic SLAs or SLAs per supplier. SLA configuration per supplier can be enabled via ‘Module settings' → ‘Corrective work orders’ tab → 'Use Service Level Agreements per supplier’

image-20260914-092200.png

This setting enables Service Level Agreement (SLA) configuration at the supplier level, allowing administrators to define specific SLAs for individual suppliers. For example, the standard SLA for the Critical priority may be 4 working hours, while a specific supplier may have an SLA requiring Critical work orders to be handled within 2 working hours.

image-20260914-093328.png

In the example (screenshot) above, Supplier 1 has a deviating SLA for the Critical priority. For the High priority, the regular SLA is applied because no specific SLA has been configured for Supplier 1.

A Service Level Agreements tab becomes available on the supplier page, allowing SLAs to be configured directly for each individual supplier, in addition to configuring them through the Service Level Agreements menu option.

image-20260911-142951.png

Suppliers may have different working hours and service level agreements depending on the type and priority of the corrective work orders assigned to them. The planned handle date of a corrective work order is automatically calculated based on the SLA that applies to the assigned supplier.

Configuring SLAs per supplier enables you to monitor supplier performance and periodically assess whether corrective work orders are completed within the agreed service levels.

The Work order SLA dashboard (see the next chapter for more information) can be accessed directly from the supplier page. This allows clients to review SLA performance with the supplier based on actual work order data, including work orders completed within or outside the agreed SLA.

Work order SLA dashboard

The Work order SLA dashboard provides an overview of the SLA performance of handled corrective work orders. Using the available filters, users can analyze SLA performance for a specific building, supplier, asset, or other relevant criteria.

image-20260914-125656.png

After applying the filters, several graphs and lists are displayed, providing insight into SLA performance. The dashboard also shows overviews of open corrective work orders that are still within SLA or have already exceeded the SLA.

image-20260914-130259.pngimage-20260914-130404.png
  • SLA compliances handled corrective work orders: A pie chart with the (filtered) total number of handled corrective work orders divided in inside SLA (green) and outside SLA (red)
  • SLA compliances per priority handled corrective work orders: A column chart with the (filtered) total number of handled corrective work orders divided in inside SLA (green) and outside SLA (red) per priority
  • Within SLA vs outside SLA over a weekly period for handled corrective work orders: An area chart with the (filtered) total number of handled corrective work orders divided in inside SLA (green) and outside SLA (red) per week over a period of time
  • Within SLA vs outside SLA over a monthly period for handled corrective work orders: An area chart with the (filtered) total number of handled corrective work orders divided in inside SLA (green) and outside SLA (red) per month over a period of time
  • Total overview of handled corrective work orders (graph data): The list shows the (filtered) handled corrective work orders on which the graphs above are based. Users can drill down into individual work orders for more detailed information.
  • Corrective work orders (less than one day left until SLA due date): The list shows the (filtered) corrective work orders that are still within the SLA but have a planned handle date within the next 24 hours. These work orders can still be handled within the agreed service level.
  • Corrective work orders (overdue on SLA due date): The list shows the (filtered) corrective work orders that are outside the SLA. These work orders were not handled within the agreed service level and can be reviewed with the contractor to discuss the reasons for the delay.