SaaS FAQ stranice su radni konj konverzije kojeg agencije previdjaju

Sažetak

Većina SaaS FAQ stranica izgrađena je od zahtjeva za podršku, što znači da odgovaraju na pitanja ljudi koji su već kupili — dok zanemaruju prigovore koji sprječavaju potencijalne kupce da kupe. Ovaj članak preokreće FAQ iz post-lansirne naknadne misli u prodajni alat. Napisan za agencije koje grade web stranice za više klijenata, pokriva ponovljiv proces: prikupite prigovore od prodajnog tima, grupirajte pitanja prema fazi kupnje, napišite odgovore koji su dovoljno potpuni da završe pretragu, uparite svaki prigovor s konkretnim društvenim dokazom i održavajte stranicu na kvartalnoj razini. Format mit-nasuprot-stvarnosti pokazuje što zapravo funkcionira, s praktičnim primjerom u svakom odjeljku. Rezultat je FAQ stranica koja smanjuje opterećenje podrške i povećava šansu da se potencijalni kupac prijavi.

Većina savjeta o SaaS FAQ stranicama kreće s pogrešnog mjesta. Tretira ih kao post-lansirno čišćenje — mjesto za parkiranje odgovora na zahtjeve za podršku kako bi se tim za podršku prestao ponavljati. Takvo okvirno razmišljanje razlog je zašto FAQ stranica vašeg klijenta ne radi gotovo ništa za posao. Ono što zapravo funkcionira: FAQ stranica jedna je od rijetkih stranica koju potencijalni kupac posjeti nakon što je već odlučio da bi mogao kupiti. To je stranica u fazi odlučivanja, a ne stranica s dokumentacijom. Trebala bi biti izgrađena za uklanjanje prigovora koji stoje između posjetitelja i prijave, te zaslužuje istu stratešku pozornost kao i stranica s cijenama.

Ako ste u agenciji, problem je još oštriji. Svaki je klijent drugačiji: drugačiji proizvod, drugačiji kupac, drugačija povijest podrške. Ipak, morate proizvesti nešto što funkcionira bez početka od nule svaki put. Iskušenje je kopirati strukturu zadnjeg FAQ-a koji ste izradili. To funkcionira sve dok ne prestane, jer prigovori koji su važni klijentu iz fintech sektora nisu isti kao oni koji su važni klijentu za timsku suradnju. Okvir mora biti isti; sadržaj mora biti drugačiji. Razbijanje mitova u nastavku taj je okvir. Obrazac ispod je jednostavan: očekujte da FAQ prodaje, a ne samo informira. To mijenja način na koji prikupljate pitanja, kako ih grupirate, koliko je dugačak svaki odgovor i što stavljate pored njega.

Počnite s prodajom, ne sa zahtjevom za podršku

Započnite tražeći od prodajnog tima vašeg klijenta zadnjih pet poslova koji su utihnuli. Pitanja koja su zaustavila te poslove prvo su pitanje na koje bi vaša FAQ stranica trebala odgovoriti. Većina FAQ stranica izgrađena je od zahtjeva za podršku — pitanja ljudi koji su već kupili. Pitanja koja zapravo blokiraju prodaju dolaze od ljudi koji nisu kupili, a obično se odnose na migraciju, sigurnost, cijene i ono što se događa nakon završetka probnog razdoblja.

Evo kako to izgleda u praksi. Klijent za automatizaciju radnih tokova došao nam je s FAQ-om punim pitanja poput "Kako mogu resetirati svoju lozinku?" i "Koji preglednici su podržani?" Stranica je bila tehnički korisna i komercijalno inertna. Stoga smo pitali prodajni tim što su čuli u izgubljenim poslovima. Ispostavilo se da su potencijalni kupci pitali može li alat zamijeniti njihovu trenutnu proračunsku tablicu, zahtijeva li migracija IT odjel te odgovara li prodavačeva cjenovna lista onome što će naplata zapravo naplatiti. Obnovili smo FAQ oko ta tri prigovora, svaki s kratkim odgovorom i poveznicom na relevantnu stranicu. Pitanja o resetiranju lozinke premještena su u centar za podršku. Stranica je postala alat za zaključivanje prodaje umjesto servisnog centra.

