Strani s pogostimi vprašanji SaaS so konverzijski delovni konj, ki ga agencije spregledajo

Povzetek

Večina strani s pogostimi vprašanji SaaS je zgrajenih iz podpornih vprašanj, kar pomeni, da odgovarjajo na vprašanja ljudi, ki so že kupili – medtem ko ignorirajo ugovore, ki preprečujejo potencialnim strankam nakup. Ta članek spremeni FAQ iz poprodajne naknadne misli v prodajno sredstvo. Napisan je za agencije, ki gradijo spletne strani za več naročnikov, in zajema ponovljiv postopek: zberite ugovore od prodajne ekipe, združite vprašanja po fazi nakupa, napišite odgovore, ki so dovolj popolni, da končajo iskanje, vsak ugovor povežite s posebnim družbenim dokazom in stran vzdržujte vsake četrtletje. Format mit-vs-resničnost prikazuje, kaj dejansko deluje, s praktičnim primerom v vsakem razdelku. Rezultat je stran s pogostimi vprašanji, ki zmanjša obremenitev podpore in poveča verjetnost, da se potencialna stranka prijavi.

Večina nasvetov o straneh s pogostimi vprašanji SaaS izhaja iz napačnega izhodišča. Obravnava jih kot poprodajno čiščenje – prostor za shranjevanje odgovorov na podporna vprašanja, da se podporna ekipa ne bi ponavljala. To je razlog, zakaj stran s pogostimi vprašanji vašega naročnika ne naredi skoraj ničesar za podjetje. Kar dejansko deluje: stran s pogostimi vprašanji je ena redkih strani, ki jo potencialna stranka obišče, potem ko se je že odločila, da bi morda kupila. To je stran v fazi odločanja, ne dokumentacijska stran. Zgrajena mora biti tako, da odstrani ugovore, ki stojijo med obiskovalcem in prijavo, in si zasluži enako strateško pozornost kot cenovna stran.

Če ste v agenciji, je problem še ostrejši. Vsak naročnik je drugačen: drugačen izdelek, drugačen kupec, drugačna podporna zgodovina. Kljub temu morate ustvariti nekaj, kar deluje, ne da bi vsakič začeli iz nič. Skušnjava je, da bi kopirali strukturo zadnjega FAQ-ja, ki ste ga zgradili. To deluje, dokler ne preneha delovati, ker ugovori, ki so pomembni za fintech naročnika, niso tisti, ki so pomembni za naročnika pri sodelovanju ekip. Okvir mora biti enak; vsebina mora biti drugačna. Spodnje razbijanje mitov je ta okvir. Vzorec je preprost: pričakujte, da bo FAQ prodajal, ne le informiral. To spremeni, kako zbirate vprašanja, kako jih združujete, kako dolge so posamezni odgovori in kaj postavite poleg njih.

Začnite s prodajo, ne s podpornim vprašanjem

Začnite tako, da prodajno ekipo vašega naročnika prosite za zadnjih pet poslov, ki so zamrli. Vprašanja, ki so ustavila te posle, so prvih deset vprašanj, na katera bi morala odgovarjati vaša stran s pogostimi vprašanji. Večina strani s pogostimi vprašanji je zgrajena iz podpornih vprašanj – vprašanj ljudi, ki so že kupili. Vprašanja, ki dejansko blokirajo prodajo, prihajajo od ljudi, ki še niso kupili, in se običajno nanašajo na migracijo, varnost, cene in kaj se zgodi po koncu preizkusnega obdobja.

Takole je to videti v praksi. Naročnik za avtomatizacijo delovnih tokov je k nam prišel s pogostimi vprašanji, polnimi vprašanj, kot so "Kako ponastavim geslo?" in "Kateri brskalniki so podprti?" Stran je bila tehnično uporabna, a komercialno nedejavna. Zato smo prodajno ekipo vprašali, kaj slišijo pri izgubljenih poslih. Izkazalo se je, da so potencialne stranke spraševale, ali lahko orodje nadomesti njihovo trenutno preglednico, ali bo migracija zahtevala IT-oddelek in ali je cenik prodajalca usklajen s tem, kar bo obračunavanje dejansko zaračunalo. Obnovili smo pogosta vprašanja okoli teh treh ugovorov, vsakega s kratkim odgovorom in povezavo do ustrezne strani. Vprašanja o ponastavitvi gesla so se preselila v center za podporo. Stran je postala orodje za zapiranje poslov namesto pomoči uporabnikom.

