Një klient shkruan për një tarifë të papritur. Mesazhi bie në një radhë të përgjithshme, ku një agjent e lexon, vendos se është pyetje faturimi dhe e kalon te ekipi i faturimit. Faturimi sheh se tarifa lidhet me një ndryshim plani të bërë nga account manager-i i klientit dhe ia kalon account management-it. Account management vëren një gabim teknik në mënyrën se si u aplikua plani dhe e dërgon te technical support. Tri caktime më vonë, ticket-i mbërrin te dikush që mund ta rregullojë dhe klienti ka pritur dy ditë.
Askush në atë zinxhir nuk bëri asgjë të gabuar. Secili mori një vendim të arsyeshëm me informacionin që kishte. Problemi është strukturor: routing-u varej nga fakti që secili lexonte ticket-in dhe hamendësonte se ku i takonte më pas. Ky udhëzues përshkruan një qasje praktike për ta dizajnuar triazhin, që caktimet e para të jenë të sakta shumë më shpesh.
Matni si lëvizin ticket-et në të vërtetë
Para se të ndryshoni ndonjë rregull, zbuloni sa riorientim po ndodh dhe ku. Shumica e platformave help desk regjistrojnë historinë e caktimeve, edhe nëse ajo nuk shfaqet në raportet standarde. Eksportoni një kampion ticket-esh të zgjidhura së fundi dhe numëroni sa caktime pati secili para zgjidhjes. Pastaj shikoni shtigjet: cilat radhë ua kalojnë më shpesh ticket-et cilave radhë të tjera.
Kjo zakonisht zbulon një numër të vogël modelesh të përsëritura. Ndoshta një pjesë e madhe e ticket-eve të shënuara si «teknike» janë në fakt probleme qasjeje në llogari. Ndoshta faturimi merr shumë ticket-e që në të vërtetë kanë të bëjnë me kushtet e kontratës. Këto modele ju tregojnë se ku logjika e routing-ut është më e dobët dhe cilat kategori kanë nevojë për përkufizime më të qarta.
- Pjesa e ticket-eve të zgjidhura që në caktimin e parë.
- Numri mesatar i ricaktimeve për ticket, i ndarë sipas radhës fillestare.
- Kalimet më të zakonshme nga një radhë në tjetrën.
- Koha e shpenzuar duke pritur në radhë para caktimit përfundimtar.
Përcaktoni kategoritë sipas atyre që i zgjidhin
Shumë kategori ticket-esh përcaktohen sipas temës: faturim, teknike, llogari, të përgjithshme. Temat janë intuitive për klientët, por jo gjithmonë përputhen me atë kush mund ta zgjidhë çështjen. Një pyetje për një faturë mund ta trajtojë faturimi nëse ka të bëjë me pagesën, account management nëse ka të bëjë me çmimin, ose technical support nëse fatura u gjenerua gabim.
Një qasje më e besueshme është t'i përcaktoni kategoritë sipas ekipit ose aftësisë që nevojitet për t'i zgjidhur, dhe pastaj të përshkruani sinjalet që tregojnë çdo kategori. Për çdo ekip zgjidhës, shkruani llojet e çështjeve që zotërojnë, informacionin që u duhet për të filluar punën dhe shembuj ticket-esh që duken të ngjashme, por i takojnë diku tjetër. Ky dokument bëhet baza si për rregullat e automatizuara, ashtu edhe për trajnimin e agjentëve.
Routing-u funksionon më mirë kur kategoritë përshkruajnë kush mund ta rregullojë problemin, jo se për çfarë mendon klienti se është problemi.
Kapni informacionin e duhur që në pranim
Shumë gabime routing-u ndodhin sepse ticket-i mbërrin pa informacionin e nevojshëm për ta klasifikuar. Një email i lirë që thotë «llogaria ime nuk po punon» mund të nënkuptojë një problem hyrjeje, një abonim të pezulluar ose një bug. Sa më i strukturuar të jetë informacioni që mblidhni në pikën e kontaktit, aq më i lehtë bëhet routing-u.
Kjo nuk do të thotë t'i detyroni klientët nëpër formularë të gjatë. Disa pyetje të zgjedhura mirë, si me cilën fushë produkti lidhet çështja dhe nëse përfshin një tarifë, mund të mjaftojnë. Po aq të dobishme janë të dhënat që klienti nuk ka nevojë t'i japë: nëse ticket-i vjen nga një kontakt i njohur, sistemi mund të kërkojë planin e tyre, account manager-in, porositë e fundit dhe çdo incident të hapur që prek rajonin e tyre. Lidhja e help desk-ut me CRM-në dhe sistemin e faturimit për këtë qëllim shpesh përmirëson routing-un më shumë se çdo ndryshim i vetë rregullave.
Kombinoni rregullat me klasifikimin
Pasi kategoritë dhe të dhënat e pranimit janë të qarta, routing-u mund të automatizohet në shtresa. Shtresa e parë përdor rregulla të qarta të bazuara në të dhëna të strukturuara: ticket-et nga llogaritë enterprise shkojnë te ekipi i tyre i dedikuar, ticket-et që përmendin një numër porosie dhe një rimbursim shkojnë te faturimi, ticket-et e dërguara përmes raportuesit të bug-eve në aplikacion shkojnë te technical support. Këto rregulla janë transparente, të parashikueshme dhe të lehta për t'u rregulluar.
Shtresa e dytë trajton ticket-et që rregullat nuk mund t'i vendosin me besim, zakonisht mesazhe të lira pa sinjale të qarta. Këtu, një model gjuhësor ose klasifikues teksti i stërvitur mbi ticket-e të kaluara mund të sugjerojë një kategori dhe një nivel besimi. Kur besimi është i lartë, ticket-i drejtohet automatikisht. Kur është i ulët, ticket-i shkon te një grup i vogël triazhi, puna e të cilit është të klasifikojë shpejt dhe vendimet e të cilit regjistrohen që klasifikuesi dhe rregullat të përmirësohen.
- Aplikoni së pari rregullat deterministe, aty ku të dhënat e strukturuara e bëjnë përgjigjen të qartë.
- Përdorni klasifikimin vetëm për ticket-et e mbetura të paqarta.
- Drejtojini rastet me besim të ulët te njerëzit, në vend që të hamendësoni.
- Regjistroni çdo korrigjim, që rregullat dhe modelet të mësojnë prej tij.
Ndihmon që arsyeja e çdo vendimi routing-u t'u mbetet e dukshme agjentëve. Nëse një ticket u dërgua te faturimi sepse përmendte një rimbursim, agjenti e sheh këtë menjëherë dhe, nëse ishte gabim, e kupton pse. Routing-u i errët që agjentët nuk mund ta shpjegojnë tenton ta gërryejë besimin shpejt.
Mbylleni ciklin me të dhënat e ricaktimit
Routing-u nuk përfundon kurrë. Produktet ndryshojnë, shfaqen lloje të reja çështjesh dhe ekipet riorganizohen. Sinjali i vazhdueshëm më i dobishëm është vetë ricaktimi. Çdo herë që një agjent e lëviz një ticket në një radhë tjetër, ajo është një copë e vogël evidencash se routing-u mund të jetë më i mirë. Duke u kërkuar agjentëve të zgjedhin një arsye të shkurtër kur ricaktojnë, si «kategori e gabuar» ose «nevojitet qasje në llogari», këto lëvizje kthehen në të dhëna.
Rishikojini këto të dhëna me një orar të rregullt, ndoshta mujor. Kërkoni kalimet që ndodhin më shpesh dhe pyesni nëse një ndryshim rregulli, një pyetje pranimi ose një përkufizim më i qartë kategorie do t'i parandalonte. Me kalimin e kohës, pjesa e ticket-eve të zgjidhura që në caktimin e parë duhet të rritet dhe ngarkesa e grupit të triazhit duhet të zvogëlohet.
Nga ku të filloni
Eksportoni tre muaj ticket-esh të zgjidhura dhe llogaritni shkallën e zgjidhjes që në caktimin e parë dhe kalimet më të zakonshme. Rishkruajini kategoritë rreth ekipeve që zgjidhin çdo lloj çështjeje, me shembuj se çfarë i takon ku. Identifikoni dy ose tri pika të dhënash që mund t'i tërhiqnit automatikisht nga CRM-ja ose sistemi i faturimit në pranim. Pastaj prezantoni një numër të vogël rregullash të qarta për rastet më të qarta dhe dërgoni gjithçka tjetër nëpër një hap triazhi, derisa të keni mjaft të dhëna për të automatizuar më tej.
Edhe përmirësimet e modesta kanë rëndësi. Nëse një ekip trajton 3.000 ticket-e në muaj dhe zvogëlon ricaktimet me disa qindra, kursimi nuk është vetëm kohë agjentësh, por edhe ditë pritjeje të klientit që nuk ndodhin më.