Prioritering av supportsaker 101: Optimaliser supportarbeidsflyten

Discover how to deliver better software and systems in rapidly scaling environments. Join our Community

Prioritering av supportsaker hjelper kundestøtteteam med å håndtere arbeidsmengden effektivt ved å rangere problemer basert på hvor presserende, alvorlige og forretningskritiske de er. CTO Trent Thacker utforsker velprøvde metoder, som å forstå nivåene for prioritet og alvorlighetsgrad, slik at teamet kan levere raskere løsninger.

Effective Ticket Prioritization Strategies for Customer Support Teams Featured Image

Key Takeaways

Alvorlighetsgrad kontra prioritet: Kjenn forskjellen: Ikke alle kritiske problemer har høyest prioritet, og ikke alle saker med lav alvorlighetsgrad bør settes til side. Ved å skille mellom systempåvirkning (alvorlighetsgrad) og hvor presserende saken er for brukeren (prioritet) sikrer du at teamet håndterer de riktige problemene til riktig tid.

Tjenestenivåavtaler: Oppskriften på suksess: Tydelige og realistiske tjenestenivåavtaler (SLA-er) samordner kundenes forventninger med teamets kapasitet. SLA-er fungerer som et veiledende rammeverk for svar- og løsningstider, og sikrer ansvarlighet og konsekvens.

Automatiser smart, behold mennesket i sentrum: Bruk automatisering til å effektivisere arbeidsflyter, fra å merke supportsaker til å prioritere dem basert på forhåndsdefinerte regler, men ikke erstatt meningsfull kommunikasjon i teamet. Balanser verktøy og menneskelig oppfølging for å skape et effektivt og empatisk supportsystem.

Opplæring: Ditt hemmelige våpen: Kontinuerlig opplæring gir teamet kunnskapen som trengs for å håndtere nye funksjoner og oppdateringer, noe som reduserer forsinkelser og øker tryggheten. Et velinformert team leverer raskere løsninger, mer fornøyde kunder og færre problemer.

Som en som har vært både CTO og produkt- og brukerstøtteleder i programvareselskaper, har jeg lært at prioritering av saker handler om å finne en balanse. Internt handler det om å holde produktteamet effektivt – å håndtere raske gevinster som er enkle å løse, sammen med mer komplekse saker med stor innvirkning som tar tid.

Eksternt handler det om å innfri kundenes forventninger, selv når «100 % feilfri hele tiden» ikke er realistisk. Utfordringen ligger i å vurdere alvorlighetsgraden og innvirkningen til hver sak, og samordne dem med tjenestenivåavtaler, sikkerhetsrisikoer og brukeropplevelsen – ikke bare lytte til den høyeste stemmen i rommet.

La oss være ærlige: Tilnærmingen min til prioritering av saker er ikke en løsning som passer for alle. Mindre selskaper kan lene seg mot å tilfredsstille store kunder som betaler regningene, mens større organisasjoner kanskje prioriterer sikkerhet og samsvar for å beskytte omdømmet sitt.

Uavhengig av organisasjonens størrelse eller type er målet det samme – å skape et prioriteringssystem som fordeler ressurser effektivt, holder kommunikasjonen tydelig og sørger for at både kunder og team er fornøyde. Gjort riktig betyr dette raskere svartider, mer fornøyde kunder, motiverte team og færre kriseinnsatser.

La oss se på hvordan vi kommer dit.

Hva er prioritering av saker?

Prioritering av saker er prosessen med å organisere og rangere saker fra kundestøtte eller interne problemer basert på hvor presserende de er, hvilken innvirkning de har, og hvilken forretningsverdi de gir. Det er en viktig praksis for brukerstøtteteam, som sørger for at ressursene fordeles effektivt og at de mest presserende problemene håndteres først.

Grunnleggende innebærer prioritering av saker å vurdere både alvorlighetsgraden til et problem (hvor mye det påvirker systemfunksjonaliteten) og prioriteten (hvor presserende det påvirker brukerne eller virksomheten).

Et sikkerhetsbrudd eller systemutfall som påvirker alle brukere, kan for eksempel klassifiseres som et kritisk problem med høy prioritet som krever umiddelbar oppmerksomhet. En mindre visuell feil eller en forespørsel om en funksjon kan derimot ha lavere prioritet. Ved å innføre et tydelig prioriteringssystem kan organisasjoner forhindre flaskehalser, redusere etterslep av saker og sørge for at teamene fokuserer innsatsen på det som betyr mest.

