Helpdesksoftware: Skab et robust ticketflow
Helpdesksoftware er mest nyttig, når det understøtter en klar arbejdsmetode. At købe et værktøj afgør ikke, hvem der ejer en henvendelse, hvornår en sag skal afvente, eller hvad der tæller som løst. Dit team skal træffe de valg først.
Denne guide viser dig, hvordan du designer et praktisk ticket-workflow omkring din eksisterende supportmail. Fokus er på driftsmodellen, ikke på en funktionssammenligning. Hvis du vil se, hvordan e-mail, tildeling, status, prioritet, tags, noter og ticket-historik hænger sammen i ét produkt, kan du gennemgå Deskheroes delte indbakke- og ticketingfunktioner, mens du arbejder dig gennem trinnene.
Begynd med den vej, en kundehenvendelse skal følge
Tegn den normale vej fra modtagelse til løsning, før du konfigurerer noget. En nyttig første version er enkel: En besked ankommer, nogen gennemgår den, den rette person overtager ansvaret, teamet udfører arbejdet, og kunden modtager et endeligt svar.
Lav derefter en liste over de undtagelser, der regelmæssigt bryder denne vej. Et faktureringsspørgsmål kan kræve et andet team. Et teknisk problem kan kræve undersøgelse. En kunde kan holde op med at svare. To beskeder kan beskrive det samme problem. Disse tilfælde fortæller dig, hvilke statuser, overdragelser og sikkerhedsforanstaltninger dit workflow har brug for.
Hold kortlægningen centreret omkring beslutninger. Besvar disse spørgsmål for hvert trin:
- Hvem er ansvarlig for den næste handling?
- Hvilke oplysninger skal være til stede, før ticketen kan gå videre?
- Hvad skal der ske, når den ansvarlige ikke er tilgængelig?
- Hvordan kan en anden User forstå den aktuelle status uden at bede om en opsummering?
- Hvilken hændelse betyder, at henvendelsen reelt er afsluttet?
Et workflow er sundt, når enhver User kan åbne en ticket og se, hvad der er sket, hvad der skal ske som det næste, og hvem der ejer næste trin.
Brug et lille statussæt med præcise betydninger
Statusnavne ser ofte indlysende ud, men teams fortolker dem forskelligt. Definer hver status ud fra, hvem der har ansvaret for den næste handling. Denne ene regel forhindrer mange tickets i at gå i stå.
| Statusformål | Brug den, når | Hvem handler som det næste |
|---|---|---|
| Nyt arbejde | Henvendelsen er ankommet, men er ikke blevet gennemgået | Teamet, der håndterer modtagelsen |
| Aktivt arbejde | En User undersøger sagen eller forbereder et svar | Den tildelte User |
| Afventer | Teamet har brug for oplysninger eller handling fra kunden eller en anden part | Den navngivne eksterne part, med en ansvarlig for opfølgning internt i teamet |
| Løst | Teamet har udført det ønskede arbejde og sendt resultatet | Ingen, medmindre kunden svarer |
Undgå at oprette en status for hver afdeling, hvert emne eller hvert hasteniveau. Brug tildeling eller grupper til ejerskab, tags til emner og prioritet til hast. Når hvert felt har ét formål, kan Users læse køen ensartet.
Adskil ejerskab, prioritet og klassificering
Disse tre begreber besvarer forskellige spørgsmål. Ejerskab angiver, hvem der skal handle. Prioritet angiver, hvor hurtigt der er brug for opmærksomhed. Klassificering angiver, hvilken type henvendelse det er. Hvis de blandes sammen, opstår der uklare køer og upålidelige rapporter.
Gør én User eller gruppe ansvarlig
Alle åbne tickets bør have en tydelig ansvarlig. Delt ansvar bliver nemt til intet ansvar. En gruppe kan modtage nyt arbejde, men en bestemt User bør overtage, når arbejdet begynder. Definer en backupregel ved fravær og en regel for overdragelse, når den nødvendige ekspertise ændrer sig.
Definer prioritet med observerbare betingelser
Skriv prioritetsregler i et enkelt sprog. En afbrydelse, der påvirker mange kunder, bør for eksempel have højere prioritet end et generelt spørgsmål. Lad ikke prioritet blive en måde at markere enhver utålmodig henvendelse som akut. En kort, skriftlig definition giver Users en begrundelse, de kan anvende konsekvent.
Brug tags til fremtidig handling, ikke pynt
Opret kun et tag, når det hjælper teamet med at dirigere arbejdet, finde et nyttigt segment eller besvare et tilbagevendende spørgsmål. Gennemgå tags med jævne mellemrum, og slå næsten identiske tags sammen. Et mindre ordforråd giver renere visninger og mere pålidelige analyser.
Design overdragelser, der bevarer konteksten
En overdragelse bør flytte ansvaret uden at tvinge den næste User til at rekonstruere sagen. Bevar kundesvar og private noter på ticketens tidslinje. Før du omfordeler sagen, skal du tilføje det aktuelle resultat, det spørgsmål, der mangler svar på, og den næste forventede handling.
Brug interne noter til samarbejde, der ikke skal sendes til kunden. Brug et kundesvar, når du har brug for at bekræfte modtagelsen, anmode om oplysninger eller forklare en forsinkelse. Denne skelnen holder samtalen klar og giver kolleger den nødvendige kontekst.
Når to tickets omhandler det samme problem, skal du beslutte, hvilken post der er den autoritative kilde. Flet dubletten ind i hovedticketen, og fortsæt derefter ét sted. Parallelle poster inviterer til modstridende svar og opdeler historikken.
Tilføj servicemål, når workflowet er stabilt
Mål kan ikke reparere uklart ejerskab. Sørg først for, at nyt arbejde bliver gennemgået, at tildelinger er synlige, og at afventende tickets har en vej til opfølgning. Definer derefter forventninger til svar og løsning ud fra de tidsrum, hvor dit team faktisk arbejder.
Hold øje med tickets, der nærmer sig et mål, ikke kun tickets, der allerede har overskredet det. Målet er at sætte handling i gang, mens der stadig er tid. Deskheroes SLA-politikker understøtter mål for første svar og løsning, tidsplaner for åbningstid, filtre, advarsler og en dashboardvisning.
Test workflowet med virkelige scenarier
Gå repræsentative henvendelser igennem, før du ruller processen ud. Medtag et enkelt spørgsmål, en henvendelse, hvor den ansvarlige skifter, en sag, der afventer kunden, en dublet og en genåbnet samtale. Kontrollér for hvert scenarie, om den næste handling og den ansvarlige stadig er tydelige.
Gennemfør testen med Users, der ikke har designet workflowet. Hvis de har brug for mundtlig vejledning, er reglerne eller feltnavnene endnu ikke tydelige nok. Tilpas processen, og gentag derefter scenarierne.
Under implementeringen skal du føre en kort log over undtagelser. Notér situationer, hvor Users ikke ved, hvilken status, ansvarlig eller prioritet de skal vælge. Gennemgå loggen regelmæssigt, og ændr kun workflowet, når der viser sig et gentaget mønster. På den måde undgår du, at systemet ophober enkeltstående regler.
Mål flowet, ikke aktivitet for aktivitetens egen skyld
Nyttig rapportering bør vise, hvor kunder venter, og hvor arbejdet går i stå. Begynd med ticketvolumen, tid til første svar, løsningstid, alderen på backlogen og genåbnede henvendelser. Se på tendenser og segmenter i stedet for at behandle ét gennemsnit som hele sandheden.
Knyt hver måling til en beslutning. En voksende backlog af gamle tickets kan kræve tydeligere ejerskab eller større kapacitet. Langsomt første svar kan pege på utilstrækkelig dækning af modtagelsen. Hyppige genåbninger kan være tegn på ufuldstændige løsninger eller forvirrende svar. Se vores guide til rapporteringstal for helpdesk for en mere dybdegående måleplan.
Gennemgå workflowet, når data viser en tilbagevendende flaskehals. Tilføj ikke felter eller trin, blot fordi softwaren gør det muligt. Den bedste helpdeskopsætning er den mindste, der pålideligt gør ejerskab, kontekst og næste handling synlige.
En praktisk tjekliste til implementeringen
- Kortlæg den normale vej for en henvendelse og de almindelige undtagelser.
- Definer hver status ud fra, hvem der har ansvaret for den næste handling.
- Adskil ejerskab, hast og emneklassificering.
- Dokumentér, hvad en komplet overdragelse skal indeholde.
- Test workflowet med realistiske supportsituationer.
- Tilføj servicemål, når routing og ejerskab er pålidelige.
- Vælg et lille sæt målinger, der er knyttet til driftsmæssige beslutninger.
- Gennemgå undtagelser, og forenkle regler, som Users anvender inkonsekvent.
Når disse beslutninger er skrevet ned, bliver konfigurationen meget nemmere. Dit værktøj bør gøre den aftalte proces synlig og gentagelig, samtidig med at der er tilstrækkelig fleksibilitet til usædvanlige tilfælde.