Deskhero
Latviešu
Sākt bez maksas

← Back to articles

Kuri palīdzības dienesta pārskatu rādītāji patiešām ir svarīgi

Kuri palīdzības dienesta pārskatu rādītāji patiešām ir svarīgi

Ja šonedēļ izveidojat tikai vienu lietu, izveidojiet vienas lapas iknedēļas vadītāja informācijas paneli, kas katru pirmdienas rītu parāda jūsu komandai visus astoņus rādītājus. Viss pārējais, tostarp aģentu stundas logrīki un ceturkšņa vadības prezentācijas, var pagaidīt, līdz šis vienīgais pārskats darbojas uzticami.

Lūk, ko katrs rādītājs patiesībā jums pasaka:

  • Pirmās atbildes laiks atbild uz jautājumu: cik ilgi klienti gaida atbildi no cilvēka?
  • MTTR atbild uz jautājumu: cik ilgs laiks patiesībā nepieciešams problēmas atrisināšanai no sākuma līdz beigām?
  • Problēmas atrisināšana pirmajā kontaktā atbild uz jautājumu: vai aģenti atrisina jautājumus ar pirmo mēģinājumu, vai arī pārsūta pieteikumus no viena cilvēka citam?
  • CSAT atbild uz jautājumu: vai klienti ir apmierināti ar to, kā tika atrisināta viņu problēma?
  • SLA ievērošana atbild uz jautājumu: vai jūs izpildāt savus solījumus par atbildes un atrisināšanas laiku?
  • Pieteikumu apjoms un neizskatīto pieteikumu uzkrājums atbild uz jautājumu: vai ienākošais pieprasījums pārsniedz jūsu komandas kapacitāti?
  • Atkārtotas atvēršanas rādītājs atbild uz jautājumu: vai “atrisinātie” pieteikumi tiešām paliek atrisināti?
  • Izmaksas par pieteikumu atbild uz jautājumu: cik uzņēmumam maksā katra atbalsta mijiedarbība?

Neviens no šiem skaitļiem atsevišķi neko daudz nenozīmē. Ātrs FRT kopā ar zemu FCR vienkārši nozīmē, ka jūs atbildat ātri, bet nepareizi. Īstā prasme palīdzības dienesta pārskatu rādītāju izmantošanā ir izvēlēties pareizās kombinācijas, pareizi segmentēt datus un novirzīt pareizo skatījumu pareizajai personai.

Galvenie secinājumi

Uzticami palīdzības dienesta pārskati nozīmē konsekventi sekot astoņiem galvenajiem rādītājiem, tos pareizi segmentēt un noteiktā ritmā nosūtīt pareizo skatījumu pareizajai auditorijai.

Punkts Informācija
Sāciet ar astoņiem rādītājiem Sekojiet FRT, MTTR, FCR, CSAT, SLA ievērošanai, neizskatīto pieteikumu attiecībai, atkārtotas atvēršanas rādītājam un izmaksām par pieteikumu.
Vispirms izveidojiet iknedēļas informācijas paneli Vienas lapas vadītāja pārskats ir labāks par plašu sistēmu ar daudzām cilnēm, ko neviens nepārbauda.
Pielāgojiet informācijas paneļus auditorijai Vadībai nepieciešamas tendences, vadītājiem — ikdienas operatīvie skati, bet aģentiem — viņu personīgās rindas reāllaikā.
Apvienojiet rādītājus, lai pamanītu manipulācijas Skatiet FCR kopā ar atkārtotas atvēršanas rādītāju un FRT kopā ar CSAT, lai iegūtu pilnu ainu.
Deskhero automatizē pārskatu veidošanas slāni Tā divvirzienu e-pasta sinhronizācija un iebūvētā pieteikumu analītika ģenerē šos galvenos rādītājus bez manuāla darba izklājlapās.

Saturs

Palīdzības dienesta pārskatu rādītāji un KPI: kāda ir atšķirība?

Rādītājs ir jebkurš skaitlis, ko varat izmērīt. KPI ir rādītājs, kuram jūsu organizācija ir piešķīrusi pietiekamu nozīmi, lai noteiktu mērķi un regulāri rīkotos. Pieteikumu apjoms ir rādītājs. “Uzturēt vidējo pieteikumu skaitu zem 40 pieteikumiem uz aģentu dienā” ir KPI. Savukārt etalons ir ārējs atskaites punkts, piemēram, nozares vidējais rādītājs, kas vispirms palīdz saprast, vai jūsu KPI mērķis vispār ir reālistisks.

