HelpDesk

Terminologi
Bestem strukturen til HelpDesk-prosjekter
Koble til postkasse til Easy Project
Slik konfigurerer du prosjektkonfigurasjon
Hvordan sette opp prosjektkonfigurasjon – detaljer
Hvordan jobbe med billettbehandling
Slik konfigurerer du e-postmaler
Slik konfigurerer du globale innstillinger
Filter "Trenger reaksjon"
HelpDesk-brukere
Hjørnesituasjoner

Disse instruksjonene vil gå gjennom alle trinnene for å konfigurere HelpDesk fra brukergrensesnittet. Fra tilkobling av postkasser til Easy Project, gjennom prosjektinnstillinger, til finjustering av dashbordene. Dette er ikke en teknisk manual for å konfigurere cron (eller planlagte oppgaver på serversiden). Cron må allerede være konfigurert for at HelpDesk skal fungere.

 

0 Terminologi

La oss først starte med en ordliste med brukte vilkår i den følgende håndboken.

postboks - en e-postadresse koblet til Easy Project, hvorfra mottatte e-poster behandles til billetter i respektive HelpDesk-prosjekter
Billett - oppgave opprettet fra en mottatt e-post i en postboks, eller en oppgave internt opprettet av klienter i et HelpDesk-prosjekt
HelpDesk-prosjekt – et prosjekt knyttet til HelpDesk, hvor billetter kan opprettes
Domene - Den andre delen av en e-postadresse. For eksempel fra e-post worker.Joe@client.com domene er bare client.com
Nøkkelord – ord eller en streng av ord som finnes i postfag
SLA - service nivå aggreement. I forenklet mening brukt i Easy Project, kontraktstid for å reagere av selskap på billetter sendt av klient. Beregnet i timer
Original e-post – E-post sendt til en HelpDesk-postkasse som billetten ble opprettet fra
operatør - Disse vilkårene skal brukes til støttearbeideren, som jobber med billettene

 

1 Bestem strukturen til HelpDesk-prosjekter

Avhengig av om du vil ha et enkelt prosjekt for alle billetter eller differensiere HelpDesk-postkasser, eller til og med ha spesielle prosjekter for forskjellige kunder, må du bestemme strukturen på prosjektene før noen konfigurasjon starter. Denne avgjørelsen vil påvirke noen ytterligere trinn oppført i denne håndboken.

Her er mulighetene:

1.1 Enkeltprosjekt for alle billetter

Hvis du bare skal ha ett prosjekt, som samler e-post fra en enkelt postkasse, er det ingen beslutning å ta >> alle e-poster som sendes til postkassen, oppretter billetter i samme prosjekt.

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

Det spiller ingen rolle hvilket nivå dette prosjektet er, i utgangspunktet lever det sitt eget liv innenfor hvilken som helst del av prosjektstrukturen din. Men hvis du planlegger å starte med et enkelt prosjekt og senere fortsette å utvide HelpDesk, bør du se alternativene nedenfor.

1.2 Én postboks, flere HelpDesk-prosjekter

Eksempel: Du bruker postkassen support@mycompany.com. Alle mottatte e-poster går inn i et generelt prosjekt. Men du har en klient som har et spesielt prosjekt og spesielle betingelser> e-post fra domene client.com behandles i spesialprosjektet.

Selvfølgelig kan du få flere kunder skilt på denne måten. I dette tilfellet kan prosjektstrukturen se slik ut:

Et annet alternativ er å ha Standard HelpDesk-prosjektet på første nivå og spesialprosjektene under.

En annen måte, som noen ganger kan bli brukt, er en struktur:

> Klient1
>> Prosjekt for handel
>> Prosjekt for implementering
>>Prosjekt for HelpDesk

> Klient2
>> Prosjekt for handel
>> Prosjekt for implementering
>>Prosjekt for HelpDesk

Dette anbefales imidlertid ikke hvis du planlegger å samle billetter fra ulike problemer til noen aggregerte lister, statistikker eller oppsummeringer.

1.3 Flere postkasser, ingen spesielle klientprosjekter

Eksempel: Du bruker postkasser support@mycompany.com, info@mycompany.com, it@mycompany.com og e-postmeldinger er bare sortert i henhold til postkassen, ikke ifølge avsenderen.

I så fall kan du få 3-prosjekter på samme nivå og muligens under et hovedprosjekt som dekker dem alle.

Disse prosjektene kan være helt uten tilknytning og falle til separate deler av organisasjonen, de kan være i forskjellige prosjekttrær (under forskjellige toppprosjekter).

1.4 Flere postkasser, med spesielle klientprosjekter

Nåværende Easy Project HelpDesk-funksjonalitet gjør det mulig å separere klienter utelukkende etter avsender og ikke ved en kombinasjon av avsender og mottakerpostkasse.

Eksempel: Du bruker postkasser support@mycompany.com, info@mycompany.com, it@mycompany.com. Du har en spesiell klient som sender støtteforespørsler fra domain client.com

Den anbefalte strukturen er:

Når vi kommer tilbake til prosjektstrukturen generelt, er det noen ytterligere vurderinger som må gjøres. Hvis du har som mål å integrere HelpDesk-behandling med en annen avdeling i organisasjonen din (for eksempel utvikling), kan det være lurt å vurdere å sette HelpDesk-prosjekter litt dypere inn i prosjektstrukturen.

Korrekt prosjektstruktur vil gjøre det mulig for deg å generere ulike rapporter, oppføringer, statistikk over flere faser av virksomheten din.

 

2 Koble postkasse til Easy Project

Nå kan vi starte med selve oppsettet av HelpDesk-komponenter. For å ha Easy Project-behandle postbokser, må de kobles til på følgende måte.

2.1 Administrasjon >> HelpDesk >> Alle postbokser >> Legg til postboks

2.2 Skriv inn gyldig legitimasjon for postkassen din – klikk Test for å sikre at Easy Project kan nå postkassen

Innstilling av notater:

• Aktiv - postboksen skannes regelmessig av Easy Project for nye uleste meldinger. Hvis deaktivert, sjekker ikke Easy Project postboksen. Men du kan beholde postboksen i Easy Project for mulig fremtidig bruk.
• Bruk en annen avsender - når bruker på e-postserveren ikke er det samme som postkasse (for eksempel HelpDesk-postbruker). Skriv inn den gyldige maliboxen her, som er representert av brukeren.
• SSL - hvis du bruker et SSL -sertifikat på din mailserver
• Aktiver OAuth – OAuth 2.0-protokollen brukes av hundrevis av kjente tjenester som en alternativ autentiseringsmetode. Når det gjelder HelpDesks postkasse, kan den brukes til å verifisere avsenderens legitimasjon ved å bruke en ekstern applikasjon, som for øyeblikket støttes er Googles arbeidsområde (tidligere G Suite) og Microsoft Exchange kontoer. Du må lese OAuth 2.0 -dokumentasjonen for den andre applikasjonen for å vite hva du skal skrive inn i hvert felt. Selvfølgelig må du ha administratortilgang til den andre applikasjonen for å finne nødvendig informasjon, for eksempel nettstedets URL, klient -ID, klienthemmelighet, autorisere URL, token -URL, omfang, etc.
  
• Folder - hvis du vil at Easy Project bare skal sjekke bestemte mapper for uleste e -poster.
• I suksess flytte til – hvis en e-post behandles riktig av Easy Project (billett er opprettet), vil den bli flyttet dit
• I feil flytte til – hvis en e-post blir behandlet feil (billett er ikke opprettet), vil den bli flyttet dit

Når du har testet tilkoblingen, klikker du på Legg til.

