← Back to articles

Helpdeskprogramvare: Bygg en billettflyt som holder mål

Helpdesk-programvare er mest nyttig når den støtter en tydelig arbeidsmåte. Det å kjøpe et verktøy avgjør ikke hvem som eier en forespørsel, når en sak bør settes på vent, eller hva som regnes som løst. Teamet må ta disse valgene først.

Denne veiledningen viser deg hvordan du utformer en praktisk arbeidsflyt for saker rundt den eksisterende support-e-posten din. Den fokuserer på arbeidsmodellen, ikke en sammenligning av funksjoner. Hvis du vil se hvordan e-post, tildeling, status, prioritet, tagger, notater og sakshistorikk henger sammen i ett produkt, kan du se gjennom Deskheroes funksjoner for delt innboks og saksbehandling mens du følger trinnene.

Start med veien en kundehenvendelse bør følge

Tegn opp den vanlige veien fra henvendelsen kommer inn til den er løst, før du konfigurerer noe. En nyttig første versjon er enkel: En melding kommer inn, noen gjennomgår den, riktig person tar eierskap, teamet utfører arbeidet, og kunden får et endelig svar.

List deretter opp unntakene som regelmessig bryter denne veien. Et fakturaspørsmål kan trenge et annet team. Et teknisk problem kan kreve en undersøkelse. En kunde kan slutte å svare. To meldinger kan beskrive det samme problemet. Disse tilfellene forteller deg hvilke statuser, overleveringer og sikkerhetsmekanismer arbeidsflyten trenger.

Hold kartleggingen sentrert rundt beslutninger. Svar på disse spørsmålene for hvert trinn:

  • Hvem har ansvar for neste handling?
  • Hvilken informasjon må være på plass før saken går videre?
  • Hva skal skje når den ansvarlige ikke er tilgjengelig?
  • Hvordan kan en annen User forstå den nåværende tilstanden uten å be om et sammendrag?
  • Hvilken hendelse betyr at forespørselen faktisk er ferdig?

En arbeidsflyt er sunn når enhver User kan åpne en sak og se hva som har skjedd, hva som skjer videre, og hvem som eier neste trinn.

Bruk et lite statussett med presise betydninger

Statusnavn kan virke selvforklarende, men team tolker dem ulikt. Definer hver status ut fra hvem som har ansvar for neste handling. Denne ene regelen forhindrer mange saker fra å bli stående fast.

Statusens formålBruk den nårHvem handler nå
Nytt arbeidForespørselen har kommet inn, men er ikke gjennomgåttTeamet som håndterer mottaket
Aktivt arbeidEn User undersøker saken eller forbereder et svarDen tildelte User
VenterTeamet trenger informasjon eller handling fra kunden eller en annen partDen navngitte eksterne parten, med en ansvarlig for oppfølging internt i teamet
LøstTeamet har fullført det etterspurte arbeidet og sendt resultatetIngen, med mindre kunden svarer

Unngå å opprette en status for hver avdeling, hvert tema eller hvert hastenivå. Bruk tildeling eller grupper for eierskap, tagger for temaer og prioritet for hvor raskt noe haster. Når hvert felt har ett formål, kan Users lese køen på en konsekvent måte.

Skill mellom eierskap, prioritet og klassifisering

Disse tre begrepene svarer på forskjellige spørsmål. Eierskap sier hvem som skal handle. Prioritet sier hvor raskt oppmerksomhet trengs. Klassifisering sier hva slags forespørsel det er. Når de blandes sammen, oppstår uklare køer og upålitelige rapporter.

Gjør én User eller gruppe ansvarlig

Alle åpne saker bør ha en tydelig ansvarlig. Delt ansvar blir lett til manglende ansvar. En gruppe kan motta nye oppgaver, men en bestemt User bør ta over når arbeidet begynner. Definer en backupregel ved fravær og en regel for overlevering når det trengs annen ekspertise.

Definer prioritet med observerbare forhold

Skriv prioriteringsreglene i et enkelt språk. Et avbrudd som påvirker mange kunder, bør for eksempel ha høyere prioritet enn et generelt spørsmål. Ikke la prioritet bli en måte å merke enhver utålmodig forespørsel som kritisk. En kort, skriftlig definisjon gir Users en begrunnelse de kan bruke konsekvent.

Bruk tagger for fremtidig handling, ikke pynt

Opprett bare en tagg når den hjelper teamet med å rute arbeid, finne et nyttig segment eller besvare et tilbakevendende spørsmål. Gå gjennom taggene med jevne mellomrom og slå sammen nesten identiske tagger. Et mindre begrepssett gir ryddigere visninger og mer pålitelig analyse.

