Deskhero
Latviešu
Sākt bez maksas

← Back to articles

Palīdzības dienesta pārskatu metrikas, kas jāuzrauga vadītājiem

Palīdzības dienesta pārskatu metrikas, kas jāuzrauga vadītājiem

Būtiskākie palīdzības dienesta pārskatu rādītāji ir pieteikumu apjoms, pirmās atbildes laiks, vidējais atrisināšanas laiks (MTTR), atrisināšana pirmajā kontaktā (FCR), CSAT, SLA atbilstība, neizskatīto pieteikumu skaits un to vecums, atkārtotas atvēršanas rādītājs, eskalācijas rādītājs, Lietotāja noslodze, viena pieteikuma izmaksas un kanālu apjoms. Izsekojiet tiem kopā kā vienotam kopumam, nevis kā izvēlnei, no kuras izvēlēties, jo koncentrēšanās uz vienu skaitli rada nevēlamus stimulus: ja dzenaties tikai pēc ātruma, pieaug atkārtoti atvērto pieteikumu skaits; ja dzenaties tikai pēc CSAT, var pieaugt viena pieteikuma izmaksas.

Palīdzības dienesta pārskatu rādītāju apkopošanas vienā skatā mērķis ir vienlaikus aptvert četrus uzdevumus: efektivitāti, kvalitāti, darba slodzi un izmaksas. Ja kādu no tiem neiekļaujat, vadāt, balstoties uz nepilnīgu ainu.

Lūk, darba saraksts, ko šodien iekļaut informācijas panelī:

  • Pieteikumu apjoms: kopējais apjoms un sadalījums pa kanāliem, lai personāla plānošana atbilstu pieprasījumam
  • Pirmās atbildes laiks (FRT): cik ilgi klienti gaida pirmo saturisko atbildi
  • MTTR: mediānais atrisināšanas laiks, sadalīts pēc prioritātes
  • FCR: to pieteikumu procentuālā daļa, kas atrisināti bez eskalācijas vai papildu saziņas
  • CSAT: apmierinātības rādītājs pēc pieteikuma
  • SLA atbilstība: to pieteikumu procentuālā daļa, kas atbilst atbildes un atrisināšanas mērķiem
  • Neizskatītie pieteikumi un to vecums: atvērtie pieteikumi, sagrupēti pēc gaidīšanas ilguma
  • Atkārtotas atvēršanas rādītājs: pieteikumi, kas aizvērti un noteiktā laika periodā atvērti atkārtoti
  • Esk alācijas rādītājs: to pieteikumu procentuālā daļa, kas pārsūtīti 2. līmenim vai augstāk
  • Lietotāja noslodze: aktīvais darba laiks salīdzinājumā ar pieejamo kapacitāti
  • Viena pieteikuma izmaksas: kopējās atbalsta izmaksas dalītas ar pieteikumu apjomu
  • Kanālu apjoms: sadalījums pa e-pastu, tērzēšanu, tālruni un pašapkalpošanos

Nākamais solis: izveidojiet vienas lapas iknedēļas informācijas paneli, kurā redzams apjoms, FRT, MTTR, CSAT un neizskatīto pieteikumu vecums. Tas ir ātrākais veids, kā piecpadsmit minūšu laikā saprast, vai nedēļas laikā kaut kas būtiski nogājis greizi.

Galvenās atziņas

Palīdzības dienesta pārskati ir efektīvi tad, kad vadītāji kopā seko efektivitātes, kvalitātes, darba slodzes un izmaksu rādītājiem, nevis optimizē kādu vienu skaitli izolēti.

Atziņa Sīkāka informācija
Sekojiet pilnam kopumam Apvienojiet FRT, MTTR, FCR, CSAT, SLA atbilstību, neizskatīto pieteikumu vecumu, atkārtotas atvēršanas rādītāju, eskalācijas rādītāju, noslodzi un viena pieteikuma izmaksas.
Vērtējiet FCR kopā ar atkārtotas atvēršanas rādītāju Augsts FCR vienatnē var slēpt priekšlaicīgu pieteikumu aizvēršanu; atkārtotas atvēršanas rādītājs atklāj to, ko FCR neparāda.
Veidojiet konkrētai auditorijai paredzētus informācijas paneļus Vadībai nepieciešamas tendences un izmaksas; vadītājiem — darba slodze un riski; Lietotājiem — viņu pašu rinda.
Izmantojiet reāllaika datus operācijām un vēsturiskos datus stratēģijai Rindas dziļums un SLA taimeri nosaka tās pašas dienas lēmumus; tendenču dati palīdz pieņemt lēmumus par darbinieku pieņemšanu un procesu izmaiņām.
Automatizējiet datu plūsmu Deskhero vienā sistēmā strukturē pieteikumus no e-pasta, veidlapām un sava AI tērzēšanas robota, kā arī nodrošina fiksētus Statistics skatus ar Excel eksportu.

