Vijf essentiële ticketing automatiseringen om mee te beginnen

NinjaOne ticketing automations

Automatisering van tickets Zoals alle Ninja-producten biedt het IT Ticketing System van Ninja gebruikers veel mogelijkheden om tijd te besparen door middel van automatisering. Het opzetten van automatiseringen tegen een tabula rasa kan een ontmoedigende taak zijn als u voor het eerst begint met ticketing.

We hebben deze blogpost geschreven om nieuwe gebruikers op weg te helpen met algemene, nuttige automatiseringen die u vanaf de eerste dag kunt gebruiken. Deze handleiding geeft stap-voor-stap uitleg en schermafbeeldingen om te laten zien hoe u deze automatiseringen instelt. Bovendien zal deze post deel uitmaken van een uitgebreidere reeks van ticketing automatiseringsvoorbeelden die de complexiteit zullen vergroten.

Laten we zonder verder oponthoud eens duiken in vijf veelgebruikte automatiseringen waarmee ticketing een fluitje van een cent wordt voor uw bedrijf:

1) Tickets automatiseren en organiseren in Ticketing Boards op basis van verschillende criteria

In dit voorbeeld bekijken we hoe we ticketingautomatisering kunnen instellen om tickets te organiseren en te laten escaleren naar twee verschillende ticketingboards: T2-serviceverzoeken en T3-serviceverzoeken.

Gebruikscasus: Routeer een supportticket dat meer diepgaande kennis vereist automatisch naar het T2 ticket board. Als voor dat ticket een materiedeskundige nodig is, kan dit ticket worden geëscaleerd naar het T3 ticket board. Tot slot kunnen tickets automatisch worden toegewezen aan het T3 ticket board als ze afkomstig zijn van een bepaald support e-mailadres (bijv. [email protected]).

Wat is er nodig?

  • Maak twee ticketboards, één voor Tier 2-technici en één voor Tier 3-technici
  • Een op gebeurtenissen gebaseerde automatisering maken om relevante tags (T2 of T3) te detecteren en meldingen naar het juiste e-mailadres te sturen
  • Maak een specifiek e-mailadres aan dat alle T3-level aanvragen ontvangt

Hoe dit op te zetten – Escalatie naar T2 bestuur:

Eerst moet u de ticketverkoopborden instellen voor T2- en T3-tickets. Elk bord toont alleen tickets waar een specifiek technicusniveau aan moet werken; het T2-bord toont bijvoorbeeld alleen tickets die technici van niveau 2 moeten behandelen. U kunt het ticketbord instellen onder Configuraties  Integraties  Ticketing  Borden: Zodra u naar het gedeelte boards van ticketing gaat, moet u T2- en T3-borden maken met de voorwaarden die het beste bij uw bedrijf passen. In de afbeelding hieronder hebben we het T2-bord opgesteld met condities waarvan we dachten dat ze pasten bij een standaard T2-ondersteuning: Vervolgens koppelen we dit bord aan een automatisering, te vinden onder Configuraties ➡️ Integraties ➡️ Ticketing ➡️ Automatisering ➡️ Aanmaken. Deze automatisering is een event-gebaseerde automatisering die alle tickets die ondersteuning op T2-niveau vereisen naar het T2 ticket board routeert als ze voldoen aan alle voorwaarden die we hebben ingesteld:

Als aan deze voorwaarden is voldaan, selecteren we de acties die we willen ondernemen wanneer een ticket wordt doorgestuurd naar het T2 ticket board. De T2-tag zorgt ervoor dat het ticket naar het T2-bord wordt geleid; we willen er ook voor zorgen dat het ticket niet langer op het T1-bord ligt, dus verwijderen we de T1-tag. Tot slot willen we ervoor zorgen dat alle T2-technici op de hoogte zijn van het nieuwe ticket, dus brengen we hen op de hoogte door een e-mail te sturen naar hun gedeelde mailbox.