Effektive svar betyr færre oppfølgingssaker, mindre kundefrafall og mindre tid brukt på komplekse problemer. Alt dette fører til et brukerstøtteteam som kan arbeide med optimale og mer effektive ressurser.  

Forstå prioriteringsnivåene for saker

Prioritering av saker og alvorlighetsgraden til saker bør alltid vurderes sammen.  

Alvorlighetsnivåer for saker måler innvirkningen på systemet. En nettside som ikke lastes inn, eller data som ikke lagres riktig, vil være problemer med høy alvorlighetsgrad, mens en stavefeil vil ha lav alvorlighetsgrad fordi den ikke påvirker bruken av programvaren.  

Prioritetsnivåer måler innvirkningen på virksomheten eller brukeren. At en bruker ikke kan logge inn på et nettsted, er et problem med høy prioritet, mens en skjerm som krasjer fordi en bruker har angitt 50 kallenavn for seg selv (jeg har personlig bare 3), ikke er en normal arbeidsflyt og mest sannsynlig vil være en sak med lavere prioritet.

Både prioritet og alvorlighetsgrad har sine egne nivåer. La oss se på disse:

Vanlige prioritetsnivåer for saker

  • Høy prioritet (P1): Dette er et problem som krever umiddelbar oppmerksomhet fordi det påvirker viktige funksjoner, blokkerer brukere eller utgjør en betydelig forretningsrisiko. For teamene mine er sikkerhetsrelaterte problemer alltid P1-saker. Vi vil aldri la åpne dører stå igjen som kan kompromittere data. At en bruker ikke kan logge inn, at en skjerm ikke lastes inn eller at systemet krasjer, bør også vurderes på dette nivået.  
  • Middels prioritet (P2): Dette er et problem som påvirker brukervennlighet eller ytelse, men som ikke stanser viktige funksjoner. Vi bør løse det snart, men vi trenger ikke slippe alt vi har i hendene for å løse det som en nødsituasjon. For teamene mine er P2-saker vanligvis «irriterende» problemer. Et popup-vindu som må flyttes hver gang for å komme videre. Ytelsesproblemer som lang ventetid eller lange innlastingstider. Problemer som påvirker brukerens ytelse eller på annen måte endrer den normale flyten.
  • Lav prioritet (P3): Dette er et mindre problem med minimal innvirkning på brukervennligheten. Dette er brukergrensesnittproblemer uten vesentlig innvirkning (stavefeil, justering, grammatikk osv..), eller til og med kundeønsker som er «kjekt å ha», og som produktteamet bestemmer seg for å behandle som et problem i stedet for en forbedring. Ikke undervurder kraften og virkningen en enkel gest som dette kan ha på kunden din. Litt goodwill kan føre langt!
Get Free Access
Get regular tech leadership wisdom for delivering better software and systems.
Get Free Access

Have an account? Log In

Vanlige alvorlighetsnivåer for saker

  • Kritisk alvorlighetsgrad (S1): Den fryktede kritiske feilen. Dette er et problem som fullstendig bryter systemet (eller en kritisk funksjon), slik at det blir ubrukelig for sluttbrukerne. datatap, eller til og med oppfattet datatap hos sluttbrukeren, er alltid en S1 hos teamene mine. Vi ønsker at kundene våre ikke skal miste data når det er mulig. Som jeg også nevnte tidligere, vil sikkerhetsproblemer nesten alltid være en S1.  
  • Høy alvorlighetsgrad (S2): Dette er et problem som forstyrrer kjernefunksjonaliteten, men som ikke deaktiverer produktet fullstendig. Når det finnes en akseptabel omgåelse, kan problemet nedgraderes fra S1 til S2 etter enighet mellom alle interessentene. At en bruker ikke kan få tilgang til en bestemt rapport eller et dashbord, men fortsatt kan legge inn de nødvendige dataene, vil vanligvis klassifiseres som en S2. Særlig hvis brukeren har en alternativ måte å få tilgang til dataene de har lagt inn på.  
  • Middels alvorlighetsgrad (S3): Dette er et problem som ikke hindrer brukerne i å bruke hovedfunksjonene, men som kan forstyrre den generelle brukervennligheten til systemet. Tenk på funksjoner som finnes i systemet ditt, som ikke brukes mye, eller som ikke er en kritisk og sentral funksjon, men som ikke fungerer helt som de skal.  
  • Lav alvorlighetsgrad (S4): Dette er et mindre problem som har minimal innvirkning på brukeropplevelsen eller systemfunksjonaliteten. Skrivefeil, feiljustert grafikk eller overlappende inndatafelt er alle eksempler på hvordan jeg bruker S4-klassifiseringen.  

