HelpDesk

Terminologi
Beslut dig for strukturen af ​​HelpDesk-projekter
Tilslutning af postkasse til Easy Redmine
Sådan konfigureres projektkonfiguration
Sådan opsætter du projektkonfiguration – detaljer
Sådan arbejder du med billetbehandling
Sådan konfigureres e-mail skabeloner
Sådan konfigureres globale indstillinger
Filtrer "Brug for reaktion"
HelpDesk-brugere
Hjørnesituationer

Disse instruktioner vil gennemgå alle trinene for at konfigurere HelpDesk fra brugergrænsefladen. Fra tilslutning af postkasser til Easy Redmine, gennem projektindstillinger, til finjustering af dashboards. Dette er ikke en teknisk manual til at konfigurere cron (eller planlagte opgaver på serversiden). Cron skal allerede være konfigureret for at HelpDesk kan fungere. Instruktioner til at indstille cron er link..

 

0 terminologi

Lad os først starte med en ordliste over brugte udtryk i den følgende manual.

postkasse - en e-mailadresse forbundet til Easy Redmine, hvorfra modtagne e-mails behandles til billetter i respektive HelpDesk-projekter
Billet - opgave oprettet fra en modtaget e-mail i en postkasse, eller en opgave internt oprettet af klienter i et HelpDesk-projekt
HelpDesk projekt – et projekt tilknyttet HelpDesk, hvor billetter kan oprettes
Domæne - den anden del af en e-mail-adresse. For eksempel er e-mailarbejder.Joe@client.com-domænet bare client.com
Nøgleord - ord eller en streng ord indeholdt i mailemne
SLA - aftale om serviceniveau. I forenklet betydning brugt i Easy Redmine, kontraheret tid til at reagere af selskabet på billetter indsendt af klienten. Beregnet i timer
Original e-mail - E-mail sendt til en HelpDesk-postkasse, hvorfra billetten blev oprettet
Operatør - disse vilkår vil blive brugt for supportmedarbejderen, der arbejder med billetterne

 

1 Beslut dig for strukturen af ​​HelpDesk-projekter

Afhængigt af om du vil have et enkelt projekt for alle billetter eller differentiere HelpDesk-postkasser, eller endda have specielle projekter for forskellige kunder, skal du tage stilling til strukturen af ​​projekterne, før en eventuel konfiguration starter. Denne beslutning vil påvirke nogle yderligere trin, der er angivet i denne manual.

Her er mulighederne:

1.1 Enkeltprojekt for alle billetter

Hvis du kun vil have et projekt, der samler e-mails fra en enkelt postkasse, er der ingen beslutning om at træffe >> alle e-mails sendt til postkassen opretter billetter til det samme projekt.

Eksempel: Alle dine klienter sender supportanmodninger til support@mycompany.com

Det er lige meget hvilket niveau dette projekt er, dybest set lever det sit eget liv inden for enhver del af din projektstruktur. Men hvis du planlægger at starte med et enkelt projekt og senere fortsætte med at udvide HelpDesk, bør du se mulighederne nedenfor.

1.2 Én postkasse, flere HelpDesk-projekter

Eksempel: Du bruger postkassen support@mycompany.com. Alle modtagne e-mails går ind i et generelt projekt. Men du har en klient, der har et specielt projekt, og særlige betingelser> e-mails fra domæne client.com behandles i det specielle projekt.

Selvfølgelig kan du få flere kunder adskilt på denne måde. I dette tilfælde kan projektstrukturen se sådan ud:

En anden mulighed er at have Standard HelpDesk-projektet på første niveau og de særlige projekter under det.

En anden måde, som nogle gange kan bruges, er en struktur:

> Klient1
>> Projekt for handel
>> Projekt til implementering
>>Projekt til HelpDesk

> Klient2
>> Projekt for handel
>> Projekt til implementering
>>Projekt til HelpDesk

Dette anbefales dog ikke, hvis du planlægger at samle billetter fra forskellige problemer til nogle samlede lister, statistikker eller resume.

1.3 Flere postkasser, ingen specielle klientprojekter

Eksempel: Du bruger postkasser support@mycompany.com, info@mycompany.com, it@mycompany.com og e-mails sorteres kun efter postkassen, ikke ifølge afsenderen.

I sådanne tilfælde kan du have 3-projekterne på samme niveau og muligvis under et hovedprojekt, der dækker dem alle.

Disse projekter kan være helt uafhængige og falde til separate dele af din organisation, de kan være i forskellige projekttræer (under forskellige topprojekter).

1.4 Flere postkasser med specielle kundeprojekter

Nuværende Easy Redmine HelpDesk-funktionalitet gør det muligt at adskille klienter udelukkende efter afsenderen og ikke ved en kombination af afsender og modtagende postkasse.

Eksempel: Du bruger postkasser support@mycompany.com, info@mycompany.com, it@mycompany.com. Du har en speciel klient, der sender supportanmodninger fra domæne client.com

Den anbefalede struktur er:

Når vi vender tilbage til projektstrukturen generelt, er der nogle yderligere overvejelser, der skal gøres. Hvis du sigter mod at integrere HelpDesk-behandling med en anden afdeling af din organisation (f.eks. udvikling), kan du overveje at sætte HelpDesk-projekter en lille smule dybere ind i projektstrukturen.

Korrekt projektstruktur giver dig mulighed for at generere forskellige rapporter, lister, statistikker i flere faser af din virksomhed.

 

2 Tilslutning af postkasse til Easy Redmine

Nu kan vi starte med selve opsætningen af ​​HelpDesk-komponenter. For at få Easy Redmine til at behandle postkasser, skal de være forbundet på følgende måde.

2.1 Administration >> HelpDesk >> Alle postkasser >> Tilføj postkasse

2.2 Indtast gyldige legitimationsoplysninger for din postkasse – Klik på Test for at sikre, at Easy Redmine kan nå postkassen

Indstilling af noter:

• Aktiv - postkasse scannes regelmæssigt af Easy Redmine for nye ulæste beskeder. Hvis den er deaktiveret, tjekker Easy Redmine ikke postkassen. Men du kan beholde postkassen i Easy Redmine til mulig fremtidig brug.
• Brug en anden afsender - når bruger på mailserveren ikke er det samme som postkasse (f.eks. HelpDesk-mail-bruger). Indtast her den gyldige malibox, som er repræsenteret af brugeren.
• SSL - hvis du bruger et SSL -certifikat på din mailserver
• Aktiver OAuth – OAuth 2.0-protokollen bruges af hundredvis af velkendte tjenester som en alternativ godkendelsesmetode. Hvad angår HelpDesks postkasse, kan den bruges til at bekræfte afsenderens legitimationsoplysninger ved hjælp af en ekstern applikation, som i øjeblikket understøttes er Google-arbejdsområde (tidligere G Suite) og Microsoft Exchange konti. Du skal læse OAuth 2.0 -dokumentation for den anden applikation for at vide, hvad der præcist skal indtastes i hvert felt. Selvfølgelig skal du have administratoradgang til den anden applikation for at finde de nødvendige oplysninger, f.eks. Webstedets URL, klient -id, klienthemmelighed, godkende URL, token -URL, omfang osv.
  
• Folder - hvis du ønsker, at Easy Redmine kun skal tjekke bestemte mapper for ulæste e-mails.
• I succes flytte til – hvis en e-mail behandles korrekt af Easy Redmine (billet er oprettet), bliver den flyttet dertil
• I fejl flyt til – hvis en e-mail behandles forkert (billet er ikke oprettet), bliver den flyttet dertil

Når du har testet forbindelsen, skal du klikke på Gem.

