SaaS-UKK-sivut ovat konversioveturit, jotka toimistot ohittavat

Yhteenveto

Useimmat SaaS-sivustojen UKK-sivut rakennetaan tukipyyntöjen pohjalta, mikä tarkoittaa, että ne vastaavat kysymyksiin ihmisiltä, jotka ovat jo ostaneet – samalla kun ne jättävät huomiotta esteet, jotka estävät potentiaalisia asiakkaita ostamasta. Tämä artikkeli kääntää UKK:n julkaisun jälkeisestä jälkiajatuksesta myyntivaltiksi. Kirjoitettu toimistoille, jotka rakentavat sivustoja useille asiakkaille, se kattaa toistettavan prosessin: kerää esteet myyntitiimiltä, ryhmittele kysymykset ostovaiheen mukaan, kirjoita vastaukset, jotka ovat riittävän kattavia lopettamaan haun, yhdistä jokainen este tiettyyn sosiaaliseen todisteeseen ja päivitä sivua neljännesvuosittain. Myytti-vs-todellisuus-formaatti näyttää, mikä oikeasti toimii, ja jokaisessa osiossa on käytännön esimerkki. Tuloksena on UKK-sivu, joka vähentää tuen kuormitusta ja lisää todennäköisyyttä, että potentiaalinen asiakas rekisteröityy.

Useimmat neuvot SaaS-UKK-sivuista lähtevät väärästä paikasta. Ne käsittelevät niitä julkaisun jälkeisenä siivouksena – paikkana, johon voi pysäköidä vastaukset tukipyyntöihin, jotta tukitiimi voi lopettaa itsensä toistamisen. Tämä kehys on syy siihen, miksi asiakkaasi UKK-sivu ei tee liiketoiminnalle juuri mitään. Mikä oikeasti toimii: UKK-sivu on yksi harvoista sivuista, joita potentiaalinen asiakas käy katsomassa sen jälkeen, kun hän on jo päättänyt, että saattaa ostaa. Se on päätösvaiheen sivu, ei dokumentaatiosivu. Se pitäisi rakentaa poistamaan esteet, jotka seisovat vierailijan ja rekisteröitymisen välillä, ja se ansaitsee saman strategisen huomion kuin hinnoittelusivu.

Jos olet toimistossa, ongelma on vieläkin terävämpi. Jokainen asiakas on erilainen: eri tuote, eri ostaja, eri tukihistoria. Sinun on kuitenkin tuotettava jotain, joka toimii ilman, että aloitat joka kerta tyhjästä. Kiusaus on kopioida viimeksi rakentamasi UKK:n rakenne. Se toimii kunnes se ei toimi, koska esteet, jotka ovat tärkeitä fintech-asiakkaalle, eivät ole samoja kuin tiimiyhteistyöasiakkaalle. Kehyksen täytyy olla sama; sisällön on oltava erilainen. Alla oleva myyttien purkaminen on tuo kehys. Alla oleva malli on yksinkertainen: odota UKK:n myyvän, ei vain tiedottavan. Se muuttaa sitä, miten keräät kysymyksiä, miten ryhmittelet ne, kuinka pitkiä vastauksista tulee ja mitä asetat niiden viereen.

Aloita myynnistä, älä tukipyynnöstä

Aloita pyytämällä asiakkaasi myyntitiimiltä viisi viimeisintä kauppaa, jotka hiljenivät. Kysymykset, jotka pysäyttivät nämä kaupat, ovat ensimmäiset kymmenen kysymystä, joihin UKK-sivusi pitäisi vastata. Useimmat UKK-sivut rakennetaan tukipyynnöistä – kysymyksistä ihmisiltä, jotka ovat jo ostaneet. Kysymykset, jotka todella estävät myyntiä, tulevat ihmisiltä, jotka eivät ole ostaneet, ja ne liittyvät yleensä siirtymiseen, tietoturvaan, hinnoitteluun ja siihen, mitä tapahtuu kokeilujakson jälkeen.