Satura rādītājs

Kas ir palīdzības dienesta pārskatu rādītāji un KPI?

Rādītājs ir jebkurš skaitlis, ko jūs mērāt. KPI ir rādītājs, kas piesaistīts mērķim un parāda, vai sniegums ir pieņemams. Pieteikumu apjoms ir rādītājs; “atrisināt 90% pieteikumu 8 darba stundu laikā” ir KPI, kas izveidots, balstoties uz rādītāju.

Palīdzības dienesta pārskatu rādītājus parasti iedala četrās grupās, un izpratne par to, kuru grupu aplūkojat, palīdz nepārvērtēt vienu dimensiju:

  • Produktivitātes rādītāji: pieteikumu apjoms, Lietotāja noslodze, uz Lietotāju dienā aizvērto pieteikumu skaits
  • Efektivitātes rādītāji: pirmās atbildes laiks, MTTR, laiks līdz pirmajai atbildei pa kanāliem
  • Kvalitātes rādītāji: CSAT, FCR, atkārtotas atvēršanas rādītājs, kvalitātes nodrošināšanas rezultāti
  • Izmaksu rādītāji: viena pieteikuma izmaksas, viena atrisinātā jautājuma izmaksas, virsstundu skaits, kas saistīts ar neizskatīto pieteikumu pieaugumu

Visbiežākā komandu kļūda ir izvēlēties rādītājus tāpēc, ka rīks tos prot uzrādīt, nevis tāpēc, ka tie atbilst uzņēmējdarbības mērķim. Ja vadībai rūp klientu noturēšana, CSAT un atkārtotas atvēršanas rādītājs var būt svarīgāki par neapstrādātu pieteikumu skaitu. Ja vadībai rūp darbinieku skaita plānošana, pieteikumu apjoms un Lietotāja noslodze var būt svarīgāki par CSAT. Sāciet ar lēmumu, kas jums jāpieņem, un pēc tam izvēlieties rādītāju, kas palīdz to pieņemt.

14 būtiskākie palīdzības dienesta rādītāji: definīcijas, formulas un darbības

Katrs no šiem rādītājiem ir vadītāja darba instruments, nevis rezultātu tabula. Lūk, ko katrs nozīmē, kā to aprēķināt, kā to sadalīt un kā rīkoties, kad tā vērtība mainās.

Pieteikumu apjoms. Noteiktā periodā saņemto pieteikumu kopskaits. Formula: jauno pieteikumu skaits, sadalīts pēc kanāla, prioritātes un kategorijas. Ja apjoms palielinās bez atbilstošām izmaiņām produktā, pārbaudiet, vai nav kļūdas, darbības pārtraukuma vai mārketinga kampaņas, kas palielina datplūsmu. Ilgstošs apjoma pieaugums bez darbinieku skaita palielināšanas ir agrīnākā pazīme, ka var rasties problēmas ar neizskatītajiem pieteikumiem.

Kanālu apjoms. Pieteikumu apjoms, sadalīts pēc saņemšanas avota: e-pasts, tīmekļa iegultās veidlapas, tērzēšana, tālrunis. Tas parāda, kur ieguldīt resursus, lai novirzītu klientus uz pašapkalpošanos. Ja tērzēšanas apjoms trīskāršojas, bet atrisināšanas kvalitāte pasliktinās, tā ir apmācību, nevis personāla problēma.

Pirmās atbildes laiks (FRT). Laiks no pieteikuma izveides līdz pirmajai saturiskajai Lietotāja atbildei. Formula: (pirmās atbildes laika zīmogs mīnus izveides laika zīmogs) summa, dalīta ar pieteikumu skaitu. Sadaliet pēc kanāla un prioritātes. FRT ir noderīgs, jo tas mēra pirmo gaidīšanas periodu, ko piedzīvo klients. Kad FRT palielinās, pirms risinājuma izvēles pārbaudiet maršrutēšanu, personāla noslodzi un pieprasījumu. Automātiskie saņemšanas apstiprinājumi jāskaita atsevišķi no saturiskajām atbildēm. Deskhero AI automātiskās atbildes tiek ieskaitītas kā pirmā atbilde un tiek atsevišķi nošķirtas no cilvēku atbildēm.

