Kaip sukurti bilietų rūšiavimo prioritetų matricą, kuri suderintų visų agentų veiksmus pagal poveikį ir skubumą

Jei jūsų pagalbos komanda kasdien tvarko daugiau nei saują bilietų, jau žinote problemą: ne kiekviena problema nusipelno tokio pat skubumo, tačiau be aiškios sistemos agentai priima intuityvius sprendimus, kurie skiriasi nuo vieno agento iki kito. Vienas agentas atlyginimų sistemos sutrikimą vertina kaip kritinį, o kitas pažymi kaip vidutinio prioriteto ir juda toliau. Laikui bėgant šis nenuoseklumas kenkia SLA veiklos rezultatams, erzina klientus ir palaidoja tikrus pavojus po krūva įprastinių užklausimų.

Bilietų rūšiavimo prioritetų matrica išsprendžia šią problemą. Ji kiekvienam agentui suteikia tą patį vadovėlį, pagal kurį nustatoma, kuriuos bilietus imtis pirmiausiai, remiantis dviem objektyviais veiksniais: kiek žmonių yra paveikti (poveikis) ir kaip greitai problemai reikia dėmesio (skubumas). Rezultatas – prioriteto lygis, kuriuo gali pasitikėti visa komanda.

Šiame vadove išmoksite tiksliai, kaip sukurti prioritetų matricą savo pagalbos operacijoms, kaip susieti ją su SLA tikslais, kokias metrikas sekti ir kaip išvengti dažniausių klaidų, kurias komandos daro diegdamos tokią sistemą. Procesas atitinka ITIL suderintą geriausią praktiką, tačiau išlieka pakankamai praktiškas, kad būtų pritaikomas bet kurioje pagalbos tarnyboje – ar turėtumėte oficialų ITSM sprendimą, ar nedidelę klientų aptarnavimo komandą.

Sunkumas: Vidutinis Įgyvendinimo laikas: 2–4 valandos apibrėžimui ir konfigūravimui; nuolatinis tobulinimas per kelias savaites Būtinos sąlygos: Prieiga prie pagalbos tarnybos platformos nustatymų (administratoriaus teisės kurti pasirinktinius laukus, taisykles ar automatizavimą), aiškus supratimas apie savo SLA įsipareigojimus ir bent vieno komandos vadovo ar vadybininko indėlis, galintis patvirtinti poveikio ir skubumo apibrėžimus

Kas yra bilietų rūšiavimo prioritetų matrica?

Bilietų rūšiavimo prioritetų matrica yra dvimatė lentelė, kuri apskaičiuoja prioritetą iš dviejų įvesties duomenų: poveikio ir skubumo. Poveikis matuoja sutrikimo apimtį ir sunkumą. Skubumas matuoja, kaip greitai reikia sprendimo, kol verslas nepatirs realios žalos. Langelis, kuriame jie susikerta, suteikia prioriteto lygį, paprastai nuo P1 (kritinis) iki P4 (žemas).

ITIL terminais, prioritetas niekada nėra atskiras sprendimas. Jis visada išvedamas iš poveikio ir skubumo. Šis skirtumas svarbus, nes pašalina subjektyvumą. Kai agentas mato bilietą, jis atsako į du konkrečius klausimus: „Kiek žmonių ar sistemų yra paveikta?" ir „Kaip greitai tai reikia sutvarkyti?" Tada matrica atlieka likusią dalį.

Ši sistema vienodai tinka IT incidentų valdymui, klientų aptarnavimo eilėms ir vidaus paslaugų tarnyboms. Pavadinimai gali keistis (kai kurios komandos naudoja „sunkumas" vietoj „poveikis" arba „kritiškumas" vietoj „skubumas"), bet pagrindinė logika išlieka ta pati.