2.2.1 Hvor finder man OAuth 2.0 -legitimationsoplysninger til Microsoft- og Google -konti

For at forbinde Easy Redmine med en Google Workspace-konto ved hjælp af OAuth 2.0-protokollen, skal du oprette en konto på Google Cloud Platform, få de nødvendige legitimationsoplysninger, der er angivet der, og kopier dem til postkasseindstillingerne i vores applikation. Nogle nyttige instruktioner kan findes link..

For at forbinde Easy Redmine med en Microsoft Exchange-konto ved hjælp af OAuth 2.0-protokollen, skal du oprette en konto på Microsoft Azure portal, indhent de nødvendige legitimationsoplysninger, der er angivet der, og kopier dem til postkasseindstillingerne i vores applikation. Nogle nyttige instruktioner kan findes link..

Adgangstokens har en begrænset levetid (maks. 6 måneder), du kan ikke oprette ubegrænsede. Efter dette tidspunkt stopper postkassen med at fungere, og et nyt token skal genereres og genindsættes i applikationen.

En OAuth 2.0-adgangs-URL af formen "/organisations/oauth2/v2.0/authorize" er kun gyldig, hvis adgang til applikationen er aktiveret i organisationen. Ellers skal adgangs-URL'en have formen "/[TENANT_ID]/organizations/oauth2/v2.0/authorize". De korrekte indstillinger kan findes i sektionen Endpoints.

Når to-faktor-godkendelse (2FA) er konfigureret i Microsoft Azure, skal alle tilsluttede postkasser opdateres.

2.2.1.1 Fejl "Brugeren er godkendt, men ikke tilsluttet"

Dette skyldes, at den valgte Azure-bruger, som postkassen er registreret igennem, ikke har tilladelse til at få adgang til postkassen. I dette tilfælde er det ikke nok, hvis brugeren er administrator, da han skal have licens til at bruge Office 365. Hvis brugeren har delegeret tilladelse (han må ikke tilføje adgang til postkassen, da det kræver godkendelse af f.eks. en administrator ), skal han få den relevante omfangstilladelse i Azure og deaktivere denne mulighed på samme tid.

Opløsning:

• Brugeren skal enten være den direkte ejer af den postkasse, han tilgår (og dermed have de nødvendige tilladelser til at gøre det).
• Alternativt kan han være en anden (licenseret) bruger, som har fået adgang til den pågældende postkasse.

Et andet muligt problem er, at kontoen oprettes som POP3 i stedet for IMAP. POP3 understøtter ikke OAUTH i systemet.

Opløsning:

• Sørg for, at kontoen er indstillet som IMAP i både azurblå og i Easy Redmine.

2.2.1.2 Fejl: Microsoft Help Desk opretter forbindelse, men holder op med at virke efter nogen tid

Du glemte at aktivere retten til offlineadgang.

2.2.1.3 Use case: Mange postkasser, en super Help Desk-bruger

Hvis du har flere Help Desk-postkasser opsat i Microsoft Exchange, og du vil delegere adgangsrettigheder til alle disse postkasser til en enkelt bruger, kan du gøre det via Microsoft 365 administrationscenter » Admin centre » Udveksling.

Du vil blive omdirigeret til Exchange-administrationscentersektionen. Klik her på fanen Modtagere » Postkasser og vælg den postkasse, hvis adgangsret du vil delegere. En højre pop op-sidebjælke åbnes og klik på Delegering.

Nedenfor kan du se tegnet Læs og administrer (fuld adgang) med en Rediger-knap at klikke på.

Du kan derefter søge efter og tilføje brugere, der bliver medlemmer af denne postkasse med samme rettigheder som postkasseejeren.

Den bruger, du vælger, skal have Help Desk-administratorrettigheder på Easy Redmine-siden.

2.2.2 Aktivering af OAuth 2.0-godkendelse med Azure Active Directory

Når du bruger OAuth 2.0-godkendelse, får du adgang til en webtjeneste fra en klientapplikation. Måden du gør dette på afhænger af det tilskud du bruger. I denne tutorial, vil du lære, hvordan du konfigurerer tildelingstypen for klientlegitimationsoplysninger for applikationer i Azure Active Directory.

2.3 Konfigurer hyppigheden af ​​postkassescanning

Højreklik på postkassen og vælg Indstillinger

Nu er du tilbage til postkasseindstillingerne, men med en ekstra indstilling. Som standard er den indstillet til Hvert 5. minut. Men det anbefales generelt at have denne indstilling omkring hvert 10. minut. Hvis du har mange postkasser tilsluttet Easy Redmine, kan denne automatiske scanningsopgave tage længere tid og overbelaste din server med for hyppige scanninger, hvilket vil bremse hele applikationen.

Knapnotater:

• Udfør – start manuelt postkassescanningen
• Historik – se tidligere postkassescanninger
• Slet – fjern postkasse fra Easy Redmine scannede postkasser
• Deaktiver – deaktiver automatisk postkassescanning

2.4 Automatisk deaktivering

Behandling af postkasse med regelmæssige intervaller kræver serverressourcer, især hvis du har flere postkasser. Af denne grund har vi implementeret en mekanisme, der automatisk deaktiverer behandling af postkasse efter 3 gange lykkedes det ikke at godkende og downloade e-mails. Deaktiver betyder, at feltet Aktiv vil blive slukket. Du vil stadig være i stand til at bekræfte indstillingerne, teste og aktivere.

Hvorfor? For at gemme dine ressourcer. Hvorfor skal serveren blive ved med at pinge en ufunktionel postkasse?

 

3 Projektkonfiguration

Mailbox er tilsluttet og scannet af Easy Redmine, men vi har endnu ikke indstillet, hvor billetterne skal oprettes. Før et projekt forbindes til HelpDesk, kan billetter ikke oprettes, fordi enhver opgave generelt kræver et projekt.

Denne del vil blive opdelt i forskellige scenarier i henhold til formålet med hvert projekt.

3.1 Standardprojekt for postkasse

I eksemplerne i det forrige kapitel ville dette være projekterne Standard HelpDesk, INFO – generelt, IT – generelt, SUPPORT – generelt, dvs. ikke begrænset til et bestemt domæne af afsenderen.

1. Klik på "Tilføj til HelpDesk"mulighed på en projektoversigtsside for det valgte projekt.
   
2. Vælg den postkasse, som projektet vil være standard for
   
3. Rul ned og Gem

En komplet forklaring af alle HelpDesk-projektindstillinger følger yderligere i dette kapitel.

3.2 Særligt bygherreprojekt

Fra eksemplerne i kapitel 1 ville disse være projekterne: Bohemia Sun, Trains Francais, Client 123, Client ABC, Client XYZ, Client 1>>Projekt til HelpDesk, Client 2>>Projekt til HelpDesk

1. Vælg projekt
2. Udfyld felterne fremhævet nedenfor. Indstilling af noter er under skærmbilledet
   
3. Rul ned og Gem.

Indstilling af noter:

• Standard for postkasse - MÅ IKKE vælg en hvilken som helst postkasse, hvis du vil indstille dette projekt som et specielt klientprojekt
• Mails, domæner, nøgleord behandlet i dette projekt – alle indstillinger i dette afsnit er med OR operatør, hvilket betyder det hvis mindst en betingelse er opfyldt, oprettes billet i dette projekt
• Udfyld e-mail til fra - Når denne mulighed er valgt, vil forfatterens e-mail automatisk blive udfyldt ny billet. Denne mulighed er nyttig, når du har projekter, hvor billetter er oprettet af rigtige brugere, i stedet for at behandle indgående e-mails.
• Søgeord – I dette eksempel, hvis en e-mail modtaget i NOGEN HelpDesk-postkassen indeholder hele strengen Jeg kommer fra firmaets klient ABC, billet vil blive sorteret i dette projekt. Brug ikke den samme nøgleordstreng til flere projekter, kun den første post i databasen med strengen bruger den udpegede nøgleordstreng
• Mail eller domæne – indgående e-mails scannes for disse værdier i FRA-feltet i e-mailen. I dette eksempel kan afsenderen være enhver med postkasse, der slutter med clientABC.com, eller det kan også være en specifik person med en anden e-mail, men vi ønsker, at hans billetter skal sorteres i dette projekt