Kada provodite ovaj intervju, nemojte se zadovoljiti s "pitaju o cijenama." Tražite točan tekst. "Je li cijena po korisniku ili po radnom prostoru?" je upotrebljivo. "Pitaju o cijenama" nije. Također pitajte što konkurencija radi što klijent ne može lako nadmašiti — to obično otkrije prigovore koje je prodajni tim umoran slušati. Stavite ih na sam vrh stranice.

Ovo je jedno mjesto gdje se izgradnja SaaS web stranice iznutra prema van isplati: krenete od pitanja koja postavljaju stvarni kupci, a zatim gradite stranicu oko njih. Upozorenje je da ne možete u potpunosti preskočiti pitanja podrške. Neki su posjetitelji postojeći kupci. No, najvrjedniji prostor na stranici trebao bi ići pitanjima koja se pojavljuju prije kupnje, ne nakon nje. Ako trebate zadržati neka pitanja podrške na stranici, premjestite ih na samo dno pod jasno označenim naslovom "Postojeći kupci." Tako služite obje publike ne dopuštajući da pitanja podrške dominiraju. Koristan način za provođenje intervjua jest poslati prodajnom timu jednostavan upit: navedite svako pitanje koje je potencijalni kupac postavio prošli mjesec na koje ste morali odgovoriti ručno. Dobit ćete dva popisa. Pitanja koja zahtijevaju prosudbu materijal su za FAQ; ona na koja se može odgovoriti poveznicom pripadaju u dokumentaciju.

Duljina nije temeljitost

Načelo koje vrijedi zadržati jest relevantnost po poziciji. Posjetitelj koji je tri minute u besplatnom probnom razdoblju ima drugačije pitanje od službenika za nabavu koji procjenjuje alat. Ako je FAQ jedan abecedni popis, službenik za nabavu mora proći kroz "Kako mogu promijeniti svoj avatar?" da bi pronašao "Kako rješavate pohranu podataka?" Većina posjetitelja neće to učiniti. Otići će.

Jedan klijent, SaaS za upravljanje projektima, imao je FAQ koji je bio abecediran i protezao se na nekoliko stranica. Ponovno smo ga grupirali u četiri kategorije: "Prije nego što počnete" (što radi, kako se uspoređuje), "Tijekom probnog razdoblja" (postavljanje, ograničenja), "Kupnja" (cijene, fakturiranje, sigurnosne provjere) i "Nakon kupnje" (promjene naplate, podrška). Kategorija kupnje bila je prva jer se tamo gubio novac. Broj riječi nije se puno promijenio, ali stranica je s popisa postala vođeni put.

Unutar svake kategorije koristite jedno od dva pravila redoslijeda. Ako proizvod ima jasan način kupnje, poredajte prema ozbiljnosti: pitanje koje odmah zaustavlja posao ide prvo. Ako proizvod nema očit slijed, poredajte prema učestalosti — ali samo unutar kategorije, ne na cijeloj stranici. Ono što je važno jest da posjetitelj može pronaći pitanje koje ga zanima bez čitanja svega. Koristite sidrene poveznice na vrhu stranice kako bi službenik za nabavu mogao skočiti izravno na "Kupnju", a korisnik probnog razdoblja na "Tijekom probnog razdoblja." Na tipičnoj SaaS stranici, to su dvije skupine koje donose najviše prijava i najviše izgubljenih poslova, pa zaslužuju vrh stranice.

Za pitanja o cijenama, ista logika koju biste primijenili na stranicu s cijenama izgrađenu za konverzije vrijedi i unutar FAQ-a: prvo stavite detalje relevantne za odluku, zatim obrazloženje, zatim poveznicu. Ne tjerajte posjetitelja da traži cijenu plana koji želi. I unutar kategorije kupnje razmislite o slijedu. Stavite sigurnost i usklađenost prije načina plaćanja jer je sigurnosna provjera često vratar koji zaustavlja evaluaciju prije nego što se uopće pojavi pitanje o plaćanju.

