Deskhero
Dansk
Prøv gratis

← Back to articles

Dashboards til kundesupportledere: Skabeloner og KPI'er

Dashboards til kundesupportledere: Skabeloner og KPI'er

Supportledere har ofte brug for seks dashboardvisninger: en live operationel wallboard, en køvisning for ledere, scorecards for Brugere, et dashboard til CSAT-tendenser, en SLA-sundhedsmonitor og en risikovisning for ledelsen. En praktisk implementering bruger to lag: en operationel visning for Brugere og teamledere samt rollespecifikke drill-downs for ledere og direktion.

Overvej KPI’er på niveau 1: Første svartid (FRT), løsning ved første kontakt (FCR), kundetilfredshedsscore (CSAT), gennemsnitlig håndteringstid (AHT) og SLA-overholdelsesgrad.

Niveau 2 (operationel sundhed): Backlogstørrelse, eskaleringsgrad, tickets pr. Bruger.

Kvinde gennemgår udskrevne KPI-rapporter set ovenfra

Niveau 3 (forretningspåvirkning): Omkostning pr. løsning, supportpåvirket omsætning og signaler om churn-risiko fra ticketmønstre.

To supportmedarbejdere diskuterer en live wallboard på et tv

En fornuftig vej til produktion er at forbinde din helpdesk, oprette rollespecifikke visninger, fastsætte tærskler og publicere hver visning dér, hvor målgruppen rent faktisk vil bruge den.

De seks skabeloner, der gennemgås nedenfor:

  • Live operationel wallboard
  • Kø- og arbejdsbelastningsvisning for ledere
  • Scorecards for Brugere
  • CSAT- og kvalitetsdashboard
  • Monitor til SLA og ældre tickets
  • Strategisk og produktrettet dashboard

Pro-tip: Byg ikke alle seks på én gang. Start med wallboarden og én visning for ledere. Få dem på plads, før du tilføjer resten.

Indholdsfortegnelse

Hvilke typer supportdashboards findes der, og hvornår bør du bruge dem?

Delte wallboards i realtid gør operationelle nøgletal synlige for hele teamet. Men ikke alle dashboards bør opdatere hvert sekund, og ikke alle målgrupper har brug for den samme visning.

De fire hovedtyper kan opdeles efter beslutningshastighed og målgruppe:

  • Operationel wallboard: Live kødybde, aktive tickets, Brugere online og nedtællingstimere for SLA. Udviklet til Brugere og teamledere, der skal reagere inden for få minutter. Opdatering: realtid.
  • Kø- og bemandingsvisning for ledere: Åbne tickets efter alder og prioritet, Brugeres tilgængelighed, procentdel af SLA’er i risikozonen og heatmaps over backlog. Opdatering: realtid til hver time.
  • Personligt scorecard for Brugere: Lukkede tickets i dag, personlig CSAT, AHT og placering på ranglisten. Opdatering: realtid eller øjebliksbillede ved vagtens afslutning.
  • Risikodashboard for ledelsen: SLA-tendens, CSAT-tendens, eskaleringsgrad, churn-risikomarkeringer og omkostning pr. løsning. Opdatering: dagligt til ugentligt.

To yderligere typer tjener specifikke formål. Et CSAT- og kvalitetsdashboard følger svarprocenter på undersøgelser, tendenslinjer og stikprøver af ordrette kommentarer. Et dashboard til SLA og ældre tickets forudsiger brud, før de sker.

Dashboardtype Primær målgruppe Understøttet beslutning Opdateringsfrekvens
Live operationel wallboard Brugere, teamledere Reagér på stigninger i køen nu Realtid
Køvisning for ledere Supportledere Omfordel arbejdsbelastning, markér SLA-risiko Realtid til hver time
Scorecard for Brugere Individuelle Brugere Korrigér egen adfærd, følg mål Realtid eller ved vagtens afslutning
CSAT og kvalitet QA, ledere Identificér fokusområder for coaching Dagligt
SLA og ældre tickets Ledere, drift Forebyg brud, eskalér tidligt Realtid til hver time
Risikovisning for ledelsen Direktører, VP’er Opdag risici på forretningsniveau Dagligt til ugentligt