Šī atšķirība ir svarīga, jo lielākā daļa atbalsta komandu noslīkst rādītājos, nekad nenosakot, kuri no tiem ir KPI. Softabase ieteikumi par būtiskajiem palīdzības dienesta etaloniem iesaka ierobežot galveno izsekojamo rādītāju kopumu līdz desmit vai mazāk, jo informācijas paneļi ar vairāk nekā 30 datu punktiem rada troksni, nevis signālu. Vadītāji pārstāj tos aplūkot, un pārskatu veidošana kļūst par formalitāti.

Grupējiet rādītājus pēc jautājuma, uz kuru tie atbild, un pārskatu izveide kļūs daudz vienkāršāka:

Ātruma rādītāji (FRT, MTTR) parāda, cik ātri komanda strādā. Kvalitātes rādītāji (CSAT, FCR, atkārtotas atvēršanas rādītājs) parāda, vai šis ātrums sniedz labus rezultātus. Atbilstības rādītāji (SLA izpilde) parāda, vai jūs pildāt līgumā vai iekšēji noteiktos solījumus. Efektivitātes rādītāji (izmaksas par pieteikumu, aģentu noslodze) parāda, cik maksā operācijas uzturēšana. Apjoma rādītāji (pieteikumu skaits, neizskatīto pieteikumu uzkrājums) parāda pieprasījumu.

Diagramma, kurā palīdzības dienesta rādītāji iedalīti pēc veida

Vadību parasti interesē efektivitātes un kvalitātes tendences vairāku mēnešu griezumā. Vadītāji ik dienu vai ik nedēļu seko atbilstībai un apjomam. Aģentiem reāllaikā nepieciešami viņu rindai atbilstoši ātruma un kvalitātes rādītāji. Šo auditoriju apvienošana vienā informācijas panelī ir visbiežākā kļūda palīdzības dienesta analītikas izveidē, un tieši tāpēc tik daudzi pārskatu rīki dažu nedēļu laikā pēc ieviešanas tiek ignorēti.

Galvenie palīdzības dienesta rādītāji: definīcijas, formulas un etaloni

Šeit ir uzziņu lapa. Aprēķiniet katru rādītāju šādā veidā, segmentējiet to atbilstoši šīm līnijām un izmantojiet šos diapazonus kā sākumpunktu, nevis kā rezultātu tabulu, kas akli jāizpilda.

Pirmās atbildes laiks (FRT) mēra pagājušo laiku no pieteikuma izveides līdz pirmajai saturiskajai cilvēka atbildei. Formula: pirmās atbildes laika zīmoga un pieteikuma izveides laika zīmoga starpību summa, dalīta ar pieteikumu skaitu. Automātiskās saņemšanas apstiprinājuma ziņas neiekļaujiet — tā nav atbilde, bet gan saņemšanas apliecinājums. Segmentējiet pēc kanāla un prioritātes, jo 4 stundu FRT e-pastā ir pavisam kas cits nekā 4 stundu FRT tiešajā tērzēšanā. Softabase 2026. gada etalonu ieteikumi nosaka reālistiskus FRT mērķus aptuveni 4 stundas e-pastam, 60 sekundes tērzēšanai un 30 sekundes tālrunim. HelpDeskFocus pētījums arī norāda, ka FRT ir spēcīgākais atsevišķais kopējās apmierinātības prognozētājs, tāpēc to vērts izsekot pa kanāliem, nevis apvienot vienā uzņēmuma vidējā rādītājā.

Vidējais atrisināšanas laiks (MTTR) mēra visu dzīves ciklu no pieteikuma izveides līdz tā slēgšanai. Ja atrisināšanas laiki ir asimetriski, izmantojiet mediānu, nevis vidējo vērtību — tas notiek gandrīz vienmēr, jo daži sarežģīti pieteikumi var vidējo rādītāju palielināt par vairākām stundām. Segmentējiet pēc prioritātes līmeņa. Softabase etaloni standarta pieteikumiem iesaka vienu līdz divām dienām, augstas prioritātes pieteikumiem — dažas stundas, bet kritiskiem incidentiem — ļoti īsu laiku, tomēr īsto mērķi jānosaka, balstoties uz jūsu vēsturiskajiem datiem.

Problēmas atrisināšana pirmajā kontaktā (FCR) mēra to pieteikumu daļu, kas slēgti bez atkārtotas sazināšanās, un tiek aprēķināta, dalot pirmajā kontaktā atrisināto pieteikumu skaitu ar kopējo pieteikumu skaitu. Segmentējiet pēc kategorijas un aģenta darba stāža; jaunie darbinieki sākumā gandrīz vienmēr šo rādītāju pazemina. Nozares etalonu ieteikumi par saprātīgu mērķa diapazonu uzskata 72–78%.

