...

1. What is this module about

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:

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.

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 himself or herself as the responsible person to handle it.

How to create service groups

1. Waar gaat deze module over

De module Verzoeken is ontworpen om het voor gebruikers gemakkelijker te maken om verzoeken in te dienen en problemen in het gebouw en de gebieden waar ze werken te rapporteren. Als er bijvoorbeeld een noodverlichting kapot is of de toegangsdeur klemt, kan de gebruiker een verzoek indienen en kan de verantwoordelijke persoon of het team het probleem afhandelen. Via de verzoekmodule kan het verzoekproces worden bewaakt en geëvalueerd.

De volgende delen gaan dieper in op enkele kernconcepten van deze module:

1.1 Servicegroepen

Servicegroepen zijn de belangrijkste onderdelen van de module Verzoeken. Een servicegroep is een groep gebruikers of een enkele gebruiker die verantwoordelijk is voor het afhandelen van ingediende aanvragen voor een specifiek domein. Kleine bedrijven hebben misschien maar één servicegroep die alle aanvragen afhandelt, terwijl grotere bedrijven meerdere servicegroepen voor elk domein kunnen hebben.

Zo behandelt de servicegroep 'IT' alle IT-gerelateerde verzoeken, de servicegroep 'Facility' alle gebouw- en gebiedsgerelateerde verzoeken en de servicegroep 'Landscaping' alle verzoeken die te maken hebben met de omgeving buiten en rond het gebouw.

Servicegroepen worden automatisch bepaald in een verzoek op basis van het geselecteerde probleemtype (meer over probleemtypes in het volgende hoofdstuk). Het verzoek wordt automatisch toegewezen aan de hele servicegroep en een van de leden van die servicegroep kan het verzoek aan zichzelf toewijzen als de verantwoordelijke persoon om het af te handelen.

Servicegroepen maken

• Rechtstreeks vanuit de activering van de module 'Aanvragen' (Requests module activation and information)

• Via the ‘Module settingsde 'Module-instellingen' → ‘Requests’ 'Aanvragen' → 'Servicedesk service groups’ include

...

For each of the service groups, a user profile can be created via the ‘User profile management dashboard' on the administrator's startboard.

...

• servicegroepen' opnemen

...

Voor elk van de servicegroepen kan een gebruikersprofiel worden aangemaakt via het 'dashboard voor gebruikersprofielbeheer' op het startpaneel van de beheerder.

Gebruikers met de systeemgroep '4. Servicedesk medewerker' systeemgroep krijgen automatisch het servicedesk dashboard tabblad, waarmee ze de verzoeken kunnen afhandelen die aan hun servicegroepen en zichzelf zijn toegewezen. Voor meer informatie: https://spacewell.atlassian.net/wiki/spaces/KB/pages/81133665/Requests+module+activation+and+information#4.5-Navigation-menu-and-startboard-options

1.2

...

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

There are two ways to select a problem type in a request. The desired option to select a 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 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 three characters, all problem types are shown which comply. Besides the problem 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 list or use keywords to find the relevant problem type. All the problem types 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:

1. Cleaning request

2. IT request

...

1. Cleaning

   1. Toilets

   2. Kitchen

2. IT

   1. Request a new device

   2. Device stolen or missing

   3. Issues with device

      1. Laptop

      2. Phone

      3. Tablet

3. Electricity

   1. Defective wall outlet

   2. Defective lighting

4. Furniture

   1. …

   2. …

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 (Defective wall outlet or Defective lighting).

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 customer can use a problem type hierarchy of a maximum 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 that can influence the handling process. Some important settings on problem types:

• Service group: To which service group is the request automatically assigned.

• Priority: The priority determined in the problem type is automatically copied 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 solve 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 with which you’re experiencing 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 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 be 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’¹. The default problem tree is already available and can be filled with the customer's desired problem types.

...

Typen problemen

Een ander zeer belangrijk element van de requests module zijn de probleemtypes. Een probleemtype is een manier om onderscheid te maken tussen verschillende soorten verzoeken. Het probleemtype heeft ook verschillende opties die de standaard servicegroep, prioriteit, gedrag, zichtbaarheid en vooraf gedefinieerde waarden van velden in een verzoek bepalen. Zo kan bijvoorbeeld de asset categorie worden bepaald binnen het probleemtype. Als een gebruiker een verzoek aanmaakt met (bijvoorbeeld) het probleemtype 'Printer kapot', dan mag het bedrijfsmiddel dat aan het verzoek is gekoppeld alleen uit de categorie 'Printer' komen. Het heeft geen zin als de gebruiker een asset kan koppelen uit een andere categorie dan 'Printer'.

