1. What is this module about

The Requests module is designed to facilitate the users to create requests and report issues in the building and areas they are working. For example, if an emergency light is broken or the entrance door is jamming, the user can create a request, and the responsible person or team can handle the issue. Via the request module, the request process can be monitored and evaluated.

The next parts will go into more detail on some of the core concepts of this module:

1.1 Service groups

Service groups are the most important components of the requests module. A service group is a group of users or a single user responsible for handling submitted requests for a specific domain. Small companies might only have one service group handling all requests, while bigger companies can have multiple service groups for each domain.

For example, the service group ‘IT’ handles all IT-related requests, the service group ‘Facility' handles all building and area-related requests, and the service group 'Landscaping’ handles all requests related to the environment outside and around the building.

Service groups are automatically determined in a request based on the selected problem type (more about problem types in the next chapter). The request is automatically assigned to the entire service group, and one of the members of that service group can assign the request to himself or herself as the responsible person to handle it.

How to create service groups

• Directly from within the ‘Requests’ module activation (Requests module activation and information)

• Via the ‘Module settings' → ‘Requests’ → 'Servicedesk service groups’ include

For each of the service groups, a user profile can be created via the ‘User profile management dashboard' on the administrator's startboard.

Users with the ‘4. Servicedesk employee’ system group will automatically get the service desk dashboard tab, via which they can handle the requests assigned to their service groups and themselves. For more information: https://spacewell.atlassian.net/wiki/spaces/KB/pages/81133665/Requests+module+activation+and+information#4.5-Navigation-menu-and-startboard-options

1.2 Problem types

Another very important element of the requests module is the problem types. A problem type is a way to distinguish between different types of requests. The problem type also has several options that determine the default service group, priority, behavior, visibility, and pre-defined values of fields in a request. For example, the asset category can be determined within the problem type. If a user creates a request with (for instance) the problem type ‘Printer broken', the asset linked to the request should only be from the category ‘Printer’. It does not make sense if the user can link an asset from a category other than 'Printer'.

There are two ways to select a problem type in a request. The desired option to select a problem type in a request can be determined via the ‘Module settings’ → ‘Requests’ → ‘Problem type via keywords’.

• Drop-down field (Problem type via keywords = No): The user first selects the main level problem type from a drop-down list. After selecting the first level, the second drop-down field becomes visible, where the user can select the second-level problem type from the hierarchy. After selecting the second level, the third drop-down field becomes visible, where the user can select the third-level problem type from the hierarchy. The second and/or third-level problem type drop-down field only applies if the hierarchy has the same number of levels. If the hierarchy only has two levels, obviously, the third-level drop-down field will not become visible. Workplace Management only supports a problem type hierarchy of 3 levels maximum by default.

• Keywords field (Problem type via keywords = Yes): The user can search the applicable problem type via a keywords (text) field. The user starts typing, and after typing at least three characters, all problem types are shown which comply. Besides the problem type name, the keywords field of the problem type is evaluated. To use this option, it is, of course, necessary to fill the keywords for every problem type used with relevant search terms.

A user creating a request can select the problem type from a pre-defined drop-down list or use keywords to find the relevant problem type. All the problem types can be selected in a request, and the hierarchy of the problem types is determined by the customer.

Example 1: The customer only wants two problem types, which can be selected in a request:

1. Cleaning request

2. IT request

Example 2: The customer has a problem-type list with a hierarchy of various levels. The user creating the request first selects the top level, and then the next level of problem types becomes available to select based on the previous level:

1. Cleaning

   1. Toilets

   2. Kitchen

2. IT

   1. Request a new device

   2. Device stolen or missing

   3. Issues with device

      1. Laptop

      2. Phone

      3. Tablet

3. Electricity

   1. Defective wall outlet

   2. Defective lighting

4. Furniture

   1. …

   2. …

In this example (when using the problem type drop-down fields), first, the user needs to select the main problem type (Cleaning, IT, Electricity, or Furniture). After selecting for example 'Electricity', the sub problem types become available and the user needs to select the next applicable problem type (Defective wall outlet or Defective lighting).

When using the problem type keywords search field, the customer can add as many main and sub-level problem types as desired.

When using the problem type drop-down fields, the customer can use a problem type hierarchy of a maximum of three levels by default.