2.2.1 Hvor finner jeg OAuth 2.0 -legitimasjon for Microsoft- og Google -kontoer

For å koble Easy Project til en Google Workspace -konto ved hjelp av OAuth 2.0 -protokollen, må du opprette en konto på Google Cloud Platform, skaff deg de nødvendige legitimasjonene som er oppgitt der, og kopier dem til postkasseinnstillingene i applikasjonen vår. Noen nyttige instruksjoner kan bli funnet her..

For å koble Easy Project til en Microsoft Exchange -konto ved hjelp av OAuth 2.0 -protokollen, må du opprette en konto på Microsoft Azure portal, skaff deg de nødvendige legitimasjonene som er oppgitt der, og kopier dem til postkasseinnstillingene i programmet vårt. Noen nyttige instruksjoner kan bli funnet her..

Tilgangstokens har en begrenset levetid (maksimalt 6 måneder), du kan ikke opprette ubegrensede. Etter denne tiden vil postkassen slutte å fungere og et nytt token må genereres og legges inn på nytt i applikasjonen.

En OAuth 2.0-tilgangs-URL for skjemaet "/organizations/oauth2/v2.0/authorize" er bare gyldig hvis tilgang til applikasjonen er aktivert i organisasjonen. Ellers må tilgangs-URLen ha formen "/[TENANT_ID]/organizations/oauth2/v2.0/authorize". De riktige innstillingene finner du i Endpoints-delen.

Når tofaktorautentisering (2FA) er satt opp i Microsoft Azure, må alle tilkoblede postbokser oppdateres.

2.2.1.1 Feil "Bruker er autentisert, men ikke tilkoblet"

Dette er fordi den valgte Azure-brukeren som postkassen er registrert gjennom, ikke har tilgang til postkassen. I dette tilfellet er det ikke nok om brukeren er administrator da han må ha lisens for å bruke Office 365. Hvis brukeren har delegert tillatelse (han har ikke lov til å legge til tilgang til postkassen siden det krever godkjenning av f.eks. en administrator ), må han få riktig omfangstillatelse i Azure og deaktivere dette alternativet samtidig.

Løsning:

• Brukeren må enten være den direkte eieren av postkassen han har tilgang til (og dermed ha de nødvendige tillatelsene til å gjøre det).
• Alternativt kan han være en annen (lisensiert) bruker som har fått tilgang til den postkassen.

Et annet mulig problem er at kontoen er opprettet som POP3 i stedet for IMAP. POP3 støtter ikke OAUTH i systemet.

Løsning:

• Sørg for at kontoen er satt som IMAP i både azurblå og i Easy Project.

2.2.1.2 Feil: Microsoft Help Desk kobler seg til, men slutter å fungere etter en stund

Du glemte å aktivere rettigheten for frakoblet tilgang.

2.2.1.3 Bruksområde: Mange postbokser, en super Help Desk-bruker

Hvis du har flere Help Desk-postbokser satt opp i Microsoft Exchange og du ønsker å delegere tilgangsrettigheter til alle disse postboksene til en enkelt bruker, kan du gjøre det via Microsoft 365 administrasjonssenter » Administrasjonssentre » Utveksling.

Du vil bli omdirigert til Exchange-administrasjonssenterdelen. Klikk her på fanen Mottakere » Postbokser og velg postkassen du vil delegere tilgangsrettighetene til. Et høyre popup-sidefelt åpnes og klikker på Delegering.

Legg merke til Les og administrer (full tilgang)-skiltet nedenfor med en Rediger-knapp å klikke på.

Du kan deretter søke etter og legge til brukere som blir medlemmer av denne postkassen med samme rettigheter som postkasseeieren.

Brukeren du velger må ha Help Desk-administratorrettigheter på Easy Project-siden.

2.2.2 Aktivere OAuth 2.0-autentisering med Azure Active Directory

Når du bruker OAuth 2.0-autentisering, får du tilgang til en webtjeneste fra en klientapplikasjon. Måten du gjør dette på avhenger av tilskuddet du bruker. I denne opplæringen, vil du lære hvordan du konfigurerer tildelingstypen for klientlegitimasjon for applikasjoner i Azure Active Directory.

2.3 Konfigurer frekvensen for postboksskanning

Høyreklikk på postkassen og velg Innstillinger

Nå er du tilbake til postboksinnstillingene, men med en ekstra innstilling. Som standard er den satt til hvert 5-minutt. Men det anbefales vanligvis å ha denne innstillingen rundt hvert 10-minutt. Hvis du har mange postkasser koblet til Easy Project, kan denne automatiske skanneoppgaven ta lengre tid og overbelaste serveren din med for hyppige skanninger, noe som vil bremse hele applikasjonen.

Knappnotater:

• Utfør – start postboksskanningen manuelt
• Historikk – se tidligere postboksskanning
• Slett – fjern postkasse fra Easy Project skannede postbokser
• Deaktiver – deaktiver automatisk postboksskanning

2.4 Automatisk deaktivering

Å behandle postboks med jevne mellomrom krever serverressurser, spesielt hvis du har flere postbokser. Av denne grunn har vi implementert en mekanisme som automatisk deaktiverer behandling av postkasse etter 3 ganger mislyktes den i å autentisere og laste ned e-poster. Deaktiver betyr at feltet Aktiv blir slått av. Du vil fortsatt kunne bekrefte innstillingene, teste og aktivere.

Hvorfor? For å lagre ressursene dine. Hvorfor skal serveren fortsette å pinge en ufunksjonell postboks?

 

3 Prosjektkonfigurasjon

Mailbox er koblet til og skannet av Easy Project, men så langt har vi ikke satt hvor billettene skal opprettes. Før et prosjekt kobles til HelpDesk, kan ikke billetter opprettes fordi, generelt sett, krever hver oppgave et prosjekt.

Denne delen skal deles i forskjellige scenarier, i henhold til målet for hvert prosjekt.

3.1 Standardprosjekt for postkasse

I eksemplene på det siste kapitlet vil dette være prosjektene Standard HelpDesk, INFO – generelt, IT – generelt, SUPPORT – generelt, dvs. ikke begrenset til et bestemt domene av avsenderen.

1. Klikk på "Legg til HelpDesk"alternativ på en prosjektoversiktsside for det valgte prosjektet.
   
2. Velg postkassen der prosjektet vil være standard
3. Rull ned og Spar

En fullstendig forklaring av alle HelpDesk-prosjektinnstillingene vil følge videre i dette kapittelet.

3.2 Spesielt byggherreprosjekt

Fra eksemplene i kapittel 1 vil disse være prosjektene: Bohemia Sun, Trains Francais, Client 123, Client ABC, Client XYZ, Client 1>>Project for HelpDesk, Client 2>>Project for HelpDesk

1. Velg prosjekt
2. Fyll ut feltene uthevet nedenfor. Innstilling av notater er under skjermbildet
3. Rull ned og Spar.

Innstilling av notater:

• Standard for postkasse - IKKE velg en postkasse hvis du vil angi dette prosjektet som et spesielt klientprosjekt
• E-poster, domener, nøkkelord behandlet i dette prosjektet – alle innstillingene i denne delen er med OR operatør, som betyr at Hvis minst én betingelse er oppfylt, opprettes billett i dette prosjektet
• Fyll e-post til fra - Når dette alternativet er valgt, vil forfatterens e-post automatisk fylles ut ny billett. Dette alternativet er nyttig når du har prosjekter der billetter opprettes av ekte brukere, i stedet for å behandle innkommende e-poster.
• Nøkkelord – I dette eksemplet, hvis en e-post mottas i NOEN HelpDesk-postboksen inneholder hele strengen Jeg er fra firmaets klient ABC, billett vil bli sortert i dette prosjektet. Ikke bruk samme søkeordstreng for flere prosjekter, bare den første posten i databasen med strengen vil bruke den angitte søkeordstrengen
• E-post eller domene – innkommende e-poster skannes for disse verdiene i FRA-feltet i e-posten. I dette eksemplet kan avsenderen være hvem som helst med postboks som slutter på clientABC.com, eller det kan også være en spesifikk person med en annen e-postadresse, men vi vil at billettene hans skal sorteres i dette prosjektet

