Cik ātri jāreaģē uz klienta pieteikumu un kā izveidot lead response darba plūsmu

Uz klienta pieteikumu jāreaģē tik ātri, cik uzņēmums spēj sniegt jēgpilnu un konsekventu atbildi solītajā apkalpošanas laikā. Praktiski jānodala tūlītējs automātisks saņemšanas apstiprinājums no cilvēka pirmās jēgpilnās reakcijas. Augstas prioritātes pieteikumam darba laikā var noteikt 15 minūšu mērķi, konsultācijas pieprasījumam — divas darba stundas, bet vispārīgam jautājumam — vienu darba dienu. Tie ir sākuma SLA piemēri, nevis universāli nozares standarti.

Darba plūsmai jāfiksē saņemšanas laiks, prioritāte, atbildīgais, termiņš, kontakta mēģinājums, rezultāts un nākamais solis. Tad reakcijas ātrumu var vadīt, nevis cerēt, ka kāds pamanīs pieteikumu kopējā e-pasta kastē.

Ko īsti nozīmē ātri reaģēt

Lead response jeb reakcija uz potenciālā klienta pieteikumu ir process no pieteikuma saņemšanas līdz pirmajai situācijai atbilstošajai atbildei un reģistrētam nākamajam solim. Ātrums ir tikai viena procesa daļa. Atbildei jābūt arī pareizai, jānonāk pie piemērota darbinieka un jāpalīdz klientam virzīties tālāk.

Ir lietderīgi nodalīt trīs notikumus:

1. Saņemšanas apstiprinājums informē, ka pieteikums ir saņemts, un pasaka, kad gaidāma cilvēka atbilde. To parasti var nosūtīt automātiski.
2. Pirmais kontakta mēģinājums ir zvans, personalizēts e-pasts vai cita darbība. Neatbildēts zvans pats par sevi vēl nenozīmē, ka klients ir saņēmis jēgpilnu atbildi.
3. Jēgpilna reakcija atbild uz vajadzību, uzdod nepieciešamos precizējošos jautājumus vai piedāvā konkrētu nākamo soli, piemēram, sarunas laiku.

Ja visi trīs notikumi CRM sistēmā tiek apvienoti vienā statusā “atbildēts”, uzņēmums var uzrādīt labu reakcijas laiku, lai gan klients ir saņēmis tikai automātisku vēstuli. Tāpēc automātiskais apstiprinājums un cilvēka reakcija jāmēra atsevišķi.

Kā noteikt pieteikumu apstrādes SLA

SLA šajā kontekstā ir uzņēmuma iekšēja vienošanās par to, cik ilgā laikā noteikta veida pieteikumam jāsaņem konkrēta reakcija. Mērķi nevar izvēlēties tikai pēc vēlmes “atbildēt maksimāli ātri”. Jāņem vērā klienta nolūks, pakalpojuma sarežģītība, komandas darba laiks un faktiskā kapacitāte.

Par sākuma modeli var izmantot šādu sadalījumu:

Šie termiņi ir konfigurācijas piemērs, nevis apgalvojums par optimālu rezultātu visos uzņēmumos. Ja pārdošanas cikls ir ilgs un pieteikuma izvērtēšanai vajadzīgas tehniskas zināšanas, 15 minūšu laikā var būt saprātīgi tikai apstiprināt atbildīgā speciālista iesaisti. Savukārt klienta lūgums nekavējoties atzvanīt zaudē jēgu, ja tiek apstrādāts nākamajā dienā.

Precīzi jādefinē arī pulkstenis. Vai SLA skaita kalendāro laiku vai tikai darba stundas? Kad tas sākas — formas nosūtīšanas vai ieraksta izveides brīdī? Kas to aptur? Praktiska definīcija ir sākt mērījumu brīdī, kad sistēma saņem derīgu pieteikumu, un apturēt pēc personalizētas atbildes nosūtīšanas vai notikušas sarunas. Neatbildētu zvanu reģistrē kā mēģinājumu, bet neizmanto kā vienīgo pamatu jēgpilnas reakcijas SLA apturēšanai.

Pirms automatizācijas vienojieties par procesa noteikumiem