Klientu apmierinātība (CSAT) mēra pozitīvo aptaujas atbilžu procentuālo daļu no kopējā saņemto atbilžu skaita. Segmentējiet pēc aģenta un problēmas kategorijas. Atbilžu līmenis ir tikpat svarīgs kā pats rezultāts: Softabase iesaka sasniegt vismaz 20% atbilžu līmeni, lai izvairītos no izkropļota parauga, jo zemas atsaucības aptaujas parasti aizpilda tikai ļoti apmierināti vai ļoti neapmierināti klienti. Tipiskie CSAT etaloni parasti atrodas augstā līmenī, lai gan tas būtiski atšķiras starp nozarēm.

SLA ievērošana mēra to pieteikumu procentuālo daļu, kas atbilst jūsu noteiktajām atbildes un atrisināšanas laika saistībām. Segmentējiet pēc SLA līmeņa un klienta līguma veida; uzņēmumu un bezmaksas līmeņa SLA apvienošana vienā skaitlī noslēpj būtisko.

Pieteikumu apjoms un neizskatīto pieteikumu uzkrājums mēra ienākošo pieprasījumu un neatrisināto darbu rindu. Uzkrājumu uzskaitiet gan kā absolūtu skaitu, gan kā attiecību (atvērtie pieteikumi dalīti ar vidējo dienas atrisināšanas kapacitāti), lai redzētu, vai rinda aug ātrāk, nekā komanda spēj to iztukšot.

Atkārtotas atvēršanas rādītājs mēra to atrisināto pieteikumu procentuālo daļu, kas tiek atkārtoti atvērti noteiktā periodā, parasti 48–72 stundu laikā. Segmentējiet pēc aģenta un kategorijas. Šis ir rādītājs, kas palīdz saglabāt FCR godīgu.

Izmaksas par pieteikumu mēra kopējās atbalsta darbības izmaksas, dalītas ar pieteikumu skaitu noteiktā periodā. Segmentējiet pēc kanāla, jo tālruņa atbalsts parasti izmaksā daudz vairāk par pieteikumu nekā e-pasts vai tērzēšana.

Rādītājs Formula Segmentēt pēc Etalona sākumpunkts
Pirmās atbildes laiks Laiks līdz pirmajai cilvēka atbildei Kanāls, prioritāte E-pasts 4 h, tērzēšana 60 s, tālrunis 30 s
MTTR (mediāna) Laiks no atvēršanas līdz slēgšanai Prioritātes līmenis Standarta 24 h, augsta 4 h, kritiska 1 h
Problēmas atrisināšana pirmajā kontaktā Pirmajā kontaktā slēgtie pieteikumi ÷ kopējais pieteikumu skaits Kategorija, aģenta stāžs 72–78%
CSAT Pozitīvās atbildes ÷ kopējais atbilžu skaits Aģents, kategorija 80%, ar vismaz 20% atbilžu līmeni
SLA ievērošana Atbilstošie pieteikumi ÷ kopējais pieteikumu skaits SLA līmenis, līguma veids Nosakāms katram līgumam
Atkārtotas atvēršanas rādītājs Atkārtoti atvērtie pieteikumi ÷ atrisinātie pieteikumi Aģents, kategorija Jāskata kopā ar FCR

Divi rādītāji ir jēgpilni tikai kopā: problēmas atrisināšana pirmajā kontaktā un atkārtotas atvēršanas rādītājs 48 stundu laikā. Augsts FCR kopā ar pieaugošu atkārtotas atvēršanas rādītāju nozīmē, ka aģenti slēdz pieteikumus mērķa sasniegšanai, nevis tāpēc, ka problēma patiešām ir novērsta.

Kā mērīt pareizi un izvairīties no biežākajām kļūdām

Rādītāja aprēķināšanas precizitāte ir svarīgāka par izvēlēto rādītāju. Izmantojiet mediānu, nevis vidējo vērtību jebkuram laika rādītājam ar garu asti, kas praksē nozīmē gandrīz katru jūsu publicēto atrisināšanas laika rādītāju. Viens pieteikums, kura slēgšana aizņem trīs nedēļas, jo tas gaida piegādātāja atbildi, palielinās vidējo atrisināšanas laiku tā, ka tiks nepareizi attēlots visas komandas sniegums.

