Requests module

• 1. What is this module about
  • 1.1 Service groups
  • 1.2 Service types
  • 1.3 Service Level Agreement (SLA)
  • 1.4 Duplicate check
  • 1.5 Preferred suppliers
  • 1.6 Corrective work orders
  • 1.7 Restrict request creation per building
  • 1.8 Request workflow process
  • 1.9 Other relevant options
    • 1.9.1 Knowledge base
    • 1.9.2 Sub requests
    • 1.9.3 Simple Ticketing via the Workplace App
• 2. Automatic emails sent in the workflow(s)
• 3. General request module settings
• 4. Additional information on this module

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 service type (more about service 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: Requests module activation and information

1.2 Service types

Another very important element of the requests module is the service types. A service type is a way to distinguish between different types of requests. The service 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 service type. If a user creates a request with (for instance) the service 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 service type in a request. The desired option to select a service type in a request can be determined via the ‘Module settings’ → ‘Requests’ → ‘Service type via keywords’.

• Drop-down field (Service type via keywords = No): The user first selects the main level service 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 service type from the hierarchy. After selecting the second level, the third drop-down field becomes visible, where the user can select the third-level service type from the hierarchy. The second and/or third-level service 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. Asset only supports a service type hierarchy of 3 levels maximum by default.
• Keywords field (Service type via keywords = Yes): The user can search the applicable service type via a keywords (text) field. The user starts typing, and after typing at least three characters, all service types are shown which comply. Besides the service type name, the keywords field of the service type is evaluated. To use this option, it is, of course, necessary to fill the keywords for every service type used with relevant search terms.

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

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

1. Cleaning request
2. IT request

Example 2: The customer has a service-type list with a hierarchy of various levels. The user creating the request first selects the top level, and then the next level of service 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 service type drop-down fields), first, the user needs to select the main service type (Cleaning, IT, Electricity, or Furniture). After selecting for example 'Electricity', the sub service types become available and the user needs to select the next applicable service type (Defective wall outlet or Defective lighting).

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

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

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

• Service group: To which service group is the request automatically assigned.
• Priority: The priority determined in the service 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 service 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 service 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 service 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 service type, several work order settings can also be applied, but more on this in the corrective work order chapter.

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

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

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

1.3 Service Level Agreement (SLA)

More information about SLAs in requests and corrective work orders can be found via Service Level Agreements for requests and corrective work orders.

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 service 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 service 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 service 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 service 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 service type. For some service types, it might be applicable to create work orders, and for other service 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 service type. If creating corrective work orders is determined per service type, go to the navigation menu ‘Requests’ → 'Service type schemes’ and set this setting for all relevant service types.

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

1.7 Restrict request creation per building

A request module setting, ‘Determine ticket creation per building’, controls whether this restriction is applied. When enabled, an additional setting becomes available on each building to allow or disallow ticket creation. If a building has no value configured, the system checks the parent building, continuing up the hierarchy until a value is found. If no value is found, ticket creation is considered not allowed for that building. When a user attempts to create a request/ticket for a building where ticket creation is not allowed, an error message is shown. These settings apply to both Asset and Workplace.

1.8 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 service type from the drop-down field or use the keywords field (depending on the client setting) to find the applicable service type. With the subject and description field, the user can give a detailed description of the issue the user is having. The building, area, and/or asset can or need to be selected, depending on the service type settings.

Duplicate check
After the request is submitted, the service group (determined by the service 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.9 Other relevant options

1.9.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 service 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.9.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 service type. Using sub requests can be determined per service 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 service 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 service type via the navigation menu ‘Requests' → 'Service type schemes’ → service type scheme → select the desired service type to enable and create the desired sub requests.

1.9.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 requests module, an overview of the default workflow emails can be found in the user manual: Request workflow emails

3. General request module settings

To navigate to all the general request model settings, go to Modules settings → tab Requests. Hover over the available settings to get more information about a specific setting:

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