SaaS DUK puslapiai yra konversijos darbinis arkliukas, kurio agentūros nepastebi

Summary

Dauguma SaaS DUK puslapių yra sukurti iš palaikymo bilietų, o tai reiškia, kad jie atsako į klausimus iš žmonių, kurie jau nusipirko, ir ignoruoja objekcijas, kurios sustabdo potencialius klientus nuo pirkimo. Šis straipsnis apverčia DUK iš paleidimo popamokinio apmąstymo į pardavimo turtą. Parašytas agentūroms, kuriančioms svetaines keliems klientams, jis apima kartotinį procesą: surinkite objekcijas iš pardavimų komandos, sugrupuokite klausimus pagal pirkimo etapą, parašykite atsakymus, kurie yra pakankamai išsamūs, kad užbaigtų paiešką, suporuokite kiekvieną objekciją su konkrečiu socialiniu įrodymu ir palaikykite puslapį kas ketvirtį. Mito ir realybės formatas parodo, kas iš tikrųjų veikia, su praktiniu pavyzdžiu kiekviename skyriuje. Rezultatas – DUK puslapis, kuris sumažina palaikymo krūvį ir padidina tikimybę, kad potencialus klientas užsiregistruos.

Dauguma patarimų apie SaaS DUK puslapius prasideda neteisingoje vietoje. Jie traktuoja juos kaip paleidimo valymą – vietą, kurioje galima palikti atsakymus į palaikymo bilietus, kad palaikymo komanda nebekartotų savęs. Ši sistema yra priežastis, kodėl jūsų kliento DUK puslapis beveik nieko nedaro verslui. Kas iš tikrųjų veikia: DUK puslapis yra vienas iš nedaugelio puslapių, kurį potencialus klientas aplanko po to, kai jau nusprendė, kad gali pirkti. Tai sprendimo etapo puslapis, o ne dokumentacijos puslapis. Jis turėtų būti sukurtas siekiant pašalinti objekcijas, kylančias tarp lankytojo ir registracijos, ir jis nusipelno tokio paties strateginio dėmesio kaip ir kainodaros puslapis.

Jei dirbate agentūroje, problema yra dar aštresnė. Kiekvienas klientas yra skirtingas: skirtingas produktas, skirtingas pirkėjas, skirtinga palaikymo istorija. Tačiau jūs turite sukurti kažką, kas veiktų, neskaičiuodami nuo nulio kiekvieną kartą. Pagunda yra nukopijuoti paskutinio DUK, kurį sukūrėte, struktūrą. Tai veikia iki tol, kol neveikia, nes objekcijos, kurios yra svarbios fintech klientui, nėra tos, kurios svarbios komandinio bendradarbiavimo klientui. Sistema turi būti ta pati; turinys turi būti skirtingas. Toliau pateikiamas mitų griovimas yra ta sistema. Pagrindinis modelis yra paprastas: tikėkitės, kad DUK parduos, o ne tik informuos. Tai pakeičia, kaip renkate klausimus, kaip juos grupuojate, kiek ilgas kiekvienas atsakymas ir ką dedate šalia.

Pradėkite nuo pardavimo, o ne nuo palaikymo bilieto

Pradėkite paklausdami savo kliento pardavimų komandos paskutinių penkių sandorių, kurie nutilo. Klausimai, kurie sustabdė tuos sandorius, yra pirmieji dešimt klausimų, į kuriuos jūsų DUK puslapis turėtų atsakyti. Dauguma DUK puslapių yra sukurti iš palaikymo bilietų – klausimų iš žmonių, kurie jau nusipirko. Klausimai, kurie iš tikrųjų blokuoja pardavimus, ateina iš žmonių, kurie dar nepirko, ir jie paprastai yra apie migraciją, saugumą, kainodarą ir kas nutinka pasibaigus bandomajam laikotarpiui.

Štai kaip tai atrodo praktiškai. Darbo eigos automatizavimo klientas atėjo pas mus su DUK, pilnu tokių klausimų kaip "Kaip iš naujo nustatyti slaptažodį?" ir "Kurios naršyklės palaikomos?" Puslapis buvo techniškai naudingas ir komerciškai inertiškas. Taigi paklausėme pardavimų komandos, ką jie girdi pralaimėtuose sandoriuose. Paaiškėjo, kad potencialūs klientai klausė, ar įrankis gali pakeisti jų dabartinę skaičiuoklę, ar migracijai reikės IT, ir ar pardavėjo kainoraštis atitinka tai, ką sąskaitų išrašymas iš tikrųjų apmokestins. Perkūrėme DUK aplink tas tris objekcijas, kiekvieną su trumpu atsakymu ir nuoroda į atitinkamą puslapį. Slaptažodžio atstatymo klausimai perkelti į palaikymo centrą. Puslapis tapo uždarymo įrankiu, o ne pagalbos tarnyba.