Par FRT uzskatiet pirmo cilvēka atbildi, nevis automātisko apstiprinājumu “mēs saņēmām jūsu ziņu”. Ja sistēma automātisko atbildi reģistrē kā pirmo saskari, FRT rādītāji izskatīsies mākslīgi ātri un noslēps reālu personāla trūkuma problēmu. Skaidri definējiet atkārtotas atvēršanas periodu — 24, 48 vai 72 stundas — un konsekventi piemērojiet to visās kategorijās, lai salīdzinātu vienādu ar vienādu. Pielāgojiet pārskatu laika uzskaiti faktiskajam atbalsta darba laikam; piektdien plkst. 23.00 iesniegtam un pirmdien plkst. 9.00 atbildētam pieteikumam nevajadzētu skaitīties tāpat kā trīs dienu kavējumam darba laikā, ja jūsu komanda nestrādā nedēļas nogalēs.

Visbiežākā kļūda ir vidējā rādītāja aprēķināšana starp kanāliem, kas darbojas pilnīgi atšķirīgi. E-pasta FRT un tērzēšanas FRT apvienošana vienā uzņēmuma rādītājā rada skaitli, kas precīzi neapraksta nevienu kanālu. Otra biežākā kļūda ir ziņošana par FCR, nesalīdzinot to ar atkārtotas atvēršanas rādītāju, tādējādi ļaujot aģentiem manipulēt ar skaitli, priekšlaicīgi slēdzot pieteikumus. Trešā ir paļaušanās uz CSAT rezultātu, kas balstīts uz mazu atbilžu skaitu; saskaņā ar Softabase aptauju metodoloģijas ieteikumiem rezultāts no astoņām atbildēm uz 200 pieteikumiem statistiski gandrīz neko derīgu nepasaka.

Profesionāļa padoms: Katru reizi, kad veidojat pārskatu, veiciet ātru loģikas pārbaudi: izvēlieties piecus nejaušus pieteikumus, kas slēgti “SLA ietvaros”, un manuāli pārbaudiet laika zīmogus. Ja kaut viens ir nepareizs, jūsu datu plūsmā ir kļūda, kas jānovērš, pirms prezentējat skaitļus vadībai.

Skatiet FRT blakus CSAT, bet neizskatīto pieteikumu attiecību — blakus SLA pārkāpumu skaitam. Šādas kombinācijas atklāj problēmas, ko viens skaitlis noslēpj. Komanda var uz papīra sasniegt visus SLA mērķus, kamēr uzkrājums klusi trīskāršojas, jo SLA ievērošana mēra apstrādātos pieteikumus, nevis tos, kas uzkrājas aiz tiem.

Veidojiet informācijas paneļus pēc auditorijas: vadības, vadītāju un aģentu skati

Tikai aptuveni 29% atbalsta organizāciju veido dažādiem auditorijas līmeņiem pielāgotus informācijas paneļus, un tas ir redzams. Informācijas panelis, kas izveidots aģenta ikminūtes darba slodzei, ir nederīgs vadītājam, kurš vēlas novērtēt ceturkšņa tendences, savukārt stratēģiskais vadības skats ir pārāk lēns, lai palīdzētu aģentam tūlīt pārvaldīt savu rindu.

Rokas pie galda pielāgo atbalsta austiņas

Vadībai nepieciešamas tendenču līnijas, nevis tiešsaistes skaitītāji. Viņu skatā iekļaujiet CSAT tendenci laika gaitā, izmaksas par pieteikumu pa mēnešiem, pieteikumu apjomu salīdzinājumā ar darbinieku skaitu, MTTR tendenci pa ceturkšņiem, SLA izpildes tendenci un kopējo neizskatīto pieteikumu uzkrājuma dinamiku. Viņi šo informāciju pārbauda reizi mēnesī, dažkārt reizi nedēļā, lai pamanītu, vai atbalsta funkcija aug kopā ar uzņēmumu saprātīgā tempā.

Vadītājiem nepieciešama ik dienu atjaunota operatīvā detalizācija. Viņu informācijas panelī jābūt reāllaika atvērto pieteikumu skatam pēc prioritātes, SLA ievērošanai pēc kategorijas, aģentu darba slodzes sadalījumam, šodienas pieteikumu apjomam salīdzinājumā ar dienas vidējo, uzkrājuma vecuma sadalījumam un atkārtotas atvēršanas rādītājam pa aģentiem. Šis skats palīdz pieņemt lēmumus par personālu un veikt ikdienas prioritāšu noteikšanu.

Aģentiem nepieciešams šaurs, personīgs skats reāllaikā: viņu atvērtie pieteikumi ar SLA atpakaļskaitīšanas taimeriem, personīgais CSAT rezultāts, FCR rādītājs un steidzamības secībā sakārtota pieteikumu rinda, kas gaida viņu atbildi. Viss, kas pārsniedz viņu pašu darba slodzi, ir troksnis, kas viņus palēnina.

