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 de 'Module-instellingen' → 'Aanvragen' → 'Servicedesk servicegroepen' opnemen

Open

Module-instellingen 'Verzoeken

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: Requests module activation and information | 4.5 Navigation menu and startboard options

1.2 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)

Open

Voorbeeld van een probleemtype met alle instellingen

1. Een 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 (SLA's) zijn (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 de 'Module-instellingen' → 'Aanvragen' → 'SLA tijden aanvragen workflow' opnemen

Voor elk van de vijf standaardprioriteiten (zeer laag, laag, medium, hoog, kritisch) kan 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].

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, en een verzoek wordt om 16:00 ingediend, dan moet het verzoek de volgende dag uiterlijk om 09:00 worden 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)):

Aanvullende velden worden ook weergegeven in elke aanvraag zelf:

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

Als Workplace Experience ook 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) 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