Automatizācija nevar droši sadalīt pieteikumus, ja nav zināms, pēc kādiem noteikumiem tas jādara. Vispirms jāatbild uz dažiem organizatoriskiem jautājumiem:

•          kuri kanāli rada pieteikumu un kur atrodas galvenais ieraksts;
•          kurš ir procesa īpašnieks, ja konkrēts pārdevējs nav pieejams;
•          kā atšķir steidzamu, kvalificētu un neatbilstošu pieteikumu;
•          kam piešķir pieteikumu pēc pakalpojuma, valodas, reģiona vai klienta tipa;
•          pēc cik ilga laika un kam sūta eskalāciju;
•          kā rīkojas ar dublikātiem, surogātpastu un nepilnīgiem datiem;
•          kuri statusi noslēdz pieteikuma apstrādi.

Jānosaka arī viens patiesības avots. Ja daļa informācijas atrodas e-pastā, daļa CRM un daļa darbinieka piezīmēs, nav iespējams uzticami noteikt ne atbildīgo, ne reakcijas laiku.

Lead response darba plūsma soli pa solim

1. Saņemiet un reģistrējiet pieteikumu

Mājaslapas formai, reklāmas platformai, kopējai e-pasta adresei vai citam kanālam jāizveido ieraksts vienā pārvaldības sistēmā. Saglabājiet saņemšanas laiku, avotu un sākotnējo saturu. Sistēmai jāpiešķir unikāls identifikators, lai atkārtota integrācijas izpilde neradītu vairākus vienādus pieteikumus.

Klientam nosūtiet īsu apstiprinājumu ar reālistisku atbildes termiņu. Tajā nav jāimitē personiska sarakste. Skaidri norādiet, ka ziņa ir automātiska, un paskaidrojiet, kas notiks tālāk.

2. Pārbaudiet derīgumu un dublikātus

Pirms pieteikuma nodošanas pārdevējam pārbaudiet obligātos laukus, kontaktinformācijas formātu un acīmredzamu surogātpastu. Salīdziniet e-pastu, tālruni, uzņēmumu un nesenos atvērtos ierakstus. Dublikātu nevajag vienkārši dzēst: tas var būt atkārtots klienta mēģinājums saņemt atbildi. Pievienojiet jauno aktivitāti esošajam ierakstam un, ja vajadzīgs, paaugstiniet prioritāti.

3. Piešķiriet prioritāti pēc skaidriem signāliem

Prioritāti labāk balstīt dažos pārbaudāmos signālos, nevis nesaprotamā kopējā punktu skaitā. Signāli var būt izvēlētais pakalpojums, lūgums atzvanīt, norādīts projekta termiņš, esoša klienta statuss vai konkrēta problēma, ko uzņēmums risina.

Trūkstošs budžets automātiski nenozīmē nekvalitatīvu pieteikumu, ja forma šo informāciju neprasa vai klients to vēl nevar pamatoti noteikt. Prioritātes noteikumam jāpalīdz izvēlēties apstrādes secību, nevis radīt nepamatotu spriedumu par cilvēku.

4. Piešķiriet vienu atbildīgo

Katram pieteikumam konkrētā brīdī vajadzīgs viens atbildīgais. Piešķiršanu var veidot pēc kompetences, klientu segmenta, teritorijas vai vienmērīgas slodzes. Round-robin jeb secīga sadale neder, ja tikai daļa komandas spēj atbildēt par konkrētu tehnisku pakalpojumu.

Jābūt arī rezerves noteikumam: ko sistēma dara atvaļinājuma, slimības vai pārslogotas rindas gadījumā. Paziņojums visai komandai bez individuāla īpašnieka bieži rada situāciju, kurā katrs pieņem, ka atbildēs kāds cits.

5. Iedarbiniet termiņu, atgādinājumus un eskalāciju

Pēc piešķiršanas sistēma aprēķina atbildes termiņu atbilstoši prioritātei un darba laikam. Atbildīgajam jāsaņem paziņojums darba vidē, kuru viņš patiešām izmanto. Ja termiņš tuvojas, var nosūtīt atgādinājumu; ja tas pārkāpts, pieteikumu eskalē vadītājam vai rezerves darbiniekam.