Det er vigtigt at knytte visningen til anvendelsesområdet. Et callcenter kan have wallboarden og SLA-monitoren vist på et tv hele dagen. En SaaS-helpdesk fokuserer måske på CSAT-tendenser og tilbagevendende problemer. Et e-handelsteam i højsæsonen bruger måske mere tid i køvisningen for ledere. Fjern- og hybridteams kan publicere en operationel visning i en delt kanal, hvis deres rapporteringssystem understøtter det.

Vælg en opdateringsfrekvens, der passer til beslutningen. Operationelle visninger kan have brug for live- eller timedata, mens tendens- og ledelsesvisninger kan opdateres dagligt eller ugentligt. Denne reference til supportnøgletal indeholder yderligere definitioner og kontekst.

Pro-tip: Vis dashboards dér, hvor folk allerede arbejder. Et dashboard, som ingen åbner, er bare en rapport.

Hvilke KPI’er hører hjemme på dine supportdashboards?

Et trindelt nøgletalsframework kan adskille taktiske signaler, som Brugere handler på dagligt, fra målinger, der forbinder support med bredere forretningsresultater. Her er én måde at strukturere dem på.

Infografik, der illustrerer KPI-niveauer og kategorier for supportdashboards

KPI Formel / definition Niveau Hvem ser den
Første svartid (FRT) Tid fra oprettelse af ticket til første svar fra en Bruger 1 Brugere, ledere, direktion
Løsning ved første kontakt (FCR) Tickets løst ved første kontakt ÷ samlede antal tickets 1 Ledere, direktion
CSAT Sum af positive vurderinger ÷ samlede antal undersøgelsessvar 1 Alle roller
Gennemsnitlig håndteringstid (AHT) Samlet håndteringstid ÷ håndterede tickets 1 Brugere, ledere
SLA-overholdelsesgrad Tickets løst inden for SLA ÷ samlede antal tickets 1 Ledere, direktion
Backlog / ældre tickets Åbne tickets, der er ældre end X dage 2 Ledere
Eskaleringsgrad Eskalerede tickets ÷ samlede antal tickets 2 Ledere
Tickets pr. Bruger Samlede tickets ÷ aktive Brugere 2 Ledere
Omkostning pr. løsning Samlede supportomkostninger ÷ løste tickets 3 Direktion
Supportpåvirket omsætning Omsætning fra konti med løste tickets i perioden 3 Direktion, CS-ledere
Churn-risikosignal Konti med høj ticketmængde + lav CSAT + ingen løsning 3 CS-ledere, direktion

Centrale kundeservicenøgletal som CSAT, Customer Effort Score (CES) og Net Promoter Score (NPS) følges bredt, men de tjener forskellige formål. CSAT måler tilfredshed med en specifik interaktion. CES måler, hvor nem interaktionen var. NPS måler den overordnede loyalitet. For de fleste supportdashboards hører CSAT og CES til på det operationelle lag; NPS egner sig bedre til ledelsesvisningen.

Et par bemærkninger om benchmarks: branchegennemsnit for CSAT varierer betydeligt efter sektor og tickettype. I stedet for at jagte et universelt tal bør du fastlægge dit udgangspunkt i de første 30 dage og måle forbedringer derfra. FCR-benchmarks afhænger på samme måde af produktets kompleksitet og kanalsammensætningen.

Det er kombinationen af ticketdata med CRM- og faktureringsdata, der flytter support fra operationel rapportering til forretningspåvirkning. Når du kan se, at en konto med mange tickets og faldende CSAT også skal fornye næste måned, er det et niveau 3-signal, der bør eskaleres.

Brugere kan have brug for et fokuseret udvalg af KPI’er på niveau 1. Ledere har normalt brug for niveau 1 og 2. Direktionen har generelt brug for tendenser og signaler om forretningspåvirkning frem for rå ticketantal.

Seks brugsklare dashboardskabeloner til supportteams

