Kodėl skundas apskritai pasiekia vadovą

Yra vienas rodiklis, apie kurį vadovai retai kalba atvirai: kiek skundų per savaitę pasiekia juos asmeniškai. Ne sistemą. Ne aptarnavimo komandą. Jus.

Kiekvienas toks el. laiškas yra signalas: buvo momentas, kai situaciją dar buvo galima išspręsti. Ir niekas to nepadarė. Tai nėra darbuotojų blogos valios klausimas. Tai sistemos klausimas.

Didesnėse organizacijose skundų kelias į viršų dažnai atrodo taip: klientas susiduria su problema, kreipiasi į darbuotoją, darbuotojas neturi nei įgaliojimų, nei aiškios procedūros ją išspręsti, klientas nusivilia — ir galiausiai žinutė atsiranda vadovo dėžutėje arba viešai internete.

Problema dažniausiai ne ta, kad darbuotojas nenorėjo padėti. Problema ta, kad jis nežinojo, ką jam leista daryti. Ta nežinia — kai klientas stebi, kaip darbuotojas tyli, skambina vidiniais numeriais arba sako „turiu pasitarti su vadovu" — yra pati brangiausia klaida aptarnavime.

„Klientas tuo momentu dar nėra prarastas. Bet jis jau skaičiuoja."

Nemokamas priedas prie šio straipsnio

Skundų valdymo sistema — paruošta naudoti iš karto

Excel sistema, kurią naudoju dirbdama su klientais. Ne teorija — darbo įrankis, sukurtas iš realios skundų valdymo praktikos telekomunikacijų, bankininkystės ir sveikatos priežiūros sektoriuose. Kiekvienas euras skaičiuojamas iš prielaidų, kurias pirma kalibruojate savomis.

Instrukcija
Nustatymai — prielaidos
Sarasai — taksonomija
Registras — kasdieniai įrašai
CAPA — korekciniai veiksmai
Skydelis
Pareto
Trendai
Igaliojimai
Parsisiųsti nemokamai (.xlsx)

Excel · 9 lapai · lietuvių kalba
Jokios registracijos · Jokio el. pašto · Tiesiog failas

Kas yra proaktyvus skundų valdymas

Proaktyvus skundų valdymas — tai organizacinis gebėjimas identifikuoti ir išspręsti kliento problemą prieš jai tampant oficialiu skundu. Jis remiasi trim elementais: darbuotojų įgaliojimais, skundų duomenų analize ir aiškia eskalacijos procedūra.

Tai atrodo paprastai — ir yra paprastai, kai sistema tam pastatyta. Vėluojantis pristatymas: darbuotojas skambina pirmas. Produktas su defektu: komanda informuoja prieš klientui pastebint. Sutarties neatitikimas: atsakingas žmogus tai mato ir kreipiasi.

Bet tokio elgesio negalima reikalauti iš žmogaus, kuris neturi nei įrankių problemai pastebėti, nei leidimo ją spręsti savarankiškai.

Nemokamas įvertinimas · 3 minutės

Ar jūsų komanda turi aiškius įgaliojimus spręsti problemas vietoje?

Atlikite ekspres-testą ir sužinokite, ar jūsų skundų valdymo sistema veikia — ar vis dar laukia vadovo leidimo.

Atlikti nemokamą testą

Kaip sukurti darbuotojų įgaliojimų sistemą

Vienas praktiškas ir dažnai nepakankamai įvertinamas sprendimas — aiškiai apibrėžti, ką kiekvienas darbuotojas gali padaryti savarankiškai, kai problema pagrįsta.

Pavyzdys, kuris veikia daugelyje sektorių: darbuotojas turi teisę pasiūlyti nuolaidą iki tam tikros ribos — tarkime, 10% — be papildomo suderinimo, jei problema aiški (vėlavimas, gedimas, klaida proceso metu). Virš tos ribos — eskalacija pagal aiškią procedūrą.

Tai nėra pinigų išdalijimas. Tai investicija į tai, kad problema būtų išspręsta tinkamu momentu — kol klientas dar kalba su jumis, o ne rašo atsiliepimą viešai.

Tokia sistema reikalauja trijų dalykų:

1

Aiškių ribų

Darbuotojas turi žinoti konkrečiai, ką jis gali ir ko negali. „Spręsk pagal situaciją" nėra instrukcija — tai atsakomybės perkėlimas be įrankių.

2

Pasitikėjimo kultūros

Jei darbuotojas bijo, kad savarankiškas sprendimas bus vėliau kvestionuojamas, jis niekada tų įgaliojimų nenaudos. Įgaliojimai ant popieriaus ir įgaliojimai kultūroje — du skirtingi dalykai.

3

Duomenų sekimo