Informācijas paneļa veids Atjaunošanas biežums Laika periods Galvenie rādītāji Galvenā auditorija
Operatīvais reāllaika panelis No tiešsaistes līdz ikstundas režīmam Šodiena Atvērtie pieteikumi, SLA taimeri, rindas dziļums Aģenti, vadītāji
Iknedēļas taktiskais panelis No ikdienas līdz iknedēļas režīmam Šī nedēļa salīdzinājumā ar iepriekšējo Apjoms, uzkrājuma attiecība, aģentu darba slodze Vadītāji
Stratēģisko tendenču panelis No iknedēļas līdz ikmēneša režīmam Mēnesis/ceturksnis/gads CSAT tendence, izmaksas par pieteikumu, MTTR Vadība

Reāllaika informācijas paneļi nav tikai ērtība. HelpDeskFocus pētījumā konstatēts, ka komandas, kuras izmanto reāllaika pārskatāmību, samazina SLA pārkāpumus aptuveni par 18%, galvenokārt tāpēc, ka vadītāji var pārdalīt darba slodzi, pirms rinda kļūst nekontrolējama, nevis atklāt problēmu pārskatā tikai nākamajā dienā.

Runājot par rīkiem, lielākajai daļai mazo un vidējo komandu sākumā nav nepieciešama pilna BI platformas integrācija. Iebūvētie palīdzības dienesta pārskati lieliski tiek galā ar operatīvo un iknedēļas taktisko līmeni. Izmantojiet tādu BI rīku kā Looker Studio vai Power BI tikai tad, kad nepieciešams apvienot atbalsta datus ar ieņēmumiem, darbinieku skaitu vai citām uzņēmuma sistēmām vadības līmenim, jo atbalsta datu integrēšana BI platformās var samazināt pārskatu sagatavošanas laiku par 60–75%, tiklīdz šāda datu plūsma ir izveidota. Lielākajai daļai komandu pietiek ar labi izveidotu klientu atbalsta informācijas paneli, kurā vienā ekrānā redzama galveno KPI kopa un ar kuru iknedēļas pārskatus var veidot, neatverot piecus dažādus pārskatus.

Jūsu vienas lapas KPI kontrolsarakstam iknedēļas pārskatam jāietilpst vienā skatā bez ritināšanas: FRT, MTTR (mediāna), FCR, CSAT, SLA ievērošana, neizskatīto pieteikumu attiecība, atkārtotas atvēršanas rādītājs un izmaksas par pieteikumu. Astoņi skaitļi, viens ekrāns, nekādas meklēšanas.

Pārskatu biežums un pārskatu veidņu piemēri

Pārskatu biežumam jāatbilst tam, cik ātri rādītājs var jēgpilni mainīties un cik ātri kādam uz to jāreaģē. Lūk, struktūra, ko varat pārņemt tieši.

  1. Ikdienas brīdinājumi. Iestatiet automātiskus aktivizētājus SLA pārkāpumu sliekšņiem (brīdinājumam jānostrādā brīdī, kad pieteikums sasniedz 80% no SLA perioda), pēkšņiem pieteikumu apjoma pieaugumiem (jebkurš rādītājs, kas par 30% pārsniedz pēdējo 7 dienu vidējo) un kritiskas prioritātes rindas pieaugumam virs noteikta skaita. Šiem brīdinājumiem jānonāk Slack vai e-pastā uzreiz pēc aktivizēšanās, nevis jāgaida plānotais pārskats.

  2. Iknedēļas vadītāja pārskats. Veidojiet to kā šīs nedēļas salīdzinājumu ar iepriekšējo nedēļu un to pašu nedēļu pagājušajā gadā, augšpusē pievienojot divu teikumu skaidrojumu par būtiskākajām izmaiņām. Pēc tam iekļaujiet piecas lielākās pieteikumu kategorijas pēc apjoma, aģentu darba slodzes siltuma karti, kurā redzams, kurš ir pārslogots un kuram ir brīva kapacitāte, kā arī galveno KPI kopu (FRT, MTTR, FCR, CSAT, SLA ievērošana, uzkrājuma attiecība). Nosūtiet to katru pirmdienas rītu pirms komandas iknedēļas sapulces.

  3. Ikmēneša uzņēmuma pārskats. Šis pārskats, kas paredzēts direktoriem un vadībai, aptver to pašu galveno rādītāju izmaiņas salīdzinājumā ar iepriekšējo mēnesi un gadu, izmaksas par pieteikumu pa kanāliem, personāla analīzi, kurā darbinieku skaits salīdzināts ar apjoma pieaugumu, un īsu nākotnes risku piezīmi, piemēram, par gaidāmu produkta ieviešanu, kas varētu izraisīt pieteikumu skaita pieaugumu. Šis ir pārskats, kas pamato vai apšauba pieprasījumus pēc papildu darbiniekiem.