Mit	Stvarnost
FAQ postoji da bi odgovarao na pitanja	FAQ postoji da bi uklonio prigovore na kupnju
Dulji FAQ znači temeljitiji	Preglediv, grupiran FAQ nadmašuje dugi popis
Odgovori trebaju biti kratki	Odgovori trebaju biti dovoljno potpuni da završe pretragu
Društveni dokaz pripada samo na početnu stranicu	Dokaz postavljen uz prigovor bolje pretvara
FAQ je isporuka pri lansiranju	FAQ je živi dokument s kadencom revizije

Cijena prekratkog odgovora

Ovdje je primjer prije i poslije koji koristimo s klijentima kada se bune na "duge" odgovore.

Prije: "Podržavate li SSO? Da, podržavamo."

Nakon: "SSO je dostupan na Pro planu i više. Možete ga omogućiti kada postanete vlasnik radnog prostora, iz Postavke > Sigurnost. Evo vodiča korak po korak. Ako vaš tim koristi Okta ili Azure AD, oba su podržana."

Drugi je odgovor dulji, ali i konačan. Posjetitelj prestaje tražiti jer odgovor predviđa pitanja koja slijede. Ovako pisanje naizgled je jednostavno, ali zahtijeva poznavanje stvarnih pitanja koja slijede. Najlakši način da ih pronađete jest pogledati najčešće zahtjeve za podršku za svako područje značajki i ugraditi odgovore u FAQ.

Struktura koju treba koristiti je: izravan odgovor, jedna rečenica konteksta, zatim poveznica. Podebljajte izravan odgovor kako bi ga čitatelj koji prelijeće odmah vidio. Ako imate snimku zaslona, stavite je nakon konteksta, ne prije. Nemojte zakopati odgovor u odlomak koji opisuje značajku. To je isti princip koji čini API dokumentaciju tvrtki poput Stripea i Twiloa iznimnom: možete sletjeti, dobiti odgovor i otići. Dublje ulazimo u taj standard u našem vodiču o pisanju SaaS API dokumentacije koju programeri stvarno koriste. Oprez: "potpuno" ne znači "dugo radi dužine." Zid teksta i dalje je zid teksta.

Postoji i pitanje tona. Prekratak odgovor obično zvuči osorno ili čak nepristojno; predug odgovor zvuči obrambeno. Idealna mjera je odgovor koji bi kompetentna osoba za podršku dala u e-poruci: izravan odgovor, kratko objašnjenje i sljedeći korak. Ako tim za podršku vašeg klijenta piše korisne e-poruke, zatražite nekoliko i iskoristite ih kao model. Ako ne, možete sami napisati model i pustiti tim za podršku da ga ispravi. To je također dobar način da dobijete potporu tima za podršku, jer FAQ počinje izgledati kao njihove najbolje e-poruke, a ne korporativni dokument.

Uparite prigovor s njegovim dokazom

Uzmite svaki prigovor na FAQ stranici vašeg klijenta i postavite jedno pitanje: koji dio društvenog dokaza bi ga razbio? Klijent za elektroničke potpise imao je snažan odjeljak s preporukama na početnoj stranici. No, kada smo pogledali sigurnosno pitanje u FAQ-u — "Kako čuvate moje dokumente sigurnima?" — odgovor je bio suhoparan jezik usklađenosti. Preporuka s početne stranice pravnog tima koja kaže "naš tim za usklađenost ih je odobrio u manje od jednog dana" bila je upravo ono što je tom odgovoru trebalo.

Počeli smo uparivati svaki prigovor s komadom dokaza: sigurnosno pitanje dobilo je preporuku o usklađenosti, pitanje o cijeni dobilo je citat kupca koji je prešao s konkurencije, pitanje o migraciji dobilo je rečenicu o kupcu koji je preselio cijelu tvrtku bez zastoja. FAQ je prestao biti zasebna stranica i postao dio prezentacije.