Ko izvajate ta intervju, se ne zadovoljite z "sprašujejo o cenah". Vprašajte za točno besedilo. "Ali je cena na uporabnika ali na delovni prostor?" je uporabno. "Sprašujejo o cenah" ni. Prav tako vprašajte, kaj počne konkurent, česar naročnik ne more zlahka preseči – to običajno razkrije ugovore, ki jih je prodajna ekipa naveličana poslušati. Te postavite na sam vrh strani.

To je eno od področij, kjer se gradnja spletne strani SaaS od znotraj navzven obrestuje: začnete z vprašanji, ki jih postavljajo resnični kupci, nato pa okoli njih zgradite spletno stran. Opozorilo: podpornih vprašanj ne morete popolnoma izpustiti. Nekateri obiskovalci so obstoječe stranke. Toda najboljši del strani bi moral biti namenjen vprašanjem, ki se pojavijo pred nakupom, ne po njem. Če morate na strani obdržati nekaj podpornih vprašanj, jih premaknite na sam dno pod jasno označenim naslovom "Obstoječe stranke". Tako boste služili obema občinstvoma, ne da bi podporna vprašanja prevladala. Uporaben način za izvedbo intervjuja je, da prodajni ekipi pošljete preprost poziv: navedite vsako vprašanje, ki ga je potencialna stranka postavila prejšnji mesec in na katerega ste morali odgovoriti ročno. Dobili boste dva seznama. Vprašanja, ki zahtevajo presojo, so gradivo za pogosta vprašanja; tista, na katera lahko odgovorite s povezavo, sodijo v dokumentacijo.

Dolžina ni temeljitost

Načelo, ki se ga je vredno držati, je ustreznost glede na položaj. Obiskovalec, ki je tri minute v brezplačnem preizkusu, ima drugačno vprašanje kot nabavni referent, ki ocenjuje orodje. Če so pogosta vprašanja en sam abecedni seznam, mora nabavni referent prebrskati "Kako spremenim svoj avatar?", da najde "Kako ravnate z residenčnostjo podatkov?" Večina obiskovalcev tega ne bo storila. Odšli bodo.

En naročnik, SaaS za upravljanje projektov, je imel pogosta vprašanja, ki so bila abecedno razvrščena in obsegala več strani. Ponovno smo jih združili v štiri kategorije: "Pred začetkom" (kaj orodje počne, s čim se primerja), "Med preizkusom" (nastavitev, omejitve), "Nakup" (cene, fakturiranje, varnostni pregledi) in "Po nakupu" (spremembe obračunavanja, podpora). Kategorija nakupa je bila prva, ker tam se je izgubljal denar. Število besed se ni bistveno spremenilo, vendar je stran prešla s seznama na vodeno pot.

Znotraj vsake kategorije uporabite eno od dveh pravil razvrščanja. Če ima izdelek jasen način nakupa, razvrstite po resnosti: vprašanje, ki povsem ustavi posel, gre prvo. Če izdelek nima očitnega zaporedja, razvrstite po pogostosti – vendar le znotraj kategorije, ne na celotni strani. Pomembno je, da obiskovalec najde vprašanje, ki ga zanima, ne da bi prebral vse. Uporabite sidrne povezave na vrhu strani, da lahko nabavni referent skoči neposredno na "Nakup", uporabnik preizkusa pa na "Med preizkusom." Na tipični strani SaaS sta to dve skupini, ki prinašata največ prijav in največ izgubljenih poslov, zato dobita vrh strani.

Za vprašanja o cenah posebej velja ista logika, ki bi jo uporabili za cenovno stran, zgrajeno za konverzije, tudi znotraj pogostih vprašanj: najprej postavite podrobnosti, pomembne za odločitev, nato utemeljitev, nato povezavo. Ne silite obiskovalca, da išče ceno želenega načrta. In znotraj kategorije "Nakup" znova premislite o zaporedju. Varnost in skladnost postavite pred načine plačila, ker je varnostni pregled pogosto vratar, ki ustavi ocenjevanje, preden se sploh pojavi vprašanje o plačilu.