Tādas platformas kā Zendesk piedāvā iepriekš izveidotus informācijas paneļus ar galvenajiem rādītājiem, piemēram, izveidotajiem pieteikumiem, neatrisinātajiem pieteikumiem, pirmās atbildes laika mediānu un SLA sasniegšanas rādītāju. Tas ir saprātīgs sākuma paraugs, ja veidojat pārskatu struktūru no nulles un vēlaties pārņemt pārbaudītu lauku kopumu.

Kā pārvērst rādītāju signālus darbībā

Pārskats, kas vienkārši stāv iesūtnē, ir velti ieguldīts darbs. Katram rādītājam, kas mainās sliktā virzienā, jāizraisa konkrēta, noteiktai personai piešķirta rīcība, nevis neskaidra saruna par to, ka “tam jāpievērš uzmanība”.

Augošs uzkrājums. Vispirms pārbaudiet, vai tā ir apjoma vai caurlaidības problēma. Ja apjoms ir pieaudzis, izveidojiet pagaidu prioritāšu noteikšanas komandu vai biežākajiem jautājumiem ieviesiet pašapkalpošanās risinājumu, izmantojot mākslīgā intelekta tērzēšanas robotu. Ja caurlaidība ir samazinājusies, pārbaudiet, vai nav apmācību trūkuma vai bojāta maršrutēšanas noteikuma. Atbildīgais: atbalsta vadītājs. Pēc izmaiņām nedēļu ik dienu sekojiet uzkrājuma attiecībai.

Krītošs FCR. Noskaidrojiet kategorijas, kas rādītāju pazemina, un pārbaudiet, vai problēma nav zināšanu trūkums. Bieži vien viens vai divi problēmu veidi atkārtoti ceļo starp aģentiem. Papildiniet iekšējo zināšanu bāzi ar skaidru šīs kategorijas atrisināšanas procesu un atkārtoti apmāciet komandu. Atbildīgais: komandas vadītājs. Pārbaudiet FCR pa kategorijām pēc divām nedēļām, nevis uzreiz, jo aģentiem nepieciešams laiks, lai jaunos norādījumus apgūtu.

Krītošs CSAT. Salīdziniet to ar FRT un MTTR tajā pašā periodā; lēna atbilde ir visbiežākais iemesls. Ja ātrums nav mainījies, izlasiet faktiskos pieteikumus ar negatīvām atbildēm. Atkārtojošies modeļi kļūs redzami ātri. Atbildīgais: vadītājs. Mēnesi ik nedēļu sekojiet CSAT, jo paraugi bieži ir pārāk mazi, lai uzticētos salīdzinājumam no nedēļas uz nedēļu.

Augošs atkārtotas atvēršanas rādītājs. Nekavējoties salīdziniet to ar FCR; parasti tas nozīmē, ka aģenti slēdz pieteikumus pārāk agri, lai sasniegtu atrisināšanas mērķi. Tieši pārrunājiet to ar iesaistītajiem aģentiem un apsveriet iespēju mainīt motivācijas sistēmu, kas atalgo ātrumu, neņemot vērā atkārtotu atvēršanu. Atbildīgais: vadītājs. Pārbaudiet ik nedēļu.

Augošas izmaksas par pieteikumu. Vispirms pārbaudiet kanālu sadalījumu, jo pāreja no e-pasta vai tērzēšanas uz tālruņa atbalstu šo rādītāju palielinās arī bez komandas snieguma izmaiņām. Ja kanālu sadalījums ir stabils, problēma, visticamāk, ir pārāk liels personāla skaits vai virsstundu izmaksas. Atbildīgais: direktors. Pārskatiet reizi mēnesī, jo šis rādītājs mainās lēni.

Profesionāļa padoms: Nekad nevērtējiet intervences ietekmi ātrāk nekā pēc divām nedēļām. Lielākajā daļā palīdzības dienesta rādītāju ir tik daudz ikdienas trokšņa, ka viena laba vai slikta diena var izskatīties pēc tendences, lai gan tā nav. Pirms spriest, vai risinājums darbojies, ļaujiet tam darboties vismaz vienu pilnu pārskata ciklu.