Vidējais atrisināšanas laiks (MTTR). Vidējais vai mediānais laiks no izveides līdz atrisināšanai. Formula: (atrisināšanas laika zīmogs mīnus izveides laika zīmogs) summa, dalīta ar atrisināto pieteikumu skaitu. Izmantojiet mediānu kopā ar vidējo vērtību, ja vairāku dienu novirzes izkropļo vidējo rādītāju. Sadaliet pēc prioritātes un kategorijas. Pieaugošs MTTR zemas prioritātes pieteikumiem, kamēr steidzamie pieteikumi paliek nemainīgi, var norādīt uz triāžas vai kapacitātes problēmu.

Atrisināšana pirmajā kontaktā (FCR). To pieteikumu procentuālā daļa, kas aizvērti vienas mijiedarbības laikā bez papildu saziņas vai eskalācijas. Formula: pirmajā kontaktā atrisināto pieteikumu skaits dalīts ar kopējo pieteikumu skaitu, reizināts ar 100. FCR un atkārtotas atvēršanas rādītājs vienmēr jāvērtē kopā. Augsts FCR kopā ar pieaugošu atkārtotas atvēršanas rādītāju var nozīmēt, ka Lietotāji pieteikumus aizver priekšlaicīgi.

CSAT. Apmierinātības rādītājs pēc atrisināšanas, parasti vērtējums no 1 līdz 5, kas saistīts ar noslēguma aptauju. Formula: apmierināto atbilžu skaits dalīts ar kopējo atbilžu skaitu, reizināts ar 100. Sadaliet pēc Lietotāja, kategorijas un kanāla. CSAT kritums vienā kategorijā, piemēram, norēķinos, kamēr kopējais CSAT saglabājas stabils, var parādīt, kur nepieciešama apmācība vai procesa pārskatīšana.

NPS vai CES, ja tos mēra. Net Promoter Score mēra lojalitāti; Customer Effort Score mēra to, cik sarežģīta šķita mijiedarbība. Neviens no tiem neaizstāj CSAT, taču CES ir īpaši noderīgs, lai identificētu šķēršļus pašapkalpošanās plūsmās, pirms klienti vispār atver pieteikumu.

SLA atbilstība. To pieteikumu procentuālā daļa, kas atbilst līgumā noteiktajiem atbildes un atrisināšanas termiņiem. Formula: SLA ietvaros atrisināto pieteikumu skaits dalīts ar kopējo pieteikumu skaitu, reizināts ar 100. Sadaliet pēc prioritātes līmeņa, jo viens apvienots SLA rādītājs var slēpt faktu, ka steidzamo pieteikumu atbilstība neatbilst prasībām, kamēr zemas prioritātes pieteikumu rādītāji izskatās labi.

Neizskatītie pieteikumi un to vecums. Atvērto pieteikumu skaits, sagrupēts vecuma grupās (0–24 stundas, 1–3 dienas, vairāk nekā 3 dienas). Vecāku pieteikumu skaita pieaugums var liecināt par kapacitātes vai darbplūsmas problēmu, vēl pirms netiek sasniegts SLA mērķis.

Atkārtotas atvēršanas rādītājs. To atrisināto pieteikumu procentuālā daļa, kas atkārtoti atvērti noteiktā periodā, parasti 48 stundu laikā. Formula: atkārtoti atvērto pieteikumu skaits dalīts ar atrisināto pieteikumu skaitu, reizināts ar 100. Atkārtotas atvēršanas rādītāja salīdzināšana ar FCR palīdz atklāt, vai ātrāka aizvēršana netiek panākta uz ilgstošas atrisināšanas rēķina.

Eskalācijas rādītājs. To pieteikumu procentuālā daļa, kas novirzīti tālāk par 1. līmeni. Formula: eskalēto pieteikumu skaits dalīts ar kopējo pieteikumu skaitu, reizināts ar 100. Eskalāciju pieaugums pie nemainīga pieteikumu apjoma var liecināt par zināšanu trūkumu, maršrutēšanas problēmu vai pieteikumu sarežģītības izmaiņām.

Lietotāja noslodze. Aktīvais darba laiks dalīts ar plānoto pieejamo laiku. Formula: pieteikumiem veltītais laiks dalīts ar plānoto stundu skaitu, reizināts ar 100. Ilgstoši pārslogots darbs var palielināt izdegšanas risku, tāpēc vērtējiet šo skaitli kopā ar darba slodzi un prombūtni.

Viena pieteikuma izmaksas. Kopējās atbalsta izmaksas (algas, rīki, pieskaitāmās izmaksas), dalītas ar perioda pieteikumu apjomu. Tas vadītājiem un finanšu komandai nodrošina kopīgu veidu, kā apspriest atbalsta izmaksas.