Kodėl tai svarbu SLA veiklos rezultatams: Teisingai sukurta prioritetų matrica užtikrina, kad jūsų SLA laikrodis pradėtų veikti su tinkamu skubumo lygiu. Jei bilietas neteisingai klasifikuojamas priėmimo metu, jis arba gauna pernelyg atsipalaidavusį SLA tikslą (sukeliant delsą tikrai skubiems darbams), arba pernelyg agresyvų (nustatant komandą nereikalingiems pažeidimams). Teisingai nustatyti prioritetą rūšiavimo metu yra pats svarbiausias dalykas, kurį galite padaryti, kad apsaugotumėte savo SLA atitikties rodiklį.

Jei jūsų pagalbos tarnybos platforma palaiko automatizuotą bilietų rūšiavimą ir kategorizavimą , galite sukonfigūruoti matricą taip, kad prioritetas būtų apskaičiuojamas automatiškai, kai tik agentas pasirenka poveikio ir skubumo reikšmes. Tai visiškai pašalina rankinį prioriteto pasirinkimą ir užtikrina jūsų eilės nuoseklumą.

Poveikis vs. skubumas: dviejų dimensijų supratimas

Prieš kurdami matricą, jūsų komandai reikia bendro apibrėžimo, ką poveikis ir skubumas iš tikrųjų reiškia jūsų kontekste. Apibrėžimai turi būti pakankamai konkretūs, kad du skirtingi agentai, žiūrėdami į tą patį bilietą, priskirtų tas pačias reikšmes.

Poveikis: sutrikimo apimtis

Poveikis atsako į klausimą: „Kiek vartotojų, sistemų ar verslo procesų yra paveikta ir kaip blogai?"

Poveikis nėra apie tai, kiek nusiminęs yra vartotojas. Tai nėra apie tai, kuris skyrius pateikė bilietą. Tai faktinės problemos apimties matas. Įprasti poveikio lygiai:

• Didelis / platus: Visos organizacijos sutrikimas, kritinė klientams skirta paslauga neveikia, dideli pajamų praradimai, saugumo pažeidimas, paveikiantis kelias sistemas
• Vidutinis / reikšmingas: Paveiktas skyrius ar komanda, pabloginta antrinė verslo funkcija arba paveikti keli vartotojai, tačiau yra alternatyvus sprendimas
• Žemas / nedidelis: Paveiktas vienas vartotojas, problema yra kosmetinė arba netrukdo pagrindiniam darbui

Patarimas: Kai įmanoma, susiekite poveikio lygius su išmatuojamomis ribomis. Pavyzdžiui: „Didelis poveikis = paveikti 50 ar daugiau vartotojų ARBA pajamas generuojanti paslauga." Tai pašalina dviprasmybes.

Skubumas: lenktynės su laiku

Skubumas atsako į klausimą: „Kaip greitai tai reikia išspręsti, kol žala nepadidėja?"

Skubumas susijęs su laiko jautrumu. Didelio skubumo bilietas yra toks, kai kiekviena delsos valanda blogina situaciją. Žemo skubumo bilietą galima suplanuoti be reikšmingų verslo pasekmių. Įprasti skubumo lygiai:

• Didelis / kritinis: Nėra alternatyvaus sprendimo, veikla sustabdyta, terminas artėja arba problema aktyviai eskaluojasi
• Vidutinis: Darbas apsunkintas, bet laikinas alternatyvus sprendimas padeda išlaikyti eigą, arba problema gali palaukti kelias valandas be didelės žalos
• Žemas: Egzistuoja patikimas alternatyvus sprendimas, problema gali būti atidėta iki techninės priežiūros lango arba poveikis neauga laikui bėgant

Įspėjimas: Nepainiokite skubumo su poveikiu. Vienas vadovas, negalintis pasiekti el. pašto, tam vadovui yra ypač skubu, bet poveikis žemas (vienas vartotojas). Serverio problema, paveikianti 200 žmonių, turinčių rankinį alternatyvų sprendimą, yra didelio poveikio, bet vidutinio skubumo. Jei leisite skubumui nusverti poveikį, nuolat per daug prioritetizuosite garsius individualius prašymus, o nepakankamai prioritetizuosite plačiai paplitusias, bet tylesnes problemas.