Alvorlighetsgraden og prioritetsnivået kommer ikke alltid til å være det samme. En feil kan ha kritisk alvorlighetsgrad, men det betyr ikke nødvendigvis at den har høyest prioritet, og det motsatte kan også være tilfelle. 

Husk eksempelet mitt med en bruker som prøver å legge inn 50 kallenavn på seg selv, og at skjermbildet krasjer? Jeg ville markert dette som et problem med alvorlighetsgrad 2 (S2) og prioritetsnivå 3 (P3). Vi liker aldri at et skjermbilde krasjer, så vi ville klassifisert det som en S2. Men i dette tilfellet, hvor det ikke er en normal arbeidsflyt og sannsynligvis bare skjer 1 av 100 dager, er det av den grunn en P3 med lav prioritet.

Tilpasse prioritetsnivåer for teamet ditt

Jeg nevnte i begynnelsen at ikke alle selskaper kan, eller bør, implementere billettprioriteringen sin på samme måte. Jeg mener at hvert selskap bør utarbeide spesifikasjoner for billettprioritering basert på sine unike behov. 

Små programvareselskaper mangler ofte hele spekteret av spesialiserte roller i produktavdelingen—som produkteiere, QA-ledere, QA-ansvarlige, arkitekter, utviklere og scrum mastere—som alle spiller en rolle i å fastsette alvorlighetsgrad og prioritet for billetter.

Større selskaper har på sin side sine egne utfordringer, blant annet å samordne prioriteringssystemer på tvers av flere team og avdelinger, håndtere det store billettvolumet som kan føre til feilklassifisering, og håndtere eskaleringsskjevhet fra innflytelsesrike interessenter som ledere eller store kunder. Begge scenariene viser hvor viktig det er å lage et tydelig og fleksibelt prioriteringsrammeverk som passer organisasjonens unike struktur og behov.

Selv om det er viktig å lage et sett med retningslinjer som fungerer for organisasjonen din, trenger du ikke å begynne fra grunnen av eller overstyre bransjestandarder. Hold deg til de vanlige prioritets- og alvorlighetsnivåene. De er standard av en grunn. Bruk grunnleggende kriterier og sunn fornuft til å klassifisere nivåene dine. Det trenger ikke å være rakettvitenskap, men det må være tydelig og konsist.

Jo mer du prøver å håndtere hvert eneste brukstilfelle i formuleringen av klassifiseringsnivåene dine, desto mer uklart blir det. I tillegg kommer du uunngåelig til å utelate et brukstilfelle likevel. 

Her er noen faktorer jeg ville vurdert å tilpasse basert på den enkelte organisasjonen jeg har ansvar for på det aktuelle tidspunktet:  

  1. Påvirkning på kunder: Vurder hvor mye problemet påvirker brukerne. Be teamet undersøke om problemet påvirker alle kunder, et bestemt segment eller en bestemt region, eller bare én kunde. Problemer som påvirker en større kundebase, bør vanligvis prioriteres høyere enn problemer som bare påvirker én kunde.  Hvis denne ene kunden imidlertid er din viktigste kunde og betaler en større del av produktbudsjettet ditt, bør du absolutt prioritere problemene deres høyere enn andres.
  2. Alvorlighetsgrad og hast: Vurder hvor kritisk problemet er for produktets funksjonalitet. Et problem som blokkerer kjernefunksjonalitet for brukerne eller fører til krasj, vil vanligvis anses som kritisk, mens mindre visuelle problemer som regel kan vente.  
  3. Kundestøtteteamets kapasitet: Ta hensyn til tilgjengelige ressurser og kompetanse. Hvis en rask løsning er mulig, kan det å løse et problem med lavere prioritet øke produktiviteten og bygge goodwill hos kundene. Hvis du har et større team med både senior- og juniorkompetanse, kan det være lurt å vurdere å segmentere ressursfordelingen basert på tilgjengelig kunnskap, slik at du utnytter kunnskapsbasen maksimalt.
  4. SLA-er (tjenestenivåavtaler): SLA-er er en annen måte å tilpasse det som fungerer for organisasjonen din, basert på ressurser, kapasitet og kundebase. Jeg skal komme nærmere inn på hvordan SLA-er kan og bør fungere litt senere, men SLA-er (i likhet med prioritering av saker) kan og bør være unike for hver organisasjon. Én løsning passer ikke for alle når det gjelder SLA-er.
  5. Forretningspåvirkning: Sist, men ikke minst, er påvirkningen kundene dine opplever. Eller enda bedre: Hvem består kundebasen din av, hvilken bransje opererer de i, og hvordan påvirkes virksomheten deres av programvaren din? Bygger du programvare for NASA, som trenger uavhengig verifisering og validering eller må følge standarden for programvaresikring og programvaresikkerhet (NASA-STD-8739.8)? Eller er kundene dine helseselskaper som må overholde HIPPA-regelverket? Kanskje kundebasen din består av allmennheten, som bare ønsker god programvare som fungerer godt og ikke er full av feil. Uansett bør forretningspåvirkningen justeres deretter.