Kvalitātes nodrošināšanas jeb QA rādītāji. Pieteikumu sarakstes manuāls vai ar AI palīdzību veikts novērtējums pēc kritērijiem, kas aptver toni, precizitāti un atbilstību politikai. QA var sniegt kontekstu, ko apmierinātības aptaujas neparāda, īpaši tad, ja aptauju atbilžu skaits ir mazs.

Rādītājs Formula Galvenā auditorija
Pieteikumu apjoms Jauno pieteikumu skaits periodā Vadītājs, vadība
Pirmās atbildes laiks Summa(pirmās atbildes laiks − izveides laiks) / pieteikumi Lietotājs, vadītājs
MTTR Mediāna(atrisināšanas laiks − izveides laiks) Vadītājs, vadība
FCR Pirmajā kontaktā atrisinātie pieteikumi / kopējie pieteikumi × 100 Vadītājs
CSAT Apmierinātās atbildes / kopējās atbildes × 100 Vadītājs, vadība
SLA atbilstība SLA ietvaros atrisinātie pieteikumi / kopējie pieteikumi × 100 Vadītājs, vadība
Neizskatīto pieteikumu vecums Atvērtie pieteikumi, sagrupēti pēc vecuma Vadītājs, Lietotājs
Atkārtotas atvēršanas rādītājs Atkārtoti atvērtie pieteikumi / atrisinātie pieteikumi × 100 Vadītājs
Eskalācijas rādītājs Eskalētie pieteikumi / kopējie pieteikumi × 100 Vadītājs
Lietotāja noslodze Aktīvais darba laiks / plānotais laiks × 100 Vadītājs
Viena pieteikuma izmaksas Kopējās atbalsta izmaksas / pieteikumu apjoms Vadība
QA rādītājs Svērtais kritēriju vērtējums par pieteikumu Vadītājs, Lietotājs

Pilnu skaidrojumu par to, kā šīs definīcijas piemērot dažāda lieluma komandām, skatiet būtiskākajos palīdzības dienesta pārskatu rādītājos atbalsta vadītājiem.

Kā informācijas paneļiem jāatšķiras vadībai, vadītājiem un Lietotājiem?

Vadībai nepieciešamas tendences un izmaksas. Vadītājiem nepieciešama informācija par darba slodzi un riskiem. Lietotājiem nepieciešams koncentrēts skats uz viņu pašu rindu. Viens informācijas panelis reti labi apkalpo visas trīs auditorijas, tāpēc sāciet ar lēmumiem, kas jāpieņem katrai grupai.

Vadības logrīki: CSAT tendence 12 mēnešu periodā, kopējā SLA atbilstība ar salīdzinājumu pa mēnešiem, viena pieteikuma izmaksas, pieteikumu apjoms salīdzinājumā ar darbinieku skaitu un īss svarīgāko risku saraksts, kas iegūts no eskalācijām.

Vadītāja logrīki: pašreizējais atvērto pieteikumu skaits pēc prioritātes un rindas, SLA atbilstība pēc kategorijas, Lietotāju darba slodzes sadalījums, FCR tendence, eskalācijas rādītājs, neizskatīto pieteikumu vecuma sadalījums un slīdošie QA vidējie rādītāji.

Lietotāja logrīki: personīgie atvērtie pieteikumi, piešķirtās rindas dziļums, tuvojošies SLA termiņi un atbilstošas zināšanu saites.

Profesionāļu padoms: Uzturiet katru informācijas paneli koncentrētu. Tā vietā, lai pievienotu arvien vairāk elementu, izmantojiet detalizācijas saites un noņemiet logrīkus, kas neveicina regulāru lēmumu pieņemšanu.

Atjaunošanas biežums ir tikpat svarīgs kā logrīku izvēle. Rindas dziļumam, SLA termiņiem un Lietotāju piešķīrumiem nepieciešami aktuāli dati, jo tie nosaka tās pašas dienas lēmumus. CSAT tendences, viena pieteikuma izmaksas un QA vidējie rādītāji var tikt atjaunināti katru dienu vai nedēļu, jo tie palīdz pieņemt lēmumus, kuru sekas izpaužas ilgākā periodā. Aktuāli operatīvie dati palīdz vadītājiem pamanīt pārslogotas rindas un pārdalīt darbu, pirms tiek nokavēti termiņi.

Kā informācijas paneļiem jāatšķiras vadībai, vadītājiem un Lietotājiem? Pārskata diagramma

Reāllaika un vēsturiskie pārskati: kuri jums ir nepieciešami?