Disse skabeloner er designet til at blive kopieret direkte ind i din helpdesk eller dit BI-værktøj. Hver skabelon knytter sig til en specifik målgruppe, beslutning og datakilde.

Skabelon Primær målgruppe Uundværlige nøgletal Typiske visualiseringer Opdatering Forventet handling
Live operationel wallboard Brugere, teamledere Kødybde, FRT, SLA-nedtælling, Brugere online Målere, købjælker, alarmbannere Realtid Reagér på stigninger, omfordel tickets
Køvisning for ledere Supportledere Åbne tickets efter alder/prioritet, % SLA i risikozonen, Brugeres tilgængelighed Heatmaps, stablede bjælker Realtid til hver time Omfordel arbejdsbelastning, eskalér
Scorecards for Brugere Individuelle Brugere Lukkede tickets i dag, CSAT, AHT, placering på ranglisten Fremskridtsbjælker, mikro-tendenser Realtid eller ved vagtens afslutning Korrigér egen indsats, nå daglige mål
CSAT og kvalitet QA, ledere CSAT-tendens, svarprocent, ordrette eksempler, kvalitetsscore Tendenslinjer, fordelingsdiagrammer Dagligt Identificér fokusområder for coaching
SLA og ældre tickets Ledere, drift Prognose for SLA-brud, aldersfordeling, eskaleringsgrad Stablede bjælker, tærskelmarkører Realtid til hver time Forebyg brud, eskalér tidligt
Strategisk / produktrettet Direktører, CS-ledere Problemklynger, churn-risikomarkeringer, supportpåvirket omsætning Tendenslinjer, kohortetabeller Dagligt til ugentligt Prioritér produktforbedringer, markér fornyelsesrisiko

Skabelon 1: Live operationel wallboard. Wallboarden er hjertet på dit supportgulv. Vis kødybde pr. kanal, FRT for de seneste 60 minutter, en nedtælling for tickets, der nærmer sig et SLA-brud, samt et liveantal for Brugere online. Brug store målere til kødybden og farvekodede alarmbannere, når tærskler overskrides. Wallboards til kontor-tv kan opsættes hurtigt og giver hele teamet et fælles situationsbillede, uden at nogen behøver åbne en rapport.

Skabelon 2: Kø- og arbejdsbelastningsvisning for ledere. Det er dashboardet, du tjekker før et standupmøde. Åbne tickets sorteret efter alder og prioritet, Brugeres tilgængelighed (ledig vs. optaget vs. offline), procentdelen af SLA’er i risikozonen samt et heatmap, der viser, hvor backloggen koncentrerer sig efter segment eller produktområde. Timelig opdatering er fint for det meste, men SLA-risikoen bør opdateres i realtid.

Skabelon 3: Scorecards for Brugere. Hver Bruger ser sine egne tal: tickets lukket i dag sammenlignet med det daglige mål, personlig CSAT-score, AHT og placering på teamets rangliste. Fremskridtsbjælker fungerer godt her. En mikro-tendenslinje, der viser CSAT over de seneste 7 dage, giver Brugere kontekst uden at overvælde dem. Opdatér ved vagtens afslutning for et rent dagligt øjebliksbillede, eller i realtid, hvis teamet går op i ranglistens placering.

Skabelon 4: CSAT- og kvalitetsdashboard. CSAT-dashboards kan kombinere svarprocenter på undersøgelser, tendenslinjer og udvalgte kommentarer. Vis CSAT-tendensen over 30 og 90 dage, svarprocenten, et udvalg af nylige kommentarer samt en opdeling af kvalitetsscoren efter Bruger eller team. Tilføj segmentfiltre for kanal, produktområde eller kundetier.

Skabelon 5: Monitor til SLA og ældre tickets. Målet her er at opdage brud, før de sker. Vis en prognose for brud (tickets, der sandsynligvis overskrider SLA inden for de næste 2 timer), et diagram over aldersfordelingen for åbne tickets samt eskaleringsgraden over tid. Brug tærskelmarkører på søjlediagrammer, så risikoniveauet er visuelt tydeligt. SLA-overvågning i realtid med drill-downs til analyse af grundårsager er en standardfunktion i modne contactcenterdashboards.