Mit	Resničnost
FAQ obstaja, da odgovarja na vprašanja	FAQ obstaja, da odstranjuje nakupne ugovore
Daljši FAQ pomeni večjo temeljitost	Pregleden, združen FAQ deluje bolje kot dolg seznam
Odgovori naj bodo kratki	Odgovori naj bodo dovolj popolni, da končajo iskanje
Družbeni dokaz sodi samo na domačo stran	Dokaz, postavljen poleg ugovora, bolje konvertira
FAQ je rezultat ob zagonu	FAQ je živ dokument s kadenco pregledov

Cena prekratkega odgovora

Tukaj je primer pred in po, ki ga uporabljamo pri naročnikih, ko nasprotujejo "dolgim" odgovorom.

Pred: "Ali podpirate SSO? Da, podpiramo."

Po: "SSO je na voljo v načrtu Pro in višje. Omogočite ga lahko, ko ste lastnik delovnega prostora, v Nastavitve > Varnost. Tukaj je vodnik po korakih. Če vaša ekipa uporablja Okta ali Azure AD, sta oba podprta."

Drugi odgovor je daljši, a tudi dokončen. Obiskovalec neha iskati, ker odgovor predvidi nadaljnja vprašanja. Tako pisanje se zdi preprosto, vendar zahteva poznavanje dejanskih nadaljnjih vprašanj. Najlažji način, da jih najdete, je, da si ogledate najpogostejša podporna vprašanja za posamezno področje funkcij in odgovore vključite v pogosta vprašanja.

Struktura, ki jo uporabite, je: neposreden odgovor, en stavek konteksta, nato povezava. Krepko označite neposreden odgovor, da ga bralec takoj opazi. Če imate posnetek zaslona, ga postavite za kontekst, ne pred njega. Odgovora ne skrivajte v odstavku, ki opisuje funkcijo. To je isto načelo, zaradi katerega izstopa API dokumentacija podjetij, kot sta Stripe in Twilio: lahko pristanete, dobite odgovor in odidete. To merilo smo podrobneje obravnavali v našem vodniku o pisanju API dokumentacije za SaaS, ki jo razvijalci dejansko uporabljajo. Opozorilo: "popoln" ne pomeni "dolg zaradi dolžine same". Zid besedila je še vedno zid besedila.

Obstaja tudi vprašanje tona. Prekratek odgovor deluje osorno ali celo nesramno; predolg odgovor deluje obrambno. Najboljše je tisto, kar bi usposobljena oseba za podporo napisala v e-pošti: neposreden odgovor, kratka razlaga in naslednji korak. Če podporna ekipa vašega naročnika piše uporabna e-poštna sporočila, prosite za nekaj primerov in jih uporabite kot model. Če jih ne, lahko model napišete sami in podporni ekipi prepustite, da ga popravi. To je tudi dober način za pridobitev podpore podporne ekipe, saj pogosta vprašanja začnejo izgledati kot njihova najboljša e-poštna sporočila, ne kot korporativni dokument.

Povežite ugovor z njegovim dokazom

Za vsak ugovor na strani s pogostimi vprašanji vašega naročnika si zastavite eno vprašanje: kateri del družbenega dokaza bi ta ugovor razorožil? Naročnik za e-podpise je imel močan razdelek s pričevanji na domači strani. Toda ko smo pogledali varnostno vprašanje v pogostih vprašanjih — "Kako poskrbite za varnost mojih dokumentov?" — je bil odgovor suhoparen jezik o skladnosti. Pričevanje na domači strani pravne ekipe, ki pravi "naša ekipa za skladnost jih je odobrila v manj kot dnevu", je bilo natanko tisto zagotovilo, ki ga je ta odgovor potreboval.

Začeli smo povezovati vsak ugovor z delom dokaza: varnostno vprašanje je dobilo pričevanje o skladnosti, vprašanje o ceni je dobilo izjavo stranke, ki je prešla od konkurenta, vprašanje o migraciji pa vrstico o stranki, ki je preselila celotno podjetje brez izpadov. Pogosta vprašanja niso bila več ločena stran, temveč del predstavitve.