Reāllaika pārskati palīdz pieņemt operatīvus lēmumus konkrētajā brīdī; vēsturiskie pārskati palīdz pieņemt stratēģiskus lēmumus nedēļu vai ceturkšņu griezumā. Sajaucot abus, komandas nonāk situācijā, kur tiešraides informācijas panelis tiek pētīts sarunā par darbinieku pieņemšanu vai ceturkšņa pārskats tiek izmantots, lai izlemtu, kurš nodrošinās pēcpusdienas maiņu.

Mērķis Atjaunošanas biežums Laika horizonts Galvenie rādītāji Auditorija
Operatīvs (maršrutēšana, personāla plānošana) No reāllaika līdz reizi stundā Tā pati diena Rindas dziļums, SLA termiņi, Lietotāja statuss Vadītājs, Lietotājs
Stratēģisks (darbinieku pieņemšana, procesi) No dienas līdz mēnesim Nedēļas līdz ceturkšņi MTTR tendence, CSAT tendence, viena pieteikuma izmaksas Vadītājs, vadība

Operatīvajiem informācijas paneļiem jāpalīdz pieņemt lēmumus par maršrutēšanu un personāla plānošanu, savukārt vēsturiskie pārskati ir piemērotākais līdzeklis lēmumiem par darbinieku pieņemšanu, ieguldījumiem apmācībās un procesu izmaiņām. To sajaukšana rada tikai trokšņainu, reaģējošu vadību.

Datu jomā lielāko daļu pārskatu veidošanas problēmu novērš trīs paradumi: pirms pārskatu veidošanas apvienojiet visus pieteikumu avotus vienā sistēmā; pārbaudiet, vai statusu laika zīmogi atspoguļo realitāti; un automatizējiet atkārtojamus eksportus, ja ar iebūvēto pārskatu nepietiek. Pieteikums, kas atzīmēts kā “atrisināts” vairākas dienas pēc klienta problēmas novēršanas, izkropļos MTTR neatkarīgi no pārskatu rīka.

Izvēloties rīku, noteicošais faktors parasti ir vieta, kur jūsu dati jau atrodas. Power BI bieži ir piemērots vidēm, kurās dominē Microsoft, savukārt Tableau parasti izmanto vairāku avotu apvienošanai. Lai kuru rīku izvēlētos, pārliecinieties, ka eksports vai API ietver pieteikuma ID, attiecīgo statusa izmaiņu laika zīmogus, prioritāti, kategoriju, piešķirto personu un kanālu. Pārbaudiet precīzos laukus atbilstoši aprēķiniem, ko izmantos jūsu informācijas panelis.

Kā noteikt reālistiskus SLA un CSAT mērķus?

Nosakiet mērķus, vispirms izmērot sākuma līmeni, salīdzinot to ar līdzīgu komandu etalonu un pēc tam sadalot uzlabojumus noteiktā laika grafikā, nevis uzreiz tiecoties pēc patvaļīga “labākā nozarē” skaitļa.

  1. Izmēriet pašreizējo sākuma līmeni katram rādītājam vismaz četru līdz sešu nedēļu periodā — pietiekami ilgi, lai izlīdzinātu vienas sliktas nedēļas ietekmi.
  2. Izvēlieties etalona diapazonu no nozares avotiem vai salīdzināmām komandām, pielāgojot to savam atbalsta modelim (B2B SaaS palīdzības dienestam un liela apjoma e-komercijas komandai nevajadzētu noteikt vienādu MTTR mērķi).
  3. Nosakiet pakāpenisku mērķi ar laika grafiku, piemēram, palielināt SLA atbilstību no 82% līdz 90% divu ceturkšņu laikā, nevis pieprasīt 95% jau nākamajā mēnesī.
  4. Saistiet mērķus ar kapacitātes plānošanu, lai uzlabošanas mērķiem būtu pievienoti nepieciešamie ieguldījumi personālā vai automatizācijā, nevis tikai rīkojums tos sasniegt.

Dokumentējiet katra KPI definīciju, datu avotu, sākuma līmeni, mērķi un pārskatīšanas datumu. Etalonu pārskati var nodrošināt kontekstu, taču jūsu mērķim jāatspoguļo kanāls, nopietnība, klientam dotais solījums, darba laiks un pieejamā kapacitāte.

No kādām pārskatu veidošanas kļūdām vadītājiem jāizvairās?