Skabelon 6: Strategisk og produktrettet dashboard. Denne visning forbinder support med forretningen. Vis tilbagevendende emner i tickets og, hvor dine data understøtter det, indikatorer for kontorisiko, supportpåvirket omsætning og påvirkning af salgstragten. Kombinationen af fastholdelsesorienterede signaler med kontodata kan hjælpe CS-ledere med at undersøge risiko før en fornyelsessamtale.

Sådan fastsætter du mål, tærskler og alarmer, der faktisk ændrer adfærd

Et dashboard uden tærskler er bare en resultattavle. Tærskler omdanner nøgletal til udløsere.

Framework til fastsættelse af mål:

  1. Fastlæg dit udgangspunkt (de første 30 dage med rene data).
  2. Fastlæg et beskedent, målbart forbedringsmål ud fra udgangspunktet.
  3. Definér operationelle tærskler, der er knyttet til resultater, som dine egne data kan understøtte.

Eksempler på tærskler som startpunkt:

  • FRT for prioritet 1-tickets: alarm efter 30 minutter, eskalér efter 60 minutter.
  • Procentdel af SLA’er i risikozonen: gul ved 15 %, rød ved 25 %.
  • Udløser ved fald i CSAT: alarm, når den rullende CSAT over 7 dage falder mere end 5 point fra gennemsnittet over 30 dage.
  • Vækst i backlog: alarm, når antallet af åbne tickets vokser med mere end 20 % på én time.

Regler for alarmerouting:

  • Alle alarmer skal indeholde kontekst: antal berørte kunder, 2 til 3 eksempler på ticketlinks og det relaterede produktområde.
  • Send prioritet 1-alarmer til både den ansvarlige leder og teamets delte alarmkanal.
  • Begræns ikke-kritiske alarmer til én notifikation pr. 30 minutter for at forebygge alarmtræthed.
  • Saml alarmer med lav alvorlighed i en daglig oversigt.

Coachingworkflow, når en alarm udløses:

  1. Triagering: Hent eksempletickets. Er der tale om en stigning i volumen, et kompetencegab eller en procesfejl?
  2. Gennemgang af eksempler: Læs 3 til 5 tickets fra den markerede Bruger eller kø. Se efter mønstre.
  3. Coach og dokumentér: Tag en samtale på 10 minutter. Aftal én specifik ændring. Log den.
  4. Opfølgning og afslutning: Tjek nøgletallet igen efter 48 timer. Holdt ændringen?

Et kort lederscript til trin 3: “Jeg har bemærket, at din AHT på faktureringstickets steg med 40 % i denne uge. Jeg har fundet tre eksempler, og det ser ud til, at refusionsprocessen er uklar. Lad os gennemgå den sammen og opdatere vidensbaseartiklen.”

Pro-tip: Indstil notifikationer før eskalering tidligt nok til, at teamet kan handle, før et SLA-brud sker. Test ændringer i tærskler som små, tidsafgrænsede eksperimenter, før du gør dem permanente.

Bedste praksis for design og data i præcise dashboards

Dårlige data ind, dårlige beslutninger ud. Disse regler forebygger de mest almindelige dashboardfejl.

Tjekliste for datakilder:

  • Udpeg én autoritativ kilde pr. nøgletal. Hvis FRT findes i din helpdesk, må den aldrig genberegnes i et regneark.
  • For teams med flere kanaler skal ticket-tidsstempler normaliseres til én tidszone, før data kombineres.
  • Anbefalede sammenkoblinger til nøgletal på niveau 3 omfatter ticketdata, CRM-kontoregistre, faktureringsstatus og relevante produkthændelser.
  • Vis manglende data tydeligt. En tom celle er mindre farlig end et nul, der ser ægte ud.

Navngivning og definitioner:

  • Skriv en definition på én linje for hvert nøgletal på dit dashboard. Gem den i en delt nøgletalsordbog (en Notion-side eller wikiartikel fungerer fint).
  • Versionsstyr dine definitioner. Når du ændrer, hvordan FCR beregnes, skal du notere datoen, så historiske sammenligninger forbliver gyldige.