Pasiruošę kelti verslą į naują lygį?

Išbandykite LiveAgent nemokamai ir įsitikinkite patys.

Užsisakyti demo 30 dienų nemokamai

Kaip sukurti savo prioritetų matricą

Funkcionalios prioritetų matricos sukūrimas apima penkis žingsnius. Pirmuosius tris galite atlikti darbo sesijoje su savo komandų vadovais; paskutiniams dviem reikia administratoriaus prieigos prie pagalbos tarnybos platformos.

1 žingsnis: apibrėžkite poveikio lygius

Pradėkite išvardindami poveikio lygius, kurie yra prasmingi jūsų organizacijai. Dauguma komandų naudoja tris ar keturis lygius. Štai pradžios taškas:

Pritaikykite ribas pagal savo mastą. Įmonė, turinti 500 darbuotojų, gali apibrėžti „platų" kaip 100+ vartotojų, o 10 žmonių įkurtas startuolis gali apibrėžti kaip 5+.

2 žingsnis: apibrėžkite skubumo lygius

Apibrėžkite skubumo lygius su aiškiais sprendimo kriterijais. Dažniausia klaida čia yra pasikliauti prašytojo tonu, o ne objektyviais faktais. Suteikite agentams kontrolinį sąrašą:

3 žingsnis: sudarykite matricą

Dabar sujunkite poveikį ir skubumą į lentelę. Standartinis ITIL metodas naudoja 3×3 arba 4×4 matricą. Štai praktiška 3×3 versija, tinkanti daugumai komandų:

Didesnės organizacijos dažnai išplečia tai į 4×4 lentelę, pridėdamos “Kritinį” lygį aukščiau “Didelio” abiejose ašyse. Tai rezervuoja P1 retiems atvejams, kai ir poveikis, ir skubumas yra pačiame aukščiausiame lygyje, užuot leidus kiekvienam “didelio poveikio, didelio skubumo” bilietui patekti į aukščiausią juostą. Tai tas pats sprendimas, kurį pamatysite vėliau šiame vadove, skirtame sutramdyti matricą, kuri viską suspaudžia į P1 ir P2.

4 žingsnis: sukonfigūruokite automatizavimą savo pagalbos tarnyboje

Kai jūsų komanda susitaria dėl apibrėžimų ir lentelės, paverskite tai forma, kurią jūsų pagalbos tarnybos programinė įranga gali realiai įgyvendinti: du išskleidžiamieji laukai (poveikis ir skubumas) bei taisyklė arba apskaičiuojamas laukas, nustatantis prioritetą pagal derinį. Tai taip pat yra momentas, kai prijungiate kiekvieną prioriteto lygį prie atitinkamos SLA politikos, kad sprendimo laikrodis pradėtų veikti su tinkamu tikslu vos tik bilietas yra sukurtas.

5 žingsnis: testuokite, stebėkite ir tobulinkite

Paleiskite matricą su dalimi savo eilės arba lygiagrečiai su esamu procesu, prieš įjungdami ją visiems. Stebėkite, kaip bilietai pasiskirsto per keturias prioritetų juostas, ir patikrinkite, ar skirstymas atrodo realistiškas pagal jūsų bilietų kiekį. Kai ji pradės veikti visai komandai, stebėkite SLA metrikas ir monitoringą , aprašytus toliau, ir peržiūrėkite apibrėžimus kas ketvirtį, kai kaupiasi realūs bilietų duomenys.

Naudojant automatizuotą bilietų rūšiavimą ir kategorizavimą pašalinama dažniausia proceso nesėkmės priežastis: agentai rankiniu būdu pasirenkantys neteisingą prioritetą. Kai matricą vykdo automatizavimas, kiekvienas bilietas vadovaujasi ta pačia logika, nepriklausomai nuo to, kuris agentas jį tvarko.

Bilietų rūšiavimo SLA metrikos ir stebėjimas