Fordeler med et effektivt system for prioritering av saker

Implementering av et effektivt system for prioritering av saker kan gi organisasjonen din en rekke fordeler, som å effektivisere problemhåndteringen, forbedre kundetilfredsheten og øke teamets produktivitet. 

Disse samlede gevinstene gjør det mulig for deg og teamene dine å levere et mer pålitelig produkt og en responsiv kundestøtteopplevelse som omfatter:

  • Økt kundetilfredshet: Ved å prioritere saker basert på hast og påvirkning blir saker med høy prioritet håndtert raskt, noe som bidrar til å redusere kundenes frustrasjon og forbedre den generelle tilfredsheten. Når kundene ser at problemene deres håndteres effektivt, øker tilliten til selskapet ditt,
  • Effektiv ressursfordeling: Et system for prioritering av saker hjelper teamene med å fokusere på de mest presserende problemene, reduserer bortkastet tid og sørger for at innsatsen brukes der den betyr mest. Det bidrar også til å unngå å overbelaste enkelte teammedlemmer, og sørger i stedet for at ressursene fordeles på en hensiktsmessig måte mellom saker med høy, middels og lav prioritet.
  • Redusert etterslep: Prioritering av saker bidrar til å unngå opphopning av saker. Når saker vurderes og prioriteres riktig, håndteres de mest kritiske problemene raskt. Dette bidrar til å hindre at det bygger seg opp en mengde uavklarte saker. Når problemer i tillegg kategoriseres og prioriteres etter hast, bidrar det til raskere responstid og løsningstid. Disse kortere tidene vil påvirke resultatmålingene dine positivt og hjelpe deg direkte med å oppfylle SLA-kravene dine.
  • Tydelig kommunikasjon og åpenhet: Et strukturert prioriteringssystem bidrar til å skape tydelige forventninger hos kundene når det gjelder responstid og løsningstid. Selv om kundene kanskje ønsker at alle problemer skal løses umiddelbart, skaper åpenhet om hva som er gjennomførbart forståelse og tillit. Når disse forventningene etableres på forhånd, blir samtaler om justering av prioriteringer enklere, og det sikrer at de interne teamene er samkjørte. Dermed reduseres misforståelser og uoverensstemmelser i håndteringen av saker.
  • Bedre innsikt i produktets tilstand: Ved å spore og kategorisere sakene dine blir det mye enklere å identifisere tilbakevendende problemer og rotårsaker.  Dette vil ikke bare føre til at teamet ditt skaper bedre produktstabilitet, men bidrar også til å styrke en proaktiv tilnærming til kvalitetssikring.
  • Bedre samsvar og SLA-håndtering: Spesifikasjonene for prioritering av saker vil samsvare med SLA-kravene dine. Dette sikrer at kritiske problemer håndteres innen avtalte tidsrammer, reduserer risikoen for brudd på SLA-er og opprettholder tilliten du allerede har bygget hos kundene dine. Det sikrer også at bransjer med krav til samsvar eller regelverk kan være trygge på at saker som oppfyller bestemte kriterier, håndteres raskt og støtter deres mål for etterlevelse.

Som med enhver praksis fungerer analyse av ITSM-saksdata best med en definert arbeidsflyt. Servicedesker forbedrer tjenestene sine ved å bruke saksdata til å informere tiltakene sine, men mange organisasjoner vet ikke hvor de skal begynne. Det er fristende å vente på perfekte data, men det er mye verdi i å analysere saksdataene slik de foreligger i dag.

Share This Quote on:

Slik prioriterer du saker 

Med utallige problemer som konkurrerer om oppmerksomheten, er det ikke nok å bare håndtere saker i den rekkefølgen de kommer inn. Vellykket prioritering tar hensyn til faktorer som alvorlighetsgrad, hvor mye det haster, og innvirkning på virksomheten. Ved å innføre et strukturert system kan team håndtere de mest kritiske problemene først, redusere løsningstidene og sørge for at kundetilfredsheten forblir høy.