Visbiežākās kļūdas ir tiekšanās pēc tukšiem rādītājiem, vidējo vērtību ziņošana procentiļu vietā, ātruma apbalvošana, nepārbaudot kvalitāti, un informācijas paneļu darbība komandās izolēti.

  • Vidējā laika, nevis procentiļu izsekošana slēpj sliktākos gadījumus. Ziņojiet mediāno un 90. procentiles MTTR līdzās.
  • Ātruma apbalvošana vienatnē (ātra aizvēršana, augsts FCR), nesekojot atkārtotas atvēršanas rādītājam, var mudināt Lietotājus aizvērt pieteikumus, pirms problēma patiešām ir novērsta.
  • Atkārtotas atvēršanas rādītāja ignorēšana rada kvalitātes trūkumu; pievienojiet to, ja jūsu pieteikumu rīks to pēc noklusējuma neuzrāda.
  • Vienāda attieksme pret visiem kanāliem slēpj faktu, ka tērzēšanai un e-pastam ir ļoti atšķirīgas FRT gaidas.
  • Slikta datu higiēna (dublēti pieteikumi, nepareizi marķēta prioritāte) nemanāmi sabojā visus turpmākos rādītājus; reizi ceturksnī pārbaudiet pieteikumu marķēšanu.

Kas jāiekļauj iknedēļas un kas — ikmēneša pārskatā?

Iknedēļas pārskati aptver operatīvo stāvokli; ikmēneša pārskati aptver tendences un ietekmi uz uzņēmējdarbību.

  1. Nedēļas pieteikumu apjoms un sadalījums pa kanāliem
  2. FRT, MTTR, CSAT un FCR salīdzinājumā ar mērķi
  3. SLA atbilstība sadalījumā pa kategorijām
  4. Piecas lielākās pieteikumu kategorijas pēc apjoma
  5. Lietotāju darba slodzes sadalījums un visi kapacitātes brīdinājumi
  6. Viena rindkopa, kurā apkopots nedēļas galvenais stāsts

Ikmēneša vadības pārskatā iekļaujiet CSAT, SLA atbilstības un viena pieteikuma izmaksu izmaiņas salīdzinājumā ar iepriekšējo mēnesi un gadu, personāla līmeni salīdzinājumā ar pieprasījumu, īsu piezīmi par uzsāktajām iniciatīvām un to izmērīto ietekmi, kā arī nākotnes riskus, piemēram, sezonālus apjoma pieaugumus.

Noderīgs stāstījuma teikums varētu būt šāds: “Šonedēļ apjoms pēc norēķinu kļūdas pieauga par 14%, SLA atbilstība steidzamajiem pieteikumiem samazinājās līdz 84%, un mēs iesakām piesaistīt pagaidu papildu personālu, līdz labojums tiks ieviests.” Skaitļi ir ilustratīvi, taču struktūra lasītājam parāda izmaiņas, cēloni, sekas un rīcību. Gatavus izkārtojumus skatiet Deskhero klientu atbalsta informācijas paneļu veidnēs.

Kā šos rādītājus faktiski aprēķināt no neapstrādātiem datiem?

Precīzs aprēķins vairāk nekā no jebkuras formulas ir atkarīgs no viena faktora: konsekventiem statusu laika zīmogiem un skaidras, saskaņotas definīcijas jēdzieniem “atrisināts” un “aizvērts”. Ja puse komandas pieteikumu atzīmē kā atrisinātus, kad tiek ieviests labojums, bet otra puse — kad klients to apstiprina, jūsu MTTR salīdzina divas atšķirīgas lietas.

  1. FRT = first_response_at − created_at, aprēķināts kā perioda vidējā vai mediānā vērtība
  2. MTTR = resolved_at − created_at, aprēķināts kā mediāna un sadalīts pēc prioritātes
  3. FCR = (pieteikumi bez atkārtotas piešķiršanas un atkārtotas atvēršanas) / kopējie pieteikumi
  4. Atkārtotas atvēršanas rādītājs = 48 stundu laikā atkārtoti atvērtie pieteikumi / atrisinātie pieteikumi
  5. Lietotāja noslodze = time_spent / scheduled_hours
  6. SLA atbilstība = SLA prasībām atbilstošie pieteikumi / kopējie pieteikumi

Nepieciešamie neapstrādāto datu lauki: ticket ID, created_at, first_response_at, resolved_at, closed_at, statusa izmaiņu žurnāls, prioritāte, rinda, piešķirtā persona, time_spent un izmaksu centrs.

Vienkāršs vaicājums FRT un MTTR aprēķināšanai datumu diapazonā izskatās šādi:

SELECT AVG(first_response_at - created_at) AS avg_frt,
       PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY resolved_at - created_at) AS median_mttr
FROM tickets
WHERE created_at BETWEEN :start_date AND :end_date;

Uztveriet to kā sākotnējo struktūru un pielāgojiet sintaksi un laika zīmogu noteikumus savai datubāzei. Pirms paļaujaties uz rezultātu informācijas panelī, pārbaudiet to pret nelielu zināmu pieteikumu kopu.

Kā IT atbalsta rādītāji atšķiras no klientu apkalpošanas rādītājiem?