Fullstendig forklaring av alle HelpDesk-prosjektinnstillinger vil følge videre i neste kapittel.

VIKTIG: Det er ikke den beste praksisen å ha ett prosjekt satt både som Standard for postkasse OG spesifisert for en bestemt post eller et domene. Enhver avsender vil få sine billetter opprettet i dette prosjektet, så du trenger ikke å spesifisere dem. Denne typen innstilling kan forårsake forvirring.

3.2.1 Closing og arkivering av spesielle klientprosjekter

Når et slikt prosjekt er stengt (som faktisk blir skrivebeskyttet), vil det ikke være mulig å opprette billetter innenfor. Derfor vil dette prosjektet slutte å være et spesielt klientprosjekt, og e-poster som kommer fra domener angitt i HelpDesk-innstillingene vil bli behandlet som ukjent og falle inn i et generelt HelpDesk-prosjekt.

Det samme gjelder arkiverte prosjekter.

 

4 Prosjektkonfigurasjon – detaljer

Nå som vi differensierte typer prosjekter som kan brukes i HelpDesk, kan vi fortsette å forklare resten av prosjektinnstillingene. Når et prosjekt er koblet til HelpDesk, er det to måter å komme inn på prosjekt HelpDesk-konfigurasjonssiden.

• Administrasjon >> HelpDesk >> Alle HelpDesk-prosjekter >> Rediger
• Prosjektinnstillinger >> HelpDesk

4.1 Grunninnstillinger

Innstilling av notater:

• Oppgavetype – nye billetter i dette prosjektet vil bli opprettet med denne oppgavetypen
• Oppdragsgiver – nye billetter i dette prosjektet vil bli tildelt denne brukeren
• Medarbeider – nye billetter i dette prosjektet vil ha disse medarbeiderne (muligvalg mulig)
• Automatisk billettoppdatering – avhengig av arbeidsflyten din, kan det finnes noen billetter som er faktisk løst, og holdes åpne. For slike tilfeller kan du angi automatisk lukking i henhold til status og varighet av ikke-oppdatering. I tillegg til å stenge billetten, kan en oppfølgings-e-post fra mal sendes automatisk, for eksempel for å informere avsenderen om at billetten hans er stengt eller spørre ham om hans tilfredshet med billettløsningen.
• Kontraktsmessige timer månedlig – denne innstillingen skal kun brukes for spesielle klientprosjekter, der klienter har forhåndsbetalt et visst antall timer med støtte per måned
• Aggregerte timer – kontrakten med oppdragsgiver kan ha mulighet for å overføre ubrukte timer fra forrige måned til neste. Hvis klienten har 10 forhåndsbetalte timer, men bare brukte 7 av dem i løpet av mai, vil 3 timer bli overført til juni
• Gjenstående timer – hvor mye er igjen. Blyantknappen lar deg slette gjenværende timer manuelt – satt til 0
• Aggregert startdato – når den forhåndsbetalte perioden begynner; skal velges en dag som er felles for alle kalendermåneder, dvs. dag 1-28
• Aggregert periode – for hvilken tidsperiode er timene aggregert før de tilbakestilles til de opprinnelige kontraktsmessige timene. Hvis det fortsatt er 13 timer igjen innen utgangen av kvartalet (slutten av kvartalet bestemmes av aggregert startdato), vil de ikke bli overført til det nye kvartalet. Timene tilbakestilles til 10

Timene ved hånden er brukt tidsposter i prosjektet. Hvilke eksakte oppføringer vil bli forklart ytterligere i denne håndboken.

4.2 SLA

Dette er en viktig beregning for ethvert HelpDesk-prosjekt, men spesielt for spesielle klientprosjekter der brudd på SLA kan bli sanksjonert. Som nevnt før, kan billetter opprettes via e-post eller direkte fra systemet av klienter med spesielt begrenset tilgang til et HelpDesk-prosjekt. Begge tilfeller har en liten nyanse i SLA-innstillingen.

4.2.1 SLA for e-postgenererte billetter

Innstilling av notater:

• Navn – Tittel på SLA (for bedre SLA-administrasjon i HelpDesk-prosjektet)
• Søkeord - må fylles hvis SLA blir satt til e-post genererte billetter. I dette tilfellet er det et spesifikt søkeord, som hvis det finnes i emnet for e-posten, vil billetten bli gitt spesifikasjonene til SLA (timer, prioritet, oppgave type)
• Timer til svar – frist frem til hvilken første statusendring av billetten må finne sted. Statusendring indikerer at billetten er bekreftet og klienten har blitt informert om det
• Timer å løse – frist for å stenge billetten >> sette den i lukket status
• Prioritet – ny billett fra e-post som inneholder nøkkelordet vil ha denne prioritet
• Oppgavetype – ny billett fra e-post som inneholder nøkkelordet vil ha denne oppgavetypen. Dette er nyttig for eksempel hvis kunden har funnet en defekt i produktet og ønsker å rapportere det direkte som en defekt og ikke som en standard forespørsel om støtte. Oppdragsgiver ville derfor skrive med emne for eksempel Defekt - og billetten trenger ikke klassifiseres av HelpDesk-lederen.
• Tell SLA basert på arbeidstid – SLA-frister vil ikke bli satt for ikke-arbeidsdager eller timer på dagen. Noen SLA kan være begrenset bare til arbeidstid, men andre kan settes til 24/7
• SLA arbeidstid – tidsramme for SLA
• Arbeidsdager – arbeidskalender hvor helger, helligdager og andre arbeidsfrie dager registreres

4.2.2 Bestilling av SLAer

Med flere nivåer, nøkkelord og søkeordstrenger er det viktig å holde orden på riktig måte. Postemnene sjekkes for nøkkelord i henhold til rekkefølgen i HelpDesk-innstillingene.

Eksempel: Du har kontraktsdefinerte søkeord for "Kritisk" og "Kritisk feil", hver av dem har en annen SLA. Du må sørge for at de to fagene blir differensiert når e-postene behandles.

I dette tilfellet må du sette SLA "Critical bug" over "Critical". Mekanismen for behandling av mailsubject er enkel:

1. Søk etter "Kritisk feil" i postfaget
2. Hvis den ovennevnte strengen ikke er i emnet, søk etter den neste, i vårt tilfelle "Kritisk"
3. Hvis strengen ovenfor ikke er i emnet, fortsett å søke etter flere nøkkelord
4. Den siste SLA må være det generelle (for uspesifisert nivå) nøkkelord ved å bruke * -merket for alle fag

Hvis du setter "Kritisk" før "Kritisk feil", vil det bety at e-postmeldinger med "Kritisk feil" i emnet blir behandlet feil, fordi de vil falle inn under "Kritisk" SLA.

Generelt, jo mer spesifikk søkeordstreng, jo høyere bør posisjonen være.

SLA på en klientbillett er overtrådt. Hva gjør du for å sikre at du har fått dette under kontroll? I dette tilfellet, gå til prosjektinnstillinger >> HelpDesk en rull helt ned

