Billetlivscyklus og kommunikation med kunder i Helpdesk
Introduktion
I denne artikel vil vi gennemgå billetprocessen afhængigt af den måde en billet oprettes på i Help desk og i henhold til kundens adgang til dit system. Du vil finde tips om, hvad du skal være opmærksom på i forskellige billetproceskonfigurationer.
Denne artikel indeholder tips og forslag til forskellige konfigurationer, men ikke direkte hvordan konfigurationerne er lavet. Her er de relevante artikler:
- Help Desk dokumentation
- Brugervejledning (arbejdsgang, meddelelsesindstillinger)
Tre hovedkommunikationsveje
Starter med et skema over billetlivscyklus i ligetil situationer - når billetten følger kun én type flow fra start til slut.
- Fuld bruger i applikationen
- Helpdesk-bruger i applikation
Oprettelse og videre kommunikation inden for en billet
Billetoprettelse og yderligere kommunikation kan kombinere ovenstående tilgange.
Det er muligt at oprette en billet via e-mail og derefter følge op i applikationen (enten af fuld bruger eller helpdesk-bruger). Det er også muligt at oprette en billet via systemet og så kun følge mails.
Eksempel 1
- Billetter oprettes via e-mail - klienten sender en ny e-mail til helpdesk-adressen.
- Klienten logger ind i systemet og kan se billetten der, da han er billetforfatter.
- Kunder kan ændre statusser og andre felter samt efterlade kommentarer i henhold til deres tilladelser.
Eksempel 2
- Klienten logger på systemet og opretter en ny billet.
- Klienten modtager opdateringer via e-mail og ser kun disse opdateringer og føler ikke længere behov for at logge ind på systemet.
Eksempel 3
- Kunden opretter en billet via helpdesk-portalen
- Klienten beslutter, at han kun vil følge e-mails og logger ikke længere ind på portalen
- Klienten beslutter sig herefter for at følge med via portalen, logger I og indtaster nogle svar via portalen.
Af hensyn til dine kunders bekvemmelighed kan du bestemme, med hvilke metoder du vil tillade dem at oprette og/eller opdatere billetter. Men vigtigst af alt skal du dække alle mulige situationer, så billetter ikke forsvinder ind i en blindgyde. Workflow og andre konfigurationer giver alle de nødvendige muligheder.
Almindelige problemer
Kunden svarer på almindelig opgavebesked, men svaret behandles ikke korrekt.
Denne historie vedrører eksempel 2. Kunder tror, de svarer på en billet via e-mail, men e-mailen er ikke parret med den eksisterende billet, og i stedet oprettes en ny, eller e-mailen når slet ikke systemet. Klienten svarer på en meddelelse, eller ved en fejl opretter en ny e-mail.
Årsagen: Indstillinger for e-mailmeddelelser forventer ikke svar på meddelelsesadressen.
Løsning: Kundens svar skal sendes til en helpdesk specificeret adresse og skal indeholde billetnummeret. Notifikations-e-mailadresse (Administration >> Indstillinger >> E-mail-notifikationer >> Notifikations-e-mail-adresse (FROM)) kan være den samme som en helpdesk-mailadresse for at fange eventuelle svar fra klienter og parre dem med den billet, hvorfra meddelelsen oprindeligt blev sendt.
En anden mulighed er simpelthen at deaktivere almindelige e-mail-meddelelser til klientbrugerne. De eneste e-mails fra billetter, de ville modtage, ville blive aktivt sendt af operatørerne via helpdesk-e-mailskabeloner.
Key takeway: Dine kunder vil naturligvis blive fristet til at svare på alle e-mails, de modtager. Sørg for, at de kun modtager beskeder, som svar kan behandles korrekt.
Kunden ændrede billet til "forkert" status
Dette sker for det meste i situationer, hvor klienten har en fuld bruger i applikationen (i stedet for Helpdesk-bruger). Klienten kan have mulighed for at redigere mange felter, inklusive status og kan misfortolke betydningen af forskellige statusser. Eller på den anden side måske ikke ændre status, når du forventer, at den bliver ændret.
Årsagen: Klienten er ansvarlig for at indstille korrekt status.
Løsning: Dette er et klart anti-mønster, klienten skal ikke skulle huske nogen regler for opgavestatus.
En løsning er at skifte klientkonto til Helpdesk-brugere i stedet for fuldbrugere. Helpdesk-brugere kan oprette billetter og indtaste kommentarer i eksisterende billetter, statusændringer er baseret på Helpdesk-konfigurationer, så der er ingen chance for, at klienten "bryder" en korrekt proces. Helpdesk-brugeres billetopdateringer er praktisk taget designet til at følge helpdesk-e-mailkommunikationslogikken og -indstillingerne. Den eneste forskel er, at brugeren faktisk kan se og arbejde med en fysisk form af billetten.
Hvis du har brug for at beholde de fulde brugere for dine kunder, er vores forslag at deaktivere alle statusændringer (eller andre feltændringer), som kan ødelægge nogle af dine interne processer. Brug andre måder at spore billetter, der skal opdateres - for eksempel efter felt Opgave senest opdateret (dato for sidste opdatering), Sidst opdateret af (hvem lavede den sidste opdatering), kan du vise den sidste kommentar på en billet på listen, så det er tydeligt, at en klient har lavet opdateringen.
Et lidt mere kompliceret scenarie er fra eksempel 1, hvor du tillader billetkommunikation via e-mail, men også tillader klienter at logge på af fuld bruger. Her er hvad du skal være opmærksom på:
- Statusændring efter klientsvar via e-mail er indstillet i globale helpdesk-indstillinger
- Der er ingen håndhævelse af statusændringer for loggede brugere - der er altid muligheden for at bevare status som den er
I dette tilfælde skal du sørge for, at dine køer for svar indeholder begge typer situationer, opdateret via e-mail (f.eks. filter for en specifik status), og billetter opdateret af klienter fra applikationen (f.eks. billetliste med kolonne Sidste kommentar).
Key takeway: Kunden skal aldrig bekymre sig om dine interne processer, de har bare brug for et sted at indsende deres problemer og kommunikere med dig, processerne er på dig, og applikationen har forskellige muligheder for at sætte det stramt.
Blanding af fuldbrugere og helpdesk-brugere
Dette er blot en kraftig advarsel om ikke at kombinere løsninger, som aldrig var beregnet til at blive kombineret. Du kan bestemme, om du vil bruge
- Helpdesk-brugere - gratis, med hårdkodet begrænset adgang, eller
- Fuldbrugere – almindelige licenserede brugere, hvor du bestemmer, hvad de har adgang til
, men du bør ikke bruge begge på samme tid, især for de samme klienter. Teknisk set er fuldbruger- og Helpdesk-brugere ikke på nogen måde forbundet. De har endda en anden login-side. De repræsenterer et andet felt på opgaver (forfatter vs helpdesk-forfatter). Så der er ingen grund til at forvirre din klient ved at give dem begge adgangsmuligheder.
Hvad angår dine interne processer, er det teknisk muligt at give nogle klienter fuld brugere, og til andre blot helpdesk-brugere. Dette kræver dog præcise procesbeskrivelser og træning for dine agenter for at sikre, at de ikke blander behandlingen af billetter fra disse meget forskellige kanaler. På grund af dets organisatoriske vanskeligheder anbefaler vi på det kraftigste kun at vælge én mulighed for klientadgang.
Resumé
Lad os sætte den tidligere information tilbage til en fordøjelig form. Her er en tabel over situationer, der kan opstå baseret på typen af adgang for dine klienter til dit system.
| Klientadgang til applikationen | Muligheder for at indsende billet (klient) |
Meddelelser fra billet (agent) |
Muligheder for at opdatere billet (klient) |
Vores anbefalinger |
| Uden adgang | Send e-mail til en helpdesk-e-mailadresse. | Agent sender e-mail via skabelon fra billetten. |
|
|
| Fuld bruger |
|
|
|
|
| Helpdesk bruger |
|
Agent sender e-mail via skabelon fra billetten. |
|
|