Jei nuolaidų prašoma dėl tų pačių trijų priežasčių mėnesį po mėnesio — tai ne aptarnavimo problema. Tai proceso problema, kurią reikia spręsti prie šaknies.

Skundas kaip diagnozė

Didesnėse organizacijose padalinių vadovai dažnai pateikia skundus kaip išimtis, o ne kaip modelį. „Tai buvo ypatingas atvejis." „Klientas buvo specifiškas." Šie paaiškinimai gali būti teisingi atskirais atvejais. Tačiau kai tie patys paaiškinimai kartojasi kas mėnesį — tai jau ne išimtys. Tai sistema.

Skundo duomenys pasako tai, ko apklausos dažnai nepasako — nes skundžiasi tas, kuris jau pasiekė emocinę ribą ir nusprendė, kad verta kalbėti. Tai ne atsitiktinis atsiliepimas. Tai signalas iš žmogaus, kuris dar nenorėjo išeiti tyliai.

Skaityti skundus sistemingai — nereiškia juos žinoti. Tai reiškia kategorijas, dažnumą, pasikartojančius žodžius. Jei tris mėnesius iš eilės klientai mini tą patį etapą — tai diagnostinis duomuo, kurį vadovas gali padėti ant stalo ir pasakyti: čia yra struktūrinė priežastis, ir mes ją šaliname.

Dažniausios klaidos valdant skundus

Klaida 01
Skundas išsprendžiamas, bet nieko neužfiksuojama
Darbuotojas išsprendžia situaciją, klientas patenkintas, pokalbis užbaigiamas. Niekas neužrašo, kas nutiko ir kodėl. Po trijų savaičių — identiškas skambutis su kitu klientu.
Klaida 02
Eskalacija yra vienintelis kelias
Kai kiekviena nestandartinė situacija reikalauja vadovo sprendimo, sistema yra per lėta klientui ir per brangi organizacijai. Eskalacija turi būti išimtis, ne standartas.
Klaida 03
Mokymai apie empatiją, bet ne apie sprendimus
Darbuotojas, kuris kalba empatiją, bet neturi ką pasiūlyti, tik ilgiau atideda kliento nusivylimą. Empatija be sprendimo yra maloni — bet ji neišlaiko kliento.
Klaida 04
Skundų duomenys nepasiekia tų, kurie gali keisti procesus
Skundų informacija turi keliauti ne tik vertikaliai (vadovui), bet ir horizontaliai — ten, kur yra galimybė pašalinti priežastį.
Klaida 05
Laimėjimas matuojamas greičiu, ne rezultatu
„Atsakėme per 2 valandas" — tai proceso rodiklis. „Klientas nebeturėjo šios problemos" — tai rezultato rodiklis. Greitas atsakymas į blogą sprendimą yra greitas praradimas.

Ką daryti rytoj

1

Peržiūrėkite paskutinio mėnesio skundus kaip duomenų rinkinį

Ieškokite pasikartojančių žodžių, etapų, situacijų. Jei trys ar daugiau skundų mini tą patį — tai ne atsitiktinumas.

2

Paklauskite komandos: kas jums trukdo spręsti situaciją vietoje?

Atsakymas dažnai bus konkretus: negaliu grąžinti pinigų, negaliu pakeisti termino. Tai jūsų įgaliojimų žemėlapis.

3

Apibrėžkite vieną konkrečią ribą, kurią darbuotojas gali spręsti savarankiškai

Ne „spręskite pagal situaciją" — o konkretus scenarijus ir konkretus veiksmas. Pradėkite nuo vieno.

4

Sukurkite vidinę skundų kategorijų lentelę

Kas mėnesį — penkios dažniausiai pasikartojančios priežastys. Prie kiekvienos — atsakingas žmogus ir terminas. Tai vienintelis būdas užtikrinti, kad tas pats skundas nesugrįžtų.

„Komanda, kuri turi aiškius įgaliojimus, sprendžia problemas prieš jas tampant skundais. O vadovai gauna mažiau el. laiškų."

Kas yra registre

Dauguma organizacijų registruoja skundus. Mažai kas juos analizuoja sistemingai — ir dar mažiau kas patikrina, ar korekcinis veiksmas suveikė. Šis failas sujungia kasdienį įrašymą, kainos modelį, CAPA ciklą ir automatinę analitiką viename dokumente. Devyni lapai ir trys spalvos: mėlynus stulpelius pildo darbuotojas, geltonus — vadovas, pilki skaičiuojasi patys.

01

Nustatymai — prielaidos, be kurių eurai prasimanyti

Kontakto savikaina, kliento metinė vertė ir praradimo tikimybės pagal sunkumą. Visi kiti lapai skaičiuoja iš čia — todėl šis lapas pildomas pirmas, ne paskutinis.

  • Pradinės reikšmės (12 €, 2 000 €, 1–40 %) yra prielaidos, ne jūsų duomenys
  • SLA ribos pagal prioritetą ir rizikos slenksčiai
  • Kol nekalibruota — kiekvienas COPQ euras yra spėjimas su dviem skaitmenimis po kablelio