4.2.3 Tilbakestille SLA for lukkede billetter

Du vil også merke en innstilling øverst i SLA-delen.

Når aktivert, vil billetter som en gang ble stengt og åpnes igjen av et annet svar fra klienten, ha SLA regnet som om de var nye – fra tidspunktet for klientens svar som gjenåpnet billetten.
Eksempel: Billett nr. 1234 var åpen mandag klokka 16:00. SLA er 48 timer => tid til å løse er til onsdag 16:00. Billetten ble stengt av en operatør tirsdag klokka 10. Klienten svarte igjen at han trenger mer informasjon tirsdag klokka 00:14. Billett nr. 00 har nå satt SLA til torsdag 1234:14.

Når den er deaktivert, vil SLA alltid telles fra den opprinnelige tiden da billetten ble opprettet.
Eksempel: I scenariet fra det første tilfellet. Etter klientens svar tirsdag kl. 14: 00, vil ikke SLA bli tilbakestilt og vil forbli onsdag 16: 00. Det samme gjør når klienten åpner billetten på torsdag igjen. Billetten skulle nå fremheves som forfallen.

Fra den siste merknaden er det tydelig at denne innstillingen bare skal deaktiveres på prosjekter, der billettene er enkle og løpende kan defineres strengt, så det er ingen grunn til å åpne billettene på nytt fra kundens side.

4.2.4 SLA for internt opprettede billetter

Som nevnt tidligere, kan det hende at billetter ikke opprettes bare via e-post. Easy Project har en avansert tilgangsnivåkontroll, som gjør det mulig å gi dine kunder direkte tilgang til systemet med begrensede tillatelser (for å opprette billetter, redigere billetter, lese nyheter, ...).

Billetter laget som standardoppgaver av påloggede brukere har en litt annen måte å bestemme SLA på. Fordi det ikke blir behandlet noen e-postmeldinger, kan du ikke bestemme SLA etter nøkkelord. La oss forklare på bildet nedenfor.

Når du oppretter SLA for internt opprettede billetter, må du la nøkkelordet stå tomt. SLA blir deretter bestemt av en kombinasjon av prioritet og sporer. Når du lagrer innstillingene, forsvinner nøkkelordet, noe som indikerer at denne SLA-en brukes til internt opprettede billetter. Hvis du lar Tracker være tom, vil bare nøkkelord bli vurdert.

Ved å konfigurere arbeidsflyten effektivt, kan du begrense klienter til kun å opprette billetter i visse oppgavetyper, selv om prosjektet inneholder flere av dem. Du kan for eksempel bare tillate klienter å bare bruke oppgavetypen HelpDesk Ticket og Bug, så du kan bare sette SLA for disse oppgavetypene. Alle andre oppgavetyper vil ikke kreve SLA-innstilling fordi de ikke vil bli sendt inn av klienter og derfor ikke anses som HelpDesk-billetter.

4.2.5 SLA-hendelser og rapporter

SLA-rapporter er basert på individuelle SLA-hendelser. Disse hendelsene kan sees for hver HelpDesk-billett, bare sjekk ut SLA Events i bunnmenyen til en HelpDesk-billett. Når en billett er besvart/løst, kan du sjekke ut SLA-hendelsen her, som blant annet forteller deg hvor lang tid (i timer) som faktisk hadde gått før det første svaret fant sted, og du kan direkte sammenligne verdien med SLA-svaroppfyllelse (dvs. tiden som kreves for det første svaret) og SLA-oppfyllelsen (dvs. tiden som kreves for billettoppløsningen) i henhold til SLA-innstillingene dine på det bestemte HelpDesk-prosjektet. I tillegg til det ser du umiddelbart hvem og når som svarte/løste billetten og hvilket prosjekt denne billetten tilhører. Tidsregistreringer vises med positivt eller negativt symbol (+/-), hhv. i grønn/rød farge for å markere hvorvidt SLA er kompilert eller ikke.

SLA-arrangement opprettes bare når en supportbillett faktisk blir svart på ved å sende en e-post til en kunde, ikke før. Å legge til en kommentar til en billett fører ikke til opprettelse av SLA-hendelser fordi det ikke er klart om en slik kommentar bare er en intern melding eller et svar på kundens forespørsel.

Når en supportbillett flyttes fra ett prosjekt til et annet, beregner ikke SLA-hendelsen på nytt. SLA av billetten forblir fra det opprinnelige prosjektet, der en slik billett ble opprettet. SLA-beregning utløses bare av endring av oppgavetype eller prioritet.

For å se listen (en oversikt) over alle SLA-hendelser, gå til /easy_sla_events eller klikk på SLA-rapporter-menyelementet i sidefeltmenyen til hoved-helpdesk-dashbordet (/easy_helpdesk).

SLA-hendelser kan enkelt filtreres i henhold til forskjellige SLA, tilpassede felt eller andre kriterier.

Alle SLA-hendelser oppsummert i overordnet SLA-statistikk kan finnes på SLA-rapporter. Som standard er dette dashbordet tilgjengelig i den øverste menyen i HelpDesk-oversikten. Ved å bruke dashbordet ser du umiddelbart den totale prosentandelen av mislykket SLA-svar, mislykket SLA-løsning og gjennomsnittlig førstegangsrespons. Siden dashbordet er en standard personlig tilpasset side som mange andre, kan du tilpasse alle modulene som vises i dashbordet for å gjøre dem bedre tilpasset dine behov.

4.2.6 Billett SLA-rapporter

I tillegg til ovennevnte er det også mulig å lage SLA-rapporter over billetter.

Fra versjon 11plus.2.0 har billetter to nye felt:

• Første SLA-svar oppfyllelse - hentet fra det første SLA-arrangementet på billetten
• Siste oppfyllelse av SLA-løsning - hentet fra siste SLA-arrangement på billetten

Hvordan fungerer det

Billett opprettes -> Helpdesk-operatør svarer-> SLA-hendelse opprettes -> verdier fra denne SLA-hendelsen kopieres inn i de nevnte attributtene til billetten -> klientsvar tilbake -> operatørsvar til klient -> ny SLA-hendelse opprettes - > verdien av SLA revolve fultilment den kopierte inn i billettattributtet.

Hvor er verdien

Siden selve billetten inneholder de mest avgjørende SLA-rapporteringsdataene, kan du lage rapporter om SLA-tilfredshet rett over billettene.
Noen eksempler:

• Suksessrate for billettoppløsning
• Linjediagram over absolutt antall billetter med mislykket SLA-svar/løsning i tid

4.3 Egendefinert topp- og bunntekst

Denne innstillingen gjelder HelpDesk e-postkommunikasjon, dvs. kommunikasjon i e-postgenererte billetter. Du kan tilpasse e-poster fra forskjellige HelpDesk-prosjekter, enten det er for bedriftsidentitetsbruk, for vilkårsspesifikasjoner eller til og med konfidensialitetsfraskrivelser.

4.4 varsler

For å forhindre brudd på SLA, er det muligheten for å bruke automatiserte varsler, som varsler bekymret personell om truende problemer i form av forsinkede billetter.

En annen type varsler klokker tilbrakte tid i prosjekter, der klienter har forhåndsbetalt et bestemt antall timer med støtte (som forklart i kapittel 4.1).

Innstilling av notater:

• Overvåk forfallsdato for støttebilletter – for å være mer presis Tidsfrist i følge SLA. Hvis aktivert, genereres varsler når SLA-fristen nærmer seg. Ytterligere innstillinger forklart nedenfor
• Overvåk støttebilletter brukt til rett tid – se på brukt tid på prosjekter med spesifiserte forhåndsbetalte månedlige timer
• Liste over varsler som må ha et mottakersett – dette er forhåndskonfigurerte varsler, som bare trenger å angi en e-postadresse, hvor varslene skal sendes
• Liste over konfigurerte varsler – varsler uten manglende parameter
• Ved å klikke på hvert varsel vil du se de forhåndskonfigurerte parameterne med mulighet for å redigere dem
• Advarsel / varsling: alvorlighetsgraden av varselet
• Støttebilletter forfallstid - varsling klokker SLA løser frist (billettstenging)
• Støttebilletter timer til svar – svarfrist for varselklokker SLA (første endring av status)
• Støttebilletter forhåndsbetalte timer – varsling overvåker bruk av forhåndsbetalte månedlige timer på prosjektet

Timene som ble sett i det siste varselet er de som er logget på billetter, som er i oppgavetyper nevnt i prosjektets HelpDesk-innstillinger.

Eksempel: Standard oppgavetype for prosjektet er HelpDesk Ticket. Noen SLA er konfigurert for oppgavetypen Bug. Prosjektet inneholder andre oppgavetyper (Task, Feature development), som ikke brukes på billetter. I slike tilfeller er de forhåndsbetalte timene kun gyldige for HelpDesk Ticket og Bug. Brukt tid på andre oppgavetyper tas ikke i betraktning for dette varselet.

4.5 Lagre/slett

Oppdater – lagre endringer som er gjort i HelpDesk-innstillingene for prosjektet
Slett – fjern prosjektet fra HelpDesk. Dette betyr ikke sletting av prosjektet som helhet, det vil det bare fjerne tilkoblingen av prosjektet til HelpDesk.

5 Billettbehandling

Etter den enorme mengden innstillinger som er forklart til nå, er det på tide å se på noen praktiske implikasjoner, før vi kommer tilbake med et annet sett med innstillinger. Vi vil starte med en enkel brukssak for å demonstrere hvordan billettsettingen fungerer og hoppe over noen funksjoner. De vil bli forklart senere.

5.1 E-postgenererte billetter

For korrekt håndtering av billetter opprettet via e-post, må du sjekke at standardfeltene "epost til"Og"e-post cc"er aktive. Du kan sjekke det inn Mer » Administrasjon » Oppgavetyper » HelpDesk-billett » Standardfelt. Hvis disse standardfeltene mangler, må de ha blitt deaktivert av administratoren.

5.1.1 E-post behandles av Easy Project og billett opprettes i det bestemte prosjektet

Merknader:

• e-post til: Avsenderen av e-postskjemaet som billetten ble opprettet
• Spesifikasjon av postkassen, der oppgaven ble opprettet
• SLA-verdier – hvis de brytes, er de uthevet i rødt
• Parsert e-post – Dette er tekstinnholdet i e-posten. Bilder vises ikke direkte i denne visningen, på grunn av ytelsesoptimalisering (spesielt når billetten har mange svar og hver enkelt inneholder en signatur med firmalogo, vil billetten ta smertelig lang tid å laste på grunn av økende størrelse på hver av de neste svare)
• Full e-post tilgjengelig som vedlegg – hvis den originale e-posten inneholder bilder, kan du se den direkte i Easy Project.

5.1.2 Skriv et svar og oppdater billetten

For å møte SLA-responsen må vi endre status og svare på klienten for første gang. For de følgende eksemplene, hold et åpent sinn om billettkommunikasjonen, det er bare å demonstrere hvordan kommunikasjonen fungerer teknisk.

Lederen skrev et svar til kunden om å motta billetten, tilordnet den til en operatør og endret statusen. Svaret vil bli sendt til klienten (e-post til) når du merker av.

Send rask e-post til kunden fra mal