IT atbalsts un klientiem paredzētais atbalsts panākumus mēra atšķirīgi, lai gan abi darbojas ar pieteikumu rindām. IT atbalsta rādītāji vairāk koncentrējas uz MTTR, eskalācijas rādītāju un SLA atbilstību, kas saistīta ar incidenta nopietnību, jo dīkstāves izmaksas ievērojami pārsniedz nedaudz lēnākas atbildes izmaksas. P1 darbības pārtraukuma pieteikumam nepieciešams citāds SLA taimeris un eskalācijas ceļš nekā paroles atiestatīšanas pieprasījumam, un to apvienošana vienā MTTR skaitlī slēpj abus aspektus.

Klientu apkalpošana un e-komercijas atbalsts savukārt var piešķirt lielāku nozīmi CSAT, FCR un kanālu apjomam, jo uzņēmējdarbības ietekme izpaužas klientu noturēšanā un atkārtotos pirkumos, nevis sistēmas darbspējas laikā. Shopify tirgotājam, kas apstrādā jautājumus par pasūtījumu statusu, klientu kanālos var būt svarīgāks FRT nekā MTTR retai tehniskai eskalācijai. Deskhero Shopify integrācija attiecīgajiem pieteikumiem pievieno aktuālu informāciju par klientu, pasūtījumu, izpildi un izsekošanu, savukārt produktu katalogs var sniegt informāciju AI atbilžu melnrakstiem.

Risinājums nav izvēlēties vienu rādītāju kopumu otra vietā. Tas ir sadalīt informācijas paneli pēc atbalsta modeļa, ja jūsu komanda apkalpo abus, lai iekšējai IT rindai un klientu rindai būtu atsevišķi SLA līmeņi, atsevišķi eskalācijas noteikumi un atsevišķi etalona mērķi, nevis viens apvienots skaitlis, kas nevienam īsti neatbilst.

Vai tendenču analīze un prognozēšana var uzlabot palīdzības dienesta plānošanu?

Tendenču analīze pārvērš momentuzņēmuma rādītāju par plānošanas rīku, bet prognozēšana ļauj sagatavot personālu pirms pieprasījuma, nevis tikai uz to reaģēt. Nemainīgs CSAT skaitlis parāda, kur atrodaties šodien; 12 mēnešu CSAT tendences līkne parāda, vai iepriekšējā ceturkšņa procesa izmaiņas patiešām darbojās.

Praktiskākais pielietojums ir apjoma prognozēšana. Ja pieteikumu apjoms katru novembri regulāri pieaug produkta ieviešanas cikla dēļ, šī sezonālā modeļa salīdzināšana ar darbinieku skaitu ļauj savlaicīgi pieprasīt pagaidu personālu. Tāda pati loģika attiecas uz eskalācijas rādītāju: ilgstošs pieaugums var rosināt izmeklēšanu, pirms pasliktinās SLA atbilstība.

Atbalsta analītika var pildīt divus atšķirīgus uzdevumus: ikdienā uzturēt rindu veselīgā stāvoklī un analizēt pieteikumu saturu, lai atrastu atkārtotas tēmas, kas palīdz produktu un klientu pieredzes komandām. Sekojiet gan operatīvajam sniegumam, gan atkārtotajām tēmām, lai pārskatu programma atbalstītu vairāk nekā tikai rindu pārvaldību.

Kāpēc šis rādītāju kopums ir piemērots mūsdienīgiem palīdzības dienestiem?

Kļūda, ko redzu visbiežāk, nav sliktu rādītāju izvēle. Tā ir labu rādītāju izvēle izolēti. Komanda, kas ziņo par FCR bez atkārtotas atvēršanas rādītāja, uz papīra izskatās lieliski — līdz brīdim, kad klienti sāk iesniegt to pašu sūdzību divreiz. Efektivitātes skaitļu apvienošana ar kvalitātes pārbaudi patiešām pasargā palīdzības dienestu no tā, ka optimizācijas rezultātā pakalpojums kļūst sliktāks.

Šī grupēšana — efektivitāte, kvalitāte, darba slodze un izmaksas kopā — darbojas, jo atspoguļo to, kā patiesībā tiek pieņemti lēmumi par personālu un produktiem. Jūs nepieņemat darbiniekus, balstoties tikai uz CSAT, un nenovirzāt pieteikumus, balstoties tikai uz viena pieteikuma izmaksām. Jums nepieciešams pilns kopums, kas katru nedēļu jālasa kopā.

Ieviesiet šīs pārskatu veidošanas prakses savā palīdzības dienestā

