1. Requests in general

‪A request system is a tool used to report and address issues or maintenance needs within a facility or office building. The person creating a request provides detailed and essential information about the issue so that the responsible person or team can handle the issue accordingly and within the specified period. The request process gives transparency to the requestor and the responsible for the progress of the request.

Overall, a request system in facility management streamlines the process of reporting and resolving issues, leading to improved efficiency, better communication, and enhanced facility maintenance. It helps ensure the facility remains safe, functional, and comfortable for its occupants.

2. What is this module about

For more information on the content of this module, including detailed descriptions of some of the core components, see: Requests module in the 'Application Managers' section.

3. Why use this module

This module enables employees/users to easily submit work-related requests or report problems. The system automatically assigns these requests to the appropriate team to be handled, eliminating users needing to find the right person or team themselves. Additionally, the module allows requests to be divided into one or more corrective work orders, which can automatically be sent to preferred suppliers. Users can track the progress of their requests through reports and dashboards, evaluating if requests have been handled within the SLA (Service Level Agreement) times and work orders completed by suppliers.

3.1 Choices to be made within the module

The most relevant choices that can be made when using this module are the following:

1. Which service groups are used by the customer? All service group members will be users of the Workplace Management application and will get tasks to handle requests.

2. Which problem types are applicable to the customer? Does the customer want a simple list with only a couple of problem types to choose from or a complete hierarchy of problem types with multiple levels?

3. Does the customer want to use corrective work orders? Requests can be handled directly by the responsible service group (member) or via corrective work orders created from the request. Corrective work orders can be assigned to internal users or external suppliers to register relevant costs and handle the problem. If the customer wants to use corrective work orders:

   1. Use corrective work orders in general: corrective work orders can be created in all requests (independent from problem type)

   2. Use corrective work orders based on the problem type: Determine per problem type if corrective work orders can be created.

4. Are SLAs used to monitor the response and handle times of requests? If so, register the desired response and handle times per priority.

4. How to activate this module

As for every new module, use the ‘Module activation’ option on the administrator startboard (only available for level 2 and 3 admins). For more general information about these 'Module activation' options, see Module activation

4.1 Prerequisites before enabling this module

The requests module does not require any other modules to be activated before. However, if you want to be able to link a specific building, area, and/or asset to a request, these modules will need to be activated first. Otherwise, it is only possible to register the specific building, area, and/or asset in a description field. Insights about the number of requests for a specific building, area, or asset will then not be possible.

For more information about these modules see:

• Masterdata: Buildings and areas module activation and information

• Masterdata: Assets module activation and information

4.2 Module activation

For this specific module activation, multiple settings and options apply:

Settings to be determined

• Use SLA times: Enable this option to register the response and handle times desired per priority and be able to report on the response and handle times for all requests.

• Hide option to send request to contractor: Hide the option to forward the request to a contractor instead of working with corrective work orders. Forwarding requests to a contractor can be used if the customer does not use corrective work orders for this purpose.

• Auto close request after workdays: After a request is handled, the requestor can check if the request is handled accordingly. If the requestor does not review the request, the request is automatically closed after X days.

• Set update done by requestor flag: Enable this option if the requests need to be flagged as soon as the requestor adds more information to the request. The service group that handles the request becomes aware of the additional information and can then mark the request to confirm that the requestor's update is seen.

• Use preferred suppliers: Enable this option to register preferred suppliers in general, per building, per area, and/or per asset, and let the application automatically assign the preferred supplier to the corrective work orders.

• Use Knowledge base: Enable this option to use a knowledge base in requests, where users can add knowledge base items to help other users handle requests faster and more efficiently.

• Check duplicate problem type: Enable this option to let the application check for duplicate (open) requests with the same problem type.

• Check duplicate building: Enable this option to let the application check for duplicate (open) requests with the same building.

• Check duplicate area: Enable this option to let the application check for duplicate (open) requests with the same area.