Eskalācija nedrīkst radīt paralēlus, nekoordinētus zvanus no vairākiem cilvēkiem. Mainot atbildīgo, sistēmā jābūt redzamam, kurš turpina darbu un kas jau ir izdarīts.

6. Sniedziet situācijai atbilstošu pirmo atbildi

Atbildes veidne var palīdzēt saglabāt struktūru, taču tai nevajadzētu aizvietot pieteikuma izlasīšanu. Labā pirmajā atbildē ir atsauce uz klienta vajadzību, tikai nepieciešamie precizējošie jautājumi un viens saprotams nākamais solis.

Ja pilna atbilde prasa speciālista izvērtējumu, pasakiet, kurš jautājumu pārņems un kad gaidāms turpinājums. Klientam nav jāgaida klusumā, kamēr uzņēmums iekšēji meklē informāciju.

7. Reģistrējiet iznākumu un nākamo soli

Pēc reakcijas jāatzīmē statuss “sazinājās” un jānorāda arī konkrētais rezultāts: kontakts noticis, atbilde nav saņemta, vajadzīga kvalifikācija, saruna rezervēta, pieteikums neatbilst vai klients lūdz sazināties vēlāk. Aktīvam pieteikumam vajadzīgs nākamās darbības datums un īpašnieks.

Bez šī soļa ātra pirmā atbilde var pārvērsties lēnā turpinājumā. Nosūtīts e-pasts vēl nenoslēdz lead response procesu. To noslēdz skaidra pāreja uz kvalifikāciju, pārdošanas iespēju, turpmāku saziņu vai pamatotu slēgšanu.

Kādi dati vajadzīgi sistēmā

Minimālam pieteikuma ierakstam pietiek ar laukiem, kuri atbalsta lēmumu vai mērījumu:

Nevāciet informāciju tikai tāpēc, ka sistēmā ir pieejams lauks. Vispārīgās datu aizsardzības regulas 5. pants nosaka personas datu minimizēšanas principu, 6. pants — apstrādes tiesiskuma pamatus, 13. pants — sniedzamo informāciju datu subjektam, bet 32. pants attiecas uz apstrādes drošību. Konkrētais tiesiskais pamats un glabāšanas termiņš jāizvērtē atbilstoši faktiskajam procesam.

Atbilde uz klienta paša pieprasījumu un vēlāka reklāmas ziņu sūtīšana nav automātiski viens un tas pats nolūks. Turpmākai komerciālai saziņai atsevišķi jāizvērtē piemērojamās datu aizsardzības un komerciālo paziņojumu prasības. Šis procesa apraksts neaizstāj juridisku izvērtējumu.

Kā mērīt, vai darba plūsma strādā

Vidējais reakcijas laiks viens pats var maldināt, jo daži ļoti ilgi gaidīšanas gadījumi pazūd aiz kopējā vidējā. Praktiskā pārskatā iekļaujiet:

•          mediānas laiku līdz pirmajai jēgpilnajai reakcijai;
•          90. procentili, kas parāda lēnāk apstrādāto pieteikumu daļu;
•          pieteikumu īpatsvaru, kas apstrādāti noteiktajā SLA;
•          pieteikumus bez atbildīgā vai bez nākamās darbības;
•          kontakta mēģinājumu, sasniegta kontakta un kvalificētu pieteikumu īpatsvaru;
•          rezervēto sarunu vai cita definēta nākamā soļa īpatsvaru;
•          rezultātus pa kanāliem, prioritātēm, darba laiku un atbildīgajiem.

Mediāna ir sakārtotas datu kopas viduspunkts. 90. procentile ir robeža, zem kuras atrodas 90% novērojumu; tā palīdz pamanīt procesa “garo asti”. Šie rādītāji jāskata kopā ar kvalitāti. Ja reakcijas laiks samazinās, bet pieaug kļūdaina maršrutēšana vai klienti nesaņem atbildi uz jautājumu, process nav kļuvis labāks.