Er zijn twee manieren om een probleemtype te selecteren in een verzoek. De gewenste optie om een probleemtype te selecteren in een verzoek kan worden bepaald via de 'Module-instellingen' → 'Verzoeken' → 'Probleemtype via trefwoorden'.

• Drop-downveld (Probleemtype via trefwoorden = nee): De gebruiker selecteert eerst het probleemtype van het hoofdniveau uit een vervolgkeuzelijst. Na selectie van het eerste niveau wordt het tweede drop-downveld zichtbaar, waar de gebruiker het probleemtype van het tweede niveau uit de hiërarchie kan selecteren. Nadat het tweede niveau is geselecteerd, wordt het drop-downveld voor het derde niveau zichtbaar, waar de gebruiker het probleemtype op het derde niveau uit de hiërarchie kan selecteren. Het vervolgkeuzemenu voor het probleemtype op het tweede en/of derde niveau is alleen van toepassing als de hiërarchie hetzelfde aantal niveaus heeft. Als de hiërarchie slechts twee niveaus heeft, wordt het vervolgkeuzemenu op het derde niveau uiteraard niet zichtbaar. Workplace Management ondersteunt standaard alleen een probleemtypehiërarchie van maximaal 3 niveaus.

• Trefwoordenveld (Probleemtype via trefwoorden = Ja): De gebruiker kan het van toepassing zijnde probleemtype zoeken via een trefwoorden(tekst)veld. De gebruiker begint te typen en na het typen van ten minste drie tekens worden alle probleemtypen getoond die voldoen. Naast de naam van het probleemtype wordt ook het trefwoordenveld van het probleemtype geëvalueerd. Om deze optie te gebruiken, is het natuurlijk noodzakelijk om de trefwoorden voor elk gebruikt probleemtype te vullen met relevante zoektermen.

Een gebruiker die een verzoek aanmaakt, kan het probleemtype selecteren uit een vooraf gedefinieerde vervolgkeuzelijst of trefwoorden gebruiken om het relevante probleemtype te vinden. Alle probleemtypen kunnen worden geselecteerd in een verzoek en de hiërarchie van de probleemtypen wordt bepaald door de klant.

Voorbeeld 1: De klant wil slechts twee probleemtypen, die in een aanvraag kunnen worden geselecteerd:

1. Schoonmaakverzoek

2. IT-verzoek

Voorbeeld 2: De klant heeft een probleemtypenlijst met een hiërarchie van verschillende niveaus.De gebruiker die de aanvraag maakt, selecteert eerst het bovenste niveau en vervolgens komt het volgende niveau van probleemtypes beschikbaar om te selecteren op basis van het vorige niveau:

1. Schoonmaken

   1. Toiletten

   2. Keuken

2. IT

   1. Een nieuw apparaat aanvragen

   2. Apparaat gestolen of vermist

   3. Problemen met apparaat

      1. Laptop

      2. Telefoon

      3. Tablet

3. Elektriciteit

   1. Defect stopcontact

   2. Defecte verlichting

4. Meubilair

   1. ...

   2. ...

