| Table of Contents | ||
|---|---|---|
|
| Info |
|---|
This article is about the use of this module as an application manager, for more information on how to use the concepts in this module as a user (for instance, details on how to create an object), see the related module in the Users part of this knowledge base: Users |
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.
...
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.
...
| Info |
|---|
The enabled settings are evaluated together to determine possible duplicates for a new request. E.g. if duplicate check is enabled for problem type and propertybuilding, only open requests with both the same problem type and the same property building are used as potential duplicates. |
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:
...
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.
...
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.
...
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.
...
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.
...
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 requests module, an overview of the following default workflow emails are available:
...
Email content
...
When is it sent
...
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, if the requestor has indicated to ‘keep me posted’ on the request
...
An email requesting to perform the work requested in the request
...
If requests are sent to contractors (instead of using the corrective work order process for this), this email is sent once a request is forwarded to a contractor (in- or external)
...
The contractor to which the request is assigned
...
An email asking for more information (the email is a call to go to the request and provide extra information in the request and re-submit the request)
...
Once the service group employee sets the request to the ‘More information needed’ status (by using the function ‘Need information’)
...
The requestor, if the requestor has indicated to ‘keep me posted’ on the request
...
An email to notify the requestor that the request has been handled and can be approved or rejected (by opening the request in the application)
...
Once the request is set to handled
...
The requestor, if the requestor has indicated to ‘keep me posted’ 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 cancelled
...
Once the request gets cancelled
...
Both the service group employee the request is assigned to and the requestor, if the requestor has indicated to ‘keep me posted’ 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:
...