Fuldstændig forklaring af alle HelpDesk-projektindstillinger vil følge yderligere i næste kapitel.

VIGTIGT: Det er ikke den bedste praksis at have et projekt indstillet både som Standard for postkasse OG specificeret for en bestemt mail eller domæne. Enhver afsender får deres billetter oprettet i dette projekt, så du behøver ikke at specificere dem. Denne form for indstilling kan forårsage forvirring.

3.2.1 Lukke og arkivere specielt klientprojekt

Når et sådant projekt er lukket (ved at blive skrivebeskyttet), vil billetter ikke være muligt at oprette indenfor. Derfor vil dette projekt ophøre med at være et særligt klientprojekt, og e-mails, der kommer fra domæner, der er angivet i HelpDesk-indstillingerne, vil blive behandlet som ukendt og falde i et generelt HelpDesk-projekt.

Det samme gælder arkiverede projekter.

 

4 Projektkonfiguration – detaljer

Nu hvor vi har differentieret typer af projekter, som kan bruges i HelpDesk, kan vi fortsætte med at forklare resten af ​​projektindstillingerne. Når et projekt er forbundet til HelpDesk, er der to måder at komme ind på projektets HelpDesk-konfigurationsside.

• Administration >> HelpDesk >> Alle HelpDesk-projekter >> Rediger
  
• Projektindstillinger >> HelpDesk
  

4.1 Grundlæggende indstillinger

Indstilling af noter:

• Tracker – nye billetter i dette projekt vil blive oprettet med denne tracker
• Tildelt – nye billetter i dette projekt vil blive tildelt denne bruger
• Medarbejder – nye billetter i dette projekt vil have disse kollegaer (mulig valgmulighed)
• Automatisk billetopdatering – afhængigt af din arbejdsgang kan der eksistere nogle billetter, som er faktuelt løst, og som holdes åbne. I sådanne tilfælde kan du indstille automatisk lukning i henhold til status og varighed af ikke-opdatering. Ud over at lukke billetten kan der automatisk sendes en opfølgende e-mail fra skabelon, f.eks. med det formål at informere afsenderen om, at hans billet er blevet lukket, eller spørge ham om hans tilfredshed med billetløsningen.
• Kontraktmæssige timer månedligt – denne indstilling bør kun bruges til specielle kundeprojekter, hvor kunder har forudbetalt et vist antal timers support pr.
• Aggregerede timer – kontrakten med bygherren kan have mulighed for at overføre uudnyttede timer fra forrige måned til den næste. Hvis klienten har 10 forudbetalte timer, men kun brugte 7 af dem i løbet af maj, vil 3 timer blive overført til juni
• Resterende timer – hvor meget er der tilbage. Blyantsknappen gør det muligt at rydde resterende timer manuelt – indstillet til 0
• Aggregeret startdato – hvornår den forudbetalte periode begynder; skal vælges en dag, som er fælles for alle kalendermåneder, dvs. dag 1-28
• Aggregeret periode – for hvilket tidsrum er timerne aggregerede, før de nulstilles til de oprindelige kontraktmæssige timer. Hvis der stadig er 13 timer tilbage ved udgangen af ​​kvartalet (udgangen af ​​kvartalet bestemmes af den aggregerede startdato), vil de ikke blive overført til det nye kvartal. Timerne vil blive nulstillet til 10

De timer, der er til rådighed, bruges tidsposter i projektet. Hvilke nøjagtige poster vil blive forklaret yderligere i denne manual.

4.2 SLA

Dette er et vigtigt mål for ethvert HelpDesk-projekt, men især for specielle klientprojekter, hvor SLA-overtrædelse kan blive sanktioneret. Som tidligere nævnt kan billetter oprettes via e-mail eller direkte fra systemet af klienter med særligt begrænset adgang til et HelpDesk-projekt. Begge tilfælde har en lille nuance i SLA-indstillingen.

4.2.1 SLA for e-mail-genererede billetter

Indstilling af noter:

• Navn – Titel på SLA (for bedre SLA-administration i HelpDesk-projektet)
• Nøgleord - skal udfyldes, hvis SLA indstilles for e-mail-genererede billetter. I dette tilfælde er der et specifikt søgeord, som hvis det er indeholdt i emnet for e -mailen, vil billetten få specifikationerne for SLA (timer, prioritet, tracker)
• Timer til svar – frist, indtil hvilken første statusændring af billetten skal finde sted. Statusændring angiver, at billetten er blevet bekræftet, og kunden er blevet informeret om det
• Timer at løse – frist for at lukke billetten >> sætte den i lukket status
• Prioritet – ny billet fra e-mail, der indeholder søgeordet, vil have denne prioritet
• Tracker – ny billet fra e-mail, der indeholder søgeordet, vil have denne tracker. Dette er f.eks. nyttigt, hvis kunden har fundet en defekt i produktet og ønsker at rapportere det direkte som en defekt og ikke som en standardanmodning om support. Klienten ville derfor skrive med emne f.eks Defekt - og billetten skal ikke klassificeres af HelpDesk-manageren.
• Tæl SLA baseret på arbejdstid – SLA-deadlines vil ikke blive fastsat for ikke-arbejdsdage eller timer på dagen. Nogle SLA er muligvis kun begrænset til arbejdstid, men andre kan indstilles til 24/7
• SLA arbejdstid – tidsramme for SLA
• Arbejdsdage – arbejdskalender, hvor weekender, helligdage og andre ikke-arbejdsdage registreres

4.2.2 Bestilling af SLA'er

Med flere niveauer, søgeord og søgeordsstrenge er det vigtigt at holde orden korrekt. Mailemnerne kontrolleres for nøgleord i henhold til rækkefølgen i HelpDesk-indstillingerne.

Eksempel: Du har kontraktmæssigt definerede nøgleord til "Kritisk" og "Kritisk bug", hver af dem har en anden SLA. Du skal sørge for, at de to emner bliver differentieret, når e-mails behandles.

I dette tilfælde skal du sætte SLA "Kritisk bug" over "Kritisk". Mekanismen for behandlingen af ​​mailsubjekt er enkel:

1. Søg efter "Kritisk bug" i postemnet
2. Hvis ovenstående streng ikke er i emnet, skal du søge efter den næste i vores tilfælde "Kritisk"
3. Hvis ovenstående streng ikke er i emnet, skal du fortsætte med at søge efter yderligere nøgleord
4. Den sidste SLA skal være det generelle (for uspecificeret niveau) nøgleord ved hjælp af * -mærket for alle fag

Hvis du lægger "Kritisk" før "Kritisk bug", vil det betyde, at e-mails med "Kritisk bug" i emnet behandles forkert, fordi de falder ind under "Kritisk" SLA.

---

Generelt, jo mere specifik nøgleordstreng, jo højere skal dens placering være.

SLA på en klientbillet er blevet brudt. Hvad gør du for at sikre dig, at du har kontrolleret dette? I dette tilfælde skal du gå til projektindstillinger >> HelpDesk og rulle hele vejen ned

