Rezervacijų sistema su CRM: kodėl neužtenka kalendoriaus

Kalendoriaus įrašas nėra pardavimo įrašas

Kalendorius atsako tik į vieną klausimą: ar tuo metu žmogus laisvas. Jis nežino, kas užsiregistravo, ko tas žmogus nori, kiek kartų jau kalbėjotės ir kas buvo pažadėta praėjusį kartą. Jis nežino net to, ar susitikimas apskritai įvyko.

Pardavimuose to neužtenka, nes pardavimas yra seka: užklausa, pokalbis, pasiūlymas, sprendimas. Rezervacija yra tos sekos pradžia, o kalendorius ją užrašo taip, tarsi tai būtų pabaiga. Praėjus porai savaičių, įrašas nuslenka į praeitį, o kartu su juo nuslenka ir viskas, ką apie tą žmogų žinojote.

Todėl klausimas, ar rezervacijų sistemą jungti su CRM, iš tikrųjų yra klausimas, kur gyvena pardavimo istorija: sistemoje ar žmogaus galvoje.

Kas dingsta, kai rezervacija lieka tik kalendoriuje

Penki dalykai dingsta dažniausiai, ir jie kartojasi tiek mažose, tiek didesnėse komandose.

Kontaktas neįvestas. Žmogus formoje paliko vardą, el. paštą ir telefoną, bet CRM apie jį nieko nežino. Duomenis kažkas turi persirašyti ranka. Praktikoje tai daroma vakare, prieš savaitės aptarimą arba nedaroma visai.

Sandorio nėra. Susitikimas suplanuotas, bet pardavimų lentoje nauja kortelė neatsirado. Vadovas, žiūrėdamas į stadijas, mato mažiau darbo, nei jo iš tikrųjų yra, o prognozė tampa spėjimu.

Istorija išsibarsčiusi. Registracijos laiškas guli kliento pašto dėžutėje, priminimas išsiųstas iš kitos sistemos, patvirtinimas atėjo į asmeninę dėžutę, atšaukimas liko kalendoriaus pranešime. Kai po mėnesio reikia suprasti, kas vyko, tenka rinkti gabalus iš kelių vietų.

Neaišku, iš kur atėjo susitikimas. Jei visi registruojasi per tą pačią nuorodą, niekas negali pasakyti, ar žmogus atėjo iš LinkedIn, iš svetainės, ar iš šaltų laiškų. Sprendimai apie kanalus tada priimami iš nuojautos.

Po neatvykimo niekas nesusisiekia. Neįvykęs susitikimas kalendoriuje atrodo lygiai taip pat, kaip įvykęs. Niekas neuždeda užduoties, niekas neperskambina, o žmogus, kuris pats prašė laiko, tyliai iškrenta iš proceso.

Rankinis perrašinėjimas atrodo pigus, nes vienas kontaktas suvedamas greitai. Kaina matoma ne ten. Ji matoma tada, kai pardavėjas prieš pokalbį neranda konteksto, kai ataskaitoje trūksta dalies susitikimų ir kai atšaukimo priežastis, kurią klientas parašė savo žodžiais, niekur neišlieka.

Sujungtas kelias: nuo laisvo laiko iki sandorio

Sujungtoje sistemoje rezervacija yra ne įrašas, o įvykis, kuris paleidžia kelis veiksmus iš karto.

Klientas paspaudžia viešą nuorodą ir mato tik tuos laikus, kurie realiai laisvi. Užimtumas skaičiuojamas iš Google kalendoriaus ir iš jau esamų rezervacijų, o dvigubas užsakymas blokuojamas duomenų bazės lygiu, ne mandagiu prašymu palaukti. Kiekvienas komandos narys pats prijungia savo Google kalendorių, todėl laisvi langai rodomi pagal tikrą, o ne deklaruotą darbotvarkę.

Užpildęs trumpą formą, klientas gauna patvirtinimą, o susitikimas atsiranda jį priimančio komandos nario Google kalendoriuje su Google Meet nuoroda. Tuo pačiu metu kontaktas ir sandoris atsiranda CRM, todėl pardavimų lentoje susitikimas matomas iš karto, o ne tada, kai kas nors prisimena jį suvesti.

Toliau viskas kaupiasi vienoje vietoje: priminimai el. paštu ir SMS žinutėmis, kliento patvirtinimas mygtuku „Patvirtinu, dalyvausiu“, perkėlimas į kitą laiką ir atšaukimas kartu su priežastimi, kurios prašoma, kai atšaukiama arti susitikimo. Ta priežastis lieka užrašyta kliento žodžiais, todėl vėliau galima pažiūrėti, kokios priežastys kartojasi ir ką verta keisti pasiruošime.

Šaltinis yra laukas, o ne spėjimas