Hoe dit in te stellen – Escalatie naar T3 Board vanaf een bepaald e-mailadres:

De eerste stap is het instellen van een e-mail in het Ticketing-gedeelte van Ninja’s platform. Voor dit voorbeeld hebben we deze e-mail gemaakt met de volgende instellingen. Een manier om dit in te stellen is om een e-mail die naar dit adres wordt gestuurd automatisch te labelen met T3:

De volgende stap is het instellen van het T3-bord, vergelijkbaar met het instellen van het T2-bord. Het verschil hier is dat we zoeken naar tickets die de “T3” tag bevatten: Vervolgens moeten de automatiseringen worden ingesteld voor de T3 tickets met de voorwaarden die u wilt nemen, op dezelfde manier als de T2 ticket automatiseringen. In deze omstandigheden zoeken we echter naar tickets die de “T3” tag bevatten: Tot slot moet u de acties configureren die u wilt ondernemen op basis van deze automatisering. Tot slot nemen we dezelfde acties voor de T2-escalatieautomatisering: verwijder de T2-tag en stel het T3-team op de hoogte via e-mail.

2) Automatisering van ticketing met betrekking tot statuswijzigingen van tickets

In dit voorbeeld bekijken we hoe we automatiseringen kunnen instellen om de status van een ticket aan te passen op basis van bepaalde voorwaarden en om een e-mail naar de aanvrager te sturen als er een bepaalde periode verstrijkt zonder enige actie.

Gebruikscasus: Automatiseringen voor het wijzigen van ticketstatussen helpen technici om tickets aan te passen aan de status die ze hebben in de “ticketlevenscyclus” Als statussen niet handmatig worden gewijzigd, zorgen deze automatiseringen ervoor dat tickets worden verplaatst naar andere boards, uit de huidige wachtrij worden verwijderd of zelf worden gesloten als er geen verdere acties nodig zijn, zodat uw technici zich kunnen concentreren op de huidige taken. In dit voorbeeld veranderen we een ticket automatisch van open naar wachtend als de aanvrager minstens een uur niet heeft gereageerd op een technicus.

Wat er nodig is:

  • Tijdgebaseerde automatiseringen maken om te detecteren hoeveel tijd er is verstreken sinds een aanvrager op een ticket heeft gereageerd
  • Bepaling van specifieke ticket SLA’s om de tijdgebaseerde automatiseringen uit te bouwen (bijvoorbeeld: matig heeft een SLA van vier uur, dringend heeft een SLA van een uur)
  • Interne betekenissen van specifieke ticketstatussen bepalen

Hoe u dit instelt: De eerste stap hier is het instellen van het juiste automatiseringstype, wat in dit geval een tijdsgebaseerde automatisering zal zijn. Dit kan worden gedaan door te gaan naar Configuraties ➡️  Integraties ➡️  Ticketing ➡️  Automatisering ➡️  Aanmaken ➡️  Tijdgebaseerd:

Vervolgens willen we de status van een ticket aanpassen. In dit voorbeeld willen we dat alleen “Open” tickets automatisch worden bijgewerkt zodra een technicus heeft gereageerd, maar de aanvrager minstens een uur niet heeft gereageerd:

Zodra aan deze voorwaarde is voldaan, willen we dat het “Open” ticket op “Wachten” wordt gezet Dit wordt bereikt in het gedeelte Acties:

We hopen dat de aanvrager uiteindelijk zal reageren en dat we het ticket kunnen afhandelen. Zo niet, dan kunnen we het ticket automatisch sluiten.

Het tweede deel van deze automatisering kan tickets afhandelen die in deze categorie vallen. Als u dezelfde stappen volgt als hiervoor, begint de volgende automatisering als volgt:

Vervolgens willen we de actie instellen om alle tickets met de status “Wachtend” die in 120 uur niet zijn gewijzigd, bij te werken naar Opgelost. Een bijkomend voordeel is ook dat de aanvrager van het ticket een e-mail ontvangt waarin staat dat het ticket bij ons is “Opgelost”:

Er is nog een laatste stap nodig om de onderwerpregel in te stellen die de ticket-ID en de hoofdtekst bevat. Klik in het tekstveld naast de toegevoegde actie “E-mail” en voeg de onderwerpregel, de plaatshouder en de hoofdtekst in die voor u het meest relevant zijn:

3) Routeer specifieke tickets automatisch naar een technicus

In dit voorbeeld laten we zien hoe we automatiseringen kunnen instellen om tickets over specifieke problemen, taken, producten, enz. af te leveren aan een bepaalde technicus met een specialiteit op dat gebied.

Gebruikscasus: Dit soort automatiseringen kan helpen bij het verspreiden en organiseren van tickets naar technici die materiedeskundig zijn of die een specialiteit hebben met vragen die gesteld kunnen worden. In plaats van dat de technici meer algemene boards moeten doorzoeken die zijn onderverdeeld op basis van de complexiteit van het serviceniveau, kunnen ze alle tickets die ze nodig hebben direct aan hun boards toewijzen. Zo kunnen ze hun tijd efficiënter besteden aan het behandelen van het verzoek in plaats van aan het zoeken naar relevante tickets.

Wat er nodig is:

  • Maak een automatisering van een antwoordsjabloon die de volgende acties uitvoert: voeg een specifieke tag toe, wijs deze toe aan een specifieke technicus en voorzie die technicus van een bericht
  • Specifieke tags aanmaken die gerelateerd zijn aan veelvoorkomende verzoeken die specifieke technici kunnen oplossen

Hoe u dit instelt: Als andere onderdelen al zijn ingesteld (zoals accounts voor technici en ingestiemethoden die zijn ingesteld in de vorige automatisering die we hebben besproken), zijn er nog twee belangrijke onderdelen over om deze automatisering te maken. De eerste stap is het aanmaken van de benodigde sjabloon, die u kunt vinden door te gaan naar Configuraties ➡️  Integraties ➡️  Ticketing ➡️  Automatisering ➡️ Aanmaken ➡️  Antwoordsjabloon:

Vervolgens moeten we het antwoordsjabloon instellen met de acties die nodig zijn om tickets die te maken hebben met het herstellen van back-ups te routeren naar een specifieke technicus (ikzelf in het onderstaande voorbeeld):

Tot slot kunt u het tekstveld naast “Opmerking toevoegen” klikken Zodra u op dat veld klikt, krijgt u drie opties: Vul de hoofdtekst van de opmerking in, bepaal of de opmerking privé of openbaar is en voeg een plaatshouder in. Voor dit voorbeeld hebben we echter de “${ticket.tags}” placeholder ingevoegd. Er zijn verschillende opties waaruit u kunt kiezen die misschien relevanter zijn voor uw organisatie:

4) Maak een waarschuwing aan voor “Out of SLA” dringende tickets

In dit voorbeeld bekijken we hoe we waarschuwingen kunnen maken voor urgente tickets die buiten hun SLA-tijden vallen. We zullen beginnen met automatiseringen rond het opnemen van urgente tickets en eindigen met een automatisering die de nodige partijen waarschuwt.

Gebruikscasus: De zichtbaarheid van dringende tickets is essentieel om ervoor te zorgen dat problemen snel worden aangepakt en de bedrijfsimpact tot een minimum wordt beperkt. Automatiseringen zijn essentieel om ervoor te zorgen dat elk urgent ticket dat binnenkomt automatisch wordt doorgestuurd naar de technici die deze snel en effectief kunnen afhandelen. Een fout bij een willekeurige stap in het proces kan aanzienlijke problemen veroorzaken, dus het beperken van menselijke fouten is in deze situaties van het grootste belang.