Kai jūsų prioritetų matrica pradeda veikti, turite sekti, ar ji veikia. Tikslas yra ne tik teisingai priskirti prioritetus, bet ir pamatyti, kaip šie prioritetai virsta geresniais SLA rezultatais.

Pagrindinės metrikos, kurias reikia sekti

Stebėjimas: svarbiausia valdymo skydelis

Jūsų operacijų valdymo skydelis turėtų akimirksniu atsakyti į tris klausimus:

1. Kas tuoj pažeis SLA? Rodykite rizikingus bilietus (sunaudota 75%+ SLA laiko) ir jau pažeistus bilietus. Tai svarbiausias vaizdas, nes jis nurodo, kur nukreipti dėmesį dabar.
2. Kokia yra tendencija? Rodykite SLA atitiktį laikui bėgant (savaitėmis, mėnesiais), suskirstytą pagal prioritetą. Vienas atitikties skaičius gali paslėpti faktą, kad P1 našumas prastėja, o P4 gerėja.
3. Kur yra kliūtys? Rodykite perskirstymo rodiklius pagal komandą, neišspręstų bilietų kiekį pagal eilę ir FRT pagal kanalą. Jei viena komanda turi didėjantį perskirstymo rodiklį, problema greičiausiai yra rūšiavimo, o ne pajėgumo.

Naudokite spalvomis koduotą SLA būseną kiekvienam bilietui eilėje:

• Pagal tvarkaraštį: >50% SLA laiko likę
• Rizikingas: likę 25–50% SLA laiko
• Skubu: likę <25% SLA laiko
• Pažeista: SLA terminas praėjo

Pagrindiniai prasto rūšiavimo rodikliai

Kai kurios metrikos yra vėluojančios (žalą matote po to, kai ji įvyksta), o kai kurios yra pirmaujančios (jos įspėja prieš žalai plintant). Atkreipkite dėmesį į šiuos pirmaujančius rodiklius:

• Didėjantis perskirstymo rodiklis: Bilietai nukreipiami ne toms komandoms. Patikrinkite savo kategorizavimo taisykles ir agentų mokymus apie rūšiavimo ir kategorizavimo procesą.
• Augantis vienos prioritetų juostos neišspręstų bilietų kiekis: Jei P3 bilietai kaupiasi, o P1 ir P2 yra tvarkingi, jūsų rūšiavimo procesas gali per daug klasifikuoti bilietus, kad išvengtų P1 spaudimo.
• Didėjantis atotrūkis tarp FRT ir priskyrimo laiko: Jei agentai greitai patvirtina bilietus, bet priskyrimas užtrunka valandas, rūšiavimo žingsnis yra kliūtis.
• Pakartotinio atidarymo rodiklis virš 5%: Bilietai uždaromi per anksti, dažnai todėl, kad agentas skubėjo įvykdyti SLA laikmatį, o ne iki galo išsprendė problemą.

Prenumeruokite naujienlaiškį

Naujausi patarimai ir pasiūlymai tiesiai į jūsų pašto dėžutę.

El. pašto adresas

Prenumeruoti

Dažniausių prioritetų matricos problemų sprendimas

Net ir gerai sukurta matrica gali sukelti trintį. Štai dažniausios problemos ir kaip jas išspręsti.

“Prioriteto suspaudimo” spąstai

Problema, dažnai pasirodanti IT valdymo forumuose, yra tai, ką praktikai vadina prioriteto suspaudimu: per daug bilietų susitelkia toje pačioje prioritetų juostoje, nes apibrėžimai yra pernelyg neaiškūs. Kai P2 apima viską nuo “skyriaus lygio el. pašto sutrikimo” iki “vadovo klaviatūra lipni”, matrica prarado savo naudingumą.

Sprendimas yra padaryti jūsų apibrėžimus konkrečius ir, kur įmanoma, kiekybinius. Vietoj “didelis poveikis = paveikta daug vartotojų” naudokite “didelis poveikis = paveikta 50+ vartotojų ARBA pajamas generuojanti paslauga neveikia”. Agentai gali tai taikyti nuosekliai.

