1. What is this module about

...

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.

...

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

...

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.

...

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

...

• 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 worker 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.

...

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 mandatory 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 datetime

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 resubmits 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 resubmittedawaiting 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:

...

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.

...

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 pick up 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 plan boardplanboard).

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

• Registering Costscosts. Adding cost costs (planned vs. actual costcosts) 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 not be applicable to create work orders, and for other problem types, it might be applicablenot.

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 propertybuilding, area, and/or asset can or need to be selected, depending on the problem type settings.

...

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

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 ordersorder' status and can be handled further once the corrective work orders are handled.

If there is an action necesarry required from the requestor, then the request can be forwarded 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 (often frequently asked) questions or possible solutions to problems without the need to contact the service desk.

...

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 moves 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 if 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'

• Distribute 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 enabled enable the default workflow emails, see Workflow emails.

For the request requests module, an overview of the following default workflow emails are available:

...

Email content

...

When is it send

...

Send to

...

An email that a request has been assigned to the service group employee

...

When a request is assigned to a specific service group employee

...

The service group employee the request is assigned to

...

An email to the requestor if the request is set as a duplicate request of another request

...

Once a request is set as a duplicate of another request

...

The requestor of the request if the requestor has indicated to ‘keep me noticed’ on the request

...

An email requesting to perform the work requested in the request

...

If requests are send to contractors (instead of using the corrective work order process for this), this email is send once a requests is forwarded to a contractor (in or external)

...

The contractor to which the request is assigned

...

An email requesting more information (the email is a request to go to the request and provide the requested information in the request and resubmit the request)

...

Once the service group employee set the request to the ‘More information needed’ status (by using the function ‘More information needed’)

...

The requestor of the request if the requestor has indicated to ‘keep me noticed’ on the request

...

An email to notify the requestor that the request has been handled and can be approve or rejects (by opening the request in the system)

...

Once the request is put to handled

...

The requestor of the request if the requestor has indicated to ‘keep me noticed’ on the request

...

An email that a request has been rejected by the requestor after it was handled

...

Once the request gets rejected

...

The service group employee the request is assigned to

...

A email that the request has been canceled

...

Once the request gets cancelled

...

Both the service group employee the request is assigned to and the requestor of the request if the requestor has indicated to ‘keep me noticed’ on the request

...

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:

...