4.2.3 Nulstilling af SLA for lukkede billetter

Du vil også se en indstilling øverst i SLA-sektionen.

Når det er aktiveret, vil billetter, der engang var lukket og genåbnes af et andet svar fra klienten, have SLA regnet som om de var nye – fra tidspunktet for klientens svar, som genåbnede billetten.
Eksempel: Billet nr. 1234 var åben mandag kl. 16:00. SLA er 48 timer => tiden til løsning er indtil onsdag 16:00. Billetten blev lukket af en operatør tirsdag kl. 10. Klienten svarede igen, at han har brug for flere oplysninger tirsdag kl. 00:14. Billet nr. 00 har nu sat nyt SLA til torsdag 1234:14.

Når deaktiveret, tælles SLA altid fra det oprindelige tidspunkt, da billetten blev oprettet.
Eksempel: I scenariet fra det første tilfælde. Efter klientens svar tirsdag kl. 14: 00, vil SLA ikke blive nulstillet og forbliver onsdag 16: 00. Det samme gælder når klienten åbner billetten på torsdag. Billetten ville nu blive fremhævet som forfalden.

Fra den sidste note er det tydeligt, at denne indstilling kun skal deaktiveres på projekter, hvor billetterne er enkle og løsning kan defineres strengt, så der er ingen grund til at åbne billetterne igen fra klientens side.

4.2.4 SLA for internt oprettede billetter

Som tidligere nævnt må billetter ikke kun oprettes ud fra e -mails. Easy Redmine har en avanceret adgangsniveaukontrol, som giver dine kunder direkte adgang til systemet med begrænsede tilladelser (for at oprette billetter, redigere billetter, læse nyheder, ...).

Billetter oprettet som standardopgaver af indlogerede brugere har en lidt anden måde at bestemme SLA på. Da der ikke er behandlet nogen e-mails, kan du ikke bestemme SLA efter nøgleord. Lad os forklare på billedet herunder.

Når du opretter SLA for internt oprettede billetter, skal du efterlade søgeordet tomt. SLA bestemmes derefter af en kombination af prioritet og tracker. Når du gemmer indstillingerne, forsvinder søgeordet, hvilket angiver, at denne SLA bruges til internt oprettede billetter. Hvis du lader Tracker stå tom, vil kun søgeord blive overvejet.

Ved at konfigurere workflow effektivt kan du begrænse klienter til kun at oprette billetter i visse trackere, selvom projektet indeholder flere af dem. Du kan for eksempel kun tillade kunder kun at bruge tracker HelpDesk Ticket og Bug, så du kan kun indstille SLA for disse trackere. Alle andre trackere ville ikke kræve SLA-indstilling, fordi de ikke ville blive indsendt af kunder og derfor ikke ville blive betragtet som HelpDesk-billetter.

4.2.5 SLA-hændelser og rapporter

SLA-rapporter er baseret på individuelle SLA-begivenheder. Disse begivenheder kan ses pr. hver HelpDesk-billet, tjek blot SLA-begivenheder i den nederste menu af enhver HelpDesk-billet. Når en billet er besvaret/løst, kan du tjekke dens SLA-begivenhed her, som blandt andet fortæller dig, hvor lang tid (i timer) der faktisk var gået, indtil det første svar fandt sted, og du kan direkte sammenligne værdien med SLA-svaropfyldelse (dvs. tid, der kræves til det første svar) og SLA-opfyldelse (dvs. tid, der kræves til billetopløsning) i henhold til dine SLA-indstillinger på det pågældende HelpDesk-projekt. Derudover kan du øjeblikkeligt se, hvem og hvornår der har reageret/afklaret billetten, og hvilket projekt denne billet tilhører. Tidsregistreringer vises med et positivt eller negativt symbol (+/-), hhv. i grøn/rød farve for at fremhæve, om SLA'en er blevet kompileret eller ej.

SLA-begivenhed oprettes kun, når en supportbillet faktisk besvares ved at sende en e-mail til en kunde, ikke før. Tilføjelse af en kommentar til en billet fører ikke til oprettelse af SLA-begivenheder, fordi det ikke er klart, om en sådan kommentar kun er en intern meddelelse eller et svar på kundens anmodning.

Når en supportbillet flyttes fra et projekt til et andet, genberegnes SLA -begivenheden ikke. SLA'en for billetten forbliver fra det originale projekt, hvor en sådan billet blev oprettet. SLA -genberegning udløses af en ændring af tracker eller prioritet.

For at se listen (en oversigt) over alle SLA-begivenheder, skal du gå til /easy_sla_events eller klikke på SLA-rapporter-menupunktet i sidebjælkemenuen på hoved HelpDesk-dashboardet (/easy_helpdesk).

SLA-begivenheder kan let filtreres i henhold til forskellige SLA, brugerdefinerede felter eller andre kriterier.

Alle SLA-begivenheder opsummeret i overordnede SLA-statistikker kan findes på SLA-rapporters dashboard. Som standard er dette dashboard tilgængeligt i topmenuen på hoved HelpDesk-dashboardet. Ved at bruge dashboardet kan du øjeblikkeligt se den samlede procentdel af mislykket SLA-svar, mislykket SLA-løsning og gennemsnitlig førstegangssvar. Da dashboardet er en standard tilpasset side som mange andre, kan du tilpasse alle de viste moduler i dashboardet, så de passer bedre til dine behov.

4.2.6 Billet SLA-rapporter

Udover ovenstående er det også muligt at lave SLA-rapporter over billetter.

Fra version 11plus.2.0 har billetter to nye felter:

• Første SLA-svar opfyldelse - taget fra den første SLA-begivenhed på billetten
  
• Opfyldelse af sidste SLA-løsning - taget fra den sidste SLA-begivenhed på billetten

Sådan fungerer det

Billet oprettes -> Helpdesk-operatør svarer-> SLA-begivenhed oprettes -> værdier fra denne SLA-begivenhed kopieres ind i de førnævnte attributter for billetten -> klientsvar tilbage -> operatørsvar til klient -> ny SLA-begivenhed oprettes - > værdien af ​​SLA revolve fultilment den kopierede ind i billetattributten.

Hvor er værdien

Da selve billetten indeholder de mest afgørende SLA-rapporteringsdata, kan du lave rapporter om SLA-tilfredshed direkte over billetter.
Nogle eksempler:

• Billetopløsning succesrate
• Linjediagram over det absolutte antal billetter med mislykket SLA-svar/løsning i tide

4.3 Brugerdefineret sidehoved og sidefod

Denne indstilling vedrører HelpDesk e-mail-kommunikation, dvs. kommunikation i e-mail-genererede billetter. Du kan tilpasse e-mails fra forskellige HelpDesk-projekter, uanset om det er til brug for virksomhedens identitet, til vilkårsspecifikationer eller endda fortrolighedsfraskrivelser.

4.4 advarsler

For at forhindre, at SLA krænkes, er der muligheden for at bruge automatiske alarmer, der giver beskæftiget personale besked om truende problemer i form af forsinkede billetter.

En anden type Alerts-ure brugt tid i projekter, hvor klienter har forudbetalt et specifikt antal timers support (som forklaret i kapitel 4.1).

Indstilling af noter:

• Overvåg supportbilletternes forfaldsdato – for at være mere præcis Forfalden tid ifølge SLA. Hvis det er aktiveret, genereres alarmer, når SLA-fristen nærmer sig. Yderligere indstillinger forklares nedenfor
• Overvåg supportbilletter brugt rettidigt - se brugt tid på projekter med specificerede forudbetalte månedlige timer
• Liste over advarsler, som skal have en modtagersæt - disse er prækonfigurerede advarsler, som kun skal indtaste en e-mailadresse, hvor meddelelserne skal sendes
• Liste over konfigurerede advarsler – advarsler uden manglende parameter
• Ved at klikke på hver alarm vises de forudkonfigurerede parametre med mulighed for at redigere dem
• Advarsel / advarsel: alvorligheden af ​​meddelelsen
• Støttebilletter forfaldstid – advarselsvagter SLA løser deadline (billetlukning)
• Supportbilletter timer til svar – advarselsvagter SLA svarfrist (første ændring af status)
• Supportbilletter forudbetalte timer - advare vagter bruger af forudbetalte månedlige timer på projektet

Timer set i den sidste alarm er dem, der er logget på billetter, som er i trackere nævnt i projektets HelpDesk-indstillinger.

Eksempel: Standard tracker for projektet er HelpDesk Ticket. Nogle SLA er konfigureret til tracker Bug. Projektet indeholder andre trackere (Task, Feature development), som ikke bruges på billetter. I sådanne tilfælde er de forudbetalte timer kun gyldige for HelpDesk Ticket og Bug. Brugt tid på andre trackere tages ikke i betragtning for denne advarsel.

4.5 Opdater/slet

Opdater – gem ændringer foretaget i HelpDesk-indstillingerne for projektet
Slet – fjern projektet fra HelpDesk. Dette betyder ikke sletning af projektet som helhed, det vil det kun fjern forbindelsen af ​​projektet til HelpDesk.

 

5 Billetbehandling

Efter den enorme mængde indstillinger, der er forklaret indtil nu, er det på tide at se på nogle praktiske konsekvenser, inden vi kommer tilbage med et andet sæt indstillinger. Vi vil starte med en simpel brugssag for at demonstrere, hvordan billetteringen fungerer og springe over nogle funktioner. De vil blive forklaret senere.

5.1 E-mail-genererede billetter

For korrekt håndtering af billetter oprettet via e-mail, skal du kontrollere, at standardfelterne "email til"Og"e-mail cc"er aktive. Du kan tjekke det ind Mere » Administration » Trackers » HelpDesk-billet » Standardfelter. Hvis disse standardfelter mangler, skal de være deaktiveret af administratoren.

5.1.1 E-mail behandles af Easy Redmine og billet oprettes i det fastlagte projekt

Bemærkninger:

• e-mail til: Afsenderen af ​​den e-mail, hvorfra billetten er oprettet
• Specifikation af postkassen, hvorfra opgaven blev oprettet
• SLA-værdier – hvis de overtrædes, er de fremhævet med rødt
• Parset e-mail - Dette er tekstindholdet i e-mailen. Billeder vises ikke direkte i denne visning på grund af ydeevneoptimering (især når billetten har mange svar, og hver enkelt indeholder en signatur med firmalogo, vil billetten tage smertefuldt lang tid at indlæse på grund af den stigende størrelse af hver af de næste svar)
• Fuld e-mail tilgængelig som en vedhæftet fil – hvis den originale e-mail indeholder billeder, kan du se den direkte i Easy Redmine.
  

5.1.2 Skriv et svar og opdater billetten

For at imødekomme SLA -svaret skal vi for første gang ændre status og svare klienten. For de følgende eksempler, hold et åbent sind om billetkommunikationen, det er bare for at demonstrere, hvordan kommunikationen fungerer teknisk.

Lederen skrev et svar til kunden om modtagelse af billetten, tildelte den til en operatør og ændrede status. Svaret sendes til klienten (e-mail til), når du markerer afkrydsningsfeltet.

Send hurtig e-mail til kunden fra skabelonen