Kai atliekate šį interviu, nesitenkinkite "jie klausia apie kainodarą". Paklauskite tikslios formuluotės. "Ar kainodara yra už vartotoją ar už darbo sritį?" yra veiksminga. "Jie klausia apie kainodarą" nėra. Taip pat paklauskite, ką konkurentas daro, ko klientas negali lengvai atkartoti – tai paprastai iškelia objekcijas, kurių pardavimų komanda jau pavargo klausytis. Įdėkite jas pačioje puslapio viršuje.

Tai viena vieta, kur SaaS svetainės kūrimas iš vidaus atsiperka: pradedate nuo klausimų, kuriuos užduoda realūs pirkėjai, tada kuriate svetainę aplink juos. Atsargumo žodis: negalite visiškai praleisti palaikymo klausimų. Kai kurie lankytojai yra esami klientai. Tačiau pagrindinis puslapio plotas turėtų atitekti klausimams, kurie kyla prieš pirkimą, o ne po jo. Jei reikia palikti keletą palaikymo klausimų puslapyje, perkelkite juos į pačią apačią po aiškiai pažymėtu "Esami klientai" antrašte. Taip aptarnaujate abi auditorijas, neleisdami palaikymo klausimams dominuoti. Naudingas būdas atlikti interviu – išsiųsti pardavimų komandai paprastą raginimą: išvardykite kiekvieną klausimą, kurį potencialus klientas uždavė praėjusį mėnesį ir į kurį turėjote atsakyti rankiniu būdu. Gausite du sąrašus. Klausimai, kuriems reikia sprendimo, yra DUK medžiaga; tie, į kuriuos galima atsakyti nuoroda, priklauso dokumentacijai.

Ilgis nėra išsamumas

Principas, kurio verta laikytis, yra aktualumas pagal poziciją. Lankytojas, praėjus trims minutėms nemokamo bandomojo laikotarpio, turi kitokį klausimą nei pirkimų vadovas, vertinantis įrankį. Jei DUK yra vienas abėcėlinis sąrašas, pirkimų vadovas turi persijoti per "Kaip pakeisti avatarą?" kad rastų "Kaip tvarkote duomenų buvimo vietą?" Dauguma lankytojų to nedarys. Jie išeis.

Vienas klientas, projektų valdymo SaaS, turėjo DUK, kuris buvo abėcėlinis ir tęsėsi kelis puslapius. Perkėlėme jį į keturias grupes: "Prieš pradedant" (ką tai daro, kaip palyginti), "Bandomojo laikotarpio metu" (sąranka, apribojimai), "Pirkimas" (kainodara, sąskaitų išrašymas, saugumo peržiūros) ir "Po pirkimo" (mokėjimo pakeitimai, palaikymas). Pirkimo grupė atsidūrė pirmoji, nes ten buvo prarandami pinigai. Žodžių skaičius labai nepasikeitė, bet puslapis iš sąrašo tapo vadovu.

Kiekvienoje grupėje naudokite vieną iš dviejų rikiavimo taisyklių. Jei produktas turi aiškų pirkimo būdą, rikiuokite pagal rimtumą: klausimas, kuris visiškai sustabdo sandorį, yra pirmas. Jei produktas neturi akivaizdžios sekos, rikiuokite pagal dažnumą – bet tik grupės viduje, ne visame puslapyje. Svarbu tai, kad lankytojas galėtų rasti jį dominantį klausimą neskaitęs visko. Puslapio viršuje naudokite nuorodas, kad pirkimų vadovas galėtų peršokti tiesiai į "Pirkimas", o bandomojo laikotarpio vartotojas – į "Bandomojo laikotarpio metu". Įprastoje SaaS svetainėje šios dvi grupės sukuria daugiausiai registracijų ir daugiausiai prarastų sandorių, todėl jos yra puslapio viršuje.

Kalbant apie kainodaros klausimus, ta pati logika, kurią taikytumėte konversijoms skirtam kainodaros puslapiui, galioja ir DUK viduje: pirmiausia pateikite sprendimui svarbias detales, tada pagrindimą, tada nuorodą. Neverskite lankytojo ieškoti norimo plano kainos. O Pirkimo grupėje vėl pagalvokite apie seką. Saugumą ir atitiktį įdėkite prieš mokėjimo būdus, nes saugumo peržiūra dažnai yra vartai, sustabdantys vertinimą, kol dar nekilo mokėjimo klausimas.

