Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

Info

Is It's 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 sent 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.


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:

...

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 resubmittedre-submitted.

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:

...

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.

Info

The enabled settings are evaluated together to determine possible duplicates for a new request. E.g. if duplicate check is enabled for problemtype problem type and property, only open requests with both the same problemtype problem type and the same property are used as potential duplicates.

...

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

...

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.

...

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'

...

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 module, the following default workflow emails are available:

Email content

When is it sendsent

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’ posted’ on the request

An email requesting to perform the work requested in the request

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

The contractor to which the request is assigned

An email requesting asking for more information (the email is a request call to go to the request and provide the requested extra information in the request and resubmit re-submit the request)

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

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

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

Once the request is put set to handled

The requestor of the request , if the requestor has indicated to ‘keep me noticed’ 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 canceledcancelled

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’ posted’ on the request

3. Additional information on this module

...