Du har to muligheder for at sende en e-mail til klienten. Når du opdaterer en HelpDesk-billet, er der muligheden "Send hurtig e-mail til kunde fra skabelon", så du kan vælge en e-mail-skabelon for dit svar til billetafsenderen. Når en skabelon er valgt, sendes e-mailen med det samme, og der kræves derfor ikke flere handlinger. Når der ikke er valgt en skabelon, har du stadig mulighed for at vælge skabelonen og bekræfte afsendelsen af ​​e-mail i næste trin som normalt (kryds "Send e-mail til kunde (med forhåndsvisning) afkrydsningsfeltet i bunden og gem). Formålet med dette funktion er primært at spare din tid, når du sender e-mails til kunder.

5.1.3 Send en opdatering til ekstern e-mail (e-mail til)

Ved at trykke på Gem gemmer du de opdateringer, der er foretaget på billetten, og du kommer til dialogen for at sende svaret til klienten.

Bemærkninger:

• Mailskabelon – hvis du har konfigureret e-mailskabeloner, kan du vælge en. Eller en skabelon vil blive forudindstillet i henhold til status. Denne funktion vil blive forklaret i yderligere kapitler
• Mail afsender – dette vil blive vist til klienten som FRA. Indstillingen af ​​befolkningen i dette felt vil blive forklaret i yderligere kapitler
• Mailemne – tilpasset eller forudindstillet i henhold til mailskabelonen. Som standard er den udfyldt af billet Emne
• Mailmodtager – afsender af den originale mail. Hvis der var andre modtagere af den originale e-mail i CC eller TO, vil de også blive tilføjet i dette felt.
• Mailsvar til – dette er altid HelpDesk-postkassen, som den originale e-mail blev sendt til
• Mail kopi – du kan tilføje andre modtagere
• Mail brødtekst – hvis en skabelon ikke blev valgt, vil den bestå af den sidste kommentar på billetten og den originale e-mail-tekst. Indholdet kan redigeres.
• Vedhæftede filer – du kan vælge vedhæftede filer til at sende med e-mailen. Det kan være nogle nyere e-mails eller nye filer, du uploadede, da du opdaterede billetten
• Send mail – mail sendes til alle modtagere
• Send ikke mail – du vil vende tilbage til detaljerne i billetten

Når vi ser tilbage på billetdetaljerne, ser vi, at SLA -svaret er forsvundet, fordi det blev foretaget.

5.1.4 Kunden svarer tilbage – hvordan e-mails er parret med en billet

Kunden har modtaget dit svar og svar tilbage. Svaret tilføjes som en kommentar fra en anonym bruger (en bruger, der ikke er registreret i systemet).

Lad os forklare her, hvordan klientens svar fandt vej til den rigtige billet.

Da lederen i det foregående trin sendte ekstern mail til klienten, indeholdt e-mailen en skjult overskrift (som alle e-mails gør) med billettens ID. Ved at svare på e-mailen var denne overskrift også indeholdt i klientens svar, og derfor identificerede HelpDesk den og tilføjede svaret til billetten med samme ID.

Her er alle måder, modtagne e-mails er parret med billetter i systemet.

1. Den skjulte overskrift på e-mail, hvor opgave-id'et gemmes
2. E-mailens emne, hvor der søges en kombination af "#" og opgave-id
3. Hvis dette ikke findes, søges emnet alene efter et nummer

Derfor, selvom klienten skriver en ny e-mail til en HelpDesk-postkasse og tilføjer billetnummeret (opgave-id) i emnet, vil den stadig blive parret. Som i det følgende eksempel.

Ny e-mail til en HelpDesk-postkasse:

Efterfølgende note i billetten:

5.1.5 Det sidste svar – billetten lukkes

Et sidste svar fra operatøren, som billetten er lukket med. Efter lukning af billetten forsvinder SLA til løsning også fra billetdetaljen.

Hvis klienten svarer igen, åbnes billetten igen til en defineret status (denne indstilling forklares nærmere).

5.1.6 Billetejerfelt

Billetejerfeltet er et valgfrit standardfelt beregnet til brug med HelpDesk-billetter. Med sin drop-down liste giver den dig mulighed for at vælge én bruger ud af alle interne brugere, der allerede er oprettet, og denne ene bruger betragtes som ejeren af ​​billetten. Feltet kan aktiveres eller deaktiveres for enhver tracker, hvor du muligvis skal have det (gå til Administration » Trackers » HelpDesk-billet » sæt kryds i feltet og gem). Som standard er billetejerfeltet deaktiveret, så HelpDesk-ledere skal gå til Administration for at aktivere det for en specifik tracker. Baseret på dette felt på HelpDesk-billetter kan HelpDesk-ledere nemt se, hvor mange billetter der blev modtaget, lukket/løst eller opdateret i henhold til deres billetejer. Så dette kan markant forbedre/forenkle HelpDesk-indsigt (dashboards, statistik) og rapporter for en defineret tidsperiode. Arbejdsgangsindstillinger såvel som handlingsknapper kan anvendes på billetejerfelt ligesom ethvert andet standard- eller brugerdefineret felt.

5.1.7 E-mail til, cc vælg fra forskellige datakilder

I marker E-mail til , E-mail cc tilføjet mulighed for at søge efter e-mails fra datakilder:

• Personlige kontakter (CRM)
  
• Interessenter
  
• Konti (CRM)
  
• HelpDesk-brugere (Helpdesk)
  

Denne funktion er deaktiveret som standard. For at aktivere det, gå til Administration >> Plugins >> E-mail felt autofuldførelse - Rediger og aktivér funktion E-mail felt autofuldførelse og nødvendige dataressourcer.

Uden at aktivere nogen af ​​dataressourcerne søger funktionen indbygget gennem brugere.

Sådan fungerer det

Hvis det er aktiveret, fungerer opgavefelterne E-mail til og cc som autofuldførelse.

5.2 Internt oprettede billetter

Hvis klienten indsender billetter direkte i dit system, kan arbejdsgangen defineres, som om du arbejdede med andre opgaver. Du vil tillade klienten at oprette HelpDesk Ticket eller Bug. De vil til at begynde med være i standardstatus (det meste kaldes blot Ny). Derefter går kommunikationen frem og tilbage mellem klient og operatør ved serier af billetopdateringer og pr ændre ansøgeren, hvilket er nødvendigt for at holde alle brugere aktive i kommunikationen. SLA'er overvåges som i den e-mail-genererede billet Svar: Statusændring; Løs: Luk billetten.

5.3 Billetter oprettet via REST API

Der er mulighed for, at opgaver/billetter oprettet via REST API (f.eks. fra en webformular) ser ud som HelpDesk-billetter oprettet fra e-mail. Bare send "easy_helpdesk_mailbox_username"parameter via API, for eksempel: issue [easy_helpdesk_mailbox_username] = 'support@company.com ". Dette vil få den nyoprettede opgave til at ligne en HelpDesk-billet fra den angivne e-mail-adresse, SLA-indstillingerne vil blive anvendt i overensstemmelse hermed, og en tak-besked vil blive sendt til afsenderen.

 

6 Mail skabeloner

Det var allerede varslet under sidste kapitel, men uden en ordentlig forklaring på bearbejdningen ville det ikke være så let at forstå, som det bliver nu. Det sidste HelpDesk-menupunkt har vi ikke introduceret.

E-mail-skabeloner bringer et vist niveau af automatisering og formalisering af kommunikationen med klienter, hvorved de anerkender din virksomhed som en professionelt handler.

En vigtig egenskab ved mail-skabeloner er det de er konfigureret pr. postkasse, Du kan ikke bruge en skabelon fra en postkasse IT@mycompany.com til e-mails sendt til support@mycompany.com.

6.1 Oprettelse af en mailskabelon

Der er faktisk to typer mail-skabeloner: autoreply og standard skabelon. Da de ikke er konfigureret anderledes, forklarer vi begge sager på én gang.

6.1.1 Tilføj ny skabelon

6.1.2 Grundlæggende egenskaber

Indstilling af noter:

• Brug til postkasse – hvilken postkasse vil have denne skabelon tilgængelig
• Opgavestatus – i henhold til denne status vil skabelonen være forududfyldt i dialogen, når svaret sendes til en ekstern mail (se kapitel 5.1.3.)
  • Hvis du vil bruge skabelonen som automatisk udsendelse af nyoprettede billetter fra e-mail, skal du indstille status til standardkortet (som konfigureret i administration >> opgavestatus). Faktisk, når en billet oprettes fra en e-mail, sendes autoreplayet i henhold til denne skabelon med det samme. Det kan bruges til at bekræfte overfor klienten, at billetten blev oprettet, og hvad de næste trin vil være.
  • Du kan muligvis lade statusen være tom, i hvilket tilfælde den aldrig udfyldes automatisk i send-mail-dialogen, men brugere vil være i stand til at vælge den manuelt
• Emne – hvad vil emnet indeholde
• Det anbefales at inkludere opgave-id'et i autosvaret - hvis du har mange billetter med samme klient, vil du bedre kunne skelne mellem dem, når du taler med klienten
• Du kan også bruge det faktiske emne, der blev brugt klientens originale e-mail

6.1.3 Dynamiske tokens og posttekst

Dynamiske tokens kan bruges til at give bestemte billetoplysninger til klienten. I en skabelon indtastes de som en af ​​nedenstående, og i den e-mail, der sendes til klienten, erstattes de af den aktuelle værdi fra billetten.

Et simpelt eksempel på autoreply.

6.1.4 Vigtige dynamiske tokens

Hvis du vil bruge mail-skabeloner effektivt, er det nødvendigt at inkludere token % Task_note% ind i skabelonen. Den bruger den kommentar, du sidst tilføjede til billetten og omgiver den med den anden tekst i skabelonen.

Brug token til at tilføje en virksomhedssignatur til de udgående e-mails % User_signature%. Den bruger HTML-signaturen for den aktuelle bruger (som opdaterer billetten), der kan indstilles på brugerens profil.

Eksempel: Lad os udtænke en simpel skabelon, der indeholder kommentar fra supportoperatøren, den samlede tid brugt på billetten og firmaets signatur for brugeren.

Sådan ser skabelonen ud.

Sådan skriver operatøren kommentarbilletopdateringen.

Og dette vil være den sendte e-mail i henhold til skabelonen.

Bemærk: Når du bruger e-mail-skabeloner sammen med speciel overskrift og footing af e-mails på et bestemt projekt (kapitel 4.3.), Pakker projektets header og sidefod hele e-mailen, der sendes til klienten, ikke kun e-mail-skabelonen eller bare den del, der blev tilføjet af sidste kommentar.

6.2 Standard e-mail-skabelon

Det er muligt at vælge en HelpDesk e-mail skabelon som Standard. Det betyder, at når du sender en kommentar til en kunde, er der større chance for, at en skabelon er valgt på forhånd (hvilket efterlader mindre manuelt arbejde for supportoperatøren).

Opførslen er som følger:

Forudsætninger

• en e-mail-skabelon kan indstilles som standard
• hver e-mail-skabelon skal have en tilknyttet postkasse
• du kan have flere postkasser i dit system
• e-mail-skabelon kan være (men det er ikke påkrævet) forbundet til en bestemt status

situationer

• en billet oprettes manuelt (ikke via e-mail) - skabelon fra a er forvalgt i henhold til status; Hvis den ikke findes, er standardskabelonen forvalgt
• en billet oprettes fra en anden postkasse end den, som standard-e-mail-skabelonen bruges med – skabelon med denne postkasse er forudvalgt baseret på status (samme som i øjeblikket) => ingen skabelon forvalges automatisk, hvis der bruges status, som der ikke er tildelt nogen skabelon til
• en billet oprettes fra den postkasse, som standardskabelonen bruges med – skabelonen er forudvalgt baseret på status – hvis en sådan skabelon ikke findes, er standardskabelonen forudvalgt

Skjul SLA-data

Oplysninger om SLA-respons og løsningstid på opgavedetaljer kan skjules for valgte brugertyper (Administration >> Brugertyper >> Rediger).

SLA kan også skjules for bestemte brugere (Administration >> Brugere >> Rediger).

En bruger vil ikke se SLA'erne, hvis mindst en af ​​indstillingerne vedrørende deres bruger eller brugertype er aktiveret.

Sidehoved og sidefod på HelpDesk-e-mails

Globalt indstillet sidehoved og sidefod af e-mail-meddelelser (Administration >> Indstillinger >> E-mail-meddelelser) vil ikke længere være en del af e-mails sendt fra HelpDesk.

For at tilføje sidehoved og sidefod til HelpDesk-e-mails, skal du gå til HelpDesk-indstillinger for et specifikt projekt (Projekt >> Indstillinger >> HelpDesk).

Bekræft databasekonfiguration

Opgradering af test afslørede en inkompatibilitet i to konfigurationer, der tidligere samarbejdede korrekt.

Sørg for, at både databaseserver og config / database.yml har det samme (anbefalede) utf8mb4-sæt.

1) etc / my.cnf