Du har to alternativer for å sende en e-post til klienten. Når du oppdaterer en HelpDesk-billett, er det et alternativ "Send rask e-post til kunde fra mal" som lar deg velge en e-postmal for svaret ditt for billettavsenderen. Når en mal er valgt, sendes e-posten umiddelbart og dermed er det ikke nødvendig med flere handlinger. Når ingen mal er valgt, har du fortsatt muligheten til å velge mal og bekrefte sending av e-post i neste trinn som vanlig (kryss av for "Send e-post til kunde (med forhåndsvisning) i bunnen og lagre). Formålet med dette funksjonen er hovedsakelig å spare tid når du sender e-post til kunder.

5.1.3 Send en oppdatering til ekstern e-post (e-post til)

Ved å trykke på Lagre, lagrer du oppdateringene som er gjort på billetten, og du kommer til dialog om å sende svaret til klienten.

Merknader:

• E-postmal – hvis du har konfigurert e-postmaler, kan du velge en. Eller en mal vil bli forhåndsinnstilt i henhold til status. Denne funksjonen vil bli forklart i flere kapitler
• E-postavsender – dette vil bli vist til klienten som FRA. Innstilling av befolkningen i dette feltet vil bli forklart i ytterligere kapitler
• E-postemne – tilpasset eller forhåndsinnstilt i henhold til e-postmalen. Som standard er den fylt ut av billettemnet
• E-postmottaker – avsender av den originale e-posten. Hvis det var andre mottakere av den opprinnelige e-posten i CC eller TO, vil de også bli lagt til i dette feltet.
• E-postsvar til – dette er alltid HelpDesk-postboksen som den opprinnelige e-posten ble sendt til
• E-postkopi – du kan legge til andre mottakere
• E-posttekst – hvis en mal ikke ble valgt, vil den bestå av den siste kommentaren på billetten og den originale e-postteksten. Innholdet er redigerbart.
• Vedlegg – du kan velge vedlegg å sende med e-posten. Det kan være noen nyere e-poster eller nye filer du lastet opp da du oppdaterte billetten
• Send e-post – e-post sendes til alle mottakere
• Ikke send e-post – du kommer tilbake til detaljene i billetten

Når vi ser tilbake på billettdetaljene, ser vi at SLA-svaret har forsvunnet, fordi det ble gjort.

5.1.4 Kunden svarer tilbake – hvordan e-postene er sammenkoblet med billett

Kunden har mottatt svaret og svarer tilbake. Svaret vil bli lagt til som en kommentar fra en anonym bruker (en bruker som ikke er registrert i systemet).

La oss forklare her hvordan fant kundens svar veien til riktig billett.

Da lederen i forrige trinn sendte e-post til klienten, inneholdt e-posten en skjult overskrift (som alle e-poster gjør) med ID-en til billetten. Ved å svare på e-posten ble denne overskriften også inneholdt i klientens svar, og derfor identifiserte HelpDesk den og la svaret til billetten med samme ID.

Her er alle måter mottatte e-postmeldinger er koblet til billetter i systemet.

1. Skjult overskrift av e-post, der oppgavens ID er lagret
2. Emne av e-posten, hvor en kombinasjon av "#" og oppgave-ID er søkt
3. Hvis dette ikke er funnet, søkte emnet for et nummer alene

Følgelig, selv om klienten skriver en ny e-post til en HelpDesk-postboks og legger til billettnummeret (oppgave-ID) i emnet, vil den fortsatt være sammenkoblet. Som i følgende eksempel.

Ny e-post til en HelpDesk-postboks:

Senere notat i billetten:

5.1.5 Siste svar – billetten stenges

Ett siste svar fra operatøren, med hvilken billetten er stengt. Etter at billetten er avsluttet, vil SLA for å forsvinne også forsvinne fra billettdetaljene.

Hvis klienten svarer igjen, vil billetten bli gjenåpnet til en definert status (denne innstillingen vil bli forklart ytterligere).

5.1.6 Billetteierfelt

Billetteierfeltet er et valgfritt standardfelt beregnet for bruk med HelpDesk-billetter. Med sin nedtrekksliste lar den deg velge én bruker av alle interne brukere som allerede er opprettet, og denne ene brukeren regnes som eieren av billetten. Feltet kan aktiveres eller deaktiveres for enhver oppgavetype der du måtte ha det (gå til Administrasjon » Oppgavetyper » HelpDesk-billett » kryss av i feltet og lagre). Som standard er billetteierfeltet deaktivert, så HelpDesk-ledere må gå til Administrasjon for å aktivere det for en bestemt oppgavetype. Basert på dette feltet på HelpDesk-billetter kan HelpDesk-ledere enkelt se hvor mange billetter som ble mottatt, stengt/løst eller oppdatert i henhold til billetteieren. Så dette kan betydelig forbedre/forenkle HelpDesk-innsikt (dashboard, statistikk) og rapporter for en definert tidsperiode. Arbeidsflytinnstillinger, så vel som handlingsknapper, kan brukes på billetteierfelt akkurat som alle andre standard eller egendefinerte felt.

5.1.7 E-post til, cc velg fra ulike datakilder

I felt Epost til og Epost cc lagt til muligheten til å søke etter e-post fra datakilder:

• Personlige kontakter (CRM)
  
• Interessenter
  
• Kontoer (CRM)
  
• HelpDesk-brukere (Helpdesk)
  

Denne funksjonen er deaktivert som standard. For å aktivere det, gå til Administrasjon >> Plugins >> Autofullfør e-postfelt - Rediger og aktiver funksjonen Autofullfør e-postfelt og nødvendige dataressurser.

Uten å aktivere noen av dataressursene, søker funksjonen naturlig gjennom brukere.

Hvordan fungerer det

Hvis aktivert, fungerer oppgavefeltene E-post til og cc som autofullføring.

5.2 Internt opprettede billetter

Hvis klienten sender inn billetter direkte i systemet ditt, kan arbeidsflyten defineres som om du jobbet med andre oppgaver. Du vil tillate klienten å lage HelpDesk Ticket eller Bug. De vil i utgangspunktet være i standardstatus (oftest kalt Ny). Deretter går kommunikasjonen frem og tilbake mellom klient og operatør ved serier av billettoppdateringer og ved endring av rettighetshaver, som er nødvendig for å holde alle brukere aktive i kommunikasjonen. SLAer overvåkes som i e-post generert billett Svar: Endring av status; Løse: Lukke billetten.

5.3 Billetter opprettet via REST API

Det er mulighet for at oppgaver/billetter opprettet via REST API (for eksempel fra et nettskjema) ser ut som HelpDesk-billetter opprettet fra e-post. Bare send "easy_helpdesk_mailbox_username"parameter via API, for eksempel: issue [easy_helpdesk_mailbox_username] = 'support@company.com ". Dette vil føre til at den nyopprettede oppgaven ser ut som en HelpDesk-billett fra den oppgitte e-postadressen, SLA-innstillingene vil bli brukt tilsvarende og en takkemelding vil bli sendt til avsenderen.

 

6 Mail maler

Det ble forespeilet allerede under siste kapittel, men uten en skikkelig forklaring på bearbeidingen ville det ikke vært så lett å forstå som det blir nå. Det siste HelpDesk-menyelementet har vi ikke introdusert.

E-postmaler gir et visst nivå av automatisering og formalisering av kommunikasjonen med klienter, som de anerkjenner din bedrift som en profesjonell handel.

En viktig egenskap for Mail-maler er det de er konfigurert per postkasse, Du kan ikke bruke en mal fra en postkasse IT@mycompany.com for e-postmeldinger sendt til support@mycompany.com.

6.1 Opprette en postmal

Det er effektivt to typer postmaler: autoreply og standard mal. Fordi de ikke er konfigurert annerledes, vil vi forklare begge sakene samtidig.

6.1.1 Legg til ny mal

6.1.2 Grunnleggende attributter

Innstilling av notater:

• Bruk for postkasse – hvilken postkasse vil ha denne malen tilgjengelig
• Oppgavestatus – i henhold til denne statusen vil malen være forhåndsutfylt i dialogen når svaret sendes til en ekstern post (se kapittel 5.1.3.)
  • For å bruke malen som autoreply til nyopprettede billetter fra e-post, still inn statusen til standard-en (som konfigurert i administrasjon >> oppgavestatus). I virkeligheten, når en billett er opprettet fra en e-post, vil autoreplyet i henhold til denne mal sendes umiddelbart. Det kan brukes til å bekrefte til klienten at billetten ble opprettet og hva de neste trinnene vil være.
  • Du kan la statusen være tom, i så fall vil den aldri bli automatisk fylt ut i dialogboksen for send post, men brukerne vil kunne velge den manuelt
• Emne – hva vil emnet inneholde
• Det anbefales å inkludere oppgave-ID-en i autosvaret - hvis du har mange billetter med samme klient, vil du være bedre i stand til å skille mellom dem når du snakker med klienten
• Du kan også bruke det aktuelle emnet som ble brukt til klientens originale epost

6.1.3 Dynamiske tokens og posttekst

Dynamiske tokens kan brukes til å gi spesiell billettinformasjon til klienten. I en mal blir de lagt inn som en av nedenstående, og i e-posten som sendes til klienten, vil de erstattes av den faktiske verdien fra billetten.

Et enkelt eksempel på en autoreply.

6.1.4 Viktige dynamiske tokens

Hvis du skal bruke e-postmaler effektivt, er det nødvendig å inkludere token % Task_note% inn i malen. Det vil bruke kommentaren du sist lagt til billetten og omgir den med den andre teksten i malen.

Hvis du vil legge til en bedriftssignatur i utgående e-postmeldinger, bruker du symbolet % User_signature%. Den vil bruke HTML-signaturen til den nåværende brukeren (som oppdaterer billetten) som kan settes på brukerens profil.

Eksempel: La oss utarbeide en enkel mal med kommentar fra supportoperatøren, total tid brukt på billetten og selskapets underskrift av brukeren.

Slik ser malen ut.

Dette hvordan operatøren skriver kommentaroppdateringen.

Og dette vil være den sendte e-posten i henhold til malen.

OBS: Når du bruker e-postmaler sammen med spesiell overskrift og fotstøtte på e-post på et bestemt prosjekt (Kapittel 4.3.), Setter prosjektet header og bunntekst hele e-posten til klienten, ikke bare e-postmalen, eller bare den delen som er lagt til av siste kommentar.

6.1 Standard e-postmal

Det er mulig å velge en HelpDesk e-postmal som misligholde. Det betyr at når du sender en kommentar til en kunde, er det større sjanse for at en mal er forhåndsvalgt (noe som gir mindre manuelt arbeid for supportagenten).

Oppførselen er som følger:

Forutsetninger

• en e-postmal kan settes som standard
• hver e-postmal må ha en koblet postkasse
• Du kan ha flere postkasser i systemet ditt
• e-postmalen kan være (men det er ikke påkrevd) koblet til en viss status

situasjoner

• en billett opprettes manuelt (ikke fra e-post) - mal fra a er forhåndsvalgt i henhold til status; hvis ikke funnet, er standardmalen forhåndsvalgt
• en billett opprettes fra en annen postkasse enn den som standard e-postmal brukes med – mal med denne postkassen er forhåndsvalgt basert på status (samme som for øyeblikket) => ingen mal forhåndsvalgt automatisk hvis du bruker status som det ikke er tilordnet noen mal
• en billett opprettes fra postkassen som standardmalen brukes med – malen er forhåndsvalgt basert på status – hvis ingen slik mal finnes, er standardmalen forhåndsvalgt

Skjul SLA-data

Informasjon om SLA-respons og løsningstid på oppgavedetaljer kan skjules for utvalgte brukertyper (Administrasjon >> Brukertyper >> Rediger).

SLA kan også skjules for bestemte brukere (Administrasjon >> Brukere >> Rediger).

En bruker vil ikke se SLA-ene hvis minst en av innstillingene angående deres bruker eller brukertype er aktivert.

Topp- og bunntekst på HelpDesk-e-poster

Globalt sett topp- og bunntekst for e-postvarsler (Administrasjon >> Innstillinger >> E-postvarsler) vil ikke lenger være en del av e-poster sendt fra HelpDesk.

For å legge til topp- og bunntekst for HelpDesk-e-poster, gå til HelpDesk-innstillingene for et spesifikt prosjekt (Prosjekt >> Innstillinger >> HelpDesk).

Bekreft databasekonfigurasjon

Oppgradering av tester avdekket en inkompatibilitet i to konfigurasjoner som tidligere samarbeidet riktig.

Forsikre deg om at både databaseserveren og config / database.yml har det samme (anbefalte) utf8mb4 settet.

1) etc / my.cnf