Pārskatu manuāla veidošana no atsevišķiem e-pasta un veidlapu eksportiem rada novēršamu darbu. Deskhero pārvērš Gmail vai Microsoft 365 pastkasti par palīdzības dienestu un vienā sistēmā glabā e-pasta, iegultās veidlapas un AI tērzēšanas robota pieteikumus. Tā Dashboard rāda pieteikumu apjomu, vidējo pirmās atbildes laiku, vidējo atrisināšanas laiku un katram statusam veltīto laiku. Fiksētā Statistics sadaļa pievieno tendenču, atbildes laika procentiļu, SLA, komandas, kanālu, AI un tēmu skatus ar filtriem un Excel eksportu katrai cilnei.

Deskhero

Pieteikumi, kas izveidoti pa e-pastu, iegultā tīmekļa vietnes veidlapā vai iebūvētajā AI tērzēšanas robotā, nonāk vienā koplietotā iesūtnē. AI atbilžu melnraksti var izmantot darbvietas plašāko zināšanu kopumu, savukārt klientiem paredzētās tērzēšanas robota atbildes un AI automātiskās atbildes izmanto tikai apstiprināto publisko BUJ. Daudzvalodu atbalsts palīdz Lietotājiem tulkot pieteikumus un atbildes. Tēmu klasteris izceļ atkārtotas tēmas, savukārt Statistics eksports un REST API nodrošina iespējas turpmākai analīzei. Deskhero neietver pielāgotu pārskatu veidotāju, tāpēc komandām, kurām nepieciešams īpašs informācijas panelis, eksportētie vai API pieejamie dati jāizmanto BI rīkā.

Ja pārveidojat savu pārskatu veidošanas darbplūsmu, varat sākt 30 dienu bezmaksas izmēģinājumu, kuram nav nepieciešama kredītkarte, un izpētīt Dashboard un Statistics skatus Deskhero.

Ieviesiet šīs pārskatu veidošanas prakses savā palīdzības dienestā. Pārskata diagramma

Avoti

Šie avoti pamato iepriekš aplūkotos etalonus, informācijas paneļu izveides principus un rīku ieteikumus, turklāt katrs no tiem padziļināti aplūko kādu konkrētu kopainas daļu.

BUJ

Kādi ir galvenie rādītāji servisa dienesta pārskatiem?

Pamatkopumā ietilpst pieteikumu apjoms, pirmās atbildes laiks, MTTR, FCR, CSAT, SLA atbilstība, neizskatīto pieteikumu vecums, atkārtotas atvēršanas rādītājs, eskalācijas rādītājs, Lietotāja noslodze un viena pieteikuma izmaksas — tie jāizseko kopā, nevis pa vienam.

Kādi ir pieci galvenie CX rādītāji?

Lielākā daļa komandu CX pārskatus balsta uz CSAT, FCR, pirmās atbildes laiku, atkārtotas atvēršanas rādītāju un SLA atbilstību, jo šie pieci rādītāji apvieno ātrumu, kvalitāti un uzticamību vienā viegli uztveramā kopainā.

Kādi ir KPI piemēri IT palīdzības dienestam?

IT palīdzības dienesta KPI parasti ietver MTTR pēc nopietnības līmeņa, SLA atbilstību P1 incidentiem, eskalācijas rādītāju un neizskatīto pieteikumu vecumu, jo IT atbalsts incidenta nopietnībai piešķir lielāku nozīmi nekā vispārēja klientu apkalpošana.

Kādi ir labi KPI IT nodaļai?

Papildus pieteikumu līmeņa rādītājiem IT nodaļas bieži seko viena pieteikuma izmaksām, Lietotāja noslodzei un atrisināšanai pirmajā kontaktā, lai līdzsvarotu pakalpojuma kvalitāti ar personāla izmaksām un kapacitāti.

Cik bieži jāveido palīdzības dienesta pārskati?

Operatīvajiem logrīkiem, piemēram, rindas dziļumam un SLA termiņiem, nepieciešami aktuāli dati, savukārt tendenču rādītājiem, piemēram, CSAT un viena pieteikuma izmaksām, bieži pietiek ar iknedēļas vai ikmēneša atjaunošanu.

Vai tāda palīdzības dienesta platforma kā Deskhero var automātiski nodrošināt šādus pārskatus?

Deskhero vienā sistēmā apkopo pieteikumus no e-pasta, tīmekļa veidlapām un sava AI tērzēšanas robota. Tās fiksētās Statistics cilnes aptver tendences, atbildes laikus, SLA, Lietotājus, kanālus, AI un tēmas, kā arī nodrošina filtrus un Excel eksportu katrai cilnei. Komandām, kurām nepieciešama turpmāka analīze, pieejams arī REST API.