Mitai	Realybė
DUK egzistuoja atsakyti į klausimus	DUK egzistuoja pašalinti pirkimo objekcijas
Ilgesnis DUK reiškia išsamesnį	Skenuojamas, sugrupuotas DUK pranoksta ilgą sąrašą
Atsakymai turėtų būti trumpi	Atsakymai turėtų būti pakankamai išsamūs, kad užbaigtų paiešką
Socialinis įrodymas priklauso tik pagrindiniam puslapiui	Įrodymas, padėtas šalia objekcijos, konvertuoja geriau
DUK yra paleidimo pristatomasis dokumentas	DUK yra gyvas dokumentas su peržiūros periodiškumu

Per trumpo atsakymo kaina

Štai prieš ir po, kurį naudojame su klientais, kai jie prieštarauja "ilgiems" atsakymams.

Prieš: "Ar palaikote SSO? Taip, palaikome."

Po: "SSO pasiekiamas Pro plane ir aukštesniuose. Galite jį įgalinti, kai esate darbo srities savininkas, per Nustatymai > Sauga. Štai nuoseklus vadovas. Jei jūsų komanda naudoja Okta arba Azure AD, abu palaikomi."

Antrasis atsakymas yra ilgesnis, bet jis taip pat yra galutinis. Lankytojas nustoja ieškoti, nes atsakymas numato tolesnius klausimus. Toks rašymas atrodo paprastas, bet reikalauja žinoti, kokie iš tikrųjų yra tolesni klausimai. Lengviausias būdas juos rasti – pažvelgti į dažniausius palaikymo bilietus kiekvienoje funkcijų srityje ir įtraukti atsakymus į DUK.

Naudojama struktūra: tiesioginis atsakymas, vienas konteksto sakinys, tada nuoroda. Paryškinkite tiesioginį atsakymą, kad skaitytojas jį iškart pamatytų. Jei turite ekrano kopiją, įdėkite ją po konteksto, o ne prieš. Nelaidokite atsakymo pastraipoje, aprašančioje funkciją. Tai tas pats principas, dėl kurio tokių įmonių kaip Stripe ir Twilio API dokumentacija išsiskiria: galite patekti, gauti atsakymą ir išeiti. Mes giliau nagrinėjame šį standartą savo vadove rašant SaaS API dokumentaciją, kurią kūrėjai iš tikrųjų naudoja. Atsargumo žodis: "išsamus" nereiškia "ilgas dėl ilgumo". Teksto siena vis tiek yra teksto siena.

Taip pat yra tono klausimas. Per trumpas atsakymas linkęs skambėti sausai ar net nemandagiai; per ilgas atsakymas skamba gynybiškai. Idealu yra atsakymas, kurį kompetentingas palaikymo žmogus pateiktų el. laiške: tiesioginis atsakymas, trumpas paaiškinimas ir kitas žingsnis. Jei jūsų kliento palaikymo komanda rašo naudingus el. laiškus, paprašykite kelių ir naudokite juos kaip modelį. Jei ne, galite patys parašyti modelį ir leisti palaikymo komandai jį pataisyti. Tai taip pat geras būdas gauti palaikymo komandos pritarimą, nes DUK pradeda atrodyti kaip jų geriausi el. laiškai, o ne kaip korporacinis dokumentas.

Suporuokite objekciją su jos įrodymu

Paimkite kiekvieną objekciją savo kliento DUK ir užduokite vieną klausimą: koks socialinio įrodymo elementas tai neutralizuotų? El. parašo klientas turėjo stiprią atsiliepimų sekciją pagrindiniame puslapyje. Bet kai pažvelgėme į DUK saugumo klausimą – "Kaip saugote mano dokumentus?" – atsakymas buvo sausas atitikties kalbos tekstas. Pagrindinio puslapio atsiliepimas iš teisės komandos, sakantis "mūsų atitikties komanda juos patvirtino per mažiau nei dieną", buvo būtent tas patvirtinimas, kurio reikėjo atsakymui.

Pradėjome poruoti kiekvieną objekciją su įrodymu: saugumo klausimas gavo atitikties atsiliepimą, kainodaros klausimas gavo citatą iš kliento, kuris perėjo iš konkurento, migracijos klausimas gavo eilutę apie klientą, kuris perkėlė visą įmonę be prastovų. DUK nustojo būti atskiras puslapis ir tapo pasiūlymo dalimi.