Opozorilo tukaj je ustreznost. Stena logotipov ob pogostih vprašanjih doda malo; pričevanje, ki neposredno naslavlja ugovor, ima težo, zlasti če navaja vlogo osebe, ki ga podaja. Če vaš naročnik še nima takega dokaza, ga začnite zbirati iz istih prodajnih klicev, ki ustvarjajo ugovore. Ta dva vira prihajata iz istega vira. Ko imate pričevanje, iz njega izluščite en stavek, ki se ujema z vprašanjem iz pogostih vprašanj. Ne potrebujete celotnega citata; dovolj je en konkreten stavek. Prodajno ekipo prosite, naj ob zaključenem poslu zabeleži, ali je stranka omenila določen pomislek. Ta pomislek je prihodnje vprašanje za pogosta vprašanja, lastne besede stranke pa so njegov najboljši odgovor.

Obstaja tudi druga, manj očitna vrsta dokaza: dokaz izdelka. Če potencialna stranka vpraša "Ali lahko izvozim svoje podatke?" je najmočnejši odgovor tisti, ki vključuje posnetek zaslona zaslona za izvoz, ne le stavek, ki pravi da. Če vpraša "Kako dolgo traja preizkus?" je najmočnejši odgovor tisti, ki vključuje vrstico o tem, kaj se zgodi, ko se konča. Posnetki zaslona in kratki GIF-i tukaj delujejo, ker pokažejo, ne le trdijo. To je tudi mesto, kjer se pogosta vprašanja povezujejo s predstavitvijo funkcij: vprašanje, kot je "Kako se to razlikuje od preglednice?" bi moralo povezovati na razdelek spletnega mesta, ki prikazuje razliko, ne na zid primerjalnega besedila.

FAQ je proces, ne rezultat ob zagonu

Trajno načelo za agencijo je, da je stran s pogostimi vprašanji proces, ne stran. Izdelek naročnika se spreminja vsak mesec; novi ugovori se pojavijo ob vsaki spremembi cen, vsakem novem konkurentu, vsakem četrtletju. Stran, ki jo objavite januarja, je do marca ugibanje. Agencije, ki to naredijo ponovljivo, v sodelovanje vgradijo lahkotno kadenco vzdrževanja.

Po zagonu določite četrtletni pregled, pri katerem upoštevate tri vire: nova podporna vprašanja, vprašanja s prodajnih klicev in spremembe izdelka. Pregled razdelite na dva koraka. Najprej odstranite vprašanja, ki niso več pomembna. Drugič, dodajte vprašanja, ki so se pojavila v zadnjih 90 dneh. Za to ne potrebujete vsebinskega stratega. Potrebujete navado.

To smo uvedli pri enem naročniku tako, da smo vodjo podpore prosili, naj označi vsak zahtevek, na katerega bi lahko odgovorilo spletno mesto. Po nekaj četrtletjih nam je vodja podpore začel pošiljati seznam ponavljajočih se vprašanj, še preden smo ga prosili. Pogosta vprašanja so postala skupni projekt, kar je edini način, da ostanejo aktualna. Za vsako agencijo, ki tovrstno delo izvaja pri več naročnikih, je obravnavanje pogostih vprašanj kot dela ponovljivega sistema spletnih strani SaaS tisto, kar ohranja kakovost dosledno, ne da bi vsakič znova izumljali postopek.

Pregled ne sme trajati več kot eno uro. Petnajst minut za podporna vprašanja, petnajst za prodajna vprašanja, petnajst za spremembe izdelka in petnajst za posodobitev strani. Če zaračunavate vzdrževanje vsebine, to postane ponavljajoči se prihodek. Če ne, preprečuje staranje strani. Obstaja ena metrika, ki jo je vredno spremljati, tudi če ne morete pripisati natančne številke: ali podporna ekipa poroča o manj istih vprašanjih. Ko podporna ekipa preneha odgovarjati na vprašanje, ki je zdaj v pogostih vprašanjih, je to zmaga in običajno je vidna v tonu ekipe, preden se pojavi na kateri koli nadzorni plošči. Ko podporna ekipa začne predlagati nove vnose v pogosta vprašanja, veste, da se je proces vzdrževanja prijel.

Nič od tega ne zahteva prenove ali novega orodja. Zahteva spremembo v načinu pogovora o pogostih vprašanjih s svojim naročnikom. Ne imenujte jih več "FAQ" v projektnih načrtih in jih začnite imenovati "stran z ugovori". Ta ena sprememba bo preoblikovala vsako odločitev, ki sledi, od vprašanj, ki jih zberete, do odgovorov, ki jih napišete. Prav tako bo olajšala utemeljitev vzdrževanja strani, saj noben naročnik ne oporeka potrebi po nenehnem odvračanju ugovorov.