In dit voorbeeld (bij gebruik van de vervolgkeuzemenu's voor probleemtypen) moet de gebruiker eerst het hoofdprobleemtype selecteren (Schoonmaak, IT, Elektriciteit of Meubilair). Na het selecteren van bijvoorbeeld 'Elektriciteit' worden de subprobleemtypen beschikbaar en moet de gebruiker het volgende probleemtype selecteren (Defect stopcontact of Defecte verlichting).

Als de klant het zoekveld met trefwoorden voor probleemtypen gebruikt, kan hij zoveel hoofd- en subprobleemtypen toevoegen als hij wil.

Bij het gebruik van de vervolgkeuzemenu's voor probleemtypen kan de klant standaard een probleemtypehiërarchie van maximaal drie niveaus gebruiken.

Het probleemtype wordt niet alleen gebruikt om een voorgedefinieerde lijst van mogelijke probleemtypes te hebben waaruit de gebruiker (die het verzoek aanmaakt) kan kiezen, maar het probleemtype heeft ook veel instellingen die het afhandelingsproces kunnen beïnvloeden. Enkele belangrijke instellingen voor probleemtypen:

• Servicegroep: Aan welke servicegroep wordt het verzoek automatisch toegewezen.

• Prioriteit: De prioriteit die is bepaald in het probleemtype wordt automatisch gekopieerd naar het verzoek. De prioriteit wordt gebruikt voor de Service Level Agreements (zie volgende deel).

• Extra informatie en foto: Er kan meer informatie worden opgegeven in het probleemtype. Als dit is ingesteld, wordt dit automatisch weergegeven in het verzoek aan de gebruiker die het verzoek aanmaakt om de gebruiker te helpen het probleem op te lossen zonder het verzoek te hoeven indienen (bijv. "Hebt u geprobeerd het uit en weer aan te zetten") of om het probleem correct te beschrijven (bijv. "Zorg ervoor dat u de versie van de browser toevoegt waarmee u dit probleem ondervindt").

• Verplichte en zichtbare velden: Het probleemtype bepaalt of bepaalde velden (gebouw, gebied en goed) verplicht zijn om in te vullen, niet verplicht zijn of zelfs niet zichtbaar zijn). Dit kan helpen om de pagina om een verzoek in te dienen zo schoon en duidelijk mogelijk te maken (het is bijvoorbeeld niet nodig om de gebruiker lastig te vallen met de optie om een gebied in te stellen als ze een kapotte mobiele telefoon melden).

• Instellingen werkorders: In het probleemtype kunnen ook verschillende werkorderinstellingen worden toegepast, maar meer hierover in het hoofdstuk over correctieve werkorders.

Probleemtypes kunnen worden aangemaakt en beheerd via het navigatiemenu 'Aanvragen' → 'Probleemtypeschema's'.¹. De standaard probleemstructuur is al beschikbaar en kan worden gevuld met de gewenste probleemtypen van de klant.

Het is ook mogelijk om de standaard probleemtype-importsjabloon te gebruiken om alle gewenste probleemtypen te importeren (Zie How to use the import templates)

...

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 requestEen probleemtypenschema is een boom van probleemtypen. Technisch gezien kunnen er meerdere probleemtypeschema's worden gemaakt, die elk hun eigen probleemtypes bevatten. Standaard wordt het standaard probleemtypenschema 'probleemboom' automatisch gekoppeld aan elk nieuw verzoek.

1.3 Service Level Agreement (SLA)

Service Level Agreements (SLAsSLA's) are zijn (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.

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’):

...

meestal contractuele) afspraken met interne afdelingen of externe leveranciers over de respons- en afhandeltijden van toegewezen verzoeken op basis van de prioriteit van het verzoek. De afdeling of contractant moet de verzoeken binnen een vooraf bepaalde periode beantwoorden en afhandelen, afhankelijk van de prioriteit, om te voldoen aan de SLA.

De SLA's instellen

De SLA-reactietijden en afhandeltijden per prioriteit kunnen worden beheerd (na het inschakelen van SLA-tijden via Module-instellingen → Aanvragen: 'SLA-tijden gebruiken'):

• Rechtstreeks vanuit de activering van de module 'Aanvragen Requests module activation and information

• Via the ‘Module settingsde 'Module-instellingen' → ‘Requests’ 'Aanvragen' → 'SLA times requests workflow’ includetijden aanvragen workflow' opnemen

