SaaS FAQ stranice su konverzijski radni konj kojeg agencije zanemaruju

Sažetak

Većina SaaS FAQ stranica izrađena je od zahtjeva za podršku, što znači da odgovaraju na pitanja ljudi koji su već kupili — dok ignorišu primjedbe koje sprječavaju potencijalne kupce da kupe. Ovaj članak preokreće FAQ iz post-lansirne naknadne misli u prodajni alat. Napisan za agencije koje izrađuju stranice za više klijenata, pokriva ponovljiv proces: prikupite primjedbe od prodajnog tima, grupirajte pitanja po fazi kupovine, napišite odgovore koji su dovoljno potpuni da okončaju pretragu, uparite svaku primjedbu sa specifičnim društvenim dokazom i održavajte stranicu na kvartalnom ritmu. Format mit-naspram-realnosti pokazuje šta zapravo funkcioniše, s praktičnim primjerom u svakoj sekciji. 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 podrška prestala ponavljati. Takav okvir je razlog zašto FAQ stranica vašeg klijenta ne radi gotovo ništa za posao. Ono što zapravo funkcioniše: FAQ stranica je jedna 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 dokumentacija. Treba je izgraditi tako da ukloni primjedbe koje stoje između posjetitelja i prijave te zaslužuje istu stratešku pažnju kao i stranica s cijenama.

Ako ste u agenciji, problem je još oštriji. Svaki klijent je drugačiji: drugačiji proizvod, drugačiji kupac, drugačija istorija podrške. Ipak, morate proizvesti nešto što funkcioniše bez početka od nule svaki put. Iskušenje je kopirati strukturu posljednjeg FAQ-a koji ste izradili. To funkcioniše dok ne prestane, jer primjedbe koje su važne fintech klijentu nisu iste kao one koje su važne klijentu za timsku saradnju. Okvir mora biti isti; sadržaj mora biti drugačiji. Razbijanje mitova ispod je taj okvir. Uzorak ispod je jednostavan: očekujte da FAQ prodaje, a ne samo informiše. To mijenja način na koji prikupljate pitanja, kako ih grupirate, koliko dug je svaki odgovor i šta stavljate pored njega.

Krenite od prodaje, a ne od zahtjeva za podršku

Započnite tako što ćete prodajni tim vašeg klijenta pitati za posljednjih pet poslova koji su utihnuli. Pitanja koja su zaustavila te poslove prva su deset pitanja na koja bi vaša FAQ stranica trebala odgovoriti. Većina FAQ stranica izrađena je od zahtjeva za podršku — pitanja od ljudi koji su već kupili. Pitanja koja zapravo blokiraju prodaju dolaze od ljudi koji nisu kupili, a obično se tiču migracije, sigurnosti, cijena i onoga što se događa nakon što probni period završi.

Evo kako to izgleda u praksi. Klijent za automatizaciju radnih tokova došao nam je s FAQ-om punim pitanja poput "Kako da resetujem lozinku?" i "Koji preglednici su podržani?" Stranica je bila tehnički korisna, a komercijalno inertna. Pitali smo prodajni tim šta su čuli u izgubljenim poslovima. Ispostavilo se da su potencijalni kupci pitali može li alat zamijeniti njihovu trenutnu tabelu, zahtijeva li migracija IT podršku i odgovara li prodajna cijena onome što će račun zapravo naplatiti. Rekonstruisali smo FAQ oko te tri primjedbe, svaku s kratkim odgovorom i linkom na relevantnu stranicu. Pitanja o resetovanju lozinke preseljena su u centar za podršku. Stranica je postala alat za zatvaranje prodaje umjesto službe za pomoć.

Kada vodite ovaj intervju, ne zadovoljavajte se s "pitaju o cijenama." Pitajte za tačan tekst. "Je li cijena po korisniku ili po radnom prostoru?" je upotrebljivo. "Pitaju o cijenama" nije. Također pitajte šta konkurent radi što klijent ne može lako dostići — to obično otkriva primjedbe na koje je prodajni tim umoran od slušanja. Stavite ih na sam vrh stranice.

