Biljettlivscykel och kommunikation med kunder i Helpdesk

Beskrivning

I den här artikeln kommer vi att gå igenom biljettprocessen beroende på hur en biljett skapas i Helpdesk och enligt kundens åtkomst till ditt system. Du hittar tips om vad du ska hålla utkik efter i olika biljettprocesskonfigurationer.

Den här artikeln innehåller tips och förslag på olika konfigurationer, men inte direkt hur konfigurationerna är gjorda. Här är de relevanta artiklarna:

• Help Desk dokumentation
• Underkapitel Helpdesk-användare
  
• Ägarens instruktionsbok (arbetsflöde, aviseringsinställningar)
  

Tre huvudsakliga kommunikationsvägar

Börjar med ett schema för biljettens livscykel i enkla situationer - när biljetten följer bara en typ av flöde från början till slut.

• E-postadress
• Fullständig användare i applikationen
• Helpdesk-användare i applikationen
  

Skapande och vidare kommunikation inom en biljett

Biljettskapande och vidare kommunikation kan kombinera ovanstående tillvägagångssätt.
Det är möjligt att skapa en biljett via e-post och sedan följa upp i applikationen (antingen av full användare, eller helpdesk-användare). Det går även att skapa en biljett via systemet och sedan bara följa mejl.

Exempelvis 1

1. Biljetter skapas via e-post - klienten skickar ett nytt e-postmeddelande till helpdeskadressen.
2. Klienten loggar in i systemet och kan se biljetten där, eftersom han är biljettförfattaren.
3. Kunder kan ändra status och andra fält samt lämna kommentarer, enligt deras tillstånd.

 Exempelvis 2

1. Klienten loggar in i systemet och skapar en ny biljett.
2. Klienten får uppdateringar via e-post och tittar bara på dessa uppdateringar och känner inte behov av att logga in i systemet längre.

Exempelvis 3

1. Kunden skapar en biljett via helpdeskportalen
2. Kunden bestämmer sig för att bara följa e-postmeddelanden och loggar inte längre in på portalen
3. Kunden bestämmer sig då för att han vill följa via portalen, loggar I och lägger in några svar via portalen.

För dina kunders bekvämlighet kan du bestämma med vilka metoder du vill tillåta dem att skapa och/eller uppdatera biljetter. Men viktigast av allt, du måste täcka alla möjliga situationer, så att biljetter inte försvinner in i en återvändsgränd. Arbetsflöde och andra konfigurationer ger alla nödvändiga alternativ.

Vanliga problem

Klienten svarar på vanliga uppgiftsmeddelanden, men svaret behandlas inte korrekt.

Den här historien rör exempel 2. Kunder tror att de svarar på en ärende via e-post, men e-postmeddelandet är inte ihopkopplat med den befintliga biljetten och istället skapas en ny, eller så når e-postmeddelandet inte systemet alls. Klienten svarar på ett meddelande eller skapar av misstag ett nytt e-postmeddelande.

Orsak: Inställningar för e-postmeddelanden förväntar sig inte svar på meddelandeadressen.

Lösning: Kundens svar måste skickas till en helpdesk-specifik adress och måste innehålla ärendenumret. E-postadress för meddelanden (Administration >> Inställningar >> E-postmeddelanden >> E-postadress för meddelanden (FRÅN)) kan vara densamma som en helpdesk-e-postadress för att fånga upp eventuella svar från kunder och koppla ihop dem med biljetten som meddelandet skickades från.

Ett annat alternativ är att helt enkelt inaktivera vanliga e-postmeddelanden till klientanvändarna. De enda e-postmeddelanden från biljetter de skulle få skulle aktivt skickas av operatörerna via helpdesk-e-postmallar.

Nyckelalternativ: Dina kunder kommer naturligtvis att frestas att svara på alla e-postmeddelanden de får. Se till att de bara får meddelanden som svar kan behandlas korrekt.

Kunden ändrade biljett till "felaktig" status

Detta sker oftast i situationer när klienten har en fullständig användare i applikationen (istället för Helpdesk-användare). Klienten kan ha möjlighet att redigera många fält, inklusive status och kan misstolka innebörden av olika statusar. Eller å andra sidan kanske inte ändrar status, när du förväntar dig att den ska ändras.

Orsak: Kunden ansvarar för att ställa in korrekt status. 

Lösning: Detta är ett tydligt antimönster, klienten ska inte behöva komma ihåg några regler för uppgiftsstatus. 

En lösning är att byta klientkonto till Helpdesk-användare, istället för fulla användare. Helpdesk-användare kan skapa biljetter och lägga in kommentarer i befintliga biljetter, statusändringar baseras på Helpdesk-konfigurationer, så det finns ingen chans att klienten "bryter" någon korrekt process. Helpdesk-användares biljettuppdateringar är praktiskt utformade för att följa helpdesk-e-postkommunikationens logik och inställningar. Den enda skillnaden är att användaren faktiskt kan se och arbeta med en fysisk form av biljetten.