Oprez ovdje je relevantnost. Zid logotipa blizu FAQ-a ne dodaje mnogo; preporuka koja izravno adresira prigovor nosi težinu, posebno kada navodi ulogu osobe koja je daje. Ako vaš klijent još nema takvu vrstu dokaza, počnite ga prikupljati s istih prodajnih poziva koji generiraju prigovore. Dva sredstva dolaze iz istog izvora. Kada imate preporuku, izdvojite jednu rečenicu koja odgovara pitanju iz FAQ-a. Ne trebate cijeli citat; jedna specifična rečenica je dovoljna. Zamolite prodajni tim da zabilježi, kada se posao zaključi, je li kupac spomenuo konkretnu brigu. Ta briga buduće je pitanje u FAQ-u, a kupčeve vlastite riječi njegov su najbolji odgovor.

Postoji i druga, manje očita vrsta dokaza: dokaz o proizvodu. Ako potencijalni kupac pita "Mogu li izvesti svoje podatke?" najsnažniji odgovor uključuje snimku zaslona zaslona za izvoz, ne samo rečenicu koja kaže da. Ako pita "Koliko traje probno razdoblje?" najsnažniji odgovor uključuje rečenicu o tome što se događa kada završi. Snimke zaslona i kratki GIF-ovi ovdje funkcioniraju jer pokazuju umjesto da tvrde. Ovo je također mjesto gdje se FAQ povezuje s prikazom značajki: pitanje poput "Po čemu se to razlikuje od proračunske tablice?" trebalo bi voditi na odjeljak stranice koji demonstrira razliku, a ne na zid usporednog teksta.

FAQ je proces, a ne isporuka pri lansiranju

Trajno načelo za agenciju jest da je FAQ stranica proces, a ne stranica. Proizvod klijenta mijenja se svaki mjesec; novi prigovori pojavljuju se sa svakom promjenom cijena, svakim novim konkurentom, svakim kvartalom. Stranica koju lansirate u siječnju nagađanje je do ožujka. Agencije koje ovo čine ponovljivim ugrađuju laganu kadencu održavanja u angažman.

Nakon lansiranja, postavite kvartalni pregled na kojem gledate tri ulaza: nove zahtjeve za podršku, pitanja s prodajnih poziva i promjene na proizvodu. Podijelite pregled u dva koraka. Prvo, uklonite pitanja koja više nisu važna. Drugo, dodajte pitanja koja su se pojavila u zadnjih 90 dana. Ne trebate stratega sadržaja za ovo. Trebate naviku.

To smo uveli za jednog klijenta tražeći od voditelja podrške da označi sve zahtjeve na koje je web stranica mogla odgovoriti. Nakon nekoliko kvartala, voditelj podrške počeo nam je slati popis ponavljajućih pitanja prije nego što bismo pitali. FAQ je postao zajednički projekt, što je jedini način da ostane relevantan. Za svaku agenciju koja vodi ovakvu vrstu posla na više angažmana, tretiranje FAQ-a kao dijela ponovljivog sustava SaaS web stranica ono je što održava kvalitetu dosljednom bez ponovnog izmišljanja procesa svaki put.

Pregled ne mora trajati dulje od sat vremena. Petnaest minuta za zahtjeve za podršku, petnaest za prodajna pitanja, petnaest za promjene proizvoda i petnaest za ažuriranje stranice. Ako naplaćujete održavanje sadržaja, to postaje linija ponavljajućeg prihoda. Ako ne, to sprječava starenje stranice. Postoji jedna metrika vrijedna praćenja, čak i ako ne možete pridodati tvrd broj: prijavljuje li tim za podršku manje istih pitanja. Kada tim za podršku prestane odgovarati na pitanje koje je sada na FAQ-u, to je pobjeda i obično je vidljiva u tonu tima prije nego što se pojavi na bilo kojoj nadzornoj ploči. Kada tim za podršku počne predlagati nove unose u FAQ, znate da je proces održavanja zaživio.

Ništa od ovoga ne zahtijeva redizajn ili novi alat. Zahtijeva promjenu u načinu na koji razgovarate o FAQ-u sa svojim klijentom. Prestanite ga zvati "FAQ" u projektnim planovima i počnite ga zvati "stranica prigovora." Ta jedna promjena preoblikovat će svaku odluku koja slijedi, od pitanja koja prikupljate do odgovora koje pišete. Također će znatno olakšati argument za održavanje stranice jer nijedan klijent ne osporava potrebu da se prigovori stalno otklanjaju.