Mērījumos izslēdziet testus un apstiprinātu surogātpastu, taču nedzēsiet neērtos gadījumus tikai tāpēc, ka tie pasliktina rezultātu. Atsevišķi uzskaitiet tehniskas kļūmes, dublikātus un pieteikumus ārpus darba laika. Pirms salīdzināšanas pārliecinieties, ka visiem periodiem izmantota viena SLA definīcija.

Vienkāršs plūsmas piemērs

Pieņemsim, ka pakalpojumu uzņēmums saņem konsultācijas pieprasījumu darba laikā. Sistēma izveido ierakstu, nosūta apstiprinājumu un pēc izvēlētā pakalpojuma piešķir pieteikumu attiecīgajam speciālistam. Cilvēka reakcijas termiņš ir divas darba stundas. Pirms termiņa atbildīgais saņem atgādinājumu, bet pēc pārkāpuma pieteikums nonāk pie komandas vadītāja.

Speciālists izlasa pieteikumu, nosūta personalizētu atbildi un piedāvā sarunas laiku. Sistēmā tiek atzīmēts jēgpilnas reakcijas laiks un nākamā darbība. Ja klients neatbild, turpmākie mēģinājumi notiek pēc iepriekš saskaņota ritma, nevis pēc katra darbinieka personiskās atmiņas.

Šādu plūsmu sākumā var īstenot ar formas, CRM un paziņojumu rīku konfigurāciju. Individuāla integrācija kļūst pamatota, ja ir vairāki avoti, sarežģīti maršrutēšanas noteikumi, liels kļūdu risks vai vajadzīga datu apmaiņa ar citām sistēmām.

Ierobežojumi un riski

Ātra reakcija neizlabo neskaidru piedāvājumu, neatbilstošu auditoriju vai formu, kas nesavāc lēmumam vajadzīgo informāciju. Tāpat automatizācija neatrisina komandas kapacitātes trūkumu. Ja SLA regulāri nav izpildāms, jāmaina slodzes sadale, darba laiks vai publiskais solījums.

Pārāk agresīvi atgādinājumi var radīt nevajadzīgu spiedienu uz klientu. Saziņas biežumam jāatbilst pieprasījuma būtībai, klienta izvēlētajam kanālam un piemērojamajām prasībām. Īpaši jāuzmanās, lai viens pieteikums integrācijas kļūdas dēļ neiedarbinātu vairākas vēstuļu vai zvanu virknes.

Jāparedz manuāls rezerves process, ja forma, CRM vai integrācija nedarbojas. Komandai jāzina, kur redzēt neapstrādātus pieteikumus, kā tos reģistrēt pēc sistēmas atjaunošanas un kā nepieļaut dubultu saziņu. Automatizācijas darbības jāžurnalē, bet piekļuve klientu datiem jāpiešķir tikai darbiniekiem, kuriem tā vajadzīga.

Kā ieviest procesu bez pārmērīgas sarežģīšanas

Sāciet ar vienu pieteikumu veidu, vienu atbildīgo komandu un dažiem statusiem. Divas līdz četras nedēļas reģistrējiet faktiskos reakcijas laikus un izņēmumus, pēc tam precizējiet SLA un maršrutēšanas noteikumus. Tikai tad pievienojiet sarežģītāku prioritizēšanu vai jaunus kanālus.

Pirms palaišanas pārbaudiet derīgu pieteikumu, nepilnīgus datus, dublikātu, pieteikumu ārpus darba laika, nepieejamu atbildīgo un integrācijas kļūmi. Katram scenārijam jābūt paredzamam īpašniekam un redzamam rezultātam.

Loģiski nākamie soļi ir sakārtot klienta pieteikuma formu, dokumentēt biznesa procesu pirms automatizācijas un izveidot manuālu rezerves procesu automatizācijas kļūdām.

Secinājums

Labs lead response process nav sacensība par mazāko minūšu skaitu. Tas ir izpildāms solījums klientam un pārbaudāma sistēma uzņēmumam. Ja katram pieteikumam ir prioritāte, atbildīgais, termiņš, kvalitatīva reakcija un nākamais solis, komanda var vienlaikus uzlabot ātrumu un saglabāt atbildes kvalitāti.