Wat er nodig is:

  • E-mail- en Slack-integraties opzetten om meldingen naar de benodigde partijen te sturen als een ticket buiten de SLA valt
  • Maak specifieke tags aan voor een ticket dat als “dringend” kan worden beschouwd
  • Maak een automatisering op basis van gebeurtenissen die de onderwerpregel van een e-mail controleert op “urgent” en een tag “urgent” toevoegt
  • Maak een tijdsgebaseerde automatisering die zoekt naar “urgente” tags en naar tickets die langer dan een bepaalde tijd geleden zijn beantwoord door een technicus en die Slack- en e-mailmeldingen stuurt om te escaleren  

Hoe u dit instelt: De eerste stap is het instellen van een e-mail om urgente tickets op te nemen en het opzetten van een Slack-integratie waarmee we meldingen naar de benodigde partijen kunnen sturen als een ticket buiten de SLA valt. Deze twee integraties kunnen worden ingesteld door te gaan naar Configuraties ➡️  Integraties ➡️  Meldingskanalen ➡️ Ingeschakeld:

De volgende stap is het instellen van de opnamemethoden voor elk probleem dat als “urgent” wordt beschouwd In dit voorbeeld gebruiken we twee standaard ingestiemethoden: een via een speciaal e-mailadres voor dringende problemen en een andere voor het parsen van een onderwerpregel voor het woord “dringend” In deze stap willen we eerst een e-mail toevoegen die specifiek bedoeld is voor dringende verzoeken. We willen ook dat deze e-mail het label “urgent” toevoegt aan alle verzoeken die binnenkomen, wat zal helpen bij onze voorwaarden in de volgende stap. Dit kan worden gedaan door naar Configuraties ➡️ Integraties ➡️ Ticketing ➡️ E-mail ➡️ Aanmaken te gaan:

Vervolgens zullen we een event-gebaseerde automatisering opzetten die de onderwerpregels zal analyseren op het woord “urgent” en de tag “urgent” zal toevoegen, zodat de volgende automatisering deze tickets ook kan verzamelen en escaleren indien nodig:

Tot slot maken we een automatisering die alle tickets escaleert die de tag “urgent” hebben en waarop al meer dan twee uur geen technicus heeft gereageerd:

5) Server ligt plat Automatisering

In ons laatste voorbeeld laten we zien hoe we een automatisering kunnen instellen die een ticket opent als een server down is, het ticket sluit als het probleem is opgelost en het ticket escaleert als hetzelfde probleem zich weer voordoet.

Gebruikscasus: Deze automatisering is essentieel als er bijvoorbeeld een server uitvalt in een belangrijke afdeling. Wanneer dit probleem wordt gedetecteerd, kunnen verschillende stappen worden geautomatiseerd om uw technici te helpen zich te concentreren op het aanpakken van het probleem in plaats van ernaar te zoeken en informatie te verzamelen die een fix zou kunnen vertragen. Deze automatisering kan:

  • Gebruik een vorm die u wilt,
  • Tag het probleem (wat, in combinatie met extra automatisering, dit ticket naar een goed zichtbaar ticketbord kan leiden),
  • Wijs automatisch een prioriteit en ernst toe (gebaseerd op uw bestaande beleid),
  • En handel de volgende stappen af als de situatie in korte tijd is opgelost of zich opnieuw voordoet.

Deze use case maakt gebruik van verschillende andere functionaliteiten binnen Ninja, waardoor het proces snel en eenvoudig verloopt, hoewel het op het eerste gezicht complex lijkt.

Wat er nodig is:

  • Maak een ticketautomatisering met voorwaarden die een ticket tagt wanneer het wordt aangemaakt en ernst en prioriteit toekent op basis van uw beleid, een ticket oplost wanneer de voorwaarde wordt gereset en het ticket escaleert als de voorwaarde opnieuw wordt geactiveerd
  • Bewerk uw serverbeleid om specifieke voorwaarden op te nemen voor wanneer servers down zijn
  • Bepaal de servervoorwaarden die bepalen wanneer het initiële ticket wordt aangemaakt, de initiële instellingen voor ernst en prioriteit en de initiële voorwaarden voor automatisch resetten.