Tältä se näyttää käytännössä. Työnkulkuautomaation asiakas tuli luoksemme UKK:n kanssa, joka oli täynnä kysymyksiä kuten "Miten vaihdan salasanani?" ja "Mitkä selaimet ovat tuettuja?" Sivu oli teknisesti hyödyllinen mutta kaupallisesti passiivinen. Kysyimme myyntitiimiltä, mitä he kuulivat menetetyissä kaupoissa. Kävi ilmi, että potentiaaliset asiakkaat kysyivät, voisiko työkalu korvata heidän nykyisen laskentataulukkonsa, vaatisiko siirtyminen IT-osastoa ja vastasiko myyjän hinnasto sitä, mitä laskutus oikeasti veloittaisi. Rakensimme UKK:n uudelleen näiden kolmen esteen ympärille, jokainen lyhyellä vastauksella ja linkillä asiaankuuluvalle sivulle. Salasanan vaihtoon liittyvät kysymykset siirtyivät tukikeskukseen. Sivusta tuli kaupan päättämisen työkalu eikä tukipalvelu.

Kun suoritat tämän haastattelun, älä tyydy siihen, että "he kysyvät hinnoittelusta." Kysy tarkka sanamuoto. "Onko hinnoittelu käyttäjää vai työtilaa kohden?" on toiminnallinen. "He kysyvät hinnoittelusta" ei ole. Kysy myös, mitä kilpailija tekee sellaista, jota asiakas ei pysty helposti matkimaan – se yleensä tuo pintaan esteet, joista myyntitiimi on väsynyt kuulemaan. Laita ne sivun aivan yläreunaan.

Tämä on yksi paikka, jossa SaaS-verkkosivuston rakentaminen sisältä ulospäin kannattaa: aloitat kysymyksistä, joita oikeat ostajat kysyvät, ja rakennat sitten sivuston niiden ympärille. Huomautus: et voi jättää tukikysymyksiä kokonaan pois. Jotkut vierailijat ovat olemassa olevia asiakkaita. Mutta sivun arvokkain tila tulisi antaa kysymyksille, jotka tulevat ennen ostopäätöstä, ei sen jälkeen. Jos sinun on pidettävä joitakin tukikysymyksiä sivulla, siirrä ne aivan alareunaan selkeästi otsikon "Olemassa olevat asiakkaat" alle. Näin palvelet molempia yleisöjä antamatta tukikysymysten hallita. Hyödyllinen tapa suorittaa haastattelu on lähettää myyntitiimille yksinkertainen kehotus: listaa jokainen kysymys, jonka potentiaalinen asiakas kysyi viime kuussa ja johon sinun piti vastata manuaalisesti. Saat kaksi listaa. Kysymykset, jotka vaativat harkintaa, ovat UKK-aineistoa; ne, joihin voidaan vastata linkillä, kuuluvat dokumentaatioon.

Pituus ei ole perusteellisuutta

Periaate, josta kannattaa pitää kiinni, on relevanssi sijainnin perusteella. Vierailija, joka on kolme minuuttia ilmaisessa kokeilussa, kysyy eri asiaa kuin hankinta-asiantuntija, joka arvioi työkalua. Jos UKK on yksittäinen aakkosellinen lista, hankinta-asiantuntijan on selattava läpi "Miten vaihdan profiilikuvani?" löytääkseen "Miten käsittelette tietojen sijoittumisen?" Useimmat vierailijat eivät tee niin. He poistuvat.