The problem type is not only used to have a predefined list of possible problem types the user (creating the request) can choose from, but the problem type also has a lot of settings that can influence the handling process. Some important settings on problem types:

• Service group: To which service group is the request automatically assigned.

• Priority: The priority determined in the problem type is automatically copied to the request. The priority is used for the Service Level Agreements (See next part).

• Additional information and picture: More information can be specified in the problem type. If this is set, this is automatically displayed in the request to the user creating the request to help the user either solve the problem without needing to submit the request (e.g., ‘Have you tried turning it off and on again') or help describe the issue correctly (e.g., “Make sure to add the version of the browser with which you’re experiencing this problem”).

• Mandatory and visible fields: The problem type determines if certain fields (building, area, and asset) are mandatory to fill in, not mandatory, or not even visible). This can help make the page to submit a request as clean and clear as possible (e.g., no need to bother the user with the option to set an area if they report a broken mobile phone)

• Work order settings: In the problem type, several work order settings can also be applied, but more on this in the corrective work order chapter.

Problem types can be created and managed via the navigation menu ‘Requests' → 'Problem type schemes’¹. The default problem tree is already available and can be filled with the customer's desired problem types.

It is also possible to use the default problem type import template to import all desired problem types (See How to use the import templates)

1. A problem type scheme is a tree of problem types. Technically, multiple problem type schemes can be created, each containing their own problem types. By default, the default problem type scheme 'problem tree' is automatically linked to every new request.

1.3 Service Level Agreement (SLA)

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.

Setting the SLAs

The SLA response times and handle times per priority can be managed (after enabling SLA times via Module settings → Requests: ‘Use SLA times’):

• Directly from within the ‘Requests’ module activation Requests module activation and information

• Via the ‘Module settings' → ‘Requests’ → 'SLA times requests workflow’ include

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: Creating and linking regimes].

SLAs in the request