Regler for visualisering:

  • Brug målere til enkeltværdier med et tydeligt mål (kødybde, SLA-overholdelse).
  • Brug tendenslinjer til alt, der skal ses over tid (CSAT, FRT, ticketvolumen).
  • Brug ranglister til sammenligninger på Brugerniveau, men kun når stikprøvestørrelsen er stor nok til at være meningsfuld.
  • Brug heatmaps til at vise backlogkoncentration efter segment, tidspunkt på dagen eller produktområde.
  • Brug aldrig stablede procentbjælker uden samtidig at vise absolutte værdier.
Datakilde Autoritativt nøgletal Anbefalet opdatering
Helpdesk- / ticketsystem FRT, AHT, FCR, ticketvolumen, SLA-overholdelse Realtid
CSAT-undersøgelsesværktøj CSAT-score, svarprocent, ordrette kommentarer Dagligt
CRM Kontotier, fornyelsesdato, kontraktværdi Dagligt
Faktureringssystem MRR, betalingsstatus Dagligt
Produktanalyse Funktionsbrug, loginhyppighed Dagligt til ugentligt

Governance:

  • Udpeg én dashboard-ejer pr. visning. Denne person er ansvarlig for nøjagtighedstjek og opdatering af definitioner.
  • Udfør et månedligt nøjagtighedstjek: Udtræk 10 tilfældige tickets, og kontrollér, at dashboardtallene stemmer overens med rådataene.
  • Begræns adgangen efter rolle. Brugere ser deres eget scorecard. Ledere ser data på teamniveau. Direktionen ser aggregerede tendenser.

Pro-tip: Efter lanceringen skal du manuelt beregne én uges FRT ud fra rå ticketudtræk og sammenligne den med dashboardet. Undersøg alle væsentlige afvigelser, herunder indstillinger for tidszone, filtre og arbejdstid.

Hvor lang tid tager det at implementere supportdashboards?

Implementeringstiden afhænger af teamets størrelse, datakvaliteten, antallet af kilder, og om du bruger indbygget rapportering eller et BI-værktøj. Betragt intervallerne nedenfor som planlægningsestimater, ikke garantier.

Fase Lille team (1 til 10 Brugere) Mellemstort team (11 til 49 Brugere) Modent team (50+ Brugere)
Afklaring og datakortlægning 1 til 2 dage 3 til 5 dage 1 til 2 uger
Opbygning af dashboard 2 til 3 dage 1 til 2 uger 2 til 4 uger
QA og pilotprojekt 1 til 2 dage 3 til 5 dage 1 til 2 uger
Udrulning og oplæring 1 dag 2 til 3 dage 1 uge
I alt ~1 uge 2 til 4 uger 5 uger eller mere

Roller, du har brug for:

  • Supportleder: definerer krav, validerer nøgletal og ejer udrulningen.
  • Data engineer eller BI-analytiker: bygger sammenkoblinger og opsætter opdateringspipelines.
  • QA-leder: validerer nøjagtigheden før lancering.
  • Forandringsleder (større teams): håndterer oplæring og ibrugtagning.

Omkostningsdrivere: Den største variabel er arbejdet med datateknik. Hvis din helpdesk har færdige forbindelser til dit BI-værktøj, kan du springe det meste pipelinearbejde over. Gør-det-selv-opsætninger med indbygget helpdesk-rapportering koster mindst, men giver også mindst fleksibilitet. Indlejrede leverandørdashboards (indbygget i din helpdeskplatform) er den hurtigste vej til produktion. Antallet af licenser til selvstændige BI-værktøjer vokser hurtigt for større teams.