Prioritetų matricos automatizavimas jūsų pagalbos tarnyboje

Automatizavimas yra tai, kas paverčia prioritetų matricą iš nuorodos dokumento į operacinį įrankį. Kai agentams tereikia pasirinkti poveikį ir skubumą, o sistema apskaičiuoja visa kita, jūsų rūšiavimo procesas tampa greitas, nuoseklus ir audituojamas.

Štai kaip atrodo geras automatizavimo nustatymas:

1. Agentas pasirenka poveikį ir skubumą iš išskleidžiamųjų meniu bilieto formoje.
2. Sistema apskaičiuoja prioritetą naudodama jūsų matricos taisykles ir automatiškai nustato prioriteto lauką.
3. SLA laikmatis paleidžiamas su teisingu tikslu pagal apskaičiuotą prioritetą.
4. Jei bilietas nepriskirtas po nustatyto slenksčio, sistema eskaluoja jį komandos vadovui.
5. Jei SLA laikmatis pasiekia 75%, sistema siunčia įspėjimą priskirtam agentui.

Dauguma platformų, įskaitant LiveAgent , palaiko tokio pobūdžio darbo eigą per automatizavimo taisykles, SLA politikas ir pasirinktinių laukų logiką. Jei jūsų dabartinė platforma nepalaiko apskaičiuojamų prioriteto laukų, tą patį rezultatą dažnai galite pasiekti naudodami trigeriu pagrįstas taisykles: “Kai poveikis = X ir skubumas = Y, nustatykite prioritetą = Z.”

Komandoms, kurios nori eiti toliau, DI pagrįstas rūšiavimas gali automatiškai klasifikuoti gaunamus bilietus pagal istorinius modelius, aptikti nuotaikas ir pasiūlyti poveikio bei skubumo reikšmes dar prieš agentui atidarant bilietą. Tai sumažina rankinio rūšiavimo pastangas ir gali žymiai sutrumpinti laiką iki priskyrimo. Sužinokite daugiau apie automatizuotą bilietų rūšiavimą ir kategorizavimą ir kaip jis integruojasi su SLA valdymu.

DUK

Kuo skiriasi poveikis ir skubumas prioritetų matricoje?

Poveikis matuoja sutrikimo apimtį: kiek vartotojų, sistemų ar verslo procesų yra paveikti. Skubumas matuoja, kaip greitai problemą reikia išspręsti, kol žala nepadidėjo. Serverio gedimas, paveikiantis 500 vartotojų be alternatyvaus sprendimo, yra ir didelio poveikio, ir didelio skubumo. Serverio gedimas, paveikiantis 500 vartotojų, turinčių patikimą rankinį alternatyvų sprendimą, yra didelio poveikio, bet vidutinio skubumo. Matrica sujungia abu šiuos veiksnius, kad nustatytų prioritetą.

Kaip apibrėžti poveikio lygius IT paslaugų bilietams?

Apibrėžkite poveikio lygius naudodami išmatuojamas ribas. Pradėkite nuo plačiausio lygio (paveikta visa organizacija arba visi klientai) ir eikite žemyn iki siauriausio (vienas vartotojas, kosmetinė problema). Kiekvienam lygiui nurodykite vartotojų skaičių arba paslaugos kritiškumo kriterijų. Pavyzdžiui: “Didelis poveikis = paveikta 50+ vartotojų ARBA pagrindinė verslo paslauga neveikia.” Tai neleidžia agentams spėlioti.

Kokie yra standartiniai SLA atsako laikai P1, P2, P3 ir P4 bilietams?

Įprasti etalonai: P1 (kritinis) — pirmas atsakas per 15 minučių, išsprendimas per 4 valandas; P2 (didelis) — pirmas atsakas per 1 valandą, išsprendimas per 8 darbo valandas; P3 (vidutinis) — pirmas atsakas per 4 valandas, išsprendimas per 3 darbo dienas; P4 (žemas) — pirmas atsakas per 8 darbo valandas, išsprendimas per 5 darbo dienas. Šie rodikliai turėtų būti koreguojami pagal jūsų komandos pajėgumus ir sutartinius įsipareigojimus.