Ātri uzlabojumi, piemēram, maršrutēšanas noteikuma pielāgošana vai jauna zināšanu bāzes raksta publicēšana, parasti datos parādās nedēļas laikā. Vidēja termiņa pasākumiem, piemēram, darbinieku pieņemšanai vai apmācību programmas pilnīgai pārveidei, nepieciešams pilns mēnesis vai ceturksnis, pirms varat godīgi apgalvot, ka tie ir ietekmējuši rezultātu.

Datu pārvaldība: kā pārliecināties, ka skaitļiem var uzticēties

Nekas no šī nedarbojas, ja pamatā esošie dati ir nepareizi, un kaut kur tie parasti tādi arī ir. Katram galvenajam rādītājam nepieciešams nosaukts īpašnieks, kurš atbild par tā definīciju, dokumentēta aprēķina metode, kas bez iepriekšēja brīdinājuma nemainās, noteikts atjaunošanas biežums un noteikums, kā rīkoties ar trūkstošiem vai nepareizi formatētiem datiem.

Izveidojiet īsu pārvaldības kontrolsarakstu un pārskatiet to reizi ceturksnī:

  • Katram rādītājam norīkojiet vienu atbildīgo, kurš apstiprina jebkuras izmaiņas tā definīcijā.
  • Dokumentējiet precīzu aprēķina formulu vietā, kur to var redzēt visa komanda, nevis tikai viena vadītāja atmiņā.
  • Nosakiet fiksētu datu atjaunošanas biežumu un izveidojiet brīdinājumu par jebkuru pārtraukumu, jo klusi salūzusi datu plūsma ir sliktāka par pilnīgu pārskata neesamību.
  • Pirms CSAT rezultāta publicēšanas pieprasiet minimālo atbilžu līmeni, par zemāko robežu izmantojot 20%.
  • Regulāri veiciet nejauši izvēlētu pieteikumu auditus, katru mēnesi atlasot 10–15 pieteikumus un manuāli pārbaudot laika zīmogus un kategorizāciju salīdzinājumā ar pārskatu.
  • Meklējiet anomālijas, piemēram, rādītāju, kas vienas nakts laikā pēkšņi palielinās par 40% bez atbilstoša notikuma; tas parasti liecina par bojātu integrāciju, nevis reālām izmaiņām.

Izmantojot etalonus, paļaujieties uz avotiem, kas publicē savu metodoloģiju, nevis uz piegādātāja mārketinga lapu. HDI nozares aptaujas, Forrester analītiķu pētījumi par klientu pieredzi un detalizēti ceļveži, piemēram, Softabase etalonu pārskats, ir saprātīgi sākumpunkti, taču pirms jebkura skaitļa pārvēršanas mērķī pielāgojiet to savam vēsturiskajam pamatlīmenim. Etalons pasaka, kas ir ierasts citur; tas nezina jūsu klientu bāzi, produkta sarežģītību vai komandas darba stāžu.

Praktiska piezīme par pareizu izpildi

Lielākā daļa komandu neizdodas palīdzības dienesta pārskatu veidošanā nevis tāpēc, ka izvēlas nepareizos rādītājus, bet tāpēc, ka jau no pirmās dienas cenšas sekot divdesmit rādītājiem un mēneša laikā atsakās no visa projekta. Astoņi konsekventi izsekoti rādītāji, par kuriem katru nedēļu tiek pieņemta rīcība, iemācīs jums par atbalsta darbību vairāk nekā trīsdesmit rādītāji, kuriem laiku pa laikam tikai uzmet skatienu.

Sāciet ar vienas lapas iknedēļas vadītāja informācijas paneli. Pirms pievēršaties vadības pārskatiem vai atsevišķu aģentu logrīkiem, mēnesi panāciet, lai tas darbojas pareizi. Ir vilinoši jau pirmajā dienā izveidot visu sistēmu, jo rīki to padara vienkāršu, taču disciplīna rūpīgi sekot astoņiem skaitļiem ir labāka par ilūziju, ka sekojat trīsdesmit.

Mazai vai vidējai komandai bez atsevišķa analītiķa platforma, piemēram, Deskhero, kas šos galvenos rādītājus iekļauj jau no sākuma, ir saprātīgs veids, kā izvairīties no mēnešiem ilgiem informācijas paneļu veidošanas izmēģinājumiem un kļūdām.

Kā palaist šos pārskatus bez manuāla darba