Eräällä asiakkaalla, projektinhallinnan SaaS-yrityksellä, oli aakkostettu UKK, joka oli useiden sivujen pituinen. Ryhmittelimme sen uudelleen neljään kategoriaan: "Ennen aloitusta" (mitä se tekee, miten se vertautuu), "Kokeilun aikana" (asetukset, rajoitukset), "Ostaminen" (hinnoittelu, laskutus, tietoturva-arvioinnit) ja "Oston jälkeen" (laskutusmuutokset, tuki). Ostamisen kategoria laitettiin ensimmäiseksi, koska siinä rahaa menetettiin. Sivumäärä ei muuttunut paljoa, mutta sivu muuttui listasta ohjatuksi poluksi.

Kunkin kategorian sisällä käytä toista kahdesta järjestyssäännöstä. Jos tuotteella on selkeä ostotapa, järjestä vakavuuden mukaan: kysymys, joka pysäyttää kaupan suoraan, tulee ensimmäiseksi. Jos tuotteella ei ole ilmeistä järjestystä, järjestä yleisyyden mukaan – mutta vain kategorian sisällä, ei koko sivun yli. Tärkeää on, että vierailija löytää häntä kiinnostavan kysymyksen lukematta kaikkea. Käytä ankkurilinkkejä sivun yläreunassa, jotta hankinta-asiantuntija voi siirtyä suoraan kohtaan "Ostaminen" ja kokeilukäyttäjä kohtaan "Kokeilun aikana." Tyypillisellä SaaS-sivustolla nämä ovat kaksi ryhmää, jotka tuottavat eniten rekisteröitymisiä ja eniten menetettyjä kauppoja, joten ne saavat sivun yläosan.

Erityisesti hinnoittelukysymyksissä sama logiikka, jota soveltaisit konversioon rakennettuun hinnoittelusivuun, pätee UKK:ssa: laita päätöksen kannalta olennaiset tiedot ensin, sitten perustelut, sitten linkki. Älä pakota vierailijaa etsimään haluamansa suunnitelman hintaa. Ja Ostaminen-kategorian sisällä mieti järjestystä uudelleen. Laita tietoturva ja vaatimustenmukaisuus ennen maksutapoja, koska tietoturva-arviointi on usein portinvartija, joka pysäyttää arvioinnin ennen kuin maksukysymys edes nousee esiin.

Myytti	Todellisuus
UKK on olemassa vastatakseen kysymyksiin	UKK on olemassa poistaakseen ostamisen esteet
Pidempi UKK tarkoittaa perusteellisempaa	Skannattava, ryhmitelty UKK päihittää pitkän listan
Vastausten tulisi olla lyhyitä	Vastausten tulisi olla riittävän kattavia lopettamaan haku
Sosiaalinen todiste kuuluu vain etusivulle	Esteen viereen sijoitettu todiste konvertoi paremmin
UKK on julkaisun toimitus	UKK on elävä dokumentti, jolla on tarkistusrytmi

Liian lyhyen vastauksen hinta

Tässä on ennen-jälkeen-esimerkki, jota käytämme asiakkaiden kanssa, kun he vastustavat "pitkiä" vastauksia.

Ennen: "Tuetteko kertakirjautumista (SSO)? Kyllä, tuemme."

Jälkeen: "SSO on saatavilla Pro-suunnitelmassa ja sitä korkeammissa. Voit ottaa sen käyttöön, kun olet työtilan omistaja, kohdasta Asetukset > Tietoturva. Tässä on vaiheittainen opas. Jos tiimisi käyttää Oktaa tai Azure AD:tä, molemmat ovat tuettuja."

Toinen vastaus on pidempi, mutta se on myös lopullinen. Vierailija lopettaa etsimisen, koska vastaus ennakoi jatkokysymykset. Tällainen kirjoittaminen näyttää yksinkertaiselta, mutta se edellyttää tietoa siitä, mitä jatkokysymykset oikeasti ovat. Helpoin tapa löytää ne on tarkastella kunkin toimintoalueen yleisimpiä tukipyyntöjä ja sisällyttää vastaukset UKK:hon.