Følg disse praktiske trinnene for å hjelpe teamet ditt med å mestre kunsten å prioritere saker og skape en smidigere og mer produktiv arbeidsflyt for brukerstøtten.

Definer tydelige SLA-er

Etter min erfaring er det avgjørende å opprette og administrere tjenestenivåavtaler (SLAs) for å legge til rette for god kommunikasjon. 

Teamet ditt trenger tydelige retningslinjer for å håndtere og løse problemer effektivt. Tjenestenivåavtaler (SLAs) bør fastsette målbare responstider og løsningstider, holde teamene ansvarlige og tydeliggjøre forventningene til kundene.

Slik bygger du effektive SLA-er:

  • Involver kundene: Diskuter forventningene deres til brukerstøtte og responstid for å fastsette realistiske vilkår som er fordelaktige for begge parter. Finn ut om kundene har spesielle krav som bør tas hensyn til, basert på tjenestens art.
  • Definer SLA-nivåer: Tilpass responstidene etter problemets alvorlighetsgrad og tjenestenivåene – for eksempel kan et kritisk systemavbrudd (S1) kreve svar innen én time, mens mindre problemer kan ha et tidsvindu på 24 timer. Definer hvordan respons- og løsningstider måles.
  • Sett realistiske mål: Det er bare du som kjenner størrelsen på teamet ditt og hva det er i stand til. Tilpass SLA-forpliktelsene til teamets kapasitet og ressurser, slik at leveransen blir jevn og pålitelig.
  • Planlegg for eskaleringer: Definer prosedyrer for uløste problemer som krever ekstra ressurser eller oppmerksomhet på et høyere nivå.

Ved å samkjøre SLA-ene med strategien din for sakprioritering kan du tilby konsekvent, transparent og effektiv brukerstøtte.

Fremragende programvare for brukerstøtte!

1Best for AI-powered ticket automationFree trial availableFrom $149/user/month (billed annually)Website
2Best for unified IT helpdesk & asset management14-day free trialFrom $19/user/month (billed annually)Website
3Best for AI-powered workflow automationsFree demo availableFrom $89/agent/monthWebsite
4Best for full context tickets14-day free trialPricing upon requestWebsite
5Best for ticket based workflowsFree trial availableFrom $19/user/month (billed annually)Website
6Best for AI-powered ticketing and collaborationFree plan availableFrom $35/user/monthWebsite
7Best for providing tailored assistance15-day free trialPricing upon requestWebsite
8Best for centralized ecommerce supportFree trial availableFrom $39/user/month (billed annually)Website
9Best with automated multilingual ticket handlingFree plan available; 14-day free trialFrom $16/user/monthWebsite
10Best with instant setup for cloud or on-premises21-day free trialFrom $29/monthWebsite

Bruk programvare til å følge med på ytelsen

Jeg mener bestemt at programvare bør brukes som et verktøy, ikke som en krykke man er avhengig av. Verktøy som oversikter er uvurderlige for å gi innsyn i sanntid i saksstatus, responstider og utviklingen i saksetterslepet. De hjelper teamene med å holde kursen og identifisere områder som trenger oppmerksomhet, men de bør ikke erstatte meningsfullt engasjement eller kommunikasjon i teamet.

Slik bruker du programvare effektivt til å følge med på ytelsen:

  • Sett opp oversikter for innsikt i sanntid: Bruk oversikter til å overvåke nøkkeltall som saksstatus, overholdelse av SLA-er og størrelsen på saksetterslepet med et blikk.
  • Gjennomfør regelmessige ytelsesvurderinger: Planlegg ukentlige eller månedlige gjennomganger for å vurdere teamets ytelse opp mot SLA-målene, identifisere flaskehalser og gjennomføre forbedringer.
  • Analyser innsamlede data: Bruk historiske data til å avdekke trender, vurdere arbeidsfordelingen og justere ressursfordelingen etter behov.
  • Integrer SLA-er i KPI-er: Inkluder SLA-relaterte nøkkeltall – for eksempel svarprosent, løsningstider eller kundetilfredshet – i individuelle mål og teammål for å styrke ansvarsbevisstheten.
  • Finn en balanse mellom automatisering og menneskelig oppfølging: Selv om oversikter er nyttige, bør du ha direkte kontakt med teamet for å forstå utfordringene og gi støtte der det trengs.