The priority of the request (determined by the problem type but can be changed by the service desk employee in 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 (and a related traffic sign (Red (too late) or green(Still in time)):

Additional fields are also shown in each request itself:

If already set, the actual response date and handle date fields are only shown on the request page. These 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.

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:

Tasks that are deducted from the handle date

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.

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:

1.4 Duplicate check

Automatic duplicate checks can be enabled when a request is submitted. If, for instance, a problem occurred in the main hall, where all employees pass by, it could be that more than one user creates a request with the same problem type, building, and area. If the service group receives 10 requests about the same issue, the first request is assigned to a service group responsible person. The other nine requests can be marked as a duplicate of the first request. The service group responsible now only has to follow up and handle the first request instead of handling all 10 requests individually. After the first request is handled, the other duplicate automatically follow and are automatically handled.

Duplicate checks can be enabled for:

• The same problem type

• The same building

• The same area

• The same asset

The duplicate check is only executed for open requests. Already closed requests with the same problem type, building, and the same area, for example, are not taken into account.

Duplicate checks can be enabled via the ‘Module settings' → 'Requests’ tab:

If a request is submitted, the system will automatically determine if any open requests could be potential duplicates (based on the settings). If this is the case, the first task for the service group employee will be to determine if the request is indeed a duplicate (and if so, link it to the original request) or indicate that the request is not a duplicate and continue handling the request as usual.

1.5 Preferred suppliers

Via the use of preferred suppliers, requests (or work orders) can automatically be assigned to a preferred supplier based on the role specified in the problem type. For more information about preferred suppliers, see: Preferred suppliers.

1.6 Corrective work orders

Corrective work orders can be used as an extension for requests. A corrective work order is always created as a result of a request. Corrective work order can not be created without a request. As the word 'corrective' already suggests, something must be corrected or fixed. There are multiple reasons to use corrective work orders:

• Corrective work orders can be planned in time (either via the start/end date fields on a work order, which a request does not have, or via the planboard).

• Multiple corrective work orders can be created from a single request, if, for instance, multiple contractors are needed to fix a problem.

• Registering costs. Adding costs (planned vs. actual costs) in a request is impossible. This is possible in a work order, by adding generic cost items (e.g. costs for repairs), predetermined catalog items (e.g. 10 screws) and/or predetermined inventory items (e.g. an engine part).

Creating corrective work orders can also be depending on the problem type. For some problem types, it might be applicable to create work orders, and for other problem types, it might not.

Corrective work orders can be enabled via the module activation. Via the 'Module settings' → ‘Requests' or the module settings ‘Maintenance' → ‘Corrective work orders’, it can be determined if corrective work orders can be created in each request or if it depends on the linked problem type. If creating corrective work orders is determined per problem type, go to the navigation menu ‘Requests’ → 'Problem type schemes’ and set this setting for all relevant problem types.

More information about the corrective work order module can be found: Corrective work orders module activation and information

1.7 Request workflow process

The following part describes the workflow for a request from a high-over point of view. For a detailed description, see the user manual Requests module for (end)users.

Create and submit the request
A user can create a new request and select the applicable problem type from the drop-down field or use the keywords field (depending on the client setting) to find the applicable problem type. With the subject and description field, the user can give a detailed description of the issue the user is having. The property, area, and/or asset can or need to be selected, depending on the problem type settings.

Duplicate check
After the request is submitted, the service group (determined by the problem type) is automatically assigned to the request. If at least one duplicate check is enabled, the user from the applicable service group can check whether it is a duplicate request and register this accordingly. If the request is a duplicate, the request moves to a 'Waiting for duplicate request' status and continues once the original request is handled.

Assignment of service group member
The request is automatically assigned to the applicable service group, and every member can now pick up the request by assigning it to themselves. Before the request is assigned to a service group member, details of the request can be modified by the service group to clarify or correct request information.

More information needed
If the request is not described in detail and the service group has additional questions, the request can be sent back to the requestor. The requestor will then get a task to provide the service group with more information, before re-submitting the request.

Retract and reassign
Once a request is assigned to a service group member, it can be retracted and reassigned to another service group member.

Handle the request
The request can be handled by the service group member to whom the request is assigned or via corrective work orders (if applicable and the module is activated). If corrective work orders are created, the request will go to the 'Awaiting work order' status and can be handled further once the corrective work orders are handled.

If there is an action required from the requestor, then the request can be sent back to the requestor during the handling of the request.

Review request
The requestor can review the request handled by the contractor and can either approve or reject the offered solution or fix.

1.8 Other relevant options

1.8.1 Knowledge base

The Knowledge base is a functionality to document and share relevant information. Knowledge base can be used as a stand-alone functionality or with requests. Knowledge base articles can be created to provide information on specific subjects (in general or related to a specific problem type). These articles could then help users with certain (frequently asked) questions or possible solutions to problems without the need to contact the service desk.

Enabling the Knowledge base can be done via the ‘Module settings' → ‘Requests: Knowledge base’ → 'Use Knowledge base’ setting.

For more detailed information about the knowledge base see Knowledge base.

1.8.2 Sub requests

Sub requests can be used if a problem/request consists of multiple pre-defined actions, which are always applicable for a request related to this problem (type). Using sub requests can be determined per problem type and each of the sub requests can have its own service group which needs to handle the sub request.

With sub requests, the main request is automatically broken down into one or more sub requests. After submitting the main request, it’s pushed to a 'Waiting for sub requests' status. The sub requests are all assigned to the applicable service group. Once all sub requests have been handled, the main request is automatically closed.

For example, a request is created to prepare a new work laptop when a new employee is hired. The problem type 'New employee laptop' consists of several sub requests:

• Purchase a new laptop → service group 'Purchasing'

• Create a new mailbox for the employee → service group 'IT'

• Prepare the laptop with all relevant software → service group 'IT'

• Hand out the laptop on the first day → service group 'Office Manager'

Sub requests can be enabled per problem type via the navigation menu ‘Requests' → 'Problem type schemes’ → problem tree → select the desired problem type to enable and create the desired sub requests.

1.8.3 Simple Ticketing via the Workplace App

If Workplace Experience is also used, a request can be created via the Workplace App. More information about Workplace Experience can be found here: Workplace Experience integration: Reservations module activation and information.

2. Automatic emails sent in the workflow(s)

Workflows can automatically send emails after a certain task is executed or a workflow has been in a status for a certain amount of time. The default emails need to be activated per workflow. For more information on how to enable the default workflow emails, see Workflow emails.

For the request module, the following default workflow emails are available:

3. Additional information on this module

More information on the Requests module can be found via the following related articles:

• For an (end) user manual, see: Requests module for (end)users

• For more detailed implementation information (including how to enable the module, which system groups are involved, data imports and more information on the startboard and navigation menu options) see: Requests module activation and information