Käytettävä rakenne on: suora vastaus, yksi virke kontekstia, sitten linkki. Lihavoi suora vastaus, jotta silmäilevä lukija näkee sen heti. Jos sinulla on kuvakaappaus, laita se kontekstin jälkeen, ei ennen. Älä hautaa vastausta kappaleeseen, joka kuvailee toimintoa. Tämä on sama periaate, joka tekee Stripen ja Twilion kaltaisten yritysten API-dokumentaatiosta erottuvaa: voit saapua, saada vastauksen ja poistua. Käsittelemme tätä standardia tarkemmin oppaassamme SaaS-API-dokumentaation kirjoittamisesta, jota kehittäjät oikeasti käyttävät. Huomautus: "kattava" ei tarkoita "pitkä vain pitkän vuoksi." Tekstimuuri on edelleen tekstimuuri.

On myös sävykysymys. Liian lyhyt vastaus kuulostaa usein töykeältä tai jopa epäkohteliaalta; liian pitkä vastaus kuulostaa puolustelevalta. Paras kohta on vastaus, jonka pätevä tukipalvelun työntekijä antaisi sähköpostissa: suora vastaus, lyhyt selitys ja seuraava vaihe. Jos asiakkaasi tukitiimi kirjoittaa hyödyllisiä sähköposteja, pyydä muutama ja käytä niitä mallina. Jos ei, voit kirjoittaa mallin itse ja antaa tukitiimin korjata sen. Se on myös hyvä tapa saada tukitiimi sitoutumaan, koska UKK alkaa näyttää heidän parhailta sähköposteiltaan, ei yritysdokumentilta.

Yhdistä este sen todisteeseen

Ota jokainen este asiakkaasi UKK:sta ja kysy yksi kysymys: mikä sosiaalisen todisteen pala purkaisi tämän? Sähköisen allekirjoituksen asiakkaalla oli vahva suosittelijoiden osio etusivulla. Mutta kun katsoimme UKK:n tietoturvakysymystä – "Miten pidätte asiakirjani turvassa?" – vastaus oli kuivaa vaatimustenmukaisuuskieltä. Etusivun suosittelu lakitiimiltä, jossa sanottiin "vaatimustenmukaisuustiimimme hyväksyi ne alle päivässä", oli juuri se vakuutus, jota vastaus tarvitsi.

Aloimme yhdistää jokaisen esteen todisteen kanssa: tietoturvakysymys sai vaatimustenmukaisuussuosittelijan, hinnoittelukysymys sai lainauksen asiakkaalta, joka vaihtoi kilpailijalta, siirtymiskysymys sai maininnan asiakkaasta, joka siirsi koko yrityksensä ilman käyttökatkoksia. UKK lakkasi olemasta erillinen sivu ja siitä tuli osa myyntipuhetta.

Tässä varoitus on relevanssi. Logoseinä UKK:n lähellä lisää vähän; suosittelu, joka suoraan käsittelee estettä, painaa enemmän, varsinkin kun siinä mainitaan suosittelijan rooli. Jos asiakkaallasi ei ole vielä sellaista todistetta, ala kerätä sitä samoista myyntipuheluista, jotka tuottavat esteet. Nämä kaksi resurssia tulevat samasta lähteestä. Kun sinulla on suosittelu, poimi yksi lause, joka vastaa UKK-kysymykseen. Et tarvitse koko lainausta; yksi tarkka virke riittää. Pyydä myyntitiimiä merkitsemään, kun kauppa sulkeutuu, mainitsiko asiakas tietyn huolenaiheen. Se huolenaihe on tuleva UKK-kysymys, ja asiakkaan omat sanat ovat sen paras vastaus.