Tjekliste til udrulning:

  1. Forbind din helpdesk-datakilde, og kontrollér kortlægningen af ticketfelter.
  2. Byg først den live operationelle wallboard, og publicér den på et tilgængeligt, delt sted.
  3. Tilføj køvisningen for ledere. Validér beregningerne af SLA-risiko.
  4. Test med ét team i to uger, før du ruller ud til alle teams.
  5. Udfør nøjagtighedstjekket (se governanceafsnittet ovenfor).
  6. Undervis Brugere i deres scorecards på en session på 15 minutter.
  7. Planlæg en 30-dages gennemgang for at justere tærskler og filtre.

Et lille team, der bruger indbygget helpdesk-rapportering, kan muligvis lancere en wallboard og en ledervisning på cirka en uge. Ryddelige ticketfelter og ensartede definitioner er fundamentet for alt, der følger.

Sådan understøtter Deskhero operationelle visninger og rapporteringsvisninger

Deskhero indeholder et operationelt dashboard, en konfigurerbar ticketliste, faste statistikvisninger, SLA-rapportering og en API. Det gengiver ikke alle de tilpassede BI-dashboards, der er beskrevet ovenfor, men dækker mange almindelige behov for helpdeskrapportering uden et separat BI-værktøj.

Kortlægning fra funktion til skabelon:

  • Operationelt dashboard: Statusopdelinger, aktive tickets, tickets, der venter på et første svar, tendenser i ticketvolumen, gennemsnitlig første svartid og gennemsnitlig løsningstid vises i én liveopdateret visning med et gruppefilter.
  • Køvisning for ledere: Ticketlisten understøtter kolonner og filtre for status, prioritet, gruppe, ansvarlig, tag, SLA og brugerdefinerede felter. Hver Bruger kan vælge og sortere sine egne kolonner og filtre.
  • Teamrapportering: Statistiksektionen indeholder tabeller pr. gruppe og Bruger. Bruger-ranglisten skelner også mellem arbejde håndteret af Deskhero AI via autosvar og chatbotten.
  • SLA-overvågning: Konfigurerbare politikker fastsætter mål for første svar og løsning. Dashboardets og statistikkens SLA-visninger viser aktuel risiko og historisk målopfyldelse, mens alarmer for risiko og brud bruger notifikationer i appen og via e-mail.
  • Tendens- og emnevisninger: Faste statistikfaner dækker tendenser, svartider, kanaler, AI og automatisering samt tilbagevendende emner. Emneklyngen kræver cirka 100 tickets og genskabes omtrent ugentligt på betalingsplaner.
  • Ekstern analyse: Deskheroes REST API kan levere ticketdata til en rapporteringsproces, der kombinerer dem med CRM- eller faktureringsdata. API’en er baseret på polling og har ingen udgående webhooks.

Implementeringstjekliste for Deskhero:

  • Forbind din Gmail- eller Microsoft 365-postkasse (ingen migrering, ingen ny e-mailadresse).
  • Knyt postkasser til grupper, og konfigurér de automatiseringer for nye tickets, du har brug for.
  • Tilføj Brugere, tildel roller, og konfigurér kolonner og filtre i ticketlisten.
  • Definér SLA-politikker, herunder arbejdstid og eventuelle statusser, der sætter løsningstimeren på pause.
  • Vælg præferencer for notifikationer i appen og via e-mail for hver gruppe.
  • Gennemgå først dashboardet, og brug derefter de faste statistikfaner til dybere analyse og eksport.

Deskheroes kladde-forslag kan bruge al viden i arbejdsområdet, herunder besvarede tickets, intern viden, godkendte offentlige FAQ-poster og crawlede websider. Chatbotten og automatiske svar, der er rettet mod kunder, bruger kun den godkendte offentlige FAQ. Chatbotten kan aktiveres, når arbejdsområdet har mindst 100 godkendte FAQ-poster.

Deskhero tilbyder en gratis prøveperiode på 30 dage uden krav om kreditkort. Produktets brugerflade understøtter 14 sprog, og Brugere kan oversætte tickets og kladde-svar inde i helpdesken.

Pro-tip: Forbind en postkasse i prøveperioden, konfigurér køen og SLA-politikkerne, og brug derefter data fra Dashboard og Statistics til at fastlægge et udgangspunkt, før du sætter mål.