character_set_server = utf8mb4
collation_server = utf8mb4_unicode_ci

2) config / database.yml

produktion:
  adapter: mysql2
  database: let
  vært: 127.0.0.1
  brugernavn: let
  adgangskode: "EASY_STRONG_PASSWORD"
  kodning: utf8mb4

Hvis disse ikke er på linje, kan du ikke bruge noget autofuldførende felt, fx Spring til projekt, valg af modtager, filtre osv.

Endelig skal du køre denne kommando for at indstille alle tabeller kodning korrekt.

til DB i YOUR_DB_NAME; gøre
  til TABEL i `mysql -e" brug $ {DB}; vis tabeller; " - batch - skibskolonne-navne | xargs`; gøre
    ekko "Konvertering $ {DB}. $ {TABLE}"
    mysql -e "ændre tabel $ {DB}. $ {TABLE} KONVERTER TIL tegnsæt utf8mb4 sortere utf8mb4_unicode_ci;"
  færdig
færdig

I stedet for YOUR_DB_NAME indtast navnet på din database.

Bemærk: Korrekt databasekonfiguration er et generelt krav til fejlfri drift af ethvert webapplikation. Det er ikke kun et specifikt krav til denne nye version af Easy Redmine.

Brugerdefineret design (ingen CSS)

I tilfælde af at du havde brugerdefineret branding (logo, farver, baggrund) og efter opgraderingen gik det i stykker – manglede alle stilarter, siden ser ødelagt ud, du kan nemt rette det.

Gå til side / easy_theme_desings >> find dit design >> kompilér >> indlæs igen. Det reparerer designet og indlæser typografierne.

 

7 Globale indstillinger

Nu hvor vi har gennemgået hele anvendeligheden, kan vi afslutte resten af ​​de indstillinger, der er tilbage til at blive forklaret.

Indstilling af noter:

• Afsender – hvilken e-mail er angivet som FRA på billetsvar til klient (i relation til kapitel 5.1.3.)
  • Aktuel logget bruger – bruger, der opdaterer billetten
  • Standard fra mail notifikation – email som bruges til at sende standard notifikationer fra systemet til brugere. Sat i Adminsitration >> indstillinger >> e-mail-meddelelser
  • Postkasseadresse – e-mail, som modtog den originale mail fra klienten
  • Denne indstilling er løst bundet til det sidste afkrydsningsfelt Tillad brugerdefineret afsender – hvis det er aktiveret, kan du indstille en brugerdefineret e-mail som afsender i projektets HelpDesk-indstillinger. Hvis et projekt har en e-mail udfyldt i indstillingen, vil den tilsidesætte indstillingen afsender
• Aktiver opdatering af opgaveattributter – hvis aktiveret, er det muligt at ændre visse attributter på billetten via e-mail. For eksempel ved at skrive prioritet: Høj i postorganet, ville du ændre prioriteten i overensstemmelse hermed. Dette er en temmelig avanceret funktion, og det anbefales ikke at bruge med klienter
• Accepter autogenererede mails – for eksempel nyhedsbreve
• Ignorer CC af modtagne e-mails – hvis aktiveret, behandles e-mails i CC ikke og bruges i feltet "email til"af billetten (kapitel 5.1.3. note om mailmodtager)
• Skift status efter klientsvar på – hver gang en klient skriver et svar, som opdaterer billetten, ændres status tilsvarende. Dette er især nyttigt, når billetter sættes til en lukket status efter et svar er sendt af operatøren. Medmindre klienten svarer tilbage med nogle yderligere spørgsmål, forbliver billetten lukket og skjult fra de aktive lister. Når klienten svarer, vil billetten blive genåbnet og tilbage til aktiv kø af åbne billetter
• Suspend SLA for billet, når status er – disse er statusser, når SLA-deadline ikke er bestemt, fordi billetten venter på input fra klienten, uden hvilken operatøren ikke har nogen chance for at yde support
• Tæl SLA for billet, når status er – når SLA normalt måles. Med disse funktioner kan du fint indstille billetcyklussen. For eksempel beder operatøren klienten om mere information, sætter status til pasive og SLA er sat på pause. Efter klientens svar ændres status til høring og SLA genberegnes efter den resterende tid til SLA-fristen, da billetten blev besvaret

I version 12 modtog Helpdesk en anden interessant metrik - Billetter løses af support. Du vil være i stand til at rapportere det samlede antal eller forholdet af billetter, der aldrig har forladt supportteamet.

Sådan fungerer det

1. Først skal du definere, hvilke brugere der er medlemmer af support i Help desk >> Helpdesk indstillinger - Løsning af support indstillinger
   
   
   
2. Indstillinger for underopgaver/relaterede opgaver vil afgøre, om billetter, der er løst af support, kan eller ikke kan indeholde underopgaver eller relaterede opgaver
3. Nu anbefaler vi at trykke på knappen i helpdesk-menuen - Genberegn
   
   Dette vil evaluere billetter fra de sidste 90 dage
4. Til sidst skal du gå til opgavelisten og finde filteret Løsning af support
   
   

Dette filter viser billetter, der kun blev tildelt medlemmer af supporten (i henhold til indstillingen i punkt 1). Baseret på indstillinger på punkt 2, kan billetter, der indeholder underopgaver eller relaterede opgaver, muligvis tælles som løst af support.

 

8 Filter "Har brug for reaktion"

"Behov for reaktion" er en egenskab ved HelpDesk-billetter og CRM-sager. Som standard er denne attribut indstillet til "Nej". Det ændres til "Ja", når en billet / sag tildeles en person, der svarer på den ved at sende en e-mail-besked i stedet for at tildele det tilbage til afsenderen i Klientzone eller Easy Redmine. I et sådant tilfælde forbliver modtageren af ​​billetten / sagen uændret, og derfor vil den tilsigtede modtager muligvis ikke bemærke, at opdateringen er foretaget. For at forhindre dette skal modtageren regelmæssigt tjekke alle elementer med "Behov for reaktion" -attribut indstillet til "Ja", så han får let at vide, at der er noget nyt, han skal kontrollere eller svare, selv det ikke er tildelt ham. Eller du kan bruge det, når du har brug for det for at "markere" en kundebillet, du allerede har svaret, men der er stadig noget arbejde med det og du skal informere kunden senere igen. Ved brug af "Opgaver fra filter"-modul, kan du blot oprette en boks på din hjemmeside, CRM-oversigt eller HelpDesk-oversigt som nedenstående.

 