Jei norite žinoti, kuris kanalas atveda susitikimus, šaltinį reikia užrašyti tuo momentu, kai rezervacija įvyksta. Vėliau to atkurti nebeįmanoma.

Paprasčiausias būdas yra turėti kelis kalendorius su atskiromis viešomis nuorodomis: viena eina į LinkedIn žinutes, kita į svetainės mygtuką, trečia į šaltų laiškų parašą. Kai susitikimas užsakomas, kartu matyti ir tai, per kurią nuorodą žmogus užsiregistravo, todėl kanalų vertinimas nebepriklauso nuo atminties.

Priminimų tekstai turėtų būti valdomi ten pat. Automatikų redaktoriuje matyti, kada, kokiu kanalu, kam ir koks tekstas siunčiamas, yra SMS ilgio skaitiklis ir mygtukas „Testuoti sau“. Du techniniai dalykai, kuriuos verta žinoti iš anksto: lietuviški diakritikai SMS žinutėje sumažina segmentą nuo 160 iki 70 simbolių, todėl šablonai rašomi be jų, o SMS mygtuko turėti negali, todėl vietoj jo siunčiama trumpa nuoroda tam pačiam patvirtinimo veiksmui. Vardinį SMS siuntėją su Lietuvos operatoriais reikia suderinti iš anksto, tokia tvarka galioja nuo 2023 metų liepos, ir tai daroma paleidimo metu kartu su klientu.

Integracijos per tarpines priemones veikia, bet reikalauja priežiūros

Sujungti rezervacijas su CRM galima ir per tarpinę automatizavimo priemonę. Tai normalus sprendimas, ypač kai CRM retas arba kai reikia papildomos logikos. Bet grandinėje atsiranda dar viena dalis, kurią kažkas turi prižiūrėti.

Praktikoje tokios grandinės lūžta tyliai. Pasikeičia lauko pavadinimas CRM ir susitikimai nustoja patekti į sistemą, bet niekas apie tai nesužino ilgą laiką. Pasibaigia prieigos raktas. Tas pats žmogus, užsiregistravęs iš dviejų el. pašto adresų, sukuria du įrašus, nes suvienodinimo taisyklė buvo aprašyta tik pusiau. Klaidos pranešimas atkeliauja į dėžutę žmogaus, kuris jau nebedirba įmonėje.

Todėl prieš renkantis verta atsakyti į du klausimus: kas konkrečiai pastebės, jei ryšys nutrūks, ir per kiek laiko. Jei atsakymo nėra, tarpinė grandis anksčiau ar vėliau taps duomenų skyle.

Sąžiningai apie rinką: dauguma šių dalykų vienaip ar kitaip sudėliojami ir su kitais įrankiais. Calendly Standard plane, pavyzdžiui, SMS priminimai yra, o dalis planų turi jungčių su kitomis sistemomis. Skirtumas dažniausiai ne tas, ar funkcija egzistuoja, o kiek atskirų grandžių reikia, kad rezervacija, priminimas, patvirtinimas ir sandoris gyventų viename kelyje, ir kas tas grandis prižiūri.

Ką patikrinti savo procese šiandien

Trumpas sąrašas, kurį galima pereiti kartu su komanda.

1. Paimkite tris praėjusios savaitės susitikimus ir patikrinkite, ar kiekvienas turi kontaktą CRM.
2. Patikrinkite, ar kiekvienas iš jų turi sandorį ir ar tas sandoris stovi teisingoje stadijoje.
3. Atsakykite, iš kurio kanalo atėjo kiekvienas iš jų. Jei tenka spėti, šaltinis niekur neužrašomas.
4. Raskite vieną atšauktą susitikimą ir pažiūrėkite, ar kur nors išliko atšaukimo priežastis.
5. Raskite vieną neįvykusį susitikimą ir pažiūrėkite, kas su tuo žmogumi buvo padaryta po to.
6. Suskaičiuokite, kiek atskirų sistemų reikia atidaryti, kad surinktumėte vieno kliento istoriją.
7. Nuspręskite, kas jūsų komandoje atsakingas už tai, kad rezervacijos toliau patektų į CRM.

Jei bent trys punktai lieka be atsakymo, problema yra ne pardavėjų drausmė. Problema ta, kad rezervacija ir CRM gyvena atskirai, o tarp jų stovi žmogus su rankiniu darbu.

Verta žinoti ir tai, ką paleidimas realiai reiškia. Automatinio importo iš Calendly nėra: kalendoriai, darbo valandos ir tekstai suvedami kartu su klientu. Prijungiant Google rodomas įspėjimo langas, nes programa dar nėra praėjusi Google verifikacijos. Microsoft 365 ir Outlook kol kas nepalaikomi. Duomenys laikomi Europos Sąjungoje.