Billettlivssyklus og kommunikasjon med klienter i Helpdesk
Introduksjon
I denne artikkelen vil vi gå over billettprosessen avhengig av måten en billett opprettes på i Help desk og i henhold til kundens tilgang til systemet ditt. Du finner tips om hva du bør se etter i ulike konfigurasjoner av billettprosesser.
Denne artikkelen inneholder tips og forslag til ulike konfigurasjoner, men ikke direkte hvordan konfigurasjonene er laget. Her er de relevante artiklene:
- Help Desk-dokumentasjon
- Brukermanual (arbeidsflyt, varslingsinnstillinger)
Tre hovedkommunikasjonsveier
Starter med et system for billettlivssyklus i rett frem situasjoner - når billetten følger bare én type flyt fra start til slutt.
- Epost
- Full bruker i applikasjonen
- Helpdesk-bruker i applikasjonen
Oppretting og videre kommunikasjon innenfor en billett
Billettoppretting og videre kommunikasjon kan kombinere de ovennevnte tilnærmingene.
Det er mulig å opprette en billett via e-post og deretter følge opp i applikasjonen (enten av fullbruker, eller helpdesk-bruker). Det er også mulig å opprette en billett via systemet og deretter kun følge e-post.
Eksempel 1
- Billetter opprettes via e-post - klienten sender en ny e-post til helpdesk-adressen.
- Klienten logger på systemet og kan se billetten der, siden han er billettforfatter.
- Klienter kan endre statuser og andre felt samt legge igjen kommentarer, i henhold til deres tillatelser.
Eksempel 2
- Klienten logger på systemet og oppretter en ny billett.
- Klienten mottar oppdateringer via e-post og ser kun på disse oppdateringene og føler ikke behov for å logge på systemet lenger.
Eksempel 3
- Klienten oppretter en billett via helpdesk-portalen
- Klienten bestemmer seg for at han kun vil følge e-poster og logger ikke lenger på portalen
- Klienten bestemmer seg da for å følge med via portalen, logger I og legger inn noen svar via portalen.
Av hensyn til kundenes bekvemmelighet kan du bestemme med hvilke metoder du vil la dem opprette og/eller oppdatere billetter. Men viktigst av alt, du må dekke alle mulige situasjoner, slik at billetter ikke går seg vill inn i en blindvei. Arbeidsflyt og andre konfigurasjoner gir alle nødvendige alternativer.
Vanlige problemer
Klienten svarer på vanlig oppgavevarsling, men svaret behandles ikke riktig.
Denne historien gjelder eksempel 2. Klienter tror de svarer på en billett via e-post, men e-posten er ikke paret med den eksisterende billetten og i stedet opprettes en ny, eller e-posten når ikke systemet i det hele tatt. Klienten svarer på et varsel, eller ved en feil oppretter en ny e-post.
Årsak: Innstillinger for e-postvarsling forventer ikke svar på varslingsadressen.
Løsning: Kundens svar må sendes til en helpdesk-angitt adresse og må inneholde billettnummeret. Varslings-e-postadresse (Administrasjon >> Innstillinger >> E-postvarsler >> Varslings-e-postadresse (FRA)) kan være den samme som en helpdesk-e-postadresse for å fange opp eventuelle svar fra klienter og pare dem med billetten som varselet opprinnelig ble sendt fra.
Et annet alternativ er å ganske enkelt deaktivere vanlige e-postvarsler til klientbrukerne. De eneste e-postene fra billetter de ville motta, ville bli aktivt sendt av operatørene via helpdesk-e-postmaler.
Nøkkeluttak: Kundene dine vil naturlig nok bli fristet til å svare på alle e-postmeldinger de mottar. Sørg for at de bare mottar meldinger som svar kan behandles på riktig måte.
Klienten endret billett til "feil" status
Dette skjer for det meste i situasjoner der klienten har en fullbruker i applikasjonen (i stedet for Helpdesk-bruker). Klienten kan ha muligheten til å redigere mange felt, inkludert status og kan feiltolke betydningen av ulike statuser. Eller på den annen side kanskje ikke endrer statusen når du forventer at den skal endres.
Årsak: Byggherren er ansvarlig for å sette korrekt status.
Løsning: Dette er et tydelig antimønster, klienten skal ikke måtte huske noen regler for oppgavestatuser.
En løsning er å bytte klientkonto til Helpdesk-brukere, i stedet for fullbrukere. Helpdesk-brukere kan opprette billetter og legge inn kommentarer i eksisterende billetter, statusendringer er basert på Helpdesk-konfigurasjoner, så det er ingen sjanse for at klienten vil "bryte" en korrekt prosess. Helpdesk-brukeres billettoppdateringer er praktisk utformet for å følge brukerstøttens e-postkommunikasjonslogikk og -innstillinger. Den eneste forskjellen er at brukeren faktisk kan se og jobbe med en fysisk form for billetten.
Hvis du trenger å beholde alle brukere for kundene dine, er vårt forslag å deaktivere alle statusendringer (eller andre feltendringer), noe som kan ødelegge noen av dine interne prosesser. Bruk andre måter å spore billetter som må oppdateres - for eksempel etter felt Oppgave sist oppdatert (dato for siste oppdatering), Sist oppdatert av (hvem gjorde den siste oppdateringen), kan du vise den siste kommentaren på en billett i listen, slik at det er tydelig at en klient har gjort oppdateringen.
Et litt mer komplisert scenario er fra eksempel 1, når du tillater billettkommunikasjon via e-post, men også lar klienter logge på med full bruker. Her er hva du bør se etter:
- Statusendring etter klientsvar via e-post er angitt i globale brukerstøtteinnstillinger
- Det er ingen håndhevelse av statusendring for påloggede brukere - det er alltid alternativet behold status som den er
I dette tilfellet bør du sørge for at køene for svar inneholder begge typer situasjoner, oppdatert via e-post (f.eks. filter for en spesifikk status), og billetter oppdatert av klienter fra applikasjonen (f.eks. billettliste med kolonne Siste kommentar).
Nøkkeluttak: Kunden skal aldri bekymre seg for dine interne prosesser, de trenger bare et sted å sende inn problemene sine og kommunisere med deg, prosessene er på deg og applikasjonen har ulike alternativer for å sette den tett.
Blanding av fullverdige brukere og helpdesk-brukere
Dette er bare en sterk advarsel om ikke å kombinere løsninger som aldri var ment å kombineres. Du kan bestemme om du vil bruke
- Helpdesk-brukere - gratis, med hardkodet begrenset tilgang, eller
- Fulle brukere – vanlige lisensierte brukere, der du bestemmer hva de har tilgang til
, men du bør ikke bruke begge samtidig, spesielt for de samme klientene. Teknisk sett er fullbruker- og Helpdesk-brukere ikke på noen måte koblet sammen. De har til og med en annen påloggingsside. De representerer et annet felt på oppgaver (forfatter vs brukerstøtteforfatter). Så det er ingen grunn til å forvirre klienten din ved å gi dem begge tilgangsalternativer.
Når det gjelder dine interne prosesser, er det teknisk mulig å gi noen klienter fulle brukere, og til andre bare brukere av brukerstøtte. Dette krever imidlertid presise prosessbeskrivelser og opplæring for agentene dine for å sikre at de ikke blander sammen behandling av billetter fra disse svært forskjellige kanalene. På grunn av den organisatoriske vanskeligheten, anbefaler vi på det sterkeste å bare velge ett alternativ for klienttilgang.
Oppsummering
La oss sette den forrige informasjonen tilbake til en fordøyelig form. Her er en tabell over situasjoner som kan oppstå basert på typen tilgang for klientene dine til systemet ditt.
| Klienttilgang til applikasjonen | Alternativer for å sende inn billett (klient) |
Varsler fra billett (agent) |
Alternativer for å oppdatere billett (klient) |
Våre anbefalinger |
| Uten tilgang | Send e-post til en helpdesk-e-postadresse. | Agent sender e-post via mal fra billetten. |
|
|
| Full bruker |
|
|
|
|
| Helpdesk-bruker |
|
Agent sender e-post via mal fra billetten. |
|
|