character_set_server = utf8mb4
collation_server = utf8mb4_unicode_ci

2) config / database.yml

produksjon:
  adapter: mysql2
  database: enkel
  vert: 127.0.0.1
  brukernavn: enkelt
  passord: "EASY_STRONG_PASSWORD"
  koding: utf8mb4

Hvis disse ikke er justert, vil du ikke kunne bruke noe autofullførende felt, f.eks. Hopp til prosjekt, Valg av mottaker, Filtre, etc.

Til slutt må du kjøre denne kommandoen for å sette alle tabellene koding riktig.

for DB i YOUR_DB_NAME; gjøre
  for TABELL i `mysql -e" bruk $ {DB}; vis tabeller; " - batch - skip-kolonne-navn | xargs`; gjøre
    ekko "Konvertering $ {DB}. $ {TABLE}"
    mysql -e "alter tabell $ {DB}. $ {TABLE} KONVERTER TIL tegnsett utf8mb4 sortere utf8mb4_unicode_ci;"
  gjort
gjort

I stedet for YOUR_DB_NAME skriver du inn navnet på databasen din.

Merknader: Korrekt databasekonfigurasjon er et generelt krav for feilfri kjøring av et webprogram. Det er ikke bare et spesifikt krav til denne nye versjonen av Easy Project.

Brudd på tilpasset design (ingen CSS)

I tilfelle du hadde tilpasset merkevarebygging (logo, farger, bakgrunn) og etter oppgraderingen gikk den i stykker – mangler alle stiler, siden ser ødelagt ut, du kan enkelt fikse det.

Gå til side / easy_theme_desings >> finn design >> kompiler >> last igjen. Det vil reparere designet og laste stilene.

7 Globale innstillinger

Nå som vi har gått gjennom hele brukervennligheten, kan vi fullføre resten av innstillingene som skal gjenforklares.

Innstilling av notater:

• Avsender – hvilken e-post som er oppført som FRA på billettsvar til klient (i forhold til kapittel 5.1.3.)
  • Nåværende logget bruker – bruker som oppdaterer billetten
  • Standard fra e-postvarsling – e-post som brukes til å sende standardvarsler fra systemet til brukere. Satt i Administrasjon >> innstillinger >> e-postvarsler
  • Postboksadresse – e-post, som mottok den originale e-posten fra klienten
  • Denne innstillingen er løst knyttet til den siste avmerkingsboksen Tillat egendefinert avsender – hvis den er aktivert, kan du angi en egendefinert e-post som avsender i prosjektets HelpDesk-innstillinger. Hvis et prosjekt har en e-post fylt i innstillingen, vil den overstyre avsenderinnstillingen
• Aktiver oppdatering av oppgaveattributter – hvis aktivert, er det mulig å endre visse attributter på billetten via e-post. For eksempel ved å skrive Prioritet: Høy I postlegemet vil du endre prioriteten tilsvarende. Dette er en ganske avansert funksjon, og det anbefales ikke å bruke med klienter
• Godta autogenererte e-poster – for eksempel nyhetsbrev
• Ignorer CC for mottatte e-poster – hvis aktivert, blir ikke e-poster i CC behandlet og brukt i feltet "epost til"av billetten (kapittel 5.1.3. notat om post mottaker)
• Endre status etter klientsvar til – hver gang en klient skriver et svar som oppdaterer billetten, vil status endres tilsvarende. Dette er spesielt nyttig når billetter settes til lukket status etter at et svar ble sendt av operatøren. Med mindre klienten svarer tilbake med noen tilleggsspørsmål, vil billetten forbli lukket og skjult fra de aktive oppføringene. Når klienten svarer, vil billetten være gjenåpnet og tilbake til aktiv kø med åpne billetter
• Suspend SLA for billett når status er - dette er statuser, når SLA-fristen ikke er bestemt, fordi billetten venter på input fra klienten, uten hvilken operatøren ikke har noen sjanse til å gi støtte
• Tell SLA for billett når status er – når SLA normalt måles. Med disse funksjonene kan du fint stille inn billettsyklusen. For eksempel ber operatøren klienten om mer informasjon, setter statusen til pasive og SLA er pauset. Etter klientrespons blir status endret til konsultasjon og SLA omberegnes i henhold til gjenværende tid til SLA-frist når billetten ble besvart

I versjon 12 mottok Helpdesk en annen interessant beregning - Billetter løses av support. Du vil kunne rapportere totalt antall eller andel av billetter som aldri har forlatt supportteamet.

Hvordan fungerer det

1. Først må du definere hvilke brukere som er medlemmer av support i Help desk >> Helpdesk-innstillinger - Løst av support innstillinger
   
   
   
2. Innstillinger for deloppgaver/relaterte oppgaver vil avgjøre om billetter løst av støtte kan eller ikke kan inneholde deloppgaver eller relaterte oppgaver
3. Nå anbefaler vi å trykke på knappen i helpdesk-menyen - Beregn på nytt
   
   Dette vil evaluere billetter fra de siste 90 dagene
4. Til slutt, gå til oppgavelisten og finn filteret Løst av Support
   
   

Dette filteret vil vise billetter som bare ble tildelt medlemmer av støtten (i henhold til innstillingen i punkt 1). Basert på innstillinger på punkt 2, kan billetter som inneholder deloppgaver eller relaterte oppgaver bli regnet som løst av support.

 

8 Filter "Trenger reaksjon"

"Trenger reaksjon" er en egenskap ved HelpDesk-billetter og CRM-saker. Denne egenskapen er som standard satt til "Nei". Det vil endres til "Ja" når en billett / sak er tildelt en person som svarer på den ved å sende en e-postmelding i stedet for å tildele den tilbake til avsenderen i Klientsone eller Easy Project. I så fall forblir rettighetshaveren av billetten / saken uendret, og den mottatte mottakeren kan ikke legge merke til at oppdateringen er gjort. For å forhindre dette, må mottakeren jevnlig sjekke alle elementene med "Trenger reaksjon" attributt satt til "Ja", slik at han lett blir kjent med at det er noe nytt han bør sjekke eller svare selv om den ikke er tildelt ham. Eller du kan bruke den når du trenger det å "markere" noen kundebillett du allerede har svart, men det er fortsatt noe arbeid på det og du må informere kunden senere på nytt. Ved hjelp av "Oppgaver fra filter"-modulen, kan du ganske enkelt lage en boks på hjemmesiden din, CRM-oversikt eller HelpDesk-oversikt som den nedenfor.

 