For each of the five default priorities (very low, lowVoor elk van de vijf standaardprioriteiten (zeer laag, laag, medium, highhoog, criticalkritisch) 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 [Seekan een SLA-waarde voor de responstijd en afhandeltijd worden ingesteld. Deze kunnen worden ingesteld in minuten, uren, dagen, weken of maanden. Voor uren of dagen kunnen de geplande tijden ook worden ingesteld in 'werk' uren of dagen. Indien gebruikt, worden de geplande antwoord- en afhandeltijden van een verzoek berekend, rekening houdend met de werkurenregeling [Zie: 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.

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 taken into consideration. If, for instance, a request must be handled in 2 work hours, work hours are defined as weekdays SLA's in het verzoek

De prioriteit van het verzoek (bepaald door het probleemtype, maar kan worden gewijzigd door de servicedeskmedewerker in het verzoek) bepaalt de geplande reactietijd en geplande afhandeltijd van het verzoek in combinatie met de verzenddatum/-tijd van het verzoek. De verzenddatum/-tijd wordt automatisch ingesteld op basis van het moment dat de aanvrager het verzoek indient.

De geplande antwoord- en afhandeldata worden automatisch bepaald voor een verzoek en, zoals vermeld, als er 'werk'-uren of -dagen worden gebruikt, wordt er ook rekening gehouden met het werkurenregime. Als een verzoek bijvoorbeeld in 2 werkuren moet worden afgehandeld, werkuren zijn gedefinieerd als werkdagen 08:00 -17:00, and a request is submitted at en een verzoek wordt om 16:00 , the request must be handled at the latest at ingediend, dan moet het verzoek de volgende dag uiterlijk om 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 (too late) or green(Still in timeworden afgehandeld. Als reguliere uren worden gebruikt in de SLA, zou dit 18:00 uur dezelfde dag zijn.

Als SLA's zijn ingeschakeld, toont het servicedesktopdashboard ook de geplande afhandelingsdatum (en een bijbehorend verkeersbord (rood (te laat) of groen (nog op tijd)):

...

Additional fields are also shown in each request itselfAanvullende velden worden ook weergegeven in elke aanvraag zelf:

...

If already set, the actual response date and handle date fields are only shown on the request page. 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 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 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.

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

...

Tasks that are deducted from the handle time

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

Any other tasks between submitting the request and handling the request are not deducted from the handle time. This also includes the time a request is awaiting the handling of corrective work orders.

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 timesAls deze velden al zijn ingesteld, worden ze alleen weergegeven op de aanvraagpagina. Deze velden worden ingesteld via de volgende acties:

• Responsdatum: Wordt automatisch ingesteld als de servicedeskmedewerker de eerste actie in het verzoek uitvoert. Dit geeft ofwel aan dat het verzoek een duplicaatverzoek is (of niet) of wijst het verzoek toe aan een servicedeskmedewerker.

• Afhandeldatum: wordt automatisch ingesteld zodra het verzoek is afgehandeld (handmatig of automatisch via het proces voor correctieve werkorders). Als het verzoek wordt afgewezen nadat het is afgehandeld en het opnieuw wordt afgehandeld, wordt de afhandelingsdatum opnieuw ingesteld op deze nieuwe afgehandelde datum.

De logboekdatum, responsdatum en afhandelingsdatum wijzigen

De geplande datum voor het antwoord en de geplande afhandelingsdatum in een verzoek kunnen niet worden gewijzigd, omdat deze gebaseerd zijn op prioriteit. De servicedeskmedewerker kan echter wel de feitelijke data (log-, antwoord- en afhandeldata) wijzigen als er een uitzondering nodig is op de datum/tijd die het systeem voor deze velden heeft ingesteld.

Het potloodpictogram achter het veld kan worden gebruikt als een van deze drie datums moet worden gewijzigd. Er kan een nieuwe datum/tijd worden ingesteld en er moet een reden worden toegevoegd. Als een van deze datum-/tijdvelden wordt gewijzigd, wordt de datum/tijd in rood weergegeven en wordt een logboek van deze wijzigingen weergegeven in een bijlage op de aanvraagpagina:

...

Taken die worden afgetrokken van de afhandeltijd

De tijd die nodig is om een verzoek af te handelen is niet altijd volledig in handen van de medewerkers die het verzoek afhandelen. Als er meer informatie nodig is van de verzoeker, mag de tijd die de verzoeker nodig heeft om deze informatie te verstrekken en het verzoek opnieuw in te dienen niet worden meegenomen in de SLA's. Daarom wordt de tijd dat het verzoek in deze status ('Actie verzoeker') blijft, opgeteld bij de geplande afhandelingsdatum zodra de verzoeker het verzoek opnieuw indient. Daarom wordt de tijd dat het verzoek in deze status blijft ("Actie verzoeker") toegevoegd aan de geplande afhandelingsdatum zodra de verzoeker het verzoek opnieuw indient. Dus als de indiener 8 (werk)uren nodig had om het verzoek opnieuw in te dienen, wordt er 8 (werk)uren toegevoegd aan de geplande afhandelingsdatum zodra het verzoek opnieuw is ingediend.

Alle andere taken tussen het indienen van het verzoek en het afhandelen van het verzoek worden niet afgetrokken van de afhandeltijd. Dit omvat ook de tijd dat een verzoek wacht op de afhandeling van correctieve werkorders.

SLA-dashboards

Nadat het verzoek is afgehandeld, kunnen de reactietijd en afhandeltijd worden geëvalueerd via verschillende standaardrapporten op het dashboard Verzoeken op basis van de SLA-tijden:

...

1.4

...

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.

Duplicate checks 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, building, and the same area, for example, are not taken into account.

Duplicate checks can be enabled via the ‘Module settings' → 'Requests’ tab:

...

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 continue handling the request as usual.

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:

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

• Multiple corrective work orders can be created from a single request, if, for instance, multiple contractors are needed to fix a problem.

• Registering costs. Adding costs (planned vs. actual costs) 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 not.

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.

...

Duplicaatcontrole

Automatische duplicaatcontroles kunnen worden ingeschakeld wanneer een verzoek wordt ingediend. Als er bijvoorbeeld een probleem optreedt in de centrale hal, waar alle medewerkers langskomen, kan het zijn dat meerdere gebruikers een verzoek aanmaken met hetzelfde type probleem, gebouw en gebied. Als de servicegroep 10 verzoeken ontvangt over hetzelfde probleem, wordt het eerste verzoek toegewezen aan een verantwoordelijke van de servicegroep. De andere negen verzoeken kunnen worden gemarkeerd als een duplicaat van het eerste verzoek. De servicegroepverantwoordelijke hoeft nu alleen het eerste verzoek op te volgen en af te handelen in plaats van alle 10 verzoeken afzonderlijk af te handelen. Nadat het eerste verzoek is afgehandeld, volgen de andere duplicaten automatisch en worden ze automatisch afgehandeld.

Duplicaatcontroles kunnen worden ingeschakeld voor:

• Hetzelfde probleemtype

• Hetzelfde gebouw

• Hetzelfde gebied

• Dezelfde activa

De duplicaatcontrole wordt alleen uitgevoerd voor openstaande verzoeken. Reeds afgesloten verzoeken met bijvoorbeeld hetzelfde probleemtype, gebouw en hetzelfde gebied worden niet in aanmerking genomen.

Duplicaatcontroles kunnen worden ingeschakeld via het tabblad 'Module-instellingen' → 'Aanvragen':

...

Als een verzoek wordt ingediend, zal het systeem automatisch bepalen of openstaande verzoeken mogelijk duplicaten zijn (gebaseerd op de instellingen). Als dit het geval is, is de eerste taak voor de servicegroepmedewerker om te bepalen of het verzoek inderdaad een duplicaat is (en zo ja, het te koppelen aan het oorspronkelijke verzoek) of om aan te geven dat het verzoek geen duplicaat is en het verzoek gewoon verder af te handelen.

1.5 Voorkeursleveranciers

Via het gebruik van voorkeursleveranciers kunnen aanvragen (of werkorders) automatisch worden toegewezen aan een voorkeursleverancier op basis van de rol die is opgegeven in het probleemtype. Zie voor meer informatie over voorkeursleveranciers: Voorkeursleveranciers.

1.6 Correctieve werkorders

Correctieve werkorders kunnen worden gebruikt als uitbreiding voor verzoeken. Een correctieve werkorder wordt altijd aangemaakt als gevolg van een verzoek. Correctieve werkorders kunnen niet worden aangemaakt zonder verzoek. Zoals het woord 'correctief' al aangeeft, moet er iets gecorrigeerd of hersteld worden. Er zijn meerdere redenen om correctieve werkorders te gebruiken:

• Correctieve werkorders kunnen in de tijd worden gepland (via de begin/einddatumvelden op een werkorder, die een verzoek niet heeft, of via het planbord).

• Er kunnen meerdere correctieve werkorders worden aangemaakt vanuit één aanvraag, als er bijvoorbeeld meerdere aannemers nodig zijn om een probleem op te lossen.

• Kosten registreren. Het toevoegen van kosten (geplande vs. werkelijke kosten) in een aanvraag is onmogelijk. Dit is mogelijk in een werkorder door generieke kostenposten (bijv. kosten voor reparaties), vooraf bepaalde catalogusitems (bijv. 10 schroeven) en/of vooraf bepaalde inventarisitems (bijv. een motoronderdeel) toe te voegen.

Het maken van correctieve werkorders kan ook afhankelijk zijn van het probleemtype. Voor sommige probleemtypen kan het van toepassing zijn om werkorders te maken en voor andere probleemtypen misschien niet.

Correctieve werkorders kunnen worden ingeschakeld via de moduleactivering. Via de 'Module-instellingen' → 'Aanvragen' of de module-instellingen 'Onderhoud' → 'Correctieve werkorders' kan worden bepaald of correctieve werkorders per aanvraag kunnen worden aangemaakt of dat dit afhankelijk is van het gekoppelde probleemtype. Als het aanmaken van correctieve werkorders per probleemtype wordt bepaald, ga dan naar het navigatiemenu 'Aanvragen' → 'Probleemtypeschema's' en stel deze instelling in voor alle relevante probleemtypen.

Meer informatie over de module correctieve werkorders is te vinden: Corrective work orders module activation and information

...

1.7

...

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 building, area, and/or asset can or need to be selected, depending on the problem type settings.

Duplicate check
After the request is submitted, the service group (determined 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 whether it is a duplicate request 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 can now pick up the request by assigning 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 in detail and the service group has additional questions, the request can be sent back to the requestor. The requestor will then get a task to provide the service group with more information, before re-submitting the request.

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 order' status and can be handled further once the corrective work orders are handled.

If there is an action required from the requestor, then the request can be sent back to the requestor during the handling of the request.

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.

Enabling the Knowledge base can be done via the ‘Module settings' → ‘Requests: Knowledge base’ → 'Use Knowledge base’ setting.

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.

With sub requests, the main request is automatically broken down into one or more sub requests. After submitting the main request, 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 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'

• Hand out the laptop on the first day → service group 'Office Manager'

...

Workflow aanvraagproces

Het volgende deel beschrijft de workflow voor een verzoek vanuit een high-over oogpunt. Raadpleeg de gebruikershandleiding voor een gedetailleerde beschrijving Aanvragenmodule voor (eind)gebruikers.

Het verzoek maken en indienen
Een gebruiker kan een nieuw verzoek aanmaken en het van toepassing zijnde probleemtype selecteren in het vervolgkeuzemenu of het trefwoordenveld gebruiken (afhankelijk van de clientinstelling) om het van toepassing zijnde probleemtype te vinden. Met het onderwerp- en beschrijvingsveld kan de gebruiker een gedetailleerde beschrijving geven van het probleem dat de gebruiker heeft. Het gebouw, gebied en/of onderdeel kan of moet worden geselecteerd, afhankelijk van de instellingen van het probleemtype.

Dubbele controle
Nadat het verzoek is ingediend, wordt de servicegroep (bepaald door het probleemtype) automatisch toegewezen aan het verzoek. Als ten minste één duplicaatcontrole is ingeschakeld, kan de gebruiker van de betreffende servicegroep controleren of het een duplicaatverzoek is en dit dienovereenkomstig registreren. Als het verzoek een duplicaat is, gaat het verzoek naar de status 'Wachten op duplicaatverzoek' en gaat het verder zodra het oorspronkelijke verzoek is afgehandeld.

Toewijzing van servicegroeplid
Het verzoek wordt automatisch toegewezen aan de betreffende servicegroep en elk lid kan het verzoek nu oppakken door het aan zichzelf toe te wijzen. Voordat het verzoek wordt toegewezen aan een servicegroeplid, kunnen de details van het verzoek worden gewijzigd door de servicegroep om de verzoekinformatie te verduidelijken of te corrigeren.

Meer informatie nodig
Als het verzoek niet in detail is beschreven en de servicegroep aanvullende vragen heeft, kan het verzoek worden teruggestuurd naar de indiener. De indiener krijgt dan een taak om de servicegroep van meer informatie te voorzien, voordat hij het verzoek opnieuw indient.

Intrekken en opnieuw toewijzen
Zodra een verzoek is toegewezen aan een servicegroepslid, kan het worden ingetrokken en opnieuw worden toegewezen aan een ander servicegroepslid.

Het verzoek afhandelen
Het verzoek kan worden afgehandeld door het servicegroepslid aan wie het verzoek is toegewezen of via correctieve werkorders (indien van toepassing en de module is geactiveerd). Als er correctieve werkorders worden aangemaakt, krijgt het verzoek de status 'Wacht op werkorder' en kan het verder worden afgehandeld zodra de correctieve werkorders zijn afgehandeld.

Als er een actie vereist is van de verzoeker, dan kan het verzoek teruggestuurd worden naar de verzoeker tijdens de afhandeling van het verzoek.

Beoordelingsverzoek
De aanvrager kan de aanvraag die door de aannemer is afgehandeld bekijken en de aangeboden oplossing of oplossing goedkeuren of afwijzen.

...

1.8 Andere relevante opties

1.8.1 Kennisbank

De Knowledge base is een functionaliteit om relevante informatie te documenteren en te delen. De kennisbank kan worden gebruikt als een op zichzelf staande functionaliteit of met verzoeken. Kennisbankartikelen kunnen worden gemaakt om informatie te verstrekken over specifieke onderwerpen (in het algemeen of gerelateerd aan een specifiek probleemtype). Deze artikelen kunnen gebruikers dan helpen met bepaalde (veelgestelde) vragen of mogelijke oplossingen voor problemen zonder dat ze contact hoeven op te nemen met de servicedesk.

De Knowledge base inschakelen kan via de instelling 'Module-instellingen' → 'Aanvragen: Kennisbank' → 'Kennisbank gebruiken'.

Voor meer gedetailleerde informatie over de kennisbank zie Kennisbank.

1.8.2 Subverzoeken

Subverzoeken kunnen worden gebruikt als een probleem/verzoek bestaat uit meerdere vooraf gedefinieerde acties, die altijd van toepassing zijn op een verzoek dat gerelateerd is aan dit probleem(type). Het gebruik van subverzoeken kan worden bepaald per probleemtype en elk van de subverzoeken kan een eigen servicegroep hebben die het subverzoek moet afhandelen.

Met subverzoeken wordt het hoofdverzoek automatisch opgesplitst in een of meer subverzoeken. Nadat het hoofdverzoek is ingediend, krijgt het de status 'Wachten op subverzoeken'. De subverzoeken worden allemaal toegewezen aan de betreffende servicegroep. Als alle subverzoeken zijn afgehandeld, wordt het hoofdverzoek automatisch gesloten.

Er wordt bijvoorbeeld een verzoek gemaakt om een nieuwe werklaptop klaar te maken wanneer een nieuwe medewerker wordt aangenomen. Het probleemtype 'Laptop nieuwe medewerker' bestaat uit verschillende subverzoeken:

• Een nieuwe laptop kopen → servicegroep 'Inkoop

• Maak een nieuwe mailbox voor de werknemer → servicegroep 'IT'.

• Bereid de laptop voor met alle relevante software → servicegroep 'IT'.

• Deel de laptop uit op de eerste dag → servicegroep 'Office Manager'.

Subverzoeken kunnen per probleemtype worden ingeschakeld via het navigatiemenu 'Verzoeken' → 'Probleemtypeschema's' → probleemboom → selecteer het gewenste probleemtype om in te schakelen en de gewenste subverzoeken te maken.

...

1.8.3

...

Eenvoudige ticketuitgifte via

...

de Workplace App

If Als Workplace Experience is also used, a request can be created via the Workplace App. More information about Workplace Experience can be found hereook wordt gebruikt, kan een verzoek worden aangemaakt via de Workplace App. Meer informatie over Workplace Experience vindt u hier: Workplace Experience integration: Reservations module activation and information.

2.

...

Automatische e-mails die in de 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 enable the default workflow emails, see Workflow emails.

For the request module, 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

3. Additional information on this module

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

...

worden verzonden

Workflows kunnen automatisch e-mails versturen nadat een bepaalde taak is uitgevoerd of een workflow een bepaalde tijd in een status heeft gestaan. De standaard e-mails moeten per workflow worden geactiveerd. Zie voor meer informatie over het inschakelen van de standaard workflow e-mails Workflow e-mails.

Voor de aanvraagmodule zijn de volgende standaard workflow e-mails beschikbaar:

3. Aanvullende informatie over deze module

Meer informatie over de module Verzoeken is te vinden in de volgende gerelateerde artikelen:

• Voor een (eind)gebruikershandleiding, zie: Aanvragenmodule voor (eind)gebruikers

• Voor meer gedetailleerde implementatie-informatie (inclusief hoe je de module inschakelt, welke systeemgroepen erbij betrokken zijn, gegevensimport en meer informatie over het startbord en de opties in het navigatiemenu) zie: Requests module activation and information