Almindelige faldgruber i dashboarddesign, der fører til forkerte konklusioner

Den dyreste dashboardfejl er ikke en dårlig visualisering. Det er at måle det rigtige på den forkerte måde.

At blande målgrupper på én skærm er den mest almindelige strukturelle fejl. Når Brugere og ledere deler det samme dashboard, ender du med en visning, der er for støjende for Brugere og for detaljeret for ledere. Ingen af grupperne handler på den.

For stort fokus på rå ticketvolumen kan få travle teams til at se effektive ud og effektive teams til at se langsomme ud. En høj mængde lukkede tickets med svag FCR kan være mindre sund end en lavere volumen med bedre løsningskvalitet. Kombinér volumental med kvalitetstal.

At ignorere stikprøvestørrelsen i CSAT-undersøgelser giver ekstremt ustabile scorer. En CSAT på 95 % baseret på fire svar er ikke et signal. Fastlæg en minimumsgrænse for svar, før du viser en CSAT-score, og vis altid antallet af svar sammen med scoren.

For lange intervaller mellem opdateringer forvandler dashboards i realtid til historiske rapporter. Hvis din wallboard opdateres hvert 15. minut, er det ikke en wallboard. Gennemgå dine opdateringsindstillinger efter lanceringen.

Falsk-positive alarmer opstår, når tærsklerne sættes for stramt. For mange alarmer med lav værdi får folk til at ignorere dem. Start med konservative tærskler, og stram dem først, når du har bekræftet, at signalet er nyttigt.

Afkortede Y-akser på tendenslinjer får små ændringer til at se dramatiske ud. Et fald i CSAT fra 94 % til 92 % ser katastrofalt ud på et diagram, der starter ved 90 %. Start altid procentakser ved 0, medmindre du tydeligt markerer skalaen.

En sidste ting: Rapportér aldrig et nøgletal, du ikke kan forklare til den Bruger, det påvirker. Hvis en Bruger spørger “hvordan beregnes min AHT?”, og du ikke kan svare i én sætning, er nøgletallet ikke klar til et scorecard.

Vigtigste pointer

Frameworket med seks dashboards fungerer, fordi det adskiller operationelle signaler i realtid fra strategiske visninger af forretningspåvirkning og giver hver målgruppe præcis det, den har brug for for at kunne handle.

Point Detaljer
Start med to dashboards Byg først den live operationelle wallboard og køvisningen for ledere; tilføj andre visninger, når udgangspunktet er stabilt.
Inddel dine KPI’er i niveauer Vælg et fokuseret sæt KPI’er på niveau 1 for hver målgruppe; KPI’er på niveau 3 kræver ofte sammenkoblinger med CRM og fakturering.
Alarmer har brug for kontekst Alle tærskelalarmer bør indeholde antal berørte kunder, eksempler på ticketlinks og det relaterede produktområde.
Governance forebygger afvigelser Udpeg én dashboard-ejer pr. visning, og udfør et månedligt nøjagtighedstjek mod rå ticketdata.
Deskhero-rapportering Deskhero kombinerer et operationelt dashboard, faste statistikfaner, SLA-visninger, konfigurerbare ticketfiltre, Excel-eksport og en REST API baseret på polling.

Det ville jeg bygge først som supportleder

Fristelsen er at bygge alt på én gang. Lad være.

Hvis jeg startede fra bunden, ville jeg først bygge en live wallboard og en køvisning for ledere. De to visninger besvarer de mest presserende spørgsmål: Vokser køen hurtigere, end vi kan håndtere den? Er vi på vej til at overskride en SLA?

De første 30 dage handler om at måle udgangspunktet. Sæt ikke mål endnu. Hold blot øje. Du vil se mønstre, du ikke havde forventet: en stigning hver tirsdag eftermiddag, et produktområde, der genererer en stor del af eskaleringerne, eller én Bruger, hvis AHT er tre gange teamets gennemsnit for en bestemt tickettype.

Fastlæg tærskler for niveau 1 baseret på dine observationer. Tilføj scorecards for Brugere. Gennemfør din første coachingrunde ved hjælp af den firetrinsmodel, der blev beskrevet i afsnittet om alarmer ovenfor.