9 HelpDesk-brugere (fra version 11+)

Blandt de største tilføjelser til HelpDesk i de senere år er såkaldte HelpDesk-brugere. Deres formål er at forenkle administrationen af ​​klientadgang til din Easy Redmine. Det gør det også meget nemmere for kunderne selv at indsende billetter og kommunikere med dine operatører direkte i ansøgningen.

9.1 Forudsætninger

Administration af HelpDesk-brugere er under tilladelser Se/Administrer HelpDesk-brugere under HelpDesk-sektionen i Administration >> Roller og tilladelser.

En anden indstilling, du skal kontrollere, før du begynder at oprette HelpDesk-brugere, er Administration >> Sidetilpasning >> HelpDesk-brugere >> Skabelonoversigt. Der bør være en eksisterende sideskabelon i en grundlæggende "starter"-konfiguration. Det er vigtigt, at der er en skabelon, der er sat som standard – denne skabelon vil automatisk blive anvendt på nye HelpDesk-brugere. Ellers ville dine HelpDesk-brugere have en tom side, efter de er logget ind.

HelpDesk-brugersiden indeholder 3 typer moduler:

• Ny billetformular - Den har ingen indstillinger, bare placer den for den største bekvemmelighed for dine kunder.
• HelpDesk-billetter – liste over billetter oprettet af HelpDesk-brugeren. Hver bruger kan kun se billetter, som de selv har oprettet. Dette modul kan konfigureres, såsom alle andre "liste"-moduler i applikationen. Den indeholder felter, der er synlige for HelpDesk-brugere i billetter. Hvis du har til hensigt at vise både åbne og lukkede billetter til HelpDesk-brugerne, anbefaler vi at vise dem i separate moduler.
• Opslagstavle - bare hvis du vil dele nogle brugerdefinerede oplysninger med kunderne.

9.2 HelpDesk-brugerstyring

Listen over HelpDesk-brugere er tilgængelig som et separat element i kontrolknapperne på HelpDesk-dashboardet.

Alle attributter er nødvendige:

• Fornavn
• Efternavn
• E-mail = Login
• Sprog
• Projekt – dette er projektet, hvor billetter fra denne bruger vil blive oprettet. Her kan kun vælges åbne projekter, der er knyttet til HelpDesk.
• Adgangskode – under brugeroprettelse skal du indtaste en adgangskode med mulighed for at generere adgangskodetoken, så brugeren selv kan indstille sin adgangskode via link i en e-mail. Under brugerredigering er en adgangskodeændring naturligvis ikke nødvendig.

Yderligere tilladelser:

Hver bruger kan få yderligere tilladelser til at se og administrere alle opgaver

Se alle opgaver = Tillader helpdesk-brugeren at se alle oprettede billetter under det samme projekt

Håndtere alle opgaver = Tillader helpdesk-brugeren at redigere specifikke felter fra allerede oprettede billetter (Titel, Beskrivelse og også tilføje en ny vedhæftet fil, men ikke redigere den gamle).

Brug sag

En kunde har et særligt projekt for deres billetter i din helpdesk. Der er flere brugere, der logger ind på helpdesk-portalen og indsender billetter på vegne af denne klient. En af disse brugere skal se alle de indsendte billetter, fordi hans rolle kræver at evaluere den service, du leverer.

9.2.1 CSV-import

Fra version 11plus.2.0 er det muligt at importere helpdesk-brugere via CSV. Kontakt venligst din konsulent om denne mulighed.

9.3 Log ind som HelpDesk-bruger

HelpDesk-brugere logger ind via et andet indgangspunkt end almindelige brugere. På login-skærmen under login-knappen kan du finde en kontakt. Brug URL for at dirigere dine kunder til HelpDesk-login /helpdesk/login. Som nævnt ovenfor bruges e -mail som login navn.

VIGTIGT: HelpDesk-brugere er teknisk uafhængige af almindelige brugere. Du kan bruge den samme e-mail til én almindelig bruger og én HelpDesk-bruger.
Selvom praksis antyder, at dette ikke burde være tilfældet. Du opretter enten en HelpDesk-brugerkonto, eller du beslutter dig for, at brugeren har brug for en fuld konto. Begge typer konti for én person bør kun bruges til testformål.

Efter login består selve portalen af ​​hjemmesiden, som er konfigureret af en admin, men som ikke kan konfigureres af HelpDesk-brugeren selv. I øverste højre hjørne kan profilen tilgås, inklusive redigeringstilstand. Ved siden af ​​den, log ud-knappen. Ved at klikke på en eksisterende billet eller oprette en ny billet, vil brugeren blive omdirigeret til billetdetaljen, hvor de kan tilføje kommentarer eller vedhæftede filer. For at vende tilbage til hjemmesiden skal du blot klikke på logoet i øverste venstre hjørne.

HelpDesk-brugeren har ingen roller og tilladelsesindstillinger, og du kan ikke give dem yderligere adgang til bestemte områder. Listen ovenfor er alt, hvad de kan få adgang til. Du bør ikke sende dem nogen links til elementer i din ansøgning. Det ville kun føre til adgang nægtet besked.

9.3.1 LDAP-godkendelse for HelpDesk-brugere

Fra version 11plus.2.0 kan helpdesk-brugere godkendes via LDAP.

Konfigurationen er i Admin >> Plugins >> Helpdesk-brugere >> Rediger - Ny godkendelsestilstand.

Formularen er identisk med almindelig LDAP-konfiguration, den eneste forskel er, at den gælder for helpdesk-brugere => på side /helpdesk/login

9.4 Arbejde med billetter

Fra kundens perspektiv

HelpDesk-bruger opretter en billet via formularen Ny billet på deres hjemmeside. De eneste tilgængelige attributter er Emne, Beskrivelse og vedhæftede filer. Filosofien er, at kunder ikke skal bekymre sig om organisatoriske forhold, når de har brug for hjælp fra din kundepleje. De siger blot deres problem og forventer en løsning. Intet projektvalg, ingen kategorier, ingen brugerdefinerede felter, intet prioritetsvalg – alt dette er dit supportteams ansvar.

Billetten oprettes i et projekt, som sættes direkte på HelpDesk-brugeren. Mark E-mail til i billetten udfyldes via email fra HelpDesk-brugeren. Denne bruger vil også blive indstillet som HelpDesk forfatter af billetten, som er en skjult attribut (ikke relateret til Forfatter, som er en generisk egenskab for alle opgaver i Easy Project). Dette sikrer, at de altid vil se billetten, selvom du flytter den til

Hjørnesituationer

• Situationen, når en opgaveansvarlig ikke er medlem af projektet, kan opstå i følgende tilfælde:
  • modtageren blev fjernet fra projektet, men opgaverne blev stadig tildelt ham,
  • en automatisk billetopdateringsproces indstilles i HelpDesk-modulet på en sådan måde, at nogle billetter automatisk tildeles et tidligere projektmedlem.
• Oplysninger om SLA Response vises kun i opgavedetaljer, når opgaven er i standardstatus, som er defineret på en respektive tracker.
• Vi anbefaler kraftigt, at du ikke ændrer en billets prioritet, når billetten har suspenderet SLA, da en sådan handling vil påvirke den korrekte beregning af SLA på den billet negativt.