Utform overleveringer som bevarer konteksten

En overlevering bør flytte ansvaret uten å tvinge den neste User til å rekonstruere saken. Behold kundesvar og private notater i sakens tidslinje. Før du tildeler saken på nytt, bør du legge til det som er avdekket, spørsmålet som gjenstår, og den neste forventede handlingen.

Bruk interne notater til samarbeid som ikke skal sendes til kunden. Bruk et kundesvar når du trenger å bekrefte mottak, be om informasjon eller forklare en forsinkelse. Dette skillet holder samtalen tydelig og gir kolleger konteksten de trenger.

Når to saker gjelder det samme problemet, må du avgjøre hvilken oppføring som er kilden til sannheten. Slå sammen duplikatet med hovedsaken, og fortsett deretter fra ett sted. Parallelle oppføringer inviterer til motstridende svar og splittet historikk.

Legg til servicemål etter at arbeidsflyten er stabil

Mål kan ikke reparere uklart eierskap. Sørg først for at nye oppgaver blir gjennomgått, at tildelinger er synlige, og at saker som venter, har en plan for oppfølging. Definer deretter forventninger til svartid og løsning rundt tidspunktene teamet faktisk arbeider.

Følg med på saker som nærmer seg et mål, ikke bare saker som allerede har overskredet det. Målet er å sette i gang handling mens det fortsatt er tid. Deskheroes SLA-policyer støtter mål for første svar og løsning, arbeidstidsplaner, filtre, varsler og en instrumentpanelvisning.

Test arbeidsflyten med virkelige scenarioer

Gå gjennom representative forespørsler før du ruller ut prosessen. Ta med et enkelt spørsmål, en forespørsel som bytter ansvarlig, en sak som venter på kunden, en duplikat og en gjenåpnet samtale. Kontroller i hvert scenario om neste handling og ansvarlig fortsatt er tydelige.

Gjennomfør testen med Users som ikke utformet arbeidsflyten. Hvis de trenger muntlig veiledning, er reglene eller feltnavnene ennå ikke tydelige nok. Juster prosessen og gjenta deretter scenarioene.

Under utrullingen bør du føre en kort logg over unntak. Registrer situasjoner der Users ikke vet hvilken status, ansvarlig eller prioritet de skal velge. Gå gjennom loggen regelmessig, og endre arbeidsflyten bare når et gjentakende mønster viser seg. Slik hindrer du systemet i å samle opp enkeltstående regler.

Mål flyt, ikke aktivitet for aktivitetens skyld

Nyttig rapportering bør vise hvor kundene venter, og hvor arbeidet stopper opp. Begynn med saksmengde, tid til første svar, løsningstid, alderen på restanser og gjenåpnede forespørsler. Se på trender og segmenter i stedet for å behandle ett gjennomsnitt som hele sannheten.

Knytt hver måling til en beslutning. En voksende mengde gamle restanser kan kreve tydeligere eierskap eller større kapasitet. Lang tid til første svar kan tyde på svak dekning i mottaket. Hyppige gjenåpninger kan være et tegn på ufullstendige løsninger eller forvirrende svar. Se vår veiledning om måltall for helpdesk-rapportering for en mer detaljert måleplan.

Gå gjennom arbeidsflyten når dokumentasjonen viser en tilbakevendende flaskehals. Ikke legg til felt eller trinn bare fordi programvaren tillater det. Det beste helpdesk-oppsettet er det minste som pålitelig gjør eierskap, kontekst og neste handling synlig.

En praktisk sjekkliste for utrulling

  1. Kartlegg den vanlige veien for en forespørsel og de vanligste unntakene.
  2. Definer hver status ut fra hvem som har ansvar for neste handling.
  3. Skill mellom eierskap, hast og emneklassifisering.
  4. Dokumenter hva en fullstendig overlevering må inneholde.
  5. Test arbeidsflyten med realistiske supportsenarioer.
  6. Legg til servicemål når ruting og eierskap er pålitelige.
  7. Velg et lite sett med måltall knyttet til operasjonelle beslutninger.
  8. Gå gjennom unntakene og forenkle regler som Users bruker inkonsekvent.

Når disse beslutningene er skrevet ned, blir konfigurasjonen mye enklere. Verktøyet bør gjøre den avtalte prosessen synlig og gjentakbar, samtidig som det gir nok fleksibilitet for uvanlige tilfeller.