Ved å kombinere automatisert oppfølging med regelmessige gjennomganger og engasjement i teamet kan du skape et helhetlig system som øker produktiviteten, ansvarsbevisstheten og kundetilfredsheten.

Kontinuerlig opplæring

Produktet eller plattformen din er i kontinuerlig endring, med nye funksjoner og oppdateringer av eksisterende funksjoner for å håndtere problemer på en trygg måte og oppfylle SLA-forpliktelser. En uopplært analytiker som står overfor en ukjent funksjon, kan forsinke løsningstiden, påvirke kundetilfredsheten og skape unødvendige hindringer.  

Det vil lønne seg på lang sikt å støtte teamet ditt, og faktisk alle relevante interessenter, med kontinuerlig opplæring. Her er noen anbefalte fremgangsmåter:

  • Opprett tilgjengelige kunnskapsarkiver: Vedlikehold en oppdatert intern kunnskapsbase eller wiki der teammedlemmer raskt kan finne informasjon om produktfunksjoner og kjente problemer.
  • Simuler virkelige scenarier: Bruk praktiske øvelser, for eksempel simulert problemløsning eller gjennomganger av funksjoner, for å forsterke læringen og bygge selvtillit.
  • Oppmuntre til samarbeid på tvers av team: Involver produktutviklere, QA-team og andre avdelinger for å dele innsikt og kontekst om nye funksjoner og oppdateringer.
  • Tilby rollebasert opplæring: Tilpass øktene til ulike teamroller, slik at alle – fra førstelinjestøtte til eskaleringsspesialister – får den spesifikke kunnskapen de trenger.
  • Utnytt mikrolæring: Del opp opplæringen i små moduler som er enklere å ta til seg og mindre forstyrrende for den daglige driften.
  • Følg opp opplæringsfremdriften: Bruk måledata til å overvåke fullføringsgrad for opplæringen, kunnskapsbevaring og hvilken innvirkning dette har på løsningstider og overholdelse av SLA.

Ved å prioritere kontinuerlig opplæring gjør du teamet i stand til å håndtere nye utfordringer effektivt, samtidig som du styrker moralen og bygger selvtillit. Et godt opplært team er et myndiggjort team som kan levere fremragende støtte og sikre kundetilfredshet.

Effektivisering gjennom automatisering

Bruk brukerstøtteverktøy til automatisk å tilordne prioritetsnivåer basert på forhåndsdefinerte regler, for eksempel nøkkelord, tagger eller historikken til tidligere supportsaker.

Jeg liker å bruke tagger til å gruppere og organisere supportsaker og problemer. Tagger gjør det enklere å søke etter bestemte problemer, følge opp tilbakevendende problemer og identifisere mønstre som kan gi grunnlag for produktforbedringer eller forbedringer av funksjoner.

Viktige fordeler ved tagging inkluderer:

  • Forbedret søkbarhet: Finn raskt supportsaker uten å måtte gå gjennom køen.
  • Mønstergjenkjenning: Identifiser tilbakevendende problemer for å legge til rette for proaktive produktforbedringer.
  • Personlig kundestøtte: Tilpass svarene basert på kundens unike historikk ved å merke relaterte supportsaker.
  • Effektiv ressursallokering: Utviklere kan håndtere flere lignende problemer samtidig, noe som forbedrer løsningstidene og styrker ytelsesberegningene.

Dette er spesielt nyttig i systemer som håndterer store mengder supportsaker, ettersom tagger gjør det enklere å finne bestemte problemer uten å måtte gå gjennom køen manuelt. 

Jeg er også en tilhenger av at KI, vanlige spørsmål og selvbetjeningsalternativer bygges inn i eller integreres med en plattform. En velorganisert kunnskapsbase gjør det mulig for kundene å finne svar på vanlige spørsmål eller trinn for feilsøking. 

Hvis en kunde for eksempel skriver «Hvordan oppdaterer jeg profilen min?», kan boten foreslå en artikkel med trinnvise instruksjoner. Denne integrasjonen bygger bro mellom chatbotter og selvbetjeningsressurser og løser enkle problemer og problemer med lavere prioritet med minimal menneskelig innblanding. 

Denne tilnærmingen sikrer at brukerstøtteteamet bruker mer tid på saker med høy prioritet eller komplekse saker, samtidig som kundene får raskere løsninger på de daglige behovene sine.  

Utfordringer og løsninger ved prioritering av supportsaker

Selv de best utformede systemene for prioritering av supportsaker kan møte utfordringer som forstyrrer arbeidsflyten og påvirker kundetilfredsheten. Hindringer kan overvelde teamene hvis de ikke håndteres.