Lielāko daļu palīdzības dienesta pārskatu veidošanas sarežģījumu rada nevis pareizo rādītāju izvēle, bet manuālais darbs — datu iegūšana no koplietotas iesūtnes, konsekventa pieteikumu marķēšana un vienas un tās pašas izklājlapas atjaunošana katru pirmdienu. Deskhero dažu minūšu laikā pārvērš Gmail vai Microsoft 365 pastkasti par pilnvērtīgu palīdzības dienestu, un, tā kā katrs pieteikums tiek apstrādāts vienā koplietotā sistēmā, galvenie rādītāji (FRT, MTTR, FCR, CSAT, SLA ievērošana, uzkrājums, atkārtotas atvēršanas rādītājs) tiek aprēķināti automātiski, nevis veidoti ar rokām.

Deskhero

Lūk, daži veidi, kā tas tieši atbilst šeit aprakstītajam: divvirzienu e-pasta sinhronizācija nozīmē, ka FRT tiek mērīts pret to pašu adresi, ko klienti jau izmanto, tāpēc sistēmu starpā nekas nepazūd. Mākslīgā intelekta sagatavotās atbilžu uzmetumu versijas, kas veidotas tikai no jūsu komandas apstiprinātajām zināšanām, palīdz paātrināt pirmo atbildi, nezaudējot precizitāti. Tādējādi FRT un CSAT uzlabojas kopā, nevis viens uz otra rēķina. Iebūvētā pieteikumu analītika un pieteikumu ieskatu karte nodrošina iepriekš aprakstītos vadības un vadītāju logrīkus bez datu eksportēšanas uz izklājlapu. E-komercijas komandām Shopify klienta panelis pievieno pasūtījuma kontekstu tieši pieteikuma skatā, kas īpaši samazina ar pasūtījumiem saistīto pieteikumu atrisināšanas laiku.

Ja esat maza vai vidēja komanda, kas vēlas pāriet no “mēs tam īsti nesekojam” uz funkcionējošu iknedēļas informācijas paneli, sāciet 30 dienu bezmaksas izmēģinājumu — kredītkarte nav nepieciešama — un jau pirmajā nedēļā aplūkojiet reālos FRT, MTTR un CSAT rādītājus, neizveidojot nevienu izklājlapas formulu.

Avoti

HelpDeskFocus un Softabase ceļvežos ir atrodami faktiskie etalonu skaitļi; Zendesk un HubSpot resursi ir spēcīgāki informācijas paneļu un rādītāju kombināciju izveidē.

Biežāk uzdotie jautājumi

Kādi ir galvenie pakalpojumu dienesta pārskatu rādītāji?

Galvenā kopa ir pirmās atbildes laiks, MTTR, problēmas atrisināšana pirmajā kontaktā, CSAT, SLA ievērošana, pieteikumu apjoms un neizskatīto pieteikumu uzkrājums, atkārtotas atvēršanas rādītājs un izmaksas par pieteikumu, precizitātes labad segmentējot pēc kanāla, prioritātes un kategorijas.

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

Definīcijas dažādos avotos atšķiras, taču bieži min CSAT, problēmas atrisināšanu pirmajā kontaktā, pirmās atbildes laiku, SLA ievērošanu un Net Promoter Score. CSAT un FCR parasti tiek uzskatīti par diviem rādītājiem, kas vislabāk prognozē klientu lojalitāti.

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

Spēcīgi IT palīdzības dienesta KPI ir SLA ievērošana pēc pieteikuma līmeņa, MTTR pēc prioritātes, uzkrājuma attiecība, izmaksas par pieteikumu un atkārtotas atvēršanas rādītājs 48 stundu laikā, jo tie tieši saistīti gan ar pakalpojuma kvalitāti, gan darbības izmaksām.

Kādi ir labi IT nodaļas KPI?

Papildus palīdzības dienesta rādītājiem IT nodaļas bieži seko sistēmu darbspējas laikam, vidējam incidenta atklāšanas un atrisināšanas laikam un izmaiņu kļūmju rādītājam, kā arī tādiem standarta atbalsta rādītājiem kā FRT un CSAT, lai aptvertu gan pakalpojumu sniegšanu, gan infrastruktūras uzticamību.

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

Iestatiet ikdienas brīdinājumus par SLA pārkāpumu sliekšņiem un apjoma pieaugumiem, reizi nedēļā kopā ar komandu pārskatiet strukturētu pārskatu un katru mēnesi sagatavojiet direktoriem uzņēmuma pārskatu, kurā atspoguļotas mēneša un gada griezuma tendences.

Vai palīdzības dienesta programmatūra var automātiski aprēķināt šos rādītājus?

Jā. Tādas platformas kā Deskhero automātiski aprēķina FRT, MTTR, CSAT un SLA ievērošanu no pieteikumu aktivitātes datiem, novēršot manuālo darbu izklājlapās, ko lielākajai daļai komandu ir grūti konsekventi uzturēt.