02

Sarasai — viena taksonomijos vieta

Skyriai, darbuotojai, kanalai ir šakninių priežasčių sąrašas. Pakeitus čia, pasikeičia visi išskleidžiami sąrašai registre.

  • Vienintelis taksonomijos šaltinis — nėra kur prasilenkti
  • Pakeiskite savais prieš pirmą įrašą
03

Registras — kasdienis įrašas, apie dvi minutes

Darbuotojas fiksuoja, ką klientas tvirtina. Ar tai pasitvirtino — atskiras vadovo sprendimas atskirame stulpelyje. Nepatvirtintas skundas eurų negeneruoja.

  • „Kliento teiginys“ ir „Patvirtinta pagrįsta?“ — du skirtingi laukai
  • FCR, kanalas, proceso etapas, šakninė priežastis
  • Rizikos balas = Sunkumas × Dažnis × Aptikimas, su sunkumo grindimis
  • Kaina: tiesioginė žala + aptarnavimo sąnaudos + rizikuojamos pajamos
04

CAPA — korekcija nėra korekcinis veiksmas

Kompensacija klientui sutvarko atvejį. Procesą keičia visai kitas veiksmas. Registre jie gyvena atskirai, nes maišomi jie leidžia metų metus „spręsti“ tą pačią problemą.

  • 5 Kodėl grandinė iki tikrosios priežasties
  • Efektyvumo patikra: uždaroma tik tada, kai priežastis nebekartojasi per stebėsenos laikotarpį
  • Uždaryta ≠ išspręsta — tai skaičiuojama, ne deklaruojama
  • Atitinka ISO 9001:2015 10.2.1 (d)
05

Skydelis, Pareto, Trendai — skaičiuojasi patys

Nieko pildyti nereikia. Vienintelis rankinis laukas — vadovo komentaras trendų lape.

  • FCR, SLA įvykdymas, COPQ, pakartojimų dalis
  • Pareto: kurios priežastys sugeneruoja daugiausia kainos
  • Trendai: mėnesio pokytis prieš ankstesnį
06

Igaliojimai — kas ką gali nuspręsti pats

Dažniausias skundų valdymo trūkumas: darbuotojai nežino, ką gali spręsti savarankiškai. Šis lapas lemia FCR labiau nei bet kokie mokymai.

  • 10 scenarijų nuo vėlavimo iki viešo skundo
  • 3 lygiai: darbuotojas → vadovas → direktorius

Pradėti per vieną dieną

Registras suprojektuotas taip, kad nereikėtų mokymo. Kiekvienas lapas turi instrukcijas.

01

Parsisiųskite ir atidarykite

Veikia Excel ir Google Sheets. Jokio diegimo.

02

Peržiūrėkite įgaliojimų žemėlapį

Pritaikykite scenarijus savo organizacijai.

03

Pradėkite pildyti registrą

Kiekvienas skundas — nauja eilutė.

04

Mėnesio pabaigoje — Diagnostika

Identifikuokite 5 dažniausias priežastis.

Dažni klausimai

Dažniausiai tai rodo struktūrinę priežastį — proceso spragą, neaiškią atsakomybę arba darbuotojo įgaliojimų trūkumą. Individualus skundas išsprendžiamas, bet sistema lieka nepakeista, todėl kitą mėnesį ateina identiškas skambutis su kitu klientu.
Aiški riba (pvz., iki 10% nuolaida be suderinimo) leidžia išspręsti 70–80% situacijų vietoje. Kaina — kelios nuolaidos per mėnesį. Alternatyva — vadovų laikas, kliento praradimas ir neigiamas atsiliepimas viešai.
Skundų diagnostika — tai sisteminis skundų skaitymas kaip duomenų rinkinio, ne atvejų sąrašo. Praktiškai: kas mėnesį išskiriamos penkios dažniausiai pasikartojančios priežastys, identifikuojamas proceso etapas, skiriamas atsakingas žmogus ir terminas sprendimui.
Sprendimas — tai reakcija į jau įvykusį skundą. Prevencija — sistemos kūrimas, kuris skundą sustabdo ankstesniame etape. Organizacijos, kurios turi tik sprendimo procesą be prevencijos, dirba su pastoviu krūviu, kuris niekada nemažėja.
Svarbiau stebėti tris rodiklius: ar skundų skaičius auga ar mažėja mėnesį po mėnesio, ar tos pačios priežastys kartojasi, ir kiek skundų išsprendžiama per pirmą kontaktą (FCR). Jei FCR žemiau 70% — tai sisteminis signalas.