Atsargumo žodis čia – aktualumas. Logotipų siena šalia DUK mažai ką prideda; atsiliepimas, kuris tiesiogiai sprendžia objekciją, turi svorio, ypač kai jame nurodomas jį pateikiančio asmens vaidmuo. Jei jūsų klientas dar neturi tokio įrodymo, pradėkite jį rinkti iš tų pačių pardavimų skambučių, iš kurių kyla objekcijos. Šie du turtai ateina iš to paties šaltinio. Kai turite atsiliepimą, išskirkite vieną sakinį, atitinkantį DUK klausimą. Nereikia visos citatos; pakanka vieno konkretaus sakinio. Paprašykite pardavimų komandos pažymėti, kai sandoris uždaromas, ar klientas paminėjo konkrečią problemą. Ta problema yra būsimas DUK klausimas, o paties kliento žodžiai yra geriausias atsakymas.

Yra antras, mažiau akivaizdus įrodymo tipas: produkto įrodymas. Jei potencialus klientas klausia "Ar galiu eksportuoti savo duomenis?" stipriausias atsakymas apima eksporto ekrano ekrano kopiją, o ne tik sakinį "taip". Jei jie klausia "Kiek laiko trunka bandomasis laikotarpis?" stipriausias atsakymas apima eilutę apie tai, kas nutinka jam pasibaigus. Ekrano kopijos ir trumpi GIF failai čia veikia, nes jie parodo, o ne teigia. Tai taip pat vieta, kur DUK susijungia su funkcijų pristatymu: toks klausimas kaip "Kuo tai skiriasi nuo skaičiuoklės?" turėtų vesti į svetainės skyrių, kuriame demonstruojamas skirtumas, o ne į palyginimų teksto sieną.

DUK yra procesas, o ne paleidimo pristatomasis dokumentas

Ilgalaikis principas agentūrai yra tai, kad DUK puslapis yra procesas, o ne puslapis. Kliento produktas keičiasi kiekvieną mėnesį; naujos objekcijos atsiranda su kiekvienu kainodaros pakeitimu, kiekvienu nauju konkurentu, kiekvienu ketvirčiu. Puslapis, kurį paleidžiate sausį, kovą jau yra spėlionės. Agentūros, kurios tai daro kartotinai, įtraukia lengvą palaikymo ritmą į savo darbą.

Po paleidimo nustatykite ketvirtinę peržiūrą, kurioje nagrinėjate tris įvestis: naujus palaikymo bilietus, klausimus iš pardavimų skambučių ir produkto pakeitimus. Padalinkite peržiūrą į du veiksmus. Pirma, pašalinkite klausimus, kurie nebeaktualūs. Antra, pridėkite klausimus, kurie atsirado per pastarąsias 90 dienų. Tam nereikia turinio stratego. Reikia įpročio.

Mes tai įdiegėme vienam klientui paprašydami palaikymo vadovo pažymėti kiekvieną bilietą, į kurį svetainė galėjo atsakyti. Po kelių ketvirčių palaikymo vadovas pradėjo siųsti mums pasikartojančių klausimų sąrašą prieš mums paklausiant. DUK tapo bendru projektu, ir tai vienintelis būdas išlikti aktualiam. Bet kuriai agentūrai, atliekančiai tokį darbą keliuose projektuose, DUK traktavimas kaip kartotinos SaaS svetainių sistemos dalis užtikrina, kad kokybė išliks nuosekli, nereikės išradinėti proceso kiekvieną kartą.

Peržiūra neturi trukti ilgiau nei valandą. Penkiolika minučių palaikymo bilietams, penkiolika pardavimų klausimams, penkiolika produkto pakeitimams ir penkiolika puslapio atnaujinimui. Jei imate mokestį už turinio priežiūrą, tai tampa pasikartojančių pajamų eilute. Jei ne, tai apsaugo puslapį nuo pasenimo. Yra viena metrika, į kurią verta atkreipti dėmesį, net jei negalite priskirti konkretaus skaičiaus: ar palaikymo komanda praneša mažiau tų pačių klausimų. Kai palaikymo komanda nustoja atsakinėti į klausimą, kuris dabar yra DUK, tai yra pergalė, ir ji paprastai matoma komandos tono pokytyje, kol dar pasirodo bet kurioje analitikos sistemoje. Kai palaikymo komanda pradeda siūlyti naujus DUK įrašus, žinote, kad priežiūros procesas įsišaknijo.

Nė vienam iš to nereikia pertvarkymo ar naujo įrankio. Reikia pakeisti tai, kaip kalbate apie DUK su savo klientu. Nustokite jį vadinti "DUK" projekto planuose ir pradėkite vadinti "objekcijų puslapiu". Tas vienas pakeitimas performuos kiekvieną vėlesnį sprendimą – nuo klausimų, kuriuos renkate, iki atsakymų, kuriuos rašote. Tai taip pat palengvins puslapio priežiūros argumentą, nes joks klientas neginčija poreikio nuolat šalinti objekcijas.