Hoe u dit instelt: Eerst willen we een nieuwe voorwaarde ticketautomatisering maken om een ticket aan te maken wanneer een server down is. Er zijn drie secties voor dit ticket die we hier zullen doorlopen. In het eerste gedeelte worden de noodzakelijke velden ingevuld voor het eerste ticket dat wordt aangemaakt. Hier selecteren we een formulier om te gebruiken (we hebben ‘Standaard’ gebruikt) en voegen dan een tag, de status van het ticket en prioriteit en ernst toe op basis van uw bestaande beleid:

Vervolgens vullen we het gedeelte ‘On Condition Reset’ in. Dit gedeelte zorgt ervoor dat het ticket automatisch wordt opgelost als de server binnen een bepaalde tijd weer online is: De laatste stap in deze automatisering is het invullen van het gedeelte ‘On Condition Retrigger’. Dit gedeelte zorgt voor escalatie als de server binnen een bepaalde tijd weer down gaat (bijvoorbeeld binnen 48 uur). Op basis van de velden wordt het ticket opnieuw geopend, wordt ervoor gezorgd dat de tag ‘serverisdown’ wordt toegevoegd en worden de prioriteit en de ernst verhoogd naar het hoogste niveau:

Om de cirkel rond te maken, is het laatste onderdeel dat nodig is om ervoor te zorgen dat deze automatisering correct werkt, de Server Policy Conditions. Dus gingen we naar Beleid ➡️ Windows Server ➡️ Voorwaarden ➡️ Voeg een voorwaarde toe (alleen als een apparaat niet werkt en er nog geen voorwaarden zijn ingesteld). We maken de voorwaarde ‘Apparaat ligt er 5 minuten uit’, vullen de rest van de velden in en, het belangrijkste, selecteren de Ticketing Rule die we hierboven hebben gemaakt. Hiermee wordt de automatisering gestart die we zojuist hebben gebouwd en wordt het eerste ticket aangemaakt:

Ticketing is een krachtige functie binnen Ninja en voegt een extra laag van veelzijdigheid toe aan de single-pane view die Ninja biedt, omdat automatiseringen in eerste instantie ontmoedigend kunnen zijn als u nog geen ervaring hebt met een ticketingplatform. In plaats daarvan wilden we een How-To geven voor een aantal veelvoorkomende uitvoeringen die we zien, van eenvoudige tot complexere opstellingen. We zullen nog meer berichten publiceren om u te helpen met een aantal veelvoorkomende automatiseringen, zodat u uw technici efficiënt kunt helpen bij het oplossen van problemen. Voelt u zich vrij om suggesties te doen voor de volgende versie van deze serie en neem contact op als u vragen hebt over de uitvoeringen hierboven!

Volgende stappen

Het opbouwen van een efficiënt en effectief IT-team vereist een gecentraliseerde oplossing die fungeert als uw kerndienstleveringstool. NinjaOne stelt IT-teams in staat om al hun apparaten te monitoren, beheren, beveiligen en ondersteunen, waar ze ook zijn, zonder de noodzaak van complexe on-premises infrastructuur.

Leer meer over NinjaOne Endpoint Management, bekijk een live rondleiding, of start uw gratis trial van het NinjaOne-platform

Wellicht ook interessant voor u

Bent u klaar om een IT-Ninja te worden?

Ontdek hoe NinjaOne u kan helpen IT-Management te vereenvoudigen.
Bekijk een demo×
×

Zie NinjaOne in actie!

Door dit formulier in te dienen geef ik aan akkoord te gaan met het privacybeleid van NinjaOne.

NinjaOne Terms & Conditions

By clicking the “I Accept” button below, you indicate your acceptance of the following legal terms as well as our Terms of Use:

  • Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms.
  • Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party.
  • Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library belonging to or under the control of any other software provider.
  • Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations.
  • Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks.
  • Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script.
  • EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).