Ovo je jedno od mjesta gdje se izgradnja SaaS web stranice iznutra prema van isplati: počinjete od pitanja koja stvarni kupci postavljaju, a zatim gradite stranicu oko njih. Napomena: ne možete u potpunosti preskočiti pitanja podrške. Neki posjetitelji su postojeći kupci. Ali najvažniji dio stranice trebao bi ići pitanjima koja se pojavljuju prije kupovine, a ne nakon. Ako trebate zadržati neka pitanja podrške na stranici, premjestite ih na sam dno pod jasno označenim naslovom "Postojeći kupci." Tako služite obje publike, a da pitanja podrške ne dominiraju. Koristan način za provođenje intervjua jeste da prodajnom timu pošaljete jednostavan upit: navedite svako pitanje koje je potencijalni kupac postavio prošlog mjeseca na koje ste morali odgovoriti ručno. Dobit ćete dvije liste. Pitanja koja zahtijevaju prosudbu materijal su za FAQ; ona na koja se može odgovoriti linkom pripadaju dokumentaciji.

Dužina nije temeljitost

Princip koji vrijedi zadržati je relevantnost po poziciji. Posjetitelj tri minute u besplatnom probnom periodu ima drugačije pitanje od službenika za nabavku koji procjenjuje alat. Ako je FAQ jedna abecedna lista, službenik za nabavku mora pročešljati "Kako da promijenim avatar?" da bi pronašao "Kako postupate s rezidencijalnošću podataka?" Većina posjetitelja neće. Otići će.

Jedan klijent, SaaS za upravljanje projektima, imao je FAQ koji je bio abecedno posložen i dug nekoliko stranica. Pregrupisali smo ga u četiri kategorije: "Prije nego što počnete" (šta radi, kako se poredi), "Tokom probnog perioda" (podešavanje, ograničenja), "Kupovina" (cijene, fakture, sigurnosni pregledi) i "Nakon kupovine" (promjene naplate, podrška). Kategorija kupovine bila je prva jer se tu gubio novac. Broj riječi nije se mnogo promijenio, ali stranica je s liste postala vođeni put.

Unutar svake kategorije koristite jedno od dva pravila redoslijeda. Ako proizvod ima jasan način kupovine, poredajte po ozbiljnosti: pitanje koje odmah zaustavlja posao ide prvo. Ako proizvod nema očigledan slijed, poredajte po učestalosti — ali samo unutar kategorije, ne na cijeloj stranici. Bitno je da posjetitelj može pronaći pitanje koje ga zanima bez čitanja svega. Koristite sidrene linkove na vrhu stranice kako bi službenik za nabavku mogao skočiti ravno na "Kupovina", a korisnik probnog perioda na "Tokom probnog perioda." Na tipičnoj SaaS stranici, ovo su dvije grupe koje donose najviše prijava i najviše izgubljenih poslova, pa idu na vrh stranice.

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

Mit	Stvarnost
FAQ postoji da odgovori na pitanja	FAQ postoji da ukloni primjedbe na kupovinu
Duži FAQ znači temeljitiji	Pregledan, grupisan FAQ nadmašuje dugu listu
Odgovori trebaju biti kratki	Odgovori trebaju biti dovoljno potpuni da okončaju pretragu
Društveni dokaz pripada samo na početnu stranicu	Dokaz postavljen pored primjedbe bolje konvertira
FAQ je isporuka lansiranja	FAQ je živi dokument s ritmom pregleda

Cijena prekratkog odgovora

Ovdje je prije-i-poslije koji koristimo s klijentima kada se bune protiv "dugih" odgovora.

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

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

Drugi odgovor je duži, ali je i konačan. Posjetitelj prestaje tražiti jer odgovor predviđa dodatna pitanja. Ovakvo pisanje izgleda jednostavno, ali zahtijeva poznavanje stvarnih dodatnih pitanja. Najlakši način da ih pronađete jeste da pogledate najčešće zahtjeve za podršku za svako područje funkcija i ugradite odgovore u FAQ.

Struktura koju treba koristiti je: direktan odgovor, jedna rečenica konteksta, zatim link. Podebljajte direktan odgovor kako bi ga onaj ko prelijeće odmah vidio. Ako imate snimak ekrana, stavite ga nakon konteksta, ne prije. Ne zakopavajte odgovor u paragraf koji opisuje funkciju. To je isti princip koji čini API dokumentaciju kompanija poput Stripea i Twilio-a istaknutom: možete doći, dobiti odgovor i otići. Dublje analiziramo taj standard u našem vodiču za pisanje SaaS API dokumentacije koju programeri zaista koriste. Napomena: "potpun" ne znači "dug radi dužine". Zid teksta i dalje je zid teksta.