Se på disse vanlige utfordringene og mine foreslåtte løsninger for å holde brukerstøttearbeidet i gang uten problemer:

Unngå overprioritering

Overprioritering. Ja, det er faktisk en greie! Ikke alle supportsaker kan være kritiske problemer.  Når for mange supportsaker får høy prioritet, blir virkningen av virkelig kritiske problemer utvannet. Denne utvanningen kan føre til at viktige saker ikke får den oppmerksomheten de faktisk krever. 

I tillegg kan teamene få problemer med å svare på eller løse supportsaker raskt når alt har høy prioritet, særlig fordi supportsaker med høy prioritet ideelt sett bør håndteres raskere enn andre. I beste fall kan dette føre til at teamet blir utbrent.  I verste fall vil kundetilfredsheten synke over tid, noe som fører til tap av tillit.  

Overprioritering kan unngås med noen enkle tiltak.

  • Etabler konsekvente prosesser for vurdering av saker: Over tid kan teammedlemmer begynne å merke saker som høyere prioritert som standard. Bruk av en beslutningsmatrise og gjennomføring av regelmessige gjennomganger vil bidra til å samordne prioriteringene på nytt og sikre at de opprinnelige standardene følges.
  • Definer tydelige prioritetsnivåer og kriterier: Opprett tydelige definisjoner for høy, middels og lav prioritet, med vekt på faktorer som påvirkning, hast og risiko. Denne tydeligheten hindrer teamene i å tildele høy prioritet til saker med mindre de faktisk oppfyller kritiske kriterier.  Sørg for at prioritetsnivåene er i tråd med selskapets mål og kundeforpliktelser. Problemer som påvirker samsvar eller tjenestenivåavtaler (SLA-er), kan for eksempel gå foran ikke-kritiske forespørsler om nye funksjoner, noe som bidrar til å prioritere oppgaver som samsvarer med forretningsverdien.
  • Overvåk og gjennomgå prioriteringsdata: Gjennomfør jevnlige revisjoner av sakens prioritet for å se etter mønstre.  Hvis du finner hyppige tildelinger av høy prioritet som ikke samsvarer med de definerte kriteriene, bør du justere prosessen eller definisjonene deretter.
  • Oppmuntre til åpen kommunikasjon: Lær opp teammedlemmene i hvordan de skal vurdere den faktiske påvirkningen av et problem.  Veiled dem slik at de forstår når en sak faktisk har høy prioritet.  Overprioritering kan skyldes press for å tilfredsstille kunder. Sett realistiske forventninger med kundene når det gjelder svartider basert på sakens prioritet, og presiser at saker med høy prioritet bare er forbeholdt kritiske problemer.

More Articles

Administrer sakskøer

Å administrere en sakskø for programvare kan føles som å tømme en endeløs innboks, spesielt når antallet saker begynner å øke. Men med noen strategiske grep kan du forhindre at den vokser til noe uhåndterlig.

For meg er regelmessige gjennomganger det første forsvarsverket. Jeg henter frem minner fra ungdommen (for MANGE år siden). Hver uke fikk moren min meg til å gå gjennom hvert rom i huset, tømme søppelbøttene og deretter ta søppeldunkene ut til veikanten. Gjennomgangen din bør være som å rydde ut søppelbøttene.  Gå gjennom sakskøen hver uke for å luke ut saker som er utdaterte, løst et annet sted eller kanskje ikke lenger er gyldige. 

En annen metode for å administrere sakskøen er gjennom omprioritering. Det er lett å la kunde- og kollegabias begynne å trenge inn i de godt utformede retningslinjene dine, noe som resulterer i en skjev sakskø med problemer med høy prioritet og alvorlighetsgrad. Vi har imidlertid allerede fastslått at ikke alle saker faktisk har høy prioritet. Ved konsekvent å revurdere prioriteringene og gjennomføre regelmessig opplæring kan du flytte fokuset til det som faktisk er kritisk. Når du tilbakestiller prioriteringene, kan teamet ta tak i oppgaver med stor påvirkning og holde arbeidet i gang på en smidig måte.

Supportområdet er ikke alltid glamorøst eller morsomt, og kan ofte være stressende på grunn av store saksmengder eller misfornøyde kunder som ønsker at dagens problem skulle vært løst i går. Du må finne måter å holde teamene motiverte og fornøyde på. Vær kreativ med litt vennskapelig konkurranse eller spillifisering av sakskøen.

