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:
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 the submitted requests for a specific domain. Small companies might only have one service group handling all requests and bigger companies can have multiple service groups for each of the domains.
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 him or herself as the responsible person to handle the request.
How to create service groups
Directly from within the ‘Requests’ module activation (Requests module activation and information)
Via the ‘Module settings' → ‘Requests’ → 'Servicedesks service groups’ include
For each of the service groups a user profile can be created via the ‘User profile management dashboard' on the administrators startboard.
Be aware: Each service group user profile should consists of (at least) the ‘4. Servicedesk employee’ system group and the corresponding system group of the service group, for example 'IT'. For more information on authorizing users: Authorizing users |
Users with the ‘4. Servicedesk employee’ system group will automatically get the service desk startboard 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
Another very important element of the requests module are the problem types. A problem type is a way to distinguish between different types of requests. The problem type also has several options which determine the default service group, priority, and behavior, visibility and pre-defined values of fields in a request. For example, the asset category can be determine within the problem type. If a user creates a request with (for instance) the problem type ‘Printer broken', the asset which can be 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 anything other than a 'Printer'.
In a request, the problem type can be selected via one of two options (which can be determined via 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 is only applicable, if the hierarchy also has the same number of levels. If the hierarchy only has 2 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 3 characters, all problem types are shown which comply. Besides the problem types 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 lists or uses keywords to find the relevant problem type. All the problem types which 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:
Cleaning request
IT request
Example 2: The customer has a problem type list with a hierarchy with various levels. The user creating the request first selects the top level and then the next level of problem types become available to select based on the previous level:
Cleaning
Toilets
Kitchen
IT
Request a new device
Device stolen or missing
Issues with device
Laptop
Phone
Tablet
Electricity
Defect wall outlet
Defect light
Furniture
…
…
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 (Defect wall outlet or Defect light).
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 the customer can use a problem type hierarchy of maximum 3 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 which can influence the handling process. Some important settings on problem types:
Service group: To which service group is the request automatically assigned to.
Priority: The priority determined in the problem type is automatically taken over 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 solving 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 you experience 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 on is 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 apply, 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 problem types the customer desires.
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)
Service Level Agreements (SLAs) are (usually contractual) agreements with internal departments or external suppliers on the response, and handle 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
Via the ‘Module settings' → ‘Requests’ → 'SLA times requests workflow’ include
For each of the 5 default priorities (very low, low, medium, high, critical) an SLA value for the response time and for the handle time can be set. These can be set based 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) will determine the planned response time and 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 taking 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 or green):
Additional fields are also shown in each request itself:
The actual response date and handle date are only shown on the request if already set. 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 is either indicating 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 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 the priority. The actual dates however, can be changed by the service desk employee. Since it is possible that the requestor was already responded to via phone or email before assigning the request, or the issue in the request was already handled before the request itself was set to handled, both of these dates, as well as the log date (in case the request was not submitted via workplace management by the requestor, but create by the service desk employee based on an email, thus having a log date that should be set earlier than the system has set it). if any of these three dates must be changed, the pencil icon behind the field can be used for this. A new date/time can be set and a mandatory reason must be added. If any of these date/time fields is altered, the date/time will be displayed in red and a log of these changes is shown in an include on the request page:
Tasks that are deducted from the handle date:
SLA times work as follows:
The request is still in draft and not yet submitted by the user → the response time is not yet started
The request is submitted, but not yet assigned to the responsible user → the response time is started
The request is assigned back to the requestor, because the request is not clear → the response time is pauzed
The request is (re)submitted and not yet assigned to the responsible user → the response time is started
The request is assigned to the responsbible user → the response time is stopped, the handle time is started
The request is handled and the requestor is informed → the handle time is stopped
If a request is responded to or handled on time, is simple a matter of comparing the planned response and planned handle times with the actual response or handle times
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
Automatic duplicate checks can be enabled, when a request is submitted. If 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, same building and same area. For example, if the service group receives 10 requests about the same issue, the first request is assigned to a service group responsible person. The other 9 requests are 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 check 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, the same building and the same area for example, are not taken into account.
Duplicate checks can be enabled via the ‘Module settings' → 'Requests’ tab.
With preferred suppliers, requests or work orders can automatically be assigned to the preferred supplier based on the role specified in the problem type. Preferred suppliers can be applicable in general, per building, per area or per asset. A preferred supplier is a combination of a supplier and a role. Roles can be created for specific industries/businesses, where suppliers operate in.
For example:
Supplier A - Role: IT
Supplier B - Role: Landscaping
Supplier C - Role: Furniture
If a request is submitted with the problem type role 'IT', the application checks if there are preferred suppliers:
If an asset is linked to the request → check on preferred suppliers for that asset with the role 'IT'
If an area is linked to the request → check on preferred suppliers for that area with the role 'IT'
If a building is linked to the request → check on preferred suppliers for that building with the role 'IT'
Check on preferred suppliers in general with the role 'IT'
If a preferred supplier is found, it will be automatically linked as the contractor to a possible corrective work order being created for this request.
Preferred suppliers can be enabled via the ‘Module settings' → ‘Requests: Preferred suppliers’ tab. Preferred supplier roles can be managed via the navigation menu 'Requests’ → 'Roles’
Preferred suppliers can then be managed via:
Navigation menu 'Requests' → Preferred suppliers
The ‘Preferred suppliers' tab on the building
The 'Preferred suppliers' tab on the area
The 'Preferred suppliers' tab on the asset
The system group '5. Manage problemtrees' can manage the preferred suppliers.
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 needs to be corrected or fixed.
In this case, for every request, corrective work orders can be created. Creating corrective work orders can also be depending on the problem type. For some problem types it might be not applicable to create work orders and for other problem types it might be applicable.
Corrective work orders can be enabled via the module activation. Via the 'Module settings' → ‘Requests' or the module settings ‘Maintenance' → ‘Corrective work orders’ can be determined if corrective work orders can be created in general or it is determined per 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 corrective work order module can be found: Corrective work orders module activation and information
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 the main request is submitted, it moves 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, if a new employee is hired, a request is created to prepare a new work laptop. 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 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’ → problemtree → select the desired problem type to enable and create the desired sub requests.
If Workplace Experience is also used, a request can also be created via the Workplace App. More information about Workplace Experience can be found here: Workplace Experience integration: Reservations module activation and information.
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