HelpDesk

Terminologi
Bestäm strukturen för HelpDesk-projekt
Ansluter brevlåda till Easy Redmine
Så här konfigurerar du projektkonfiguration
Hur man ställer in projektkonfiguration – detaljer
Hur man arbetar med biljettbehandling
Hur man konfigurerar e -postmallar
Så här konfigurerar du globala inställningar
Filtrera "Behöver reaktion"
HelpDesk-användare
Hörnsituationer

Dessa instruktioner kommer att gå igenom alla steg för att konfigurera HelpDesk från användargränssnittet. Från att ansluta brevlådor till Easy Redmine, genom projektinställningar, till finjustering av instrumentpanelerna. Detta är inte en teknisk manual för att konfigurera cron (eller schemalagda uppgifter på serversidan). Cron måste redan vara konfigurerat för att HelpDesk ska fungera. Instruktioner för att ställa in cron är här..

 

0 terminologi

Låt oss först börja med en ordlista över använda termer i följande manual.

brevlåda - en e-postadress kopplad till Easy Redmine, från vilken mottagna e-postmeddelanden bearbetas till biljetter i respektive HelpDesk-projekt
Biljett - uppgift skapad från ett mottaget e-postmeddelande i en brevlåda, eller en uppgift som skapats internt av klienter i ett HelpDesk-projekt
HelpDesk-projekt – ett projekt kopplat till HelpDesk, där biljetter kan skapas
Domän – den andra delen av en e -postadress. Till exempel, från e -post worker.Joe@client.com domän är bara client.com
Nyckelord – ord eller en rad ord som finns i postämne
SLA - överenskommelse om servicenivå. I förenklad mening som används i Easy Redmine, avtalad tid att reagera av företaget på biljetter som skickats av klienten. Beräknat i timmar
Ursprungligt e-postmeddelande – E-post skickas till en HelpDesk-brevlåda från vilken biljetten skapades
Operatör - dessa termer kommer att användas för supportarbetaren som arbetar med biljetterna

 

1 Bestäm strukturen för HelpDesk-projekt

Beroende på om du vill ha ett enda projekt för alla biljetter eller skilja på HelpDesk-brevlådor, eller till och med ha specialprojekt för olika kunder, måste du bestämma dig för strukturen på projekten innan någon konfiguration startar. Detta beslut kommer att påverka några ytterligare steg som anges i denna handbok.

Här är möjligheterna:

1.1 Enstaka projekt för alla biljetter

Om du bara ska ha ett projekt, som samlar mejl från en enda brevlåda, finns det inget beslut att fatta >> alla e -postmeddelanden som skickas till brevlådan skapar biljetter i samma projekt.

Exempelvis: Alla dina kunder skickar supportförfrågningar till support@mycompany.com

Det spelar ingen roll vilken nivå detta projekt är, i grund och botten lever det sitt eget liv inom någon del av din projektstruktur. Men om du planerar att börja med ett enstaka projekt och senare fortsätta expandera HelpDesk, bör du se alternativen nedan.

1.2 En brevlåda, fler HelpDesk-projekt

Exempelvis: Du använder brevlådan support@mycompany.com. Alla mottagna mejl går in i ett generellt projekt. Men du har en klient som har ett speciellt projekt och särskilda villkor> e -postmeddelanden FRÅN domän client.com behandlas i det särskilda projektet.

Naturligtvis kan du få fler kunder åtskilda på detta sätt. I det här fallet kan projektstrukturen se ut så här:

Ett annat alternativ är att ha Standard HelpDesk-projektet på första nivån och specialprojekten under det.

Ett annat sätt som ibland kan användas är en struktur:

> Klient1
>> Projekt för handel
>> Projekt för implementering
>>Projekt för HelpDesk

> Klient2
>> Projekt för handel
>> Projekt för implementering
>>Projekt för HelpDesk

Detta rekommenderas dock inte om du planerar att samla biljetter från olika problem till några aggregerade listor, statistik eller sammanfattningar.

1.3 Fler brevlådor, inga speciella kundprojekt

Exempelvis: Du använder brevlådor support@mycompany.com, info@mycompany.com, it@mycompany.com och e -postmeddelanden sorteras endast enligt brevlådan, inte enligt avsändaren.

I sådana fall kan du ha de tre projekten på samma nivå och eventuellt under ett huvudprojekt som täcker dem alla.

Dessa projekt kan vara helt orelaterade och falla till separata delar av din organisation, de kan vara i olika projektträd (under olika toppprojekt).

1.4 Fler brevlådor, med speciella kundprojekt

Nuvarande Easy Redmine HelpDesk-funktionalitet gör det möjligt att separera klienter enbart efter avsändaren och inte genom en kombination av avsändare och mottagande brevlåda.

Exempelvis: Du använder brevlådor support@mycompany.com, info@mycompany.com, it@mycompany.com. Du har en speciell klient som skickar supportförfrågningar från domänen client.com

Den rekommenderade strukturen är:

När vi återvänder till projektstrukturen i allmänhet finns det ytterligare överväganden att göra. Om du siktar på att integrera HelpDesk-bearbetning med en annan avdelning i din organisation (till exempel utveckling), kanske du vill överväga att sätta HelpDesk-projekt lite djupare i projektstrukturen.

Korrekt projektstruktur gör att du kan generera olika rapporter, listor, statistik i fler faser av ditt företag.

 

2 Ansluter brevlåda till Easy Redmine

Nu kan vi börja med själva installationen av HelpDesk-komponenter. För att ha Easy Redmine-bearbetningspostlådor måste de vara anslutna på följande sätt.

2.1 Administration >> HelpDesk >> Alla brevlådor >> Lägg till brevlåda

2.2 Ange giltiga inloggningsuppgifter för din brevlåda – klicka på Testa för att se till att Easy Redmine kan nå brevlådan

Inställningsanteckningar:

• Aktiva - brevlåda skannas regelbundet av Easy Redmine efter nya olästa meddelanden. Om det är inaktiverat kontrollerar inte Easy Redmine brevlådan. Men du kan behålla brevlådan i Easy Redmine för eventuell framtida användning.
• Använd annan avsändare - när användare på e-postservern inte är samma som postlåda (till exempel HelpDesk-e-postanvändare). Ange här den giltiga maliboxen, som representeras av användaren.
• SSL - om du använder ett SSL-certifikat på din mailserver
• Aktivera OAuth – OAuth 2.0-protokollet används av hundratals välkända tjänster som en alternativ autentiseringsmetod. När det gäller HelpDesks brevlåda kan den användas för att verifiera avsändarens autentiseringsuppgifter med hjälp av en extern applikation som för närvarande stöds är Googles arbetsyta (tidigare G Suite) och Microsoft Exchange konton. Du måste läsa OAuth 2.0-dokumentationen för det andra programmet för att veta exakt vad du ska ange i varje fält. Naturligtvis måste du ha administratörsåtkomst till den andra applikationen för att hitta den information som krävs, såsom webbadress, klient-ID, klienthemlighet, auktorisera URL, token-URL, omfattning, etc.
  
• mapp - om du vill att Easy Redmine endast ska kontrollera vissa mappar för olästa e-postmeddelanden.
• I framgång flytta till – om ett e-postmeddelande behandlas korrekt av Easy Redmine (biljett har skapats), kommer det att flyttas dit
• I misslyckande flytta till – om ett e-postmeddelande behandlas felaktigt (biljett har inte skapats) kommer det att flyttas dit

När du har testat anslutningen klickar du på Spara.

2.2.1 Var du hittar OAuth 2.0-uppgifter för Microsoft- och Google-konton

För att ansluta Easy Redmine till ett Google Workspace-konto som använder OAuth 2.0-protokollet måste du skapa ett konto på Google Cloud Platform, skaffa de nödvändiga referenserna som finns där och kopiera dem till brevlådeinställningarna i vår applikation. Några användbara instruktioner kan hittas här..

För att ansluta Easy Redmine till ett Microsoft Exchange-konto med OAuth 2.0-protokollet måste du skapa ett konto på Microsoft Azure portal, skaffa de nödvändiga referenserna som finns där och kopiera dem till brevlådeinställningarna i vår applikation. Några användbara instruktioner kan hittas här..

Åtkomsttokens har en begränsad livslängd (max 6 månader), du kan inte skapa obegränsade sådana. Efter denna tid slutar brevlådan att fungera och en ny token måste genereras och återmatas i applikationen.

En OAuth 2.0-åtkomstadress med formuläret "/organisations/oauth2/v2.0/authorize" är endast giltigt om åtkomst till applikationen är aktiverad inom organisationen. Annars måste åtkomstwebbadressen vara av formatet "/[TENANT_ID]/organisations/oauth2/v2.0/authorize". De korrekta inställningarna finns i avsnittet Endpoints.

När tvåfaktorsautentisering (2FA) är inställd i Microsoft Azure måste alla anslutna postlådor uppdateras.

2.2.1.1 Fel "Användaren är autentiserad men inte ansluten"

Detta beror på att den valda Azure-användaren genom vilken postlådan är registrerad inte har behörighet att komma åt postlådan. I det här fallet räcker det inte om användaren är administratör då denne behöver ha licens för att använda Office 365. Om användaren har delegerad behörighet (han får inte lägga till åtkomst till brevlådan eftersom det kräver godkännande av t.ex. en administratör ), måste han få lämplig omfattningsbehörighet i Azure och inaktivera det här alternativet samtidigt.

Lösning:

• Användaren måste antingen vara den direkta ägaren till brevlådan han har åtkomst till (och därmed ha de nödvändiga behörigheterna för att göra det).
• Alternativt kan han vara en annan (licensierad) användare som har fått åtkomst till den postlådan.

Ett annat möjligt problem är att kontot skapas som POP3 istället för IMAP. POP3 stöder inte OAUTH i systemet.

Lösning:

• Se till att kontot är inställt som IMAP i både azure och i Easy Redmine.

2.2.1.2 Fel: Microsoft Help Desk ansluter framgångsrikt men slutar fungera efter en tid

Du glömde att aktivera rätten för offlineåtkomst.

2.2.1.3 Användningsfall: Många brevlådor, en super Help Desk-användare

Om du har flera Help Desk-postlådor inställda i Microsoft Exchange och du vill delegera åtkomsträttigheter till alla dessa brevlådor till en enda användare, kan du göra det via Microsoft 365 administratörscenter » Administratörscenter » Exchange.

Du kommer att omdirigeras till Exchange-sektionen för administratörscenter. Klicka här på fliken Mottagare » Brevlådor och välj den postlåda vars åtkomsträtt du vill delegera. Ett höger popup-sidofält öppnas och klicka på Delegering.

Nedan märker du läs och hantera (Full Access)-tecknet med en Redigera-knapp att klicka på.

Du kan sedan söka efter och lägga till användare som blir medlemmar i denna brevlåda med samma rättigheter som brevlådans ägare.

Användaren du väljer måste ha Help Desk-administratörsrättigheter på Easy Redmine-sidan.

2.2.2 Aktivera OAuth 2.0-autentisering med Azure Active Directory

När du använder OAuth 2.0-autentisering får du tillgång till en webbtjänst från en klientapplikation. Hur du gör detta beror på vilket bidrag du använder. I denna handledning, kommer du att lära dig hur du konfigurerar klientuppgifternas beviljandetyp för applikationer i Azure Active Directory.

2.3 Konfigurera frekvensen för postlådeskanning

Högerklicka på brevlådan och välj Inställningar

Nu är du tillbaka till postlådans inställningar, men med en ytterligare inställning. Som standard är den inställd på Var 5: e minut. Men det rekommenderas i allmänhet att ha den här inställningen var 10: e minut. Om du har många brevlådor anslutna till Easy Redmine kan den här automatiska skanningsuppgiften ta längre tid och överbelasta din server med för ofta skanningar, vilket kommer att sakta ner hela programmet.

Knapp noterar:

• Execute – starta brevlådeskanningen manuellt
• Historik – visa tidigare brevlådeskannningar
• Ta bort – ta bort postlåda från Easy Redmine skannade postlådor
• Avaktivera – avaktivera automatisk brevlådeskanning

2.4 Automatisk avaktivering

Att bearbeta postlådor med jämna mellanrum kräver serverresurser, särskilt om du har flera brevlådor. Av denna anledning har vi implementerat en mekanism som automatiskt inaktiverar bearbetning av postlåda efter 3 gånger misslyckades den med att autentisera och ladda ner e-postmeddelanden. Inaktivera betyder att fältet Aktiva kommer att stängas av. Du kommer fortfarande att kunna verifiera inställningarna, testa och aktivera.

Varför? För att spara dina resurser. Varför ska servern fortsätta pinga en postlåda som inte fungerar?

 

3 Projektkonfiguration

Mailbox är ansluten och skannas av Easy Redmine, men än så länge har vi inte ställt in var biljetterna ska skapas. Innan ett projekt kopplas till HelpDesk kan biljetter inte skapas eftersom, i allmänhet, varje uppgift kräver ett projekt.

Denna del kommer att delas upp i olika scenarier, beroende på syftet med varje projekt.

3.1 Standardprojekt för brevlåda

I exemplen från det förra kapitlet skulle detta vara projekten Standard HelpDesk, INFO – allmänt, IT – allmänt, SUPPORT – allmänt, dvs inte begränsat till en viss avsändares domän.

1. Klicka på "Lägg till i HelpDesk"på en projektöversiktssida för det valda projektet.
   
2. Välj den brevlåda som projektet kommer att vara standard för
   
3. Bläddra ner och Save

En fullständig förklaring av alla HelpDesk-projektinställningar kommer att följa längre fram i detta kapitel.

3.2 Särskilt kundprojekt

Från exemplen i kapitel 1 skulle dessa vara projekten: Bohemia Sun, Trains Francais, Client 123, Client ABC, Client XYZ, Client 1>>Projekt för HelpDesk, Client 2>>Projekt för HelpDesk

1. Välj projekt
2. Fyll i fälten som markeras nedan. Inställningsanteckningar finns under skärmdumpen
   
3. Bläddra ner och Spara.

Inställningsanteckningar:

• Standard för brevlåda - INTE välj valfri brevlåda om du vill ange detta projekt som ett speciellt klientprojekt
• Mail, domäner, nyckelord bearbetade i detta projekt – alla inställningar i detta avsnitt är med OR operatör, vilket betyder att om minst ett villkor är uppfyllt skapas biljett i detta projekt
• Fyll e-post till från - När det här alternativet är valt kommer författarens e-post att automatiskt fyllas i ny biljett. Det här alternativet är användbart när du har projekt där biljetter skapas av riktiga användare, istället för att bearbeta inkommande e-postmeddelanden.
• Nyckelord – I det här exemplet, om ett e-postmeddelande tas emot i NÅGON HelpDesk-brevlådan innehåller hela strängen Jag är från företagets klient ABC, biljett kommer att sorteras in i detta projekt. Använd inte samma sökordsträng för fler projekt, bara den första posten i databasen med strängen kommer att använda den angivna sökordssträngen
• E-post eller domän – inkommande e-postmeddelanden skannas efter dessa värden i fältet FRÅN i e-postmeddelandet. I det här exemplet kan avsändaren vara vem som helst med brevlåda som slutar med clientABC.com eller det kan också vara en specifik person med en annan e-postadress, men vi vill att hans biljetter ska sorteras i det här projektet

En fullständig förklaring av alla HelpDesk-projektinställningar kommer att följa i nästa kapitel.

VIKTIGT: Det är inte den bästa praxisen att ha ett projekt som båda Standard för brevlåda OCH specificerad för en viss e -post eller domän. Alla avsändare kommer att få sina biljetter skapade i detta projekt, så du behöver inte ange dem. Denna typ av inställning kan orsaka förvirring.

3.2.1 Avsluta och arkivera specialklientprojekt

När ett sådant projekt är stängt (som i praktiken blir skrivskyddat) kommer biljetter inte att vara möjliga att skapa inom. Därför kommer detta projekt att upphöra att vara ett speciellt kundprojekt och e-postmeddelanden som kommer från domäner som ställts in i HelpDesk-inställningarna kommer att behandlas som okända och falla i ett allmänt HelpDesk-projekt.

Detsamma gäller för arkiverade projekt.

 

4 Projektkonfiguration – detaljer

Nu när vi har differentierat olika typer av projekt som kan användas i HelpDesk, kan vi fortsätta att förklara resten av projektinställningarna. När ett projekt är anslutet till HelpDesk, finns det två sätt att komma in på projektets HelpDesk-konfigurationssida.

• Administration >> HelpDesk >> Alla HelpDesk-projekt >> Redigera
  
• Projektinställningar >> HelpDesk
  

4.1 Grundinställningar

Inställningsanteckningar:

• Tracker – nya biljetter i detta projekt kommer att skapas med denna tracker
• Tilldelad – nya biljetter i det här projektet kommer att tilldelas den här användaren
• Kollega – nya biljetter i det här projektet kommer att ha dessa medarbetare (möjligt med flera val)
• Automatisk ärendeuppdatering – beroende på ditt arbetsflöde kan det finnas några ärenden som är faktalösta och hålls öppna. I sådana fall kan du ställa in automatisk stängning enligt status och varaktighet för icke-uppdatering. Förutom att stänga biljetten kan ett uppföljande e-postmeddelande från mall skickas automatiskt, till exempel i syfte att informera avsändaren om att hans biljett har stängts eller fråga honom om hans tillfredsställelse med biljettlösningen.
• Avtalstid månadsvis – denna inställning bör endast användas för speciella kundprojekt, där kunder har förbetalt ett visst antal timmars support per månad
• Sammanlagda timmar – avtalet med kunden kan ha möjlighet att överföra outnyttjade timmar från föregående månad till nästa. Om klienten har 10 förbetalda timmar, men endast använt 7 av dem under maj, kommer 3 timmar att överföras till juni
• Återstående timmar – hur mycket är kvar. Pennknappen gör det möjligt att manuellt radera återstående timmar – inställd på 0
• Sammanlagt startdatum – när förskottsbetalningsperioden börjar; måste väljas en dag som är gemensam för alla kalendermånader, dvs dag 1-28
• Aggregerad period – för vilken tidsperiod räknas timmarna ihop innan de återställs till de ursprungliga avtalstiderna. Om det fortfarande finns 13 timmar kvar vid slutet av kvartalet (kvartalets slut bestäms av det sammanlagda startdatumet), kommer de inte att överföras till det nya kvartalet. Timmarna kommer att återställas till 10

Timmarna är tillbringade tidsposter i projektet. Vilka exakta uppgifter kommer att förklaras ytterligare i denna handbok.

4.2 SLA

Detta är ett viktigt mått på alla HelpDesk-projekt, men speciellt för speciella kundprojekt där SLA-överträdelser kan bli sanktionerade. Som nämnts tidigare kan biljetter skapas via e-post eller direkt från systemet av klienter med särskilt begränsad tillgång till ett HelpDesk-projekt. Båda fallen har en liten nyans i SLA-inställningen.

4.2.1 SLA för e-postgenererade biljetter

Inställningsanteckningar:

• Namn – Titel på SLA (för bättre SLA-administration i HelpDesk-projektet)
• Nyckelord - måste fyllas i om SLA ställs in för e-postgenererade biljetter. I det här fallet finns det ett specifikt sökord, som om det finns i ämnet för e -postmeddelandet kommer biljetten att få specifikationerna för SLA (timmar, prioritet, spårare)
• Timmar till svar – deadline fram till vilken den första statusändringen av biljetten måste ske. Statusändring indikerar att biljetten har bekräftats och kunden har informerats om det
• Timmar att lösa – deadline för att stänga biljetten >> sätta den i stängd status
• Prioritet – ny biljett från e-post som innehåller nyckelordet kommer att ha denna prioritet
• Tracker – ny biljett från e-post som innehåller nyckelordet kommer att ha denna tracker. Detta är till exempel användbart om kunden har hittat ett fel i produkten och vill rapportera det direkt som ett fel och inte som en standardförfrågan om support. Kunden skulle därför skriva med ämne till exempel Defekt – och biljetten behöver inte klassificeras av HelpDesk-chefen.
• Räkna SLA baserat på arbetstid – SLA-deadlines kommer inte att sättas för icke-arbetande dagar eller timmar på dygnet. Vissa SLA kan begränsas endast till arbetstid, men andra kan ställas in på 24/7
• SLA arbetstider – tidsram för SLA
• Arbetsdagar – arbetskalender där helger, helgdagar och andra arbetsfria dagar registreras

4.2.2 Beställning av SLA

Med fler nivåer, nyckelord och sökordssträngar är det viktigt att hålla ordning på rätt ordning. E-postämnena kontrolleras för nyckelord enligt ordningen i HelpDesk-inställningarna.

Exempel: Du har avtalsmässigt definierade sökord för "Critical" och "Critical bug", var och en av dem har en annan SLA. Du måste se till att de två ämnena kommer att differentieras när e -postmeddelandena behandlas.

I det här fallet måste du sätta SLA "Critical bug" ovanför "Critical". Mekanismen för behandling av e -postmeddelanden är enkel:

1. Sök efter "Critical bug" i e -postämnet
2. Om ovanstående sträng inte finns i ämnet, sök efter nästa, i vårt fall "Kritisk"
3. Om ovanstående sträng inte finns i ämnet fortsätter du att söka efter ytterligare sökord
4. Den sista SLA måste vara det allmänna (för ospecificerad nivå) sökord som använder * -märket för alla ämnen

Om du sätter "Critical" före "Critical bug", skulle det betyda att e -postmeddelanden med "Critical bug" i ämnet behandlas felaktigt, eftersom de skulle falla under "Critical" SLA.

---

I allmänhet, ju mer specifik sökordsträng, desto högre bör dess position vara.

SLA på en klientbiljett har brutits. Vad gör du för att se till att du har kontroll över detta? I det här fallet, gå till projektinställningar >> HelpDesk en rulla hela vägen ner

4.2.3 Återställa SLA för stängda biljetter

Du kommer också att märka en inställning högst upp i SLA -sektionen.

När den är aktiverad kommer biljetter som en gång stängdes och öppnas igen av ett annat svar från klienten att ha SLA räknat som om de vore nya – från tidpunkten för kundens svar som öppnade ärendet igen.
Exempel: Biljett #1234 var öppen på måndagen klockan 16:00. SLA är 48 timmar => tid att lösa är till onsdag 16:00. Biljetten stängdes av en operatör på tisdagen klockan 10:00. Klienten svarade igen att han behöver mer information på tisdagen kl. 14. Biljett #00 har nu nytt SLA för torsdag 1234:14.

När den är inaktiverad kommer SLA alltid att räknas från den ursprungliga tiden då biljetten skapades.
Exempel: I scenariot från det första fallet. Efter klientens svar på tisdag kl. 14 kommer SLA inte att återställas och förbli på onsdag 00:16. Detsamma gäller när kunden öppnar biljetten igen på torsdag. Biljetten skulle nu framhävas som försenad.

Från den sista noten är det uppenbart att denna inställning endast bör inaktiveras på projekt, där biljetterna är enkla och lösning kan definieras strikt, så det finns ingen anledning att öppna biljetterna igen från kundens sida.

4.2.4 SLA för internt skapade biljetter

Som nämnts tidigare kanske biljetter inte bara skapas från mejl. Easy Redmine har en avancerad åtkomstnivåkontroll som gör det möjligt för dina kunder att få direktåtkomst till systemet med begränsade behörigheter (för att skapa biljetter, redigera biljetter, läsa nyheter, ...).

Biljetter som skapats som standarduppgifter av inloggade användare har ett något annorlunda sätt att bestämma SLA. Eftersom det inte behandlas några e -postmeddelanden kan du inte avgöra SLA efter sökord. Låt oss förklara på bilden nedan.

När du skapar SLA för internt skapade biljetter, lämna sökordet tomt. SLA bestäms sedan av en kombination av prioritet och spårare. När du sparar inställningarna försvinner nyckelordet, vilket indikerar att denna SLA används för internt skapade biljetter. Om du lämnar Tracker tom kommer endast sökord att övervägas.

Genom att konfigurera arbetsflödet effektivt kan du begränsa klienter att bara skapa biljetter i vissa spårare, även om projektet innehåller fler av dem. Du kan till exempel bara tillåta kunder att bara använda tracker HelpDesk Ticket och Bug, så du kan bara ställa in SLA för dessa trackers. Alla andra spårare skulle inte kräva SLA-inställning eftersom de inte skulle skickas in av kunder och därför inte skulle betraktas som HelpDesk-biljetter.

4.2.5 SLA-händelser och rapporter

SLA-rapporter baseras på individuella SLA-händelser. Dessa evenemang kan ses per varje HelpDesk-biljett, kolla helt enkelt in SLA Events i bottenmenyn på en HelpDesk-biljett. När en biljett har besvarats/lösts kan du kolla in dess SLA-event här, som bland annat berättar hur lång tid (i timmar) som faktiskt gått tills det första svaret ägde rum, och du kan direkt jämföra värdet med SLA-svarsuppfyllelse (dvs. tid som krävs för det första svaret) och SLA-uppfyllelse (dvs. tid som krävs för ärendeupplösning) enligt dina SLA-inställningar för just det HelpDesk-projektet. Utöver det ser du direkt vem och när som svarade/löste ärendet och vilket projekt denna biljett tillhör. Tidsrekord visas med positiv eller negativ symbol (+/-), resp. i grön/röd färg för att markera om SLA har kompilerats eller inte.

SLA-händelse skapas bara när en supportbiljett faktiskt besvaras genom att skicka ett e-postmeddelande till en kund, inte tidigare. Att lägga till en kommentar till en biljett leder inte till att SLA -evenemang skapas eftersom det inte är klart om en sådan kommentar bara är ett internt meddelande eller ett svar på kundens begäran.

När en supportbiljett flyttas från ett projekt till ett annat beräknas inte SLA -evenemanget. Biljettens SLA kvarstår från det ursprungliga projektet, där en sådan biljett skapades. SLA -omräkning utlöses av ändring av spårare eller prioritet.

För att se listan (en översikt) över alla SLA-händelser, gå till /easy_sla_events eller klicka på menyalternativet SLA-rapporter i sidofältsmenyn i HelpDesk-huvudpanelen (/easy_helpdesk).

SLA -händelser kan enkelt filtreras enligt olika SLA, anpassade fält eller andra kriterier.

Alla SLA-händelser sammanfattade i övergripande SLA-statistik finns på instrumentpanelen för SLA-rapporter. Som standard är den här instrumentpanelen tillgänglig i den övre menyn i HelpDesk-huvudpanelen. Med hjälp av instrumentpanelen ser du omedelbart den totala andelen misslyckade SLA-svar, misslyckade SLA-lösningar och genomsnittliga förstagångssvar. Eftersom instrumentpanelen är en personlig standardsida som många andra, kan du anpassa alla moduler som visas i instrumentpanelen så att de bättre passar dina behov.

4.2.6 Biljett SLA-rapporter

Utöver ovanstående är det även möjligt att göra SLA-rapporter ovan biljetter.

Från version 11plus.2.0 har biljetter två nya fält:

• Första SLA-svarsuppfyllelse - hämtat från det första SLA-evenemanget på biljetten
  
• Senaste SLA-uppfyllelsen - hämtat från det sista SLA-evenemanget på biljetten

Hur det fungerar

Biljett skapas -> Helpdesk-operatören svarar-> SLA-händelse skapas -> värden från denna SLA-händelse kopieras till ovannämnda attribut för ärendet -> klientsvar tillbaka -> operatörssvar till klient -> ny SLA-händelse skapas - > värdet av SLA revolve fultilment det kopierade till ticket-attributet.

Var ligger värdet

Eftersom själva biljetten innehåller de mest avgörande SLA-rapporteringsdata kan du göra rapporter om SLA-tillfredsställelse direkt ovanför ärenden.
Några exempel:

• Framgångsfrekvens för biljettupplösning
• Linjediagram över absolut antal biljetter med misslyckat SLA-svar/lösning i tid

4.3 Anpassad sidhuvud och sidfot

Den här inställningen gäller HelpDesks e-postkommunikation, dvs kommunikation i e-postgenererade biljetter. Du kan anpassa e-postmeddelanden från olika HelpDesk-projekt, oavsett om det är för företagsidentitetsanvändning, för villkorsspecifikationer eller till och med sekretessfriskrivningar.

4.4 varningar

För att förhindra att SLA kränks finns det möjlighet att använda automatiska varningar som meddelar berörd personal om hotande problem i form av försenade biljetter.

En annan typ av varningsklockor tillbringade tid i projekt, där klienterna har förbetalt en viss mängd timmar support (som förklaras i kapitel 4.1).

Inställningsanteckningar:

• Övervaka förfallodatum för supportbiljetter – för att vara mer exakt Sinom tid enligt SLA. Om det är aktiverat genereras varningar när SLA -tidsfristen närmar sig. Ytterligare inställningar förklaras nedan
• Övervaka supportbiljetter som spenderas i rätt tid – titta på spenderad tid på projekt med specificerade förbetalda månatliga timmar
• Lista över varningar som måste ha en mottagare - dessa är förkonfigurerade varningar, som bara behöver ange en e-postadress, dit aviseringarna ska skickas
• Lista över konfigurerade varningar – varningar utan parameter som saknas
• Genom att klicka på varje varning ser du de förkonfigurerade parametrarna med möjlighet att redigera dem
• Varning/varning: meddelandets allvar
• Supportbiljetter förfallotid – varna klockor SLA löser deadline (biljettstängning)
• Supportbiljetter timmar till svar – svarsdeadline för svarstider för alarmklockor (första statusändringen)
• Supportbiljetter förbetalda timmar – varna tittar på att spendera förbetalda månatliga timmar på projektet

Tittade timmar i den senaste varningen är de som är inloggade på biljetter, som finns i spårare som nämns i projektets HelpDesk-inställningar.

Exempel: Standardspåraren för projektet är HelpDesk Ticket. Vissa SLA är konfigurerade för tracker Bug. Projektet innehåller andra spårare (Task, Feature development), som inte används på biljetter. I sådana fall är de förbetalda timmarna endast giltiga för HelpDesk Ticket och Bug. Tid som spenderats på andra spårare tas inte med i beräkningen för denna varning.

4.5 Uppdatera/ta bort

Uppdatera – spara ändringar som gjorts i HelpDesk-inställningarna för projektet
Ta bort – ta bort projektet från HelpDesk. Detta betyder inte att projektet som helhet tas bort, det kommer bara att göra det ta bort anslutningen av projektet till HelpDesk.

 

5 Biljetthantering

Efter den enorma mängd inställningar som förklarats fram till nu är det dags att titta på några praktiska konsekvenser innan vi återkommer med en annan uppsättning inställningar. Vi börjar med ett enkelt användningsfall för att visa hur biljetten fungerar och hoppa över några funktioner. De kommer att förklaras senare.

5.1 E-postgenererade biljetter

För korrekt hantering av biljetter skapade via e -post måste du kontrollera att standardfält "Email till"Och"e -post cc"är aktiva. Du kan checka in det Mer » Administration » Spårare » HelpDesk-biljett » Standardfält. Om dessa standardfält saknas måste de ha inaktiverats av administratören.

5.1.1 E-post bearbetas av Easy Redmine och biljett skapas i det fastställda projektet

Anmärkningar:

• e-post till: Avsändaren av e-postmeddelandet från vilket biljetten skapades
• Specifikation för brevlådan, från vilken uppgiften skapades
• SLA-värden – om de överträds är de rödmarkerade
• Analyserad e-post – Detta är textinnehållet i e-postmeddelandet. Bilder visas inte direkt i den här vyn, på grund av prestandaoptimering (särskilt när biljetten har många svar och var och en innehåller en signatur med företagets logotyp, skulle biljetten ta smärtsamt lång tid att ladda på grund av den ökande storleken på var och en av nästa svar)
• Hela e-postmeddelandet tillgängligt som en bilaga – om det ursprungliga e-postmeddelandet innehåller bilder kan du se det direkt i Easy Redmine.
  

5.1.2 Skriv ett svar och uppdatera biljetten

För att uppfylla SLA -svaret måste vi ändra status och svara till klienten för första gången. För följande exempel, håll ett öppet sinne om biljettkommunikationen, det är bara för att demonstrera hur kommunikationen fungerar tekniskt.

Chefen skrev ett svar till kunden om att ta emot biljetten, tilldelade den till en operatör och ändrade status. Svaret skickas till klienten (e -post till) när du markerar rutan.

Skicka snabb e -post till kund från mall

Du har två alternativ för att skicka ett e-postmeddelande till klienten. När du uppdaterar en HelpDesk-biljett finns alternativet "Skicka snabbt e-post till kund från mall" som låter dig välja en e-postmall för ditt svar för ärendeavsändaren. När en mall väljs skickas e-postmeddelandet direkt och därmed krävs inga fler åtgärder. När ingen mall är vald har du fortfarande möjlighet att välja mall och bekräfta sändning av e-post i nästa steg som vanligt (kryssa i kryssrutan "Skicka e-post till kund (med förhandsgranskning) längst ner och spara). Syftet med detta Funktionen är främst att spara tid när du skickar e-post till kunder.

5.1.3 Skicka en uppdatering till extern e-post (e-posta till)

Genom att klicka på Spara sparar du de uppdateringar som gjorts på biljetten och du kommer till dialogen för att skicka svaret till klienten.

Anmärkningar:

• E-postmall – om du har konfigurerade e-postmallar kan du välja en. Eller så kommer en mall att förinställas enligt status. Denna funktion kommer att förklaras i ytterligare kapitel
• E-postavsändare – detta kommer att visas för klienten som FRÅN. Inställningen av befolkningen i detta område kommer att förklaras i ytterligare kapitel
• E-postämne – anpassat eller förinställt enligt e-postmallen. Som standard fylls den av ärendets ämne
• E-postmottagare – avsändare av det ursprungliga e-postmeddelandet. Om det fanns andra mottagare av det ursprungliga e-postmeddelandet i CC eller TO, kommer de också att läggas till i det här fältet.
• E-postsvar till – detta är alltid HelpDesk-brevlådan som det ursprungliga e-postmeddelandet skickades till
• E-postkopia – du kan lägga till andra mottagare
• E-posttext – om en mall inte har valts kommer den att bestå av den sista kommentaren på biljetten och den ursprungliga e-posttexten. Innehållet är redigerbart.
• Bilagor – du kan välja bilagor att skicka med e-postmeddelandet. Det kan vara några nyare e-postmeddelanden eller nya filer du laddade upp när du uppdaterade biljetten
• Skicka e-post – e-post skickas till alla mottagare
• Skicka inte e-post – du kommer att återgå till detaljer om biljetten

När vi tittar tillbaka på biljettdetaljer ser vi att SLA -svaret har försvunnit eftersom det gjordes.

5.1.4 Klienten svarar tillbaka – hur e-postmeddelandena kopplas ihop med en biljett

Klienten har fått ditt svar och svarar tillbaka. Svaret kommer att läggas till som en kommentar från en anonym användare (en användare som inte är registrerad i systemet).

Låt oss förklara här hur kunde klientens svar hitta rätt biljett.

När chefen i föregående steg skickade extern e-post till klienten innehöll e-postmeddelandet en dold rubrik (som alla e-postmeddelanden gör) med ärendets ID. Genom att svara på e-postmeddelandet fanns denna rubrik även i kundens svar och därför identifierade HelpDesk det och la till svaret på ärendet med samma ID.

Här är alla sätt som mottagna e -postmeddelanden är kopplade till biljetter i systemet.

1. E-postens dolda rubrik, där uppgifts-ID: t sparas
2. Ämnet för e-postmeddelandet, där en kombination av "#" och uppgifts-ID söks
3. Om detta inte hittas söks ämnet efter ett nummer ensamt

Följaktligen, även om klienten skriver ett nytt e-postmeddelande till en HelpDesk-brevlåda och lägger till ärendenumret (uppgifts-ID) i ämnet, kommer det fortfarande att paras. Som i följande exempel.

Nytt e-postmeddelande till en HelpDesk-postlåda:

Efterföljande anteckning i biljetten:

5.1.5 Det sista svaret – biljetten stängs

Ett sista svar från operatören, med vilken biljetten är stängd. Efter avslutad biljett försvinner också SLA för lösning från biljettdetaljen.

Om klienten svarar igen kommer biljetten att öppnas igen till en definierad status (denna inställning kommer att förklaras ytterligare).

5.1.6 Biljettägarefält

Fältet för biljettägare är ett valfritt standardfält avsett att användas med HelpDesk-biljetter. Med sin rullgardinslista låter den dig välja en användare av alla interna användare som redan har skapats, och denna användare anses vara ägaren till biljetten. Fältet kan aktiveras eller inaktiveras för alla spårare där du kan behöva ha det (gå till Administration » Trackers » HelpDesk-biljett » kryssa i fältet och spara). Som standard är biljettägarens fält inaktiverat så HelpDesk-ansvariga måste gå till Administration för att aktivera det för en specifik spårare. Baserat på detta fält på HelpDesk-biljetter kan HelpDesk-ansvariga enkelt se hur många biljetter som tagits emot, stängts/lösts eller uppdaterats enligt deras biljettägare. Så detta kan avsevärt förbättra/förenkla HelpDesk-insikter (dashboards, statistik) och rapporter under en definierad tidsperiod. Arbetsflödesinställningar, såväl som åtgärdsknappar, kan tillämpas på biljettägarefältet precis som alla andra standardfält eller anpassade fält.

5.1.7 E-posta till, cc välj från olika datakällor

I fält E-postadress till och E-postadress cc tillagd möjlighet att söka efter e-postmeddelanden från datakällor:

• Personliga kontakter (CRM)
  
• Intressenter
  
• Konton (CRM)
  
• HelpDesk-användare (Helpdesk)
  

Den här funktionen är inaktiverad som standard. För att aktivera det, gå till Administration >> Plugins >> E-postfält autoslutförande - Redigera och aktivera funktionen E-postfält autoslutförande och nödvändiga dataresurser.

Utan att aktivera någon av dataresurserna söker funktionen naturligt igenom användare.

Hur det fungerar

Om det är aktiverat fungerar uppgiftsfälten E-post till och cc som autoslutförande.

5.2 Internt skapade biljetter

Om klienten skickar in biljetter direkt i ditt system, kan arbetsflödet definieras som om du arbetade med andra uppgifter. Du kommer att tillåta kunden att skapa HelpDesk Ticket eller Bug. De kommer initialt att vara i standardstatus (oftast kallas de helt enkelt Ny). Sedan går kommunikationen fram och tillbaka mellan klient och operatör genom serier av biljettuppdateringar och genom byta mottagare, vilket är nödvändigt för att hålla alla användare aktiva i kommunikationen. SLA: er övervakas som i den e -postgenererade biljetten Svar: Statusändring; Lösa: Stänga biljetten.

5.3 Biljetter skapade via REST API

Det finns möjlighet för uppgifter/biljetter skapade via REST API (till exempel från ett webbformulär) att se ut som HelpDesk-biljetter skapade från e-post. Skicka bara "easy_helpdesk_mailbox_username"parameter via API, till exempel: issue [easy_helpdesk_mailbox_username] = 'support@company.com ". Detta gör att den nyskapade uppgiften ser ut som en HelpDesk-biljett från den angivna e-postadressen, SLA-inställningarna kommer att tillämpas i enlighet med detta och ett tackmeddelande kommer att skickas till avsändaren.

 

6 e-postmallar

Det förebådades redan under förra kapitlet, men utan en ordentlig förklaring av bearbetningen skulle det inte vara så lätt att förstå som det blir nu. Det senaste HelpDesk-menyalternativet har vi inte introducerat.

E -postmallar ger en viss nivå av automatisering och formalisering av kommunikationen med kunder, genom vilka de erkänner ditt företag som ett professionellt hanterande.

En viktig egenskap hos e -postmallar är det de är konfigurerade per brevlåda, du kan inte använda en mall från en brevlåda IT@mycompany.com för e -postmeddelanden som skickas till support@mycompany.com.

6.1 Skapa en e-postmall

Det finns faktiskt två typer av e -postmallar: autosvar och standardmall. Eftersom de inte är konfigurerade annorlunda kommer vi att förklara båda fallen samtidigt.

6.1.1 Lägg till ny mall

6.1.2 Grundläggande attribut

Inställningsanteckningar:

• Använd för brevlåda – vilken brevlåda kommer att ha denna mall tillgänglig
• Uppgiftsstatus – enligt denna status kommer mallen att vara förifylld i dialogen när svaret skickas till ett externt mail (se kapitel 5.1.3.)
  • Om du vill använda mallen som autosvar på nyskapade biljetter från e -post, ställer du in status som standard (som konfigurerad i administration >> uppgiftsstatus). När en biljett skapas från ett e -postmeddelande kommer autosvaret enligt den här mallen att skickas omedelbart. Den kan användas för att bekräfta för klienten att biljetten skapades och vad nästa steg blir.
  • Du kan lämna statusen tom, i så fall kommer den aldrig att fyllas i automatiskt i skicka e -postdialogen, men användarna kommer att kunna välja den manuellt
• Ämne – vad kommer ämnet att innehålla
• Det rekommenderas att inkludera uppgifts-ID i autosvaret – om du har många biljetter med samma klient kommer du att bättre kunna skilja mellan dem när du pratar med klienten
• Du kan också använda det faktiska ämnet som använde klientens ursprungliga e -post

6.1.3 Dynamiska tokens och posttext

Dynamiska tokens kan användas för att tillhandahålla särskild biljettinformation till klienten. I en mall anges de som en av nedanstående, och i e -postmeddelandet som skickas till klienten kommer de att ersättas av det verkliga värdet från biljetten.

Ett enkelt exempel på ett autosvar.

6.1.4 Viktiga dynamiska tokens

Om du ska använda e -postmallar effektivt är det nödvändigt att inkludera token %task_note% i mallen. Den kommer att använda den kommentar du senast lade till biljetten och omge den av den andra texten i mallen.

Om du vill lägga till en företagssignatur i de utgående e -postmeddelandena använder du token %user_signature%. Den kommer att använda HTML -signaturen för den nuvarande användaren (som uppdaterar biljetten) som kan ställas in på användarens profil.

Exempelvis: Låt oss ta fram en enkel mall som innehåller kommentarer från supportoperatören, total tid som spenderats på biljetten och företagets signatur för användaren.

Så här ser mallen ut.

Så här skriver operatören uppdateringen av kommentarbiljetten.

Och detta kommer att vara det skickade e -postmeddelandet enligt mallen.

Notera: När du använder e -postmallar tillsammans med särskild rubrik och grund för e -postmeddelanden på ett visst projekt (kapitel 4.3.), Lindar projekthuvudet och sidfoten hela e -postmeddelandet till klienten, inte bara e -postmallen eller bara den del som läggs till av sista kommentaren.

6.2 Standard e-postmall

Det är möjligt att välja en HelpDesk e-postmall som standard. Det betyder att när du skickar en kommentar till en kund är det större chans att en mall är förvald (vilket ger mindre manuellt arbete för supportoperatören).

Beteendet är följande:

Förutsättningar

• en e -postmall kan ställas in som standard
• varje e -postmall måste ha en länkad brevlåda
• du kan ha fler brevlådor i ditt system
• e -postmallen kan vara (men det krävs inte) ansluten till en viss status

situationer

• en biljett skapas manuellt (inte från e -post) - mall från a är förvalda enligt status; om den inte hittas är standardmallen förvald
• en biljett skapas från en annan brevlåda än den som standardmailmallen används med – mall med denna brevlåda är förvald baserat på status (samma som för närvarande) => ingen mall är automatiskt förval om den använder status som det inte finns någon mall för
• en biljett skapas från brevlådan som standardmallen används med – mallen är förvald baserat på status – om ingen sådan mall hittas är standardmallen förvald

Dölj SLA -data

Information om SLA -svar och lösningstid för uppgiftsdetaljer kan döljas för utvalda användartyper (Administration >> Användartyper >> Redigera).

SLA kan också döljas för specifika användare (Administration >> Användare >> Redigera).

En användare ser inte SLA: erna om minst en av inställningarna för deras användare eller användartyp är aktiverad.

Sidhuvud och sidfot på HelpDesk-e-postmeddelanden

Globalt inställda sidhuvud och sidfot för e-postmeddelanden (Administration >> Inställningar >> E-postmeddelanden) kommer inte längre att vara en del av e-postmeddelanden som skickas från HelpDesk.

För att lägga till sidhuvud och sidfot för HelpDesk-e-postmeddelanden, gå till HelpDesk-inställningarna för ett specifikt projekt (Projekt >> Inställningar >> HelpDesk).

Verifiera databaskonfiguration

Uppgraderingstester avslöjade en inkompatibilitet i två konfigurationer som tidigare samarbetade korrekt.

Se till att både databasservern och config/database.yml har samma (rekommenderade) utf8mb4 -uppsättning.

1) etc/my.cnf

character_set_server = utf8mb4
collation_server = utf8mb4_unicode_ci

2) config/database.yml

produktion:
  adapter: mysql2
  databas: lätt
  värd: 127.0.0.1
  användarnamn: lätt
  lösenord: "EASY_STRONG_PASSWORD"
  kodning: utf8mb4

Om dessa inte är inriktade kommer du inte att kunna använda något autofullständigt fält, t.ex. Hoppa till projekt, val av mottagare, filter, etc.

Slutligen måste du köra detta kommando för att ställa in alla tabeller som kodar korrekt.

för DB i YOUR_DB_NAME; do
  för TABELL i `mysql -e" använd $ {DB}; visa tabeller; " --batch --skip-kolumn-namn | xargs '; do
    eko "Konverterar $ {DB}. $ {TABLE}"
    mysql -e "ändra tabell $ {DB}. $ {TABELL} KONVERTERA TILL teckenuppsättning utf8mb4 collate utf8mb4_unicode_ci;"
  gjort
gjort

I stället för YOUR_DB_NAME anger du namnet på din databas.

Anmärkningar: Korrekt databaskonfiguration är ett generellt krav för att köra en webbapplikation felfritt. Det är inte bara ett specifikt krav för denna nya version av Easy Redmine.

Anpassade designavbrott (ingen CSS)

Om du hade anpassat varumärke (logotyp, färger, bakgrund) och efter uppgraderingen gick det sönder - saknar alla stilar, sidan ser trasig ut, du kan enkelt fixa det.

Gå till sida /easy_theme_desings >> hitta din design >> kompilera om >> ladda igen. Det kommer att reparera designen och ladda stilarna.

 

7 Globala inställningar

Nu när vi har gått igenom hela användbarheten kan vi avsluta resten av inställningarna som återstår att förklara.

Inställningsanteckningar:

• Avsändare – vilket e-postmeddelande som anges som FRÅN på biljettsvar till klient (i relation till kapitel 5.1.3.)
  • Aktuell inloggad användare – användare som uppdaterar ärendet
  • Standard från e-postavisering – e-post som används för att skicka standardaviseringar från systemet till användare. Sätt in Administratör >> inställningar >> e -postaviseringar
  • Brevlådeadress – e-post, som mottog originalposten från klienten
  • Den här inställningen är löst knuten till den sista kryssrutan Tillåt anpassad avsändare – om den är aktiverad kan du ställa in en anpassad e-post som avsändare i projektets HelpDesk-inställningar. Om ett projekt har ett e-postmeddelande ifyllt i inställningen kommer det att åsidosätta avsändarinställningen
• Aktivera uppdatering av uppgiftsattribut – om det är aktiverat är det möjligt att ändra vissa attribut på biljetten via e-post. Till exempel genom att skriva prioritet: Hög i brevkroppen skulle du ändra prioriteten därefter. Detta är en ganska avancerad funktion och det rekommenderas inte att använda med klienter
• Acceptera autogenererade e-postmeddelanden – till exempel nyhetsbrev
• Ignorera CC för mottagna e-postmeddelanden – om aktiverat, bearbetas e-postmeddelanden i CC inte och används i fältet "Email till"av biljetten (kapitel 5.1.3. anteckning om e -postmottagare)
• Ändra status efter kundsvar på – varje gång en kund skriver ett svar som uppdaterar ärendet kommer status att ändras i enlighet med detta. Detta är särskilt användbart när biljetter försätts till en stängd status efter att ett svar skickats av operatören. Såvida inte kunden svarar med någon ytterligare fråga, kommer biljetten att förbli stängd och dold från de aktiva listorna. När klienten svarar öppnas biljetten igen och går tillbaka till aktiv kö av öppna biljetter
• Stäng av SLA för biljett när status är – dessa är statusar, när SLA-deadline inte är fastställd, eftersom biljetten väntar på input från klienten, utan vilken operatören inte har någon chans att ge support
• Räkna SLA för biljett när status är – när SLA normalt mäts. Med dessa funktioner kan du snyggt ställa in biljettcykeln. Till exempel ber operatören kunden om mer information, sätter status till passiv och SLA är pausad. Efter klientens svar ändras status till konsultation och SLA räknas om enligt den återstående tiden till SLA -tidsfristen, när biljetten besvarades

I version 12 fick Helpdesk ytterligare ett intressant mått - Biljetter löses av support. Du kommer att kunna rapportera totalt antal eller andel biljetter som aldrig har lämnat supportteamet.

Hur det fungerar

1. Först måste du definiera vilka användare som är medlemmar av supporten i Helpdesk >> Helpdeskinställningar - Lösas av support inställningar
   
   
   
2. Inställningar för deluppgifter/relaterade uppgifter avgör om biljetter som lösts av support kan eller inte kan innehålla deluppgifter eller relaterade uppgifter
3. Nu rekommenderar vi att du trycker på knappen i helpdesk-menyn - Beräkna om
   
   Detta kommer att utvärdera biljetter från de senaste 90 dagarna
4. Slutligen, gå till uppgiftslistan och hitta filtret Lösas av support
   
   

Det här filtret visar biljetter som endast tilldelats supportmedlemmar (enligt inställningen i punkt 1). Baserat på inställningarna i punkt 2 kan biljetter som innehåller deluppgifter eller relaterade uppgifter räknas som lösta av supporten eller inte.

 

8 Filtrera "Behöver reaktion"

"Behöver reaktion" är ett attribut för HelpDesk-biljetter och CRM-ärenden. Som standard är detta attribut inställt på "Nej". Det kommer att ändras till "Ja" när en biljett/fodral tilldelas en person som svarar på det genom att skicka ett e -postmeddelande istället för att tilldela den tillbaka till avsändaren i Klientzon eller Easy Redmine. I ett sådant fall förblir mottagaren av biljetten/ärendet oförändrad och därför kan den avsedda mottagaren inte märka att uppdateringen har gjorts. För att förhindra detta bör mottagaren regelbundet kontrollera alla objekt med attributet "Behöver reaktion" inställt på "Ja" så att han lätt får veta att det är något nytt han bör kontrollera eller svara även om det inte är tilldelat honom. Eller så kan du använda den när du behöver för att "markera" någon kundbiljett som du redan svarat på men det är fortfarande lite arbete på den och du måste informera kunden senare igen. Använder sig av "Uppgifter från filter"-modul kan du helt enkelt skapa en ruta på din hemsida, CRM-översikt eller HelpDesk-översikt som den nedan.

 

9 HelpDesk-användare (från version 11+)

Bland de största tillskotten till HelpDesk de senaste åren finns så kallade HelpDesk-användare. Deras syfte är att förenkla hanteringen av klientåtkomst till din Easy Redmine. Det gör det också mycket enklare för kunderna själva att skicka in biljetter och kommunicera med dina operatörer direkt i ansökan.

9.1 Förutsättningar

Hantering av HelpDesk-användare är under behörighet Visa/hantera HelpDesk-användare under HelpDesk-delen i Administration >> Roller och behörigheter.

En annan inställning att kontrollera innan du börjar skapa HelpDesk-användare är Administration >> Sidanpassning >> HelpDesk-användare >> Mallöversikt. Det bör finnas en befintlig sidmall i en grundläggande "starter"-konfiguration. Det är viktigt att det finns en mall som är satt som standard – denna mall kommer att tillämpas automatiskt på nya HelpDesk-användare. Annars skulle dina HelpDesk-användare ha en tom sida efter att de loggat in.

HelpDesk-användarsidan innehåller 3 typer av moduler:

• Nytt ärendeformulär – Det har inga inställningar, bara placera det för största möjliga bekvämlighet för dina kunder.
• HelpDesk-biljetter – lista över biljetter skapade av HelpDesk-användaren. Varje användare kan bara se biljetter som de själva skapat. Denna modul är konfigurerbar, såsom alla andra "list"-moduler i applikationen. Den innehåller fält som är synliga för HelpDesk-användare i biljetter. Om du tänker visa både öppna och stängda biljetter för HelpDesk-användarna rekommenderar vi att du visar dem i separata moduler.
• Anslagstavla – ifall du vill dela lite anpassad information med kunderna.

9.2 HelpDesk användarhantering

Listan över HelpDesk-användare är tillgänglig som en separat post i kontrollknapparna på HelpDesk-instrumentpanelen.

Alla attribut krävs:

• Förnamn
• Efternamn
• E -post = Logga in
• Språk
• Projekt – detta är projektet där biljetter från denna användare kommer att skapas. Endast öppna projekt som är kopplade till HelpDesk kan väljas här.
• Lösenord – under användarskapandet måste du ange ett lösenord med möjlighet att generera lösenordstoken, så att användaren kan ställa in sitt eget lösenord via länk i ett e-postmeddelande. Under användarredigering krävs uppenbarligen ingen lösenordsändring.

Ytterligare behörigheter:

Varje användare kan beviljas ytterligare behörighet att se och hantera alla uppgifter

Visa alla uppgifter = Tillåter helpdesk-användaren att se alla skapade biljetter under samma projekt

Hantera alla uppgifter = Tillåter helpdesk-användaren att redigera specifika fält från redan skapade biljetter (Titel, Beskrivning och även lägga till en ny bilaga, men inte redigera den gamla).

Användningsfall

En kund har ett speciellt projekt för sina biljetter i din helpdesk. Det finns fler användare som loggar in på helpdeskportalen och skickar in biljetter på uppdrag av denna klient. En av dessa användare behöver se alla inskickade biljetter, eftersom hans roll kräver att utvärdera tjänsten som du levererar.

9.2.1 CSV-import

Från version 11plus.2.0 är det möjligt att importera helpdesk-användare via CSV. Kontakta din konsult om detta alternativ.

9.3 Logga in som HelpDesk-användare

HelpDesk-användare loggar in via en annan ingångspunkt än vanliga användare. På inloggningsskärmen under inloggningsknappen kan du hitta en switch. För att hänvisa dina kunder till HelpDesk-inloggning, använd URL /helpdesk/login. Som nämnts ovan används e -post som inloggningsnamn.

VIKTIGT: HelpDesk-användare är tekniskt oberoende av vanliga användare. Du kan använda samma e-post för en vanlig användare och en HelpDesk-användare.
Även om praxis antyder att detta inte borde vara fallet. Du skapar antingen ett HelpDesk-användarkonto eller så bestämmer du dig för att användaren behöver ett fullständigt konto. Båda typerna av konton för en person bör endast användas för teständamål.

Efter inloggning består själva portalen av hemsidan, som konfigurerades av en administratör, men som inte är konfigurerbar av HelpDesk-användaren själva. I det övre högra hörnet kan profilen nås, inklusive redigeringsläge. Bredvid den, logga ut-knappen. Genom att klicka på en befintlig ärende, eller skapa en ny ärende, omdirigeras användaren till ärendedetaljen, där de kan lägga till kommentarer eller bilagor. För att komma tillbaka till hemsidan klickar du bara på logotypen i det övre vänstra hörnet.

HelpDesk-användare har inga roller och behörighetsinställningar och du kan inte ge dem ytterligare åtkomst till vissa områden. Listan ovan är allt de kan komma åt. Du bör inte skicka dem några länkar till objekt i din ansökan. Det skulle bara leda till tillträde beviljas ej meddelande.

9.3.1 LDAP-autentisering för HelpDesk-användare

Från version 11plus.2.0 kan helpdesk-användare autentiseras via LDAP.

Konfigurationen är i Admin >> Plugins >> Helpdesk-användare >> Redigera - Nytt autentiseringsläge.

Formuläret är identiskt med vanlig LDAP-konfiguration, den enda skillnaden är att den gäller för helpdesk-användare => på sidan /helpdesk/login

9.4 Arbeta med biljetter

Ur kundens perspektiv

HelpDesk-användare skapar en biljett via formuläret Ny ärende på sin hemsida. De enda tillgängliga attributen är Ämne, Beskrivning och bilagor. Filosofin är att kunder inte ska oroa sig för organisatoriska frågor när de behöver hjälp från din kundvård. De anger helt enkelt sitt problem och förväntar sig en lösning. Inget projektval, inga kategorier, inga anpassade fält, inget prioritetsval – allt detta är ditt supportteams ansvar.

Biljetten kommer att skapas i ett projekt, som sätts direkt på HelpDesk-användaren. Fält e-post till i ärendet fylls i via e-post från HelpDesk-användaren. Denna användare kommer också att ställas in som HelpDesk-författare av biljetten, vilket är ett dolt attribut (ej relaterat till Författare, som är ett generiskt attribut för alla uppgifter i Easy Project). Detta säkerställer att de alltid kommer att se biljetten, även om du flyttar den till

Hörnsituationer

• Situationen när en uppdragsgivare inte är medlem i projektet kan uppstå i följande fall:
  • mottagaren togs bort från projektet men uppgifterna förblir honom tilldelade,
  • en automatisk ärendeuppdateringsprocess ställs in i HelpDesk-modulen på ett sådant sätt att vissa ärenden automatiskt tilldelas en tidigare projektmedlem.
• Information om SLA -svar visas endast i uppgiftsdetaljen när uppgiften är i standardstatus, som definieras på en respektive spårare.
• Vi rekommenderar starkt att du inte ändrar prioritet för en biljett när biljetten har avbrutit SLA, eftersom en sådan åtgärd skulle påverka den korrekta beräkningen av SLA på den biljetten negativt.