Postoji i pitanje tona. Prekratak odgovor obično zvuči kratko ili čak nepristojno; predugačak odgovor zvuči odbrambeno. Idealno je rješenje koje bi kompetentna osoba za podršku dala u e-poruci: direktan 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 koristite ih kao model. Ako ne pišu, možete sami napisati model i pustiti tim za podršku da ga ispravi. To je također dobar način da dobijete podršku tima jer FAQ počinje izgledati poput njihovih najboljih e-poruka, a ne korporativnog dokumenta.

Povežite primjedbu s njenim dokazom

Uzmite svaku primjedbu na FAQ-u vašeg klijenta i postavite jedno pitanje: koji bi dio društvenog dokaza razoružao ovo? Klijent za e-potpis imao je snažan odjeljak s preporukama na početnoj stranici. Ali kada smo pogledali sigurnosno pitanje u FAQ-u — "Kako čuvate moje dokumente sigurnim?" — odgovor je bio suhoparan jezik usklađenosti. Preporuka s početne stranice od pravnog tima koja kaže "naš tim za usklađenost odobrio ih je za manje od jednog dana" bila je upravo uvjeravanje koje je tom odgovoru trebalo.

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

Napomena ovdje je relevantnost. Zid logotipa pored FAQ-a dodaje malo; preporuka koja se direktno odnosi na primjedbu ima težinu, posebno ako navodi ulogu osobe koja je daje. Ako vaš klijent još nema takvu vrstu dokaza, počnite ga prikupljati s istih prodajnih poziva koji stvaraju primjedbe. Ta dva sredstva dolaze iz istog izvora. Kad imate preporuku, izdvojite jednu rečenicu koja odgovara pitanju iz FAQ-a. Ne trebate puni citat; jedna konkretna rečenica je dovoljna. Zamolite prodajni tim da zabilježi, kada se posao zaključi, je li kupac spomenuo određenu zabrinutost. Ta zabrinutost buduće je pitanje u FAQ-u, a kupčeve vlastite riječi najbolji su odgovor.

Postoji i druga, manje očigledna vrsta dokaza: dokaz proizvoda. Ako potencijalni kupac pita "Mogu li izvesti svoje podatke?" najjači odgovor uključuje snimak ekrana izvoza, a ne samo rečenicu da. Ako pita "Koliko traje probni period?" najjači odgovor uključuje rečenicu o tome što se događa kad završi. Snimci ekrana i kratki GIF-ovi ovdje djeluju jer pokazuju umjesto tvrde. Ovo je također mjesto gdje se FAQ povezuje s prikazom funkcija: pitanje poput "Po čemu se ovo razlikuje od tabele?" treba voditi na dio stranice koji demonstrira razliku, a ne na zid teksta s usporedbom.

FAQ je proces, a ne isporuka pri lansiranju

Trajni princip za agenciju je da je FAQ stranica proces, a ne stranica. Proizvod klijenta mijenja se svakog mjeseca; nove primjedbe pojavljuju se sa svakom promjenom cijena, svakim novim konkurentom, svakim kvartalom. Stranica koju lansirate u januaru nagađanje je do marta. Agencije koje ovo čine ponovljivim ugrađuju lagani ritam održavanja u suradnju.

Nakon lansiranja, postavite kvartalni pregled gdje pogledate 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 posljednjih 90 dana. Ne trebate stratega sadržaja za ovo. Trebate naviku.

Ovo smo uveli za jednog klijenta tako što smo zamolili voditelja podrške da označi svaki zahtjev koji je mogao biti riješen putem web stranice. Nakon nekoliko kvartala, voditelj podrške počeo nam je slati listu 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 ovu vrstu posla kroz više angažmana, tretiranje FAQ-a kao dijela ponovljivog SaaS web sistema održava kvalitetu dosljednom bez ponovnog izmišljanja procesa svaki put.

Pregled ne mora trajati duže od sat vremena. Petnaest minuta za zahtjeve podrške, 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, sprečava stranicu da zastari. Postoji jedna metrika koju vrijedi pratiti, čak i ako ne možete pripisati tvrd broj: prijavljuje li tim za podršku manje istih pitanja. Kad 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 kontrolnoj ploči. Kad 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. Ono što zahtijeva jeste promjena u načinu na koji govorite o FAQ-u s klijentom. Prestanite ga zvati "FAQ" u projektnim planovima i počnite ga zvati "stranica primjedbi." Ta jedna promjena preoblikovat će svaku odluku koja slijedi, od pitanja koja prikupljate do odgovora koje pišete. Također će znatno olakšati argumentaciju za održavanje stranice jer nijedan klijent ne osporava potrebu za stalnim uklanjanjem primjedbi.