Når udgangspunktet er stabilt, skal du tilføje CSAT-dashboardet og SLA-monitoren. Brug tilstrækkeligt med data til at skelne mellem et vedvarende mønster og en kortvarig udsving.

Hvis en Brugers CSAT eksempelvis falder, skal du gennemgå et lille udvalg af tickets, før du coacher. Hvis flere tickets viser, at samtaler blev lukket, før kunden bekræftede en løsning, skal I aftale en specifik procesændring og kontrollere nøgletallet igen efter en fastlagt periode.

Det er hele pointen med et dashboard. Ikke diagrammet. Men den samtale, diagrammet gør mulig.

Kom i gang med Deskheroes indbyggede rapportering

Deskhero omdanner Gmail-, Google Workspace- og Microsoft 365-postkasser til tickets i en delt indbakke. De indbyggede sektioner Dashboard og Statistics gør det muligt for teams at overvåge det operationelle arbejde og langsigtede tendenser uden først at opbygge en tilpasset rapporteringsstak.

Deskhero

Dashboardet viser statusopdelinger, arbejde, der afventer et første svar, tendenser i ticketvolumen samt svartider og løsningstider. Statistics tilføjer faste visninger af tendenser, svartider, SLA-resultater, teamaktivitet, kanaler, AI og automatisering samt tilbagevendende emner. SLA-risiko kan udløse alarmer i appen og via e-mail. Til ekstern analyse tilbyder Deskhero-helpdeskplatformen også en REST API, som rapporteringsværktøjer kan hente data fra via polling.

Start en gratis prøveperiode på 30 dage uden kreditkort. Du kan beholde din eksisterende e-mailadresse.

Nyttige kilder

  • Customer Support Metrics That Drive Real Impact, SigOS.
  • Live customer service dashboards for your whole support team, Geckoboard.
  • Customer Support Dashboard for the Office TV, BoardQ.
  • 20 Essential Customer Support Metrics to Track, Fullview.
  • AI-Powered CSAT Dashboard, Merren.
  • Customer Service Metrics: Top 10 to Measure, Qualtrics.
  • How to reduce churn in self-service SaaS, Customerscore.io.

Ofte stillede spørgsmål

Hvad er et kundesupportdashboard?

Et kundesupportdashboard er en realtids- eller planlagt visning af centrale supportnøgletal, såsom kødybde, FRT, CSAT og SLA-overholdelse, som hjælper ledere og Brugere med at overvåge resultater og reagere hurtigt på signaler.

Hvad er de fire centrale nøgletal for kundeservice?

De fire mest almindelige nøgletal for kundeservice er CSAT (kundetilfredshed), FCR (løsning ved første kontakt), FRT (første svartid) og AHT (gennemsnitlig håndteringstid). De udgør fundamentet på niveau 1 i ethvert supportdashboard.

Hvad er et CSAT-dashboard?

Et CSAT-dashboard følger resultaterne fra kundetilfredshedsundersøgelser over tid og viser tendenser i scorer, svarprocenter på undersøgelser og kundekommentarer. En daglig opdatering kan hjælpe ledere med at identificere fokusområder for coaching og kvalitetsproblemer.

Hvilke er de vigtigste typer supportdashboards?

De vigtigste typer er den live operationelle wallboard, køvisningen for ledere, scorecards for Brugere, CSAT- og kvalitetsdashboardet, monitoren til SLA og ældre tickets samt det strategiske dashboard eller risikodashboardet for ledelsen. Hver type tjener en forskellig målgruppe og beslutningsfrekvens.

Hvordan analyserer man supportdata effektivt?

Start med at inddele dine nøgletal i niveauer: niveau 1 til daglige operationelle beslutninger, niveau 2 til arbejdsbelastningens sundhed og niveau 3 til signaler om forretningspåvirkning. Kombinér ticketdata med CRM- og faktureringsregistre for at komme ud over rå volumen og forbinde supportresultater med fastholdelse og omsætning.