Kur dingsta svetainės užklausos ir kaip sutvarkyti jų perdavimą
Formos pateikimas tėra pradžia. Kaip atsekti užklausą iki CRM, atsakingo žmogaus ir atsakymo klientui, patikrinti klaidas ir sutvarkyti perdavimą.
Areza Digital
Kontaktų forma praneša, kad žinutė išsiųsta. Lankytojas uždaro naršyklės kortelę. Svetainės užkulisiuose laiškas, automatizuotas procesas ir kliento įrašas turėtų pasirūpinti, kad užklausa pasiektų reikiamą žmogų.
Būtent čia ji gali pasimesti, nors pačioje svetainėje niekas neatrodo sugedę.
Pradėkite nuo paprasto klausimo: ar galite atsekti vieną užklausą nuo formos pateikimo iki konkretaus žmogaus atsakymo? Jei tam reikia tikrinti tris pašto dėžutes ir klausinėti kolegų, perdavimo procesą verta sutvarkyti.
Gauti žinutę ir ja pasirūpinti yra skirtingi dalykai
Įsivaizduokime nedidelę konsultacijų įmonę, naudojančią svetainės formą, automatizavimo įrankį ir CRM. Tai iliustracinis pavyzdys, ne kliento projekto aprašymas.
Forma perduoda žinutę serveriui. Serveris paleidžia automatizuotą procesą. Šis ieško esamos įmonės, sukuria užklausą ir priskiria ją klientą prižiūrinčiam žmogui. Tuomet kažkas atsako.
Tai atskiri įvykiai. Sėkmingas pirmasis žingsnis nepatvirtina, kad įvyko paskutinis. Net HTTP atsakymas 202 Accepted reiškia tik tai, kad užklausa priimta apdoroti. Jis nepatvirtina, kad apdorojimas sėkmingai baigtas. Šį skirtumą paaiškina MDN.
Nuspręskite, ką svetainė iš tikrųjų gali patvirtinti. Jeigu žinutė saugiai išsaugota, bet dar laukia priskyrimo, praneškite, kad ją gavote. Nerašykite, kad ją jau peržiūrėjo žmogus, ir nežadėkite atsakymo termino, kurio komanda nėra sutarusi laikytis.
Kiekvienas perdavimas turi palikti patikrinamą įrašą
Viename lape nubraižykite visą kelią. Prie kiekvieno žingsnio nurodykite atsakingą sistemą ir tai, kas patvirtins jo sėkmę. Įtraukite ir bendras pašto dėžutes, ir rankinį darbą: svarbus dabartinis procesas, o ne jo gražesnė versija.
Braukite arba slinkite, kad palygintumėte.
| Žingsnis | Ką patikrinti | Kas turi vykti nesėkmės atveju |
|---|---|---|
| Gauti žinutę | Išsaugota užklausa su identifikatoriumi ir gavimo laiku | Išlaikyti galimybę ją atkurti; jei neišsaugota, lankytojui aiškiai pranešti apie nesėkmę |
| Sukurti užklausą | CRM įrašas, susietas su pateikimo identifikatoriumi | Perkelti užklausą į pakartotinio apdorojimo arba peržiūros eilę |
| Priskirti | Konkretus atsakingas žmogus arba prižiūrima nepriskirtų užklausų eilė | Pranešti už paskirstymą atsakingam žmogui |
| Patvirtinti gavimą | Užfiksuotas bandymas išsiųsti patvirtinimą ir jo rezultatas | Pažymėti pristatymo klaidą, neprarandant pačios užklausos |
| Atsakyti | Su užklausa susietas žmogaus atsakymas | Rodyti užklausas, kurioms neatsakyta per komandos sutartą laiką |
Svarbiausia čia yra ryšys tarp įrašų. Pilna pašto dėžutė ir pilnas CRM kontaktų sąrašas savaime neparodo, ar kiekviena užklausa pasiekė kitą etapą.
Techniniuose žurnaluose palikite tik tai, ko reikia priežiūrai: užklausos identifikatorių, etapą, laiką ir klaidos tipą. Vien dėl patogesnės paieškos nekopijuokite visos žinutės ir asmens duomenų į kiekvieną perspėjimą.
Tikrinkite svetainėje veikiantį procesą, ne vien bandomąjį paleidimą
Jei naudojate n8n, patikrinkite, į kurį „webhook“ adresą kreipiasi svetainė. Šio įrankio „Webhook“ mazgas turi atskirus testavimo ir veikiančios aplinkos adresus. Atsakymą taip pat galima grąžinti iš karto arba palaukus vėlesnių proceso žingsnių. Nuo šių nustatymų priklauso, ką įrodo sėkmingas formos atsakymas. Plačiau n8n „Webhook“ dokumentacijoje.
Naudingas patikrinimas prasideda paskelbtoje svetainės formoje ir baigiasi galutiniame įraše. Naudokite aiškiai pažymėtus testinius duomenis. Suraskite atitinkamą proceso vykdymą bei CRM įrašą ir paprašykite numatyto gavėjo patvirtinti, kad užklausą mato ir gali su ja dirbti.
Žalia varnelė proceso redaktoriuje nėra patikrinimo pabaiga. Peržiūrėkite ir laukų reikšmes. Įrašas be žinutės, susietas su netinkama įmone ar paliktas be atsakingo žmogaus, nėra tinkamai perduota užklausa.
Sutarkite, kas atsakingas, ir numatykite išimtis
„Nusiųsti pardavimams“ nėra priskyrimo taisyklė. Lieka neaišku, kuriam žmogui, kas jį pavaduoja ir kas stebi pašto dėžutę, kol užklausa dar nepriskirta.
Užrašykite trumpą sprendimų lentelę. Esamų klientų užklausos gali keliauti juos prižiūrinčiam žmogui. Naujos gali būti skirstomos pagal paslaugą ar regioną. Jei nė viena taisyklė neranda gavėjo, užklausa turi patekti į matomą eilę, už kurios peržiūrą atsako konkretus žmogus.
Šiam atsarginiam keliui skirkite tiek pat dėmesio, kiek pagrindiniam. Išbandykite įmonę, kurios CRM dar nėra. Patikrinkite nebeaktyvų gavėją. Pateikite formą nepasirinkę paslaugos. Neprivalomas formos laukas neturėtų tyliai tapti būtina sąlyga automatizuotame procese.
Pradėkite nuo kelių taisyklių, kurias komanda supranta ir gali prižiūrėti. Daugiau pridėkite tik tada, kai tam yra aiški darbo priežastis.
Pakartotinis siuntimas neturi kurti dublikatų
Laukiant atsakymo gali baigtis skirtas laikas, nors gavusi sistema jau spėjo išsaugoti duomenis. Aklai pakartojus veiksmą atsiras dar vienas įrašas. Visai nebandant pakartoti, žinutė gali likti neapdorota.
Pirmajam bandymui ir jo pakartojimams naudokite tą patį pateikimo identifikatorių. Prieš kurdami galutinį įrašą patikrinkite, ar šis pateikimas jau apdorotas. Tikslas paprastas: pakartotinai perduotas tas pats įvykis neturi sukelti naujo verslo veiksmo. Techniškai tai vadinama idempotentiškumu.
Priimanti sistema taip pat turi užtikrinti, kad vienam pateikimo identifikatoriui būtų sukurtas tik vienas įrašas. Jei patikrinimas ir išsaugojimas atliekami atskirai, vienu metu atėjusios užklausos vis tiek gali sukurti dublikatus. Kai sistema turi dokumentuotą idempotentiškumo mechanizmą, naudokite jį. Vienas pavyzdys – „Stripe“ API, tačiau konkrečios taisyklės priklauso nuo sistemos.
Vien el. pašto adreso tam nepakanka. Tas pats klientas gali pateikti dvi skirtingas, pagrįstas užklausas. Jas reikia išsaugoti atskirai, o pakartotinį vienos užklausos siuntimą susieti su jos pradiniu identifikatoriumi.
Atskirkite laikinus sutrikimus nuo problemų, kurioms reikia žmogaus. Trumpas paslaugos neveikimas gali būti priežastis pabandyti dar kartą. Neteisingai susietą lauką reikia pataisyti. Nustatykite bandymų ribą, palikite nesėkmingus įrašus matomus ir sutarkite, kas jais pasirūpins ją pasiekus.
Prieš baigdami išbandykite ir klaidų atvejus
Šiuos scenarijus tikrinkite saugioje testavimo aplinkoje. Po to su testiniais duomenimis patikrinkite įprastą kelią veikiančioje svetainėje. Neatjunkite naudojamo CRM vien tam, kad imituotumėte sutrikimą.
Braukite arba slinkite, kad palygintumėte.
| Patikrinimas | Laukiamas rezultatas |
|---|---|
| Teisinga nauja užklausa | Viena užklausa, teisingi duomenys ir matomas atsakingas žmogus |
| Tas pats įvykis perduotas du kartus | Viena užklausa, susieta su pradiniu pateikimo identifikatoriumi |
| Testo metu CRM nepasiekiamas | Atkuriamas įrašas, ribotas pakartojimas ir matoma klaidos būsena |
| Neteisingas el. pašto adresas | Aiški lauko klaida prieš priimant formą; likęs žinutės tekstas išsaugomas |
| Netinka nė viena priskyrimo taisyklė | Užklausa patenka į prižiūrimą bendrą eilę |
| Nepavyksta pristatyti gavimo patvirtinimo | Išsaugota užklausa lieka pasiekiama, o pristatymo problema užfiksuojama |
Svarbi ir lankytojo patirtis. Klaidos pranešimas turi padėti suprasti ir pataisyti problemą, o sėkmės pranešimas – patvirtinti rezultatą. Apie tai rašoma W3C formų pranešimų gairėse.
Stebėkite perdavimą, ne vien mygtuko paspaudimą
Formos pateikimo įvykis analitikoje padeda suprasti svetainės naudojimą. Jis nepatvirtina, kad klientui kas nors atsakė.
Palyginkite gautų pateikimų skaičių su galutiniais įrašais. Stebėkite laiką iki priskyrimo, laiką iki pirmojo žmogaus atsakymo ir seniausios neišspręstos klaidos amžių. Peržiūros dažnį derinkite prie užklausų kiekio. Jei jų nedaug, kiekvienos žinutės patikrinimas gali būti naudingesnis už naują suvestinę.
Gali paaiškėti, kad forma veikia gerai, o trūksta tik žmogaus nepriskirtoms užklausoms. Arba priskyrimo taisyklės veikia, tačiau pakeistas CRM laukas sustabdė įrašų kūrimą. Pirmiausia sutvarkykite konkrečią spragą.
Jei svetainės, pašto dėžutės ir CRM darbą per daug laiko žmonių atmintis, galime padėti sujungti sistemas ir sutvarkyti pardavimo užklausų perdavimą. Atsineškite vieną neseną užklausą ir kelią, kurį ji turėjo nueiti. Nuo to verta pradėti.