...
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 to anything other than a 'Printer'.
There are two ways to select a problem type in a request. The desired option to select a probelm 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 2 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 3 three characters, all problem types are shown which comply. Besides the problem types 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 lists list or uses use 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 of various levels.The user creating the request first selects the top level, and then the next level of problem types become becomes available to select based on the previous level:
...
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 a maximum 3 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 which that 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 solve the problem without needing to submit the request (e.g. ‘have , ‘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’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 applybe 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’1. The default problem tree is already available and can be filled with the customer's desired 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 regarding the response and handle 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
...
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 5 five 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 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].
...
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 taking 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 (to too late) or green(Still in time)):
...
Additional fields are also shown in each request itself:
...
The If already set, the actual response date and handle date fields are only shown on the request page 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 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 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 However, the service desk employee can change the actual dates (log date, response date , and handle date) however, can be changed by the service desk employee, dates) if an exception to the date/time the system has set these fields is needed.
| Info |
|---|
Is possible that, for instance, the problem in the request was already handled before the request in the system itself was set to handled (thus a manual correction on the handle date is needed to represent the actual handle date), or the request was not submitted via workplace management by the requestor, but create by the service desk employee based on an email send a few hours before, thus officially requiring a log date based on the time the email from the requestor was received if SLAs are to be followed strictly |
If any of these three dates must be changed, the The pencil icon behind the field can be used for thisif 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 is are altered, the date/time will be displayed in red, and a log of these changes is will be shown in an include on the request page:
...
The time it takes to handle a request is not always fully in control of the employees handling the requestit. 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 taken into account 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 the request is resubmitted by the requestor. 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 resubmitted.
...
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, same building, and same 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 9 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 check checks can be enabled for:
The same problem type
The same building
The same area
The same asset
...
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 needs to 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 board).
Multiple corrective work order orders can be created from a single request, if, for instance, multiple contractors are needed to fix a problem.
Registering Costs. It is not possible to add Adding cost (planned vs. actual cost) in a request is impossible. This is possible in a work order.
Creating corrective work orders can also be depending on the problem type. For some problem types, it might not 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’, 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
...
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 selects select the applicable problem type from the drop-down field or uses use the keywords field (depends 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 probem problem type settings.
Duplicate check
After the request is submitted, the service group (determined in 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 if whether it is a duplicate request or not 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 of this service group can now pick up the request by assigning the request 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 very detailed in detail and the service group has additional questions, the request can be forwarded back to the requestor. The requestor will then get a task to give the service group more information and can re-submit the request again.
Retract and reassign
Once a request is assgned 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 to or via corrective work orders (if applicable and the module is activated). If corrective work orders are created, the request will go to 'Awaiting work orders' status and can be handled further , once the corrective work orders are handled.
...
Review request
The requestor has the possibility to can review the request handled by the contractor and can either approve or reject the offered solution or fix.
...
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 . These articles could then help users with certain (often 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.
More For more detailed information about the knowledge base see Knowledge base.
...
With sub requests, the main request is automatically broken down into one or more sub requests. After submitting 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 if a new employee is hired. The problem type 'New employee laptop' consists of several sub requests:
...
Sub requests can be enabled per problem type via the navigation menu ‘Requests' → 'Problem type schemes’ → problemtree 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 also be created via the Workplace App. More information about Workplace Experience can be found here: Workplace Experience integration: Reservations module activation and information.
...