Du kjenner de skiltene som ofte henger på lageret, og som sier noe i retning av «85 dager uten ulykker»? Lag et mål og en tidsfrist langs disse linjene, legg til en liten premie som motivasjon, og la teamet sette i gang. Dette tømmer ikke bare køen raskere, men oppmuntrer også til fellesskap. 

Ved å gjennomgå saksdata kan organisasjoner forbedre seg organisk. Denne prosessen gir innsikt i miljøets tilstand, prosessenes helse og tjenestenes kvalitet. Regelmessig dataanalyse driver kontinuerlige forbedringer. Resultatene av saksanalysen bør følges opp, noe som kan innebære å feire suksesser når dataene ser gode ut. Ved behov kan resultatene danne grunnlag for større endringer i servicedeskstrategien eller prosessene. Det er også viktig å kommunisere resultatene til de rette interessentene, fra sluttbrukere til teknikere og ledelsen.

Share This Quote on:

Forbedre prioriteringssystemet

Så saksystemet ditt fungerer problemfritt. Du kan nå gå videre, la det være og ta fatt på det neste store målet i organisasjonen, ikke sant? Feil! Dette må være et levende system som analyseres og revurderes regelmessig. 

Jeg anbefaler at du identifiserer kriteriene og måleverdiene som fungerer best for deg og organisasjonen din. Her er noen måleverdier som jeg bruker regelmessig:

Kundetilfredshet: Ja, jeg vet at dette er selvsagt, men du ville blitt overrasket over hvor mange som blir opptatt av å fokusere bare på sakstider, gjenåpningsrater og mer. Kundene dine er den beste måleverdien. Ta kontakt med dem og vurder om du innfrir forventningene deres. Bruk undersøkelser og tilbakemeldingsskjemaer for å samle inn informasjon. Hvis du får tilbakemeldinger om at de er misfornøyde med hvor raskt saker med lav prioritet blir løst, kan det være på tide å revurdere kriteriene dine for saker med lav prioritet.

Intern tilbakemelding: Siden de arbeider direkte med supportsystemet, har teammedlemmene dine ofte uvurderlig innsikt. Informerer de deg om at de ofte ser flaskehalser oppstå? De kan også se at prioritetsklassifisering blir overbrukt. Ved å innhente tilbakemeldinger fra teamet bidrar du til å holde dem engasjert og få dem til å føle at de er en del av prosessen.  

Løsningstid: Hva er den gjennomsnittlige løsningstiden teamet ditt oppnår? Konsekvent korte løsningstider på saker med høy prioritet viser at teamet håndterer hastesaker effektivt. På den annen side kan et høyt gjennomsnitt være et tegn på symptomer som overbelastning eller overprioritering. Sammenlign de gjennomsnittlige løsningstidene med SLA-ene dine. Dette viser deg om hvert prioritetsnivå får tilstrekkelig oppmerksomhet og oppfyller avtalte standarder. Ikke vær redd for å justere nivåene dine i begge retninger.  

Avsluttende tanker

Et godt system for prioritering av supportsaker er som et veikart for supportteamet ditt. Det viser dem hvor de skal begynne, slik at de mest kritiske problemene håndteres umiddelbart, samtidig som alt annet er lett synlig. Du vil bli positivt overrasket over hvor mye tid det sparer, for ikke å nevne at det reduserer kaoset.  

Men de virkelige gevinstene oppstår når du følger med på det. Ved å overvåke hvordan saker prioriteres, kan du oppdage eventuelle problemer tidlig. Dette gir deg muligheten til å justere underveis og sørge for at ting fortsetter å fungere problemfritt, selv når de endrer seg. 

Det er som å holde bilen godt ved like. Skift olje, sjekk dekkene og fyll på drivstoff, så vil den fortsette å ta deg fremover og spare deg for mange problemer senere.

Abonner på nyhetsbrevet til The CTO Club for flere tips, verktøy og anbefalte fremgangsmåter for prioritering av supportsaker.

Trent Thacker
Trent Thacker is a dynamic technology leader with over a decade of experience driving innovation in software engineering and digital product development. As a former CTO and Product Director, Trent has a proven track record of leading high-performing teams, optimizing engineering processes, and delivering scalable solutions. Passionate about fostering engineering excellence, he thrives at the intersection of technology and leadership. Outside of work, Trent is a dedicated fitness enthusiast and an avid outdoorsman, always balancing his professional achievements with a commitment to health and family. His expertise in building tech strategies and creating impactful products makes him a go-to voice for media seeking insights on the future of software and leadership.
Follow the author:

You may also like