On olemassa toinen, vähemmän ilmeinen todisteen laji: tuotetodiste. Jos potentiaalinen asiakas kysyy "Voinko viedä datani?" vahvin vastaus sisältää kuvakaappauksen vientinäytöstä, ei vain lausetta joka sanoo kyllä. Jos he kysyvät "Kuinka kauan kokeilujakso kestää?" vahvin vastaus sisältää rivin siitä, mitä tapahtuu, kun se päättyy. Kuvakaappaukset ja lyhyet GIFit toimivat tässä, koska ne näyttävät väittämisen sijaan. Tässä kohtaa UKK liittyy myös ominaisuuksien esittelyyn: kysymys kuten "Miten tämä eroaa laskentataulukosta?" pitäisi linkittää sivuston osioon, joka demonstroi eron, ei vertailutekstimuuriin.

UKK on prosessi, ei julkaisun toimitus

Kestävä periaate toimistolle on, että UKK-sivu on prosessi, ei sivu. Asiakkaan tuote muuttuu joka kuukausi; uusia esteitä ilmaantuu jokaisen hinnoittelumuutoksen, uuden kilpailijan ja vuosineljänneksen myötä. Tammikuussa julkaisemasi sivu on arvailua maaliskuuhun mennessä. Toimistot, jotka tekevät tästä toistettavaa, rakentavat kevyen ylläpitorytmin osaksi toimeksiantoa.

Julkaisun jälkeen aseta neljännesvuosittainen tarkistus, jossa tarkastelet kolmea asiaa: uudet tukipyynnöt, myyntipuheluiden kysymykset ja tuotemuutokset. Jaa tarkistus kahteen vaiheeseen. Poista ensin kysymykset, jotka eivät enää ole olennaisia. Lisää sitten kysymykset, jotka ovat ilmaantuneet viimeisten 90 päivän aikana. Et tarvitse sisältöstrategia tätä varten. Tarvitset tavan.

Otamme tämän käyttöön yhdellä asiakkaalla pyytämällä tukipäällikköä merkitsemään kaikki liput, joihin verkkosivusto olisi voinut vastata. Parin vuosineljänneksen kuluttua tukipäällikkö alkoi lähettää meille listan toistuvista kysymyksistä ennen kuin kysyimme. UKK:sta tuli yhteinen projekti, joka on ainoa tapa pitää se relevanttina. Toimistolle, joka tekee tällaista työtä useissa toimeksiannoissa, UKK:n käsitteleminen osana toistettavaa SaaS-verkkosivustojärjestelmää pitää laadun tasaisena ilman prosessin uudelleenkeksimistä joka kerta.

Tarkistuksen ei tarvitse kestää tuntia kauempaa. Viisitoista minuuttia tukipyynnöille, viisitoista myyntikysymyksille, viisitoista tuotemuutoksille ja viisitoista sivun päivittämiseen. Jos laskutat sisällön ylläpidosta, siitä tulee toistuva tulovirta. Jos et, se estää sivua vanhenemasta. On yksi mittari, jota kannattaa seurata, vaikka siihen ei voisi liittää kovaa numeroa: raportoiko tukitiimi vähemmän samoja kysymyksiä. Kun tukitiimi lakkaa vastaamasta kysymykseen, joka nyt on UKK:ssa, se on voitto, ja se näkyy yleensä tiimin sävyssä ennen kuin se näkyy missään hallintapaneelissa. Kun tukitiimi alkaa ehdottaa uusia UKK-merkintöjä, tiedät, että ylläpitoprosessi on juurtunut.

Mikään tästä ei vaadi uudelleensuunnittelua tai uutta työkalua. Se vaatii muutoksen siinä, miten puhut UKK:sta asiakkaasi kanssa. Lopeta sen kutsuminen "UKK:ksi" projektisuunnitelmissa ja ala kutsua sitä "estesivuksi." Tämä yksi muutos muokkaa jokaista sen jälkeen tulevaa päätöstä, keräämistäsi kysymyksistä kirjoittamiisi vastauksiin. Se myös tekee sivun ylläpidon perustelemisesta paljon helpompaa, koska yksikään asiakas ei kiistä tarvetta torjua esteitä jatkuvasti.