• Check duplicate asset: Enable this option to let the application check for duplicate (open) requests with the same asset.

Service groups:

Create the desired service groups directly from the module activations ‘Servicedesk service groups’ include. At least one service group needs to be created to be able to start the module activation.

4.2.1 Workflow emails

The emails that are automatically sent via the workflow (e.g., the confirmation email to the requestor after the new request is submitted) are also generated and shown in the include on the module activation after the module activation is started. If the customer does not want to use one or more workflow emails, the emails can directly be deleted from the overview. For more information on workflow emails: Standard Workflow emails

For a detailed description of the emails sent via the workflow, see: Requests module in the 'Application Managers' section.

4.3 Data imports

When activating this module, some data imports become available, which can be used to quickly import relevant data into the system (as opposed to manually entering this data, which is also possible).

Relevant data imports become available in the module activation after the activation has been started. Default data imports can also be found on the admin startboard (only for level 2 and level 3 administrators).

For more information on data imports in general, see: Data imports

If the requests module is activated, the following default import connectors become available:

4.4 System groups

When a module is activated, system groups become available that can be assigned to user profiles. These system groups will give users access to (a subset of) navigation menu options, startboard tabs, and tasks in the relevant workflow(s).

For more general information on user profiles, system groups, users, and the user profile dashboard, see: User management

For the Requests module, the following system groups become available:

Via the 'User profile management' option on the administrator startboard, these system groups can be assigned to existing user profiles or add them to newly created user profiles.

4.4.1 Relevant system groups from other modules:

For some modules, other (master data) modules might be of importance, in order to be able to fully use this module.
For Requests, the Master data modules ‘Buildings and areas’ and ‘Assets' are often relevant therefore the following system groups could also need to be assigned to users (If not already done in the past), to be able to create and edit the relevant master data objects.

When generating the user profiles, it is advised to include these groups or have dedicated profiles (and users) for these modules.

4.5 Navigation menu and startboard options

When a module is activated, the relevant navigation menu options become available to users with the correct authorizations (based on the system groups). Next, a module-specific key user startboard tab becomes available for that particular module and is visible depending on the user's authorizations. This tab gives users insights and day-to-day work overviews relevant to the specific module.

For more general information on the navigation menu and startboard, see: https://spacewell.atlassian.net/wiki/spaces/KB/pages/441712705/Authorizing+users#2.2-Navigation-menu-and-Startboard

For the Requests module, the following navigation menu options become available:

For the Requests module, the following startboard tab becomes available:

This tab is available for the following system groups:

• Servicedesk employee

• Management dashboards requests

This startboard tab has some buttons similar to the navigation menu options with the same names. Next to that, this tab has the following includes (most are only visible if they contain data):

• Requests for my team, not yet assigned: This overview shows created tickets assigned to your team (service group) which have not yet been assigned to a team member to handle the request.

• Requests assigned to me: This overview shows requests assigned to me to handle.

5. Additional reports

Additional reports can be available for some modules via the ‘Reports’ navigation menu option.
For the requests module, there are reports available via:

• Navigation menu reports: A long list of reports related to requests available for all service groups.

• Management dashboard: A management dashboard for requests is available in the ‘Requests’ navigation menu for the ‘Management dashboards requests’ system group, with overviews and graphs related to requests (New vs handled, SLA response times, etc.):

6. Additional settings and options after enabling

For some modules, additional settings can be configured after the initial module activation via the 'Module settings' option on the administrator startboard. A module is always activated with the most used settings pre-defined. After the module is activated, the module may have more advanced settings available, which can be managed via the Module settings as well.

To navigate to all Requests settings, go to Module settings → tab Requests. Hover over the available settings to get more information:

7. Additional information

No additional information currently.

8. User manual

For the user manual with a more step-by-step explanation of the process itself, see: Requests module for (end)users

9. Q&A

Waiting for questions to be answered.