Se lenke til flytskjema:
Alle supportsaker skal behandles gjennom Freshdesk.
Hvis kunder ringer inn skal det opprettes FD sak som settes til rett kø.
Kunder oppfordres til å sende inn saker via bruker portalen på egenhånd.
Hvis nødvendig oppretter vi FD sak på vegne av kunden.
Innrapportering og dialog ang BUGS foregår i DevOps.
Teamsgruppe 'Innrapportering BUGS':
- Brukes for å raskt melde fra om bugs, eller misstanke om bugs.
- DevOps sak med prioritet=Haster og Type=feil/bug legges automatisk ut i denne gruppen.
NB! For saker som står uten ansvarlig vil ingen motta varsler. Følg med på Tilstand=Kunde Svart på gruppenivå.
1.linje
- Konsulent mottar en support sak.
- Analyserer saken, utfører nødvendig feilsøk.
- Løser saker som er innenfor deres fagfelt, fordeler sak innenfor 1.linje ut fra domenekunnskap.
- 1.linje skal i all hovedsak henvende seg til 2.linje, som tar saker videre til utvikling.
- Kartlegging av sak:
- Dokumenterer mest mulig i FD sak, forsøker å gjenskape feilen/. og skaff nødvendig tilleggsinfo.
- Sak settes til gruppe 2.linje.
- Hvis saken fortsatt skal stå i kø hos 1.linje, sett feltet 'Ingern gruppe' = 2.linje
- Tagger kun 2.linje konsulent som evt er involvert
- Velg rett 'Prioritet' (Høy/Haster for kritiske saker.
- Sak krever dypere feilsøk/kan løses av 2.linje:
- Saken ferdigstilles av 2.linje, som også kommuniserer videre med kunden
- Saken settes tilbake til 1.linjekonsulent for evt videre oppfølging med kunden.
- BUG: Mistenker eller konkluderer med BUG
- Kort notat på Teamsgruppe 'Innrapportierng BUGS' for å informere kolleger.
- Angi Type=Feil/BUG
- Kritiske bugs 'Prioritet=Haster'
- 1.linje spør 2.linje om hvem som kan se på saken.
- Sak settes til gruppe 2.linje
- Tagger rett konsulent.
- 2.linje tar over ansvaret.
- Mindre kritiske feil, 'Prioritet=Middels'
- Sak settes til gruppe 2.linje
- DevOps: Tagging - For overvåking av saker
- 1.linje konsulent blir tagget i DevOps sak som 2.linje oppretter, mottar mail med lenke. Åpne lenken, klikk på 'Follow' for å motta varsler.
- Utvikling holder oss oppdatering via meldinger fra DevOps.
- Ansvarlig konsulent svarer kunden.
2.linje svarer med signatur 'Kundeservice' hvis de står som ansvarlige. Hvis saken krever mer oppfølging settes saken tilbake til 1.linje konsulent, som behandler saken videre. - 1.linje får oppdatering via DevOps. Den som har interesse av å følge en sak klikker selv 'Follow'.
Mulig flere konsulenter må melde videre til andre kunder med samme feil. - Hvis en bug allerede er innrapportert så velger man selv 'Follow' for å motta oppdatering for saken.
Melder selv fra til kunde på saker man er ansvarlig for. - Freshdesk URL: Lenke til FD saker, kan legge inn flere saker. Samle flere på samme Work item.
- Lik oppfølging for alle BUGS, det er kun alvorlighetsgrad og prioritet som er forskjellig.
- DevOps
1.linje må følge med på DevOps saker, se hva som er registrert og hva som er løst.- Tips: Lag en Query som har 'Work Item Type=Bug', se artikkel DevOps - Tilgang, opprette Query
2.linje
- Følge aktivt med på kø for gruppe 2.linje i tillegg til egen kø.
- Saker som krever videre feilsøk fra teknisk og BUGS settes direkte til gruppen, kritiske BUGS tagges med Agent.
- Kartlegging av sak:
- Starter feilsøk
- Opprett Workitem, Rapporter BUG til utvikling.
- Kritiske BUGS. Alvorlighetsgrad=Kritisk' Har høyeste prioritet
- Mindre kritiske BUGS. Alvorlighetsgrad='Medium' tas så snart som mulig.
- Kopiere lenke for DevOps saken og lim inn i FD-notat.
- Freshdesk URL: Lenke til FD saker, evt for flere saker. Samle flere på samme Work item.
- Tag Per Arne og konsulent(er) fra 1.linje som rapporterte saken.
- Utvikling(TH) tar over ansvaret.
- Teamsgruppe 'Innrapportering BUGS': DevOps sak med prioritet=Haster og Type=feil/bug legges automatisk ut i denne gruppen.
- Dialog for oppfølging skjer i DevOps.
- Ansvarlig konsulent svarer kunden.
- 2.linje svarer med signatur 'Kundeservice' hvis de står som ansvarlige.
- Hvis saken krever mer oppfølging settes saken tilbake til 1.linje konsulent, som behandler saken videre.
Prioritet for utvikling
- Løsning kan ta litt tid.
- Kritiske Bugs har høyeste prioritet
- Mindre kritiske Bugsl prioriteres av Per Arne/Staffan
- Ansvarlig for å rapportere tilbake til support så snart en bug er fikset, gjøres via dialoger fra Work item i DevOps.
Hva anses som kritiske BUGS
Kritiske problemer er problemer som hindrer kunden i å få tilgang til Quick3 og utføre viktige oppgaver, som å håndtere sine egne kunder i butikken (kan ikke opprette bestilling, kan ikke motta betalinger), og dette skyldes systemfeil.
Kritiske problemer påvirker flere kunder. Hvis alt fungerer fint for alle kunder unntatt den som rapporterer problemet, er det sannsynligvis en konfigurasjonsfeil for den ene kunden og IKKE et kritisk problem.
Kun virkelig kritiske problemer skal rapporteres direkte til første tilgjengelige ressurs i utviklingsteamet – ideelt sett etter verifisering av 2. linje support.
Support_Timeleak
Saker som er 'tidstyver' for support merkes med egen Tag=Support_Teamleak.
Dette gjør det mulig for utvikling å filtrere spesielt på dette, og for å kunne prioritere disse sakene.
FD – Ta i bruk ‘Intern gruppe’
--> Skrives om når vi har endelig rutine klar.
Vi ser viktigheten av å gå bort fra tagging av enkelt konsulenter, siden det lett gir utfordringer hvis noen er veldig opptatt eller syke.
Vi ser på muligheten for å bruke ‘Intern gruppe’ i stedet.
Hvis du har saker der du selv står som Agent, og har tagge en person fra 2.linje, så skal disse i stedet settes mot ‘Intern gruppe’.
Anne skal sjekke opp hvordan vi kan filtrere på ‘Intern gruppe’ i oppgavelisten slik at disse blir synlige i oppgavelisten til ‘Gruppe=Support 2.linje’
Hvis en sak skal overlates til 2.linje endrer vi i ‘Gruppe’, slik vi har sagt tidligere. Men vi må bort fra det å tagge enkeltpersoner og i stedet bruke ‘Intern gruppe’ når det er noe vi trenger hjelp til, men der vi samtidig skal beholde oppfølgingen for saken selv.
Se eksempel nedenfor.
(Har bare tatt en kort beskrivelse av dette her nå, så snakker vi mer om det på supportmøtet. Men vet ikke om det blir tid til dette i morgen siden PA skal gi en del info.)
Var denne artikkelen nyttig?
Så bra!
Takk for din tilbakemelding
Beklager at vi ikke kunne være mer til hjelp
Takk for din tilbakemelding
Tilbakemeldingen er sendt inn
Vi setter pris på tilbakemeldingen din og vil prøve å rette på artikkelen