Ar prioritetų matrica gali būti naudojama ne IT pagalbos bilietams?

Taip. Poveikio ir skubumo sistema tinka bet kuriai pagalbos aplinkai, kur gaunami užklausimai turi skirtingą skubumo ir apimties lygį. Klientų aptarnavimo komandos, patalpų valdymas, HR paslaugų tarnybos ir MSP visi naudoja tos pačios matricos variacijas. Pavadinimai keičiasi, bet logika išlieka ta pati: įvertinti apimtį (poveikį) ir laiko jautrumą (skubumą), tada nustatyti prioritetą.

Kaip neleisti agentams apeiti prioritetų matricos?

Veiksmingiausias būdas – padaryti prioriteto lauką tik skaitomu ir automatiškai apskaičiuojamu pagal poveikį ir skubumą. Jei agentai negali rankiniu būdu keisti prioriteto, jie negali apeiti matricos. Jei jūsų platforma nepalaiko apskaičiuojamų laukų, galite naudoti automatizavimo taisykles, kurios nustato prioritetą pagal poveikio ir skubumo reikšmes, ir registruoti bet kokius rankinius pakeitimus audito peržiūrai.

Kokios metrikos rodo, kad rūšiavimo procesas neveikia?

Keturi pagrindiniai rodikliai: didėjantis perskirstymo rodiklis (bilietai patenka ne toms komandoms), augantis vienos prioritetų juostos neišspręstų bilietų skaičius, didėjantis atotrūkis tarp pirmojo atsako laiko ir priskyrimo laiko bei pakartotinio atidarymo rodiklis virš 5%. Bet kuris iš šių signalų reiškia, kad rūšiavimo procesui reikia dėmesio, net jei bendras SLA atitikties rodiklis atrodo priimtinas.

Kaip dažnai reikėtų peržiūrėti ir atnaujinti prioritetų matricą?

Peržiūrėkite matricą kas ketvirtį. Pažiūrėkite į bilietų pasiskirstymą pagal prioriteto lygius. Jei daugiau nei 10% bilietų patenka į P1, jūsų apibrėžimai greičiausiai per platūs. Jei P4 bilietai nuolat viršija savo SLA terminą, jūsų tikslai gali būti nerealūs. Įtraukite komandų vadovus ir agentus į peržiūrą – jie turės naudingiausių atsiliepimų, kur matrica praktiškai neveikia.

Kiti žingsniai

Prioritetų matrica nėra dokumentas, kurį sukuriate vieną kartą ir pamirštate. Veiksmingiausios komandos elgiasi su ja kaip su gyva sistema, peržiūrėdamos ją kas ketvirtį, tobulindamos apibrėžimus pagal realius bilietų duomenis ir perkvalifikuodamos agentus, kai taisyklės keičiasi.

Pradėkite nuo šiame vadove pateiktos 3×3 matricos. Apibrėžkite savo poveikio ir skubumo lygius naudodami konkrečias ribas. Sukonfigūruokite automatizavimą savo pagalbos tarnyboje. Paleiskite mėnesiui, peržiūrėkite prioritetų pasiskirstymą ir SLA atitikties duomenis bei pakoreguokite. Laikui bėgant, rasite matricą, kuri tiksliai tinka jūsų organizacijai ir kiekvieną rūšiavimo sprendimą padaro greitą, nuoseklų ir pagrįstą.

Jei norite sužinoti, kaip automatizuotas bilietų rūšiavimas ir kategorizavimas gali įgyvendinti jūsų prioritetų matricą be rankinių pastangų arba kaip pagalbos tarnyba su integruotu SLA valdymu gali sekti šiame vadove aptartas metrikas, LiveAgent platforma suteikia įrankius šioms praktikoms įgyvendinti.