Se lenke til flytskjema:
https://quickt.visualstudio.com/Quick3/_wiki/wikis/Quick3.wiki/136/Managing-Your-Workspace-in-Azure-DevOps
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 for 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.
- Sak krever dypere feilsøk:
- Dokumenterer mest mulig i FD sak, forsøker å gjenskape feilen.
- Sak settes til gruppe 2.linje.
- Tagger evt 2.linje konsulent som er involvert
- Velg rett 'Prioritet' (Høy/Haster for kritiske saker).
- BUG: Mistenker eller konkluderer med bug
- Kort notat på Teamsgruppe 'Innrapportierng BUGS' for å informere kolleger.
- Dokumenterer mest mulig i FD sak, forsøker å gjenskape feilen. 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 ansvart.
- Mindre kritiske feil, 'Prioritet=Middels'
- Sak settes til gruppe 2.linje.
- DevOps: Tagging - 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ø. Mindre kritiske BUGS settes direkte til gruppen.
- BUGS:
- Kritiske BUGS har høyeste prioritet
- Starter feilsøk
- Rapporter BUG til utvikling:
- Opprett Work item, alvorlighetsgrad=Kritisk'
- Kopiere lenke for DevOps saken og lim inn i FD-notat.
- Freshdesk URL: Lenke til FD saker, kan legge inn 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.
- Mindre kritiske feil tas så snart som mulig.
- Starter feilsøk
- Rapporter BUG til utvikling:
- Opprett Work item, alvorlighetsgrad='Medium'
- Kopiere lenke for DevOps saken og lim inn i FD-notat.
- Freshdesk URL: Lenke til FD saker, kan legge inn flere saker. Samle flere på samme Work item.
- Tag Per Arne og konsulent(er) fra 1.linje som rapporterte saken.
- Prioritering av mindre BUGS behandles av Per Arne/Staffan, som tar over ansvaret.
- Løsning kan ta litt tid.
- 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.
- Kritiske BUGS har høyeste prioritet
Utvikling
- Kritiske Bugs har høyeste prioritet
- Mindre kritiske feil 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.
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.
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