9 HelpDesk-brukere (fra versjon 11+)

Blant de største tilskuddene til HelpDesk de siste årene er såkalte HelpDesk-brukere. Deres formål er å forenkle administrasjonen av klienttilgang til ditt enkle prosjekt. Det gjør det også mye enklere for kundene selv å sende inn billetter og kommunisere med operatørene dine direkte i søknaden.

9.1 Forutsetninger

Administrasjon av HelpDesk-brukere er under tillatelser Se/behandle HelpDesk-brukere under HelpDesk-delen i Administrasjon >> Roller og tillatelser.

En annen innstilling du bør sjekke før du begynner å opprette HelpDesk-brukere er Administrasjon >> Sidetilpasning >> HelpDesk-brukere >> Oversikt over maler. Det bør være en eksisterende sidemal i en grunnleggende "starter"-konfigurasjon. Det er viktig at det finnes en mal som er satt som standard~~POS=TRUNC – denne malen vil bli brukt automatisk på nye HelpDesk-brukere. Ellers vil HelpDesk-brukerne ha en tom side etter at de har logget på.

HelpDesk-brukersiden inneholder 3 typer moduler:

• Nytt billettskjema – Det har ingen innstillinger, bare plasser det for å gjøre det mest mulig for kundene dine.
• HelpDesk-billetter – liste over billetter opprettet av HelpDesk-brukeren. Hver bruker kan kun se billetter som de selv har laget. Denne modulen er konfigurerbar, slik som alle andre "liste"-moduler i applikasjonen. Den inneholder felt som er synlige for HelpDesk-brukere i billetter. Hvis du har tenkt å vise både åpne og lukkede billetter for HelpDesk-brukerne, anbefaler vi å vise dem i separate moduler.
• Oppslagstavle – bare i tilfelle du vil dele tilpasset informasjon med kundene.

9.2 HelpDesk-brukeradministrasjon

Listen over HelpDesk-brukere er tilgjengelig som et eget element i kontrollknappene på HelpDesk-dashbordet.

Alle attributter er obligatoriske:

• Fornavn
• Etternavn
• E-post = Logg inn
• Språk
• Prosjekt – dette er prosjektet der billetter fra denne brukeren blir opprettet. Kun åpne prosjekter som er koblet til HelpDesk kan velges her.
• Passord – under brukeroppretting må du skrive inn et passord med mulighet for å generere passordtoken, slik at brukeren kan sette sitt eget passord via lenke i en e-post. Under brukerredigering er det åpenbart ikke nødvendig å endre passord.

Ytterligere tillatelser:

Hver bruker kan gis ytterligere tillatelser til å se og administrere alle oppgaver

Se alle oppgaver = Lar brukerstøtten se alle opprettede billetter under samme prosjekt

Administrer alle oppgaver = Lar brukerstøtten redigere spesifikke felt fra allerede opprettede billetter (tittel, beskrivelse og også legge til et nytt vedlegg, men ikke redigere det gamle).

Bruk saken

En klient har et spesielt prosjekt for billettene sine i brukerstøtten din. Det er flere brukere som logger på helpdesk-portalen og sender inn billetter på vegne av denne klienten. En av disse brukerne må se alle de innsendte billettene, fordi hans rolle krever å evaluere tjenesten du leverer.

9.2.1 CSV-import

Fra versjon 11plus.2.0 er det mulig å importere helpdesk-brukere via CSV. Ta kontakt med din konsulent om dette alternativet.

9.3 Logge inn som HelpDesk-bruker

HelpDesk-brukere logger inn via et annet inngangspunkt enn vanlige brukere. På påloggingsskjermen under påloggingsknappen finner du en bryter. For å sende kundene dine til HelpDesk-pålogging, bruk URL /HelpDesk/logg inn. Som nevnt ovenfor brukes e-post som påloggingsnavn.

VIKTIG: HelpDesk-brukere er teknisk uavhengige av vanlige brukere. Du kan bruke samme e-post for én vanlig bruker og én HelpDesk-bruker.
Selv om praksis antyder at dette ikke bør være tilfelle. Du oppretter enten en HelpDesk-brukerkonto, eller du bestemmer deg for at brukeren trenger en full konto. Begge typer kontoer for én person skal kun brukes til testformål.

Etter pålogging består selve portalen av hjemmesiden, som ble konfigurert av en admin, men som ikke kan konfigureres av HelpDesk-brukeren selv. Øverst til høyre er profilen tilgjengelig, inkludert redigeringsmodus. Ved siden av, logg ut-knappen. Ved å klikke på en eksisterende billett, eller opprette en ny billett, vil brukeren bli omdirigert til billettdetaljen, hvor de kan legge til kommentarer eller vedlegg. For å gå tilbake til hjemmesiden klikker du bare på logoen øverst i venstre hjørne.

HelpDesk-bruker har ingen roller og tillatelsesinnstilling, og du kan ikke gi dem ekstra tilgang til visse områder. Oppføringen ovenfor er alt de har tilgang til. Du bør ikke sende dem noen lenker til elementer i søknaden din. Det ville bare føre til ingen tilgang budskap.

9.3.1 LDAP-autentisering for HelpDesk-brukere

Fra versjon 11plus.2.0 kan helpdesk-brukere autentiseres via LDAP.

Konfigurasjonen er i Admin >> Plugins >> Helpdesk-brukere >> Rediger - Ny autentiseringsmodus.

Skjemaet er identisk med vanlig LDAP-konfigurasjon, den eneste forskjellen er at det gjelder brukerstøtte for brukerstøtte => på side /helpdesk/login

9.4 Arbeid med billetter

Fra kundens perspektiv

HelpDesk-bruker oppretter en billett via skjemaet Ny billett på hjemmesiden deres. De eneste tilgjengelige attributtene er Emne, Beskrivelse og vedlegg. Filosofien er at klienter ikke skal bekymre seg for organisatoriske forhold når de trenger hjelp fra kundeservice. De sier bare problemet sitt og forventer en løsning. Ingen prosjektvalg, ingen kategorier, ingen egendefinerte felt, ingen prioritetsvalg – alt dette er støtteteamets ansvar.

Billetten vil bli opprettet i et prosjekt, som settes direkte på HelpDesk-brukeren. Felt E-post til i billetten fylles ut på e-post til HelpDesk-brukeren. Denne brukeren vil også bli satt som HelpDesk forfatter av billetten, som er et skjult attributt (ikke relatert til Forfatter, som er en generisk egenskap for alle oppgaver i Easy Project). Dette sikrer at de alltid vil se billetten, selv om du flytter den til

 

Hjørnesituasjoner

• Situasjonen når en oppgaveansvarlig ikke er medlem av prosjektet, kan oppstå i følgende tilfeller:
  • rettighetshaveren ble fjernet fra prosjektet, men oppgavene ble fortsatt tildelt ham,
  • en automatisk billettoppdateringsprosess settes i HelpDesk-modulen på en slik måte at noen billetter automatisk tildeles et tidligere prosjektmedlem.
• Informasjon om SLA Response vises i oppgavedetaljene bare når oppgaven er i standardstatus, som er definert på en respektive tracker.
• Vi anbefaler på det sterkeste at du ikke endrer prioriteten til en billett når billetten har suspendert SLA, da en slik handling vil påvirke den korrekte beregningen av SLA på den billetten negativt.