Om du behöver behålla alla användare för dina kunder, är vårt förslag att helt inaktivera alla statusändringar (eller andra fältändringar), vilket kan bryta några av dina interna processer. Använd andra sätt att spåra biljetter som behöver uppdateras - till exempel efter fält Uppgift senast uppdaterad (datum för senaste uppdatering), Senast uppdaterad av (vem gjorde den senaste uppdateringen), kan du visa den senaste kommentaren på en biljett i listan, så att det är tydligt att en klient gjorde uppdateringen.

Ett lite mer komplicerat scenario är från exempel 1, när du tillåter ärendekommunikation via e-post, men även låter klienter logga in av full användare. Här är vad du ska hålla utkik efter:

• Statusändring efter klientsvar via e-post har ställts in i globala helpdeskinställningar
• Det finns ingen upprätthållande av statusändringar för inloggade användare - det finns alltid alternativet att behålla status som den är

I det här fallet bör du se till att dina svarsköer innehåller båda typerna av situationer, uppdaterade via e-post (t.ex. filter för en specifik status), och biljetter uppdaterade av klienter från applikationen (t.ex. biljettlista med kolumn Sista kommentaren).

Nyckelväg: Kunden ska aldrig oroa sig för dina interna processer, de behöver bara en plats att skicka in sina problem och kommunicera med dig, processerna är på dig och applikationen har olika alternativ för att sätta den tätt.

Blandar fulla användare och helpdesk-användare

Detta är bara en stark varning för att inte kombinera lösningar som aldrig var tänkta att kombineras. Du kan bestämma om du vill använda 

• Helpdesk-användare - gratis, med hårdkodad begränsad åtkomst, eller
  
• Fullständiga användare - vanliga licensierade användare, där du bestämmer vad de har tillgång till

, men du bör inte använda båda samtidigt, särskilt för samma klienter. Tekniskt sett är fullanvändare och Helpdesk-användare inte på något sätt anslutna. De har till och med en annan inloggningssida. De representerar ett annat fält för uppgifter (författare vs helpdeskförfattare). Så det finns ingen anledning att förvirra din klient genom att ge dem båda åtkomstalternativen.

När det gäller dina interna processer är det tekniskt möjligt att ge vissa kunder fullständiga användare, och till andra bara helpdesk-användare. Detta kräver dock exakta processbeskrivningar och utbildningar för dina agenter för att säkerställa att de inte kommer att blanda ihop behandlingen av biljetter från dessa mycket olika kanaler. På grund av dess organisatoriska svårighet rekommenderar vi starkt att endast välja ett alternativ för klientåtkomst.

Sammanfattning

Låt oss återföra den tidigare informationen till en smältbar form. Här är en tabell över situationer som kan uppstå baserat på typen av åtkomst för dina klienter till ditt system.

Klientåtkomst till applikationen	Alternativ för att skicka in biljett (klient)	Aviseringar från biljett (agent)	Alternativ för att uppdatera biljett (klient)	Våra rekommendationer
Utan tillgång	Skicka e-post till en helpdesk-e-postadress.	Agent skickar e-post via mall från biljetten.	Svara på mejlet från agenten Skicka nytt e-postmeddelande som innehåller #[ticket_id] till helpdesk-e-postadressen (sällsynt, men möjligt)	Se till att e-postmallar innehåller biljett-ID i ämnet. Och att agenter använder korrekta mallar för varje situation Inkommande biljettköer bör baseras på statusar som konfigurerats i Helpdesk-inställningarna
Fullständig användare	Skapa en biljett i systemet via knappen "ny uppgift". Skicka e-post till helpdesk-e-postadressen	Standardsystemmeddelande (rekommenderas inte) Agent skickar e-post via mall från biljetten	Lägg till kommentar direkt på biljettdetaljen Svara på mejlet från agenten Skicka nytt e-postmeddelande som innehåller biljett-ID till helpdesk-adress (sällsynt, men möjligt)	Inaktivera vanliga systemmeddelanden från biljetten Skicka dem endast helpdesk-e-post från mallar Om du vill aktivera systemaviseringar, se till att de skickas från en e-postadress som är ansluten till helpdesk (för att bearbeta svar) Tillåt inte statusändringar för klientanvändare i programmet Underhåll inkommande biljettköer för att räkna med biljetter som har uppdaterats av klienter från applikationen på alla tillåtna sätt Om du bestämmer dig för den här typen av åtkomst ska du inte implementera Helpdesk-användare
Helpdesk-användare	Skapa en biljett i helpdeskportalen Skicka e-post till helpdesk-e-postadressen	Agent skickar e-post via mall från biljetten.	Lägg till kommentar direkt på biljettdetaljen Svara på mejlet från agenten Skicka nytt e-postmeddelande som innehåller biljett-ID till helpdesk-adress (sällsynt, men möjligt)	Se till att e-postmallar innehåller biljett-ID i ämnet. Och att agenter använder korrekta mallar för varje situation Inkommande biljettköer bör baseras på statusar som konfigurerats i Helpdesk-inställningarna