SaaS FAQ lapas ir konversijas darba zirgs, ko aģentūras neievēro

Summary

Lielākā daļa SaaS FAQ lapu ir veidotas no atbalsta biļetēm, kas nozīmē, ka tās atbild uz jautājumiem no cilvēkiem, kuri jau ir iegādājušies — vienlaikus ignorējot iebildumus, kas attur potenciālos pircējus no pirkuma. Šis raksts pārvērš FAQ no pēcpārdošanas pieminējuma par pārdošanas aktīvu. Rakstīts aģentūrām, kas veido vietnes vairākiem klientiem, tas aptver atkārtojamu procesu: apkopojiet iebildumus no pārdošanas komandas, grupējiet jautājumus pēc pirkšanas posma, rakstiet atbildes, kas ir pietiekami pilnīgas, lai izbeigtu meklēšanu, savienojiet katru iebildumu ar konkrētu sociālo pierādījumu un uzturiet lapu reizi ceturksnī. Mītu pret realitāti formāts parāda, kas patiesībā darbojas, ar praktisku piemēru katrā sadaļā. Rezultāts ir FAQ lapa, kas samazina atbalsta slodzi un palielina iespēju, ka potenciāls klients reģistrēsies.

Lielākā daļa ieteikumu par SaaS FAQ lapām sākas no nepareizās vietas. Tās tiek uztvertas kā pēcpārdošanas uzkopšana — vieta, kur novietot atbildes uz atbalsta biļetēm, lai atbalsta komanda vairs neatkārtotos. Šī pieeja ir iemesls, kāpēc jūsu klienta FAQ lapa uzņēmumam gandrīz neko nedod. Kas patiesībā darbojas: FAQ lapa ir viena no retajām lapām, ko potenciālais klients apmeklē pēc tam, kad jau ir nolēmis, ka varētu iegādāties. Tā ir lēmuma posma lapa, nevis dokumentācijas lapa. Tai jābūt veidotai, lai novērstu iebildumus, kas stāv starp apmeklētāju un reģistrēšanos, un tā ir pelnījusi tādu pašu stratēģisko uzmanību kā cenu lapa.

Ja strādājat aģentūrā, problēma ir vēl asāka. Katrs klients ir atšķirīgs: atšķirīgs produkts, atšķirīgs pircējs, atšķirīga atbalsta vēsture. Tomēr jums ir jārada kaut kas, kas darbojas, nesākot no nulles katru reizi. Kārdinājums ir kopēt pēdējās uzbūvētās FAQ struktūru. Tas darbojas, līdz vairs nedarbojas, jo iebildumi, kas ir svarīgi fintech klientam, nav tie paši, kas svarīgi komandas sadarbības klientam. Sistēmai jābūt vienādai; saturam jābūt atšķirīgam. Zemāk esošā mītu kliedēšana ir šī sistēma. Pamatā esošais modelis ir vienkāršs: gaidiet, ka FAQ pārdos, nevis tikai informēs. Tas maina to, kā apkopojat jautājumus, kā tos grupējat, cik garas ir atbildes un ko novietojat blakus.

Start with the sale, not the support ticket

Sāciet, lūdzot klienta pārdošanas komandai pēdējos piecus darījumus, kas apstājās. Jautājumi, kas apturēja šos darījumus, ir pirmie desmit jautājumi, uz kuriem jūsu FAQ lapai jāatbild. Lielākā daļa FAQ lapu ir veidotas no atbalsta biļetēm — jautājumiem no cilvēkiem, kuri jau ir iegādājušies. Jautājumi, kas patiešām bloķē pārdošanu, nāk no cilvēkiem, kuri nav iegādājušies, un tie parasti attiecas uz migrāciju, drošību, cenām un to, kas notiek pēc izmēģinājuma perioda beigām.

Lūk, kā tas izskatās praksē. Darbplūsmas automatizācijas klients pie mums atnāca ar FAQ, kas bija pilns ar tādiem jautājumiem kā "Kā atiestatīt paroli?" un "Kuras pārlūkprogrammas tiek atbalstītas?" Lapa bija tehniski noderīga, bet komerciāli neefektīva. Tāpēc mēs jautājām pārdošanas komandai, ko viņi dzirdēja zaudētajos darījumos. Izrādījās, ka potenciālie klienti jautāja, vai rīks var aizstāt viņu pašreizējo izklājlapu, vai migrācijai būs nepieciešama IT nodaļa un vai pārdevēja cenu lapa atbilst tam, ko rēķins faktiski iekasēs. Mēs pārbūvējām FAQ ap šiem trim iebildumiem, katram pievienojot īsu atbildi un saiti uz attiecīgo lapu. Jautājumi par paroles atiestatīšanu tika pārvietoti uz atbalsta centru. Lapa kļuva par pārdošanas slēgšanas rīku, nevis palīdzības dienestu.

Veicot šo interviju, neapmierinieties ar atbildi "viņi jautā par cenām". Jautājiet precīzu formulējumu. "Vai cena ir par lietotāju vai par darbvietu?" ir rīcību rosinošs jautājums. "Viņi jautā par cenām" nav. Tāpat jautājiet, ko konkurents dara tādu, ko klients nevar viegli atdarināt — tas parasti atklāj iebildumus, kurus pārdošanas komanda ir nogurusi dzirdēt. Ievietojiet tos pašā lapas augšā.

Šeit ir viena vieta, kur SaaS vietnes veidošana no iekšienes uz āru atmaksājas: jūs sākat ar jautājumiem, ko uzdod īsti pircēji, un pēc tam veidojat vietni ap tiem. Jāatzīmē, ka nevarat pilnībā izlaist atbalsta jautājumus. Daži apmeklētāji ir esošie klienti. Bet lapas galvenajai platībai jābūt veltītai jautājumiem, kas rodas pirms pirkuma, nevis pēc tā. Ja jums ir nepieciešams saglabāt dažus atbalsta jautājumus lapā, pārvietojiet tos uz pašu apakšu zem skaidri iezīmēta virsraksta "Esošie klienti". Tādā veidā jūs apkalposiet abas auditorijas, neļaujot atbalsta jautājumiem dominēt. Noderīgs veids, kā veikt interviju, ir nosūtīt pārdošanas komandai vienkāršu pamudinājumu: uzskaitiet katru jautājumu, ko potenciālais klients uzdeva pagājušajā mēnesī un uz kuru jums bija jāatbild manuāli. Jūs saņemsiet divus sarakstus. Jautājumi, kuriem nepieciešams spriedums, ir FAQ materiāls; tie, uz kuriem var atbildēt ar saiti, pieder dokumentācijai.

Length is not thoroughness

Princips, pie kura vērts pieturēties, ir atbilstība pēc pozīcijas. Apmeklētājs trīs minūtes pēc bezmaksas izmēģinājuma sākuma uzdod citu jautājumu nekā iepirkumu speciālists, kurš izvērtē rīku. Ja FAQ ir vienots alfabētisks saraksts, iepirkumu speciālistam ir jāpārlūko "Kā mainīt avataru?", lai atrastu "Kā jūs rīkojaties ar datu glabāšanas vietu?" Lielākā daļa apmeklētāju to nedarīs. Viņi aizies.

Vienam klientam, projektu pārvaldības SaaS uzņēmumam, bija FAQ, kas bija sakārtots alfabētiski un stiepās vairāku lapu garumā. Mēs to pārgrupējām četrās kategorijās: "Pirms sākuma" (ko tas dara, kā tas salīdzinās), "Izmēģinājuma laikā" (iestatīšana, ierobežojumi), "Pirkšana" (cenas, rēķini, drošības pārskati) un "Pēc pirkuma" (norēķinu izmaiņas, atbalsts). Pirkšanas kategorija tika novietota pirmajā vietā, jo tur tika zaudēta nauda. Vārdu skaits daudz nemainījās, bet lapa no saraksta kļuva par vadītu ceļu.

Katrā kategorijā izmantojiet vienu no diviem kārtošanas noteikumiem. Ja produktam ir skaidrs pirkšanas veids, kārtojiet pēc nopietnības: jautājums, kas pilnībā aptur darījumu, ir pirmajā vietā. Ja produktam nav acīmredzamas secības, kārtojiet pēc biežuma — bet tikai kategorijas ietvaros, nevis visā lapā. Svarīgi, lai apmeklētājs var atrast sev interesējošo jautājumu, nelasot visu. Lapas augšpusē izmantojiet enkursaites, lai iepirkumu speciālists varētu pārlēkt tieši uz sadaļu "Pirkšana", bet izmēģinājuma lietotājs — uz "Izmēģinājuma laikā". Tipiskā SaaS vietnē šīs ir divas grupas, kas rada visvairāk reģistrēšanos un visvairāk zaudētu darījumu, tāpēc tās atrodas lapas augšpusē.

Īpaši attiecībā uz cenu jautājumiem tā pati loģika, ko pielietotu konversijām optimizētai cenu lapai, attiecas uz FAQ: vispirms ievietojiet lēmumam svarīgas detaļas, pēc tam pamatojumu, tad saiti. Nelieciet apmeklētājam meklēt vēlamā plāna cenu. Un pirkšanas kategorijā vēlreiz padomājiet par secību. Novietojiet drošību un atbilstību pirms maksāšanas metodēm, jo drošības pārskats bieži vien ir vārtu sargs, kas aptur izvērtēšanu, pirms rodas jautājums par maksājumu.

Mīts	Realitāte
FAQ pastāv, lai atbildētu uz jautājumiem	FAQ pastāv, lai novērstu pirkšanas iebildumus
Garāks FAQ nozīmē rūpīgāku	Uztverams, grupēts FAQ pārspēj garu sarakstu
Atbildēm jābūt īsām	Atbildēm jābūt pietiekami pilnīgām, lai izbeigtu meklēšanu
Sociālais pierādījums pieder tikai sākumlapai	Pierādījums blakus iebildumam konvertē labāk
FAQ ir palaišanas rezultāts	FAQ ir dzīvs dokuments ar pārskatīšanas regularitāti

The cost of a too-short answer

Lūk, piemērs pirms un pēc, ko izmantojam ar klientiem, kad viņi iebilst pret "gariem" atbildēm.

Pirms: "Vai atbalstāt SSO? Jā, atbalstām."

Pēc: "SSO ir pieejams Pro plānā un augstāk. To varat iespējot, kad esat darbvietas īpašnieks, sadaļā Iestatījumi > Drošība. Šeit ir soli pa solim sniegts ceļvedis. Ja jūsu komanda izmanto Okta vai Azure AD, abi tiek atbalstīti."

Otrā atbilde ir garāka, bet tā ir arī galīga. Apmeklētājs pārtrauc meklēšanu, jo atbilde paredz turpmākos jautājumus. Šāda rakstīšana šķiet vienkārša, bet tā prasa zināt, kādi patiesībā ir šie turpmākie jautājumi. Vienkāršākais veids, kā tos atrast, ir apskatīt populārākās atbalsta biļetes katrā funkciju jomā un iekļaut atbildes FAQ.

Izmantojamā struktūra ir: tieša atbilde, viens teikums kontekstam, pēc tam saite. Atzīmējiet tiešo atbildi treknrakstā, lai pārskatītājs to uzreiz redzētu. Ja jums ir ekrānuzņēmums, ievietojiet to pēc konteksta, nevis pirms tā. Neierakstiet atbildi rindkopā, kas apraksta funkciju. Tas pats princips padara tādu uzņēmumu kā Stripe un Twilio API dokumentāciju izcilu: jūs varat nokļūt, saņemt atbildi un doties prom. Mēs šo standartu padziļināti apskatām mūsu ceļvedī par SaaS API dokumentācijas rakstīšanu, ko izstrādātāji patiešām izmanto. Jāpiebilst, ka "pilnīga" nenozīmē "gara pašas labad". Īsziņu siena joprojām ir siena.

Pastāv arī tonis. Pārāk īsa atbilde mēdz izklausīties kodolīga vai pat rupja; pārāk gara atbilde izklausās aizsardzīga. Vislabākā vieta ir atbilde, ko kompetents atbalsta darbinieks sniegtu e-pastā: tieša atbilde, īss skaidrojums un nākamais solis. Ja jūsu klienta atbalsta komanda raksta noderīgus e-pastus, palūdziet dažus un izmantojiet tos kā paraugu. Ja nē, varat pats uzrakstīt paraugu un ļaut atbalsta komandai to labot. Tas ir arī labs veids, kā iegūt atbalsta komandas atsaucību, jo FAQ sāk izskatīties kā viņu labākie e-pasti, nevis korporatīvs dokuments.

Pair the objection with its proof

Ņemiet katru iebildumu klienta FAQ un uzdodiet vienu jautājumu: kāds sociālais pierādījums to atspēkotu? E-paraksta klientam mājaslapā bija spēcīga atsauksmju sadaļa. Bet, kad mēs aplūkojām FAQ drošības jautājumu — "Kā jūs nodrošināt manu dokumentu drošību?" — atbilde bija sausa atbilstības valoda. Mājaslapas atsauksme no juridiskās komandas, kurā teikts "mūsu atbilstības komanda tos apstiprināja mazāk nekā dienā", bija tieši tā pārliecība, kas šai atbildei bija nepieciešama.

Mēs sākām savienot katru iebildumu ar pierādījumu: drošības jautājums ieguva atbilstības atsauksmi, cenu jautājums ieguva citātu no klienta, kurš pārgāja no konkurenta, migrācijas jautājums ieguva rindiņu par klientu, kurš pārcēla visu savu uzņēmumu bez dīkstāves. FAQ pārstāja būt atsevišķa lapa un kļuva par daļu no piedāvājuma.

Šeit svarīga ir atbilstība. Logo siena blakus FAQ maz ko dod; atsauksme, kas tieši adresē iebildumu, ir svarīga, īpaši, ja tajā norādīta tās sniedzēja loma. Ja jūsu klientam vēl nav šāda pierādījuma, sāciet to vākt no tiem pašiem pārdošanas zvaniem, kas rada iebildumus. Abi resursi nāk no viena avota. Ja jums ir atsauksme, izņemiet vienu frāzi, kas atbilst FAQ jautājumam. Jums nav nepieciešams pilns citāts; pietiek ar vienu konkrētu teikumu. Lūdziet pārdošanas komandai atzīmēt, kad darījums tiek noslēgts, vai klients minēja kādu konkrētu bažu. Šī baža ir nākotnes FAQ jautājums, un klienta paša vārdi ir tā labākā atbilde.

Ir arī otrs, mazāk acīmredzams pierādījumu veids: produkta pierādījums. Ja potenciālais klients jautā "Vai es varu eksportēt savus datus?" spēcīgākā atbilde ietver ekrānuzņēmumu no eksporta ekrāna, nevis tikai teikumu "jā". Ja viņi jautā "Cik ilgi ilgst izmēģinājuma periods?" spēcīgākā atbilde ietver rindiņu par to, kas notiek pēc tā beigām. Ekrānuzņēmumi un īsi GIF attēli šeit darbojas, jo tie parāda, nevis apgalvo. Šeit arī FAQ savienojas ar funkciju demonstrāciju: jautājumam, piemēram, "Kā tas atšķiras no izklājlapas?" vajadzētu saistīt ar vietnes sadaļu, kas demonstrē atšķirību, nevis ar salīdzinošu tekstu sienu.

An FAQ is a process, not a launch deliverable

Noturīgais princips aģentūrai ir tāds, ka FAQ lapa ir process, nevis lapa. Klienta produkts mainās katru mēnesi; jauni iebildumi parādās ar katrām cenu izmaiņām, katru jaunu konkurentu, katru ceturksni. Lapa, ko palaižat janvārī, martā jau ir minējums. Aģentūras, kas šo padara atkārtojamu, iekļauj vieglu uzturēšanas ritmu sadarbībā.

Pēc palaišanas izveidojiet ceturkšņa pārskatu, kurā aplūkojat trīs datu avotus: jaunas atbalsta biļetes, jautājumus no pārdošanas zvaniem un produkta izmaiņas. Sadaliet pārskatu divos soļos. Pirmkārt, noņemiet jautājumus, kas vairs nav svarīgi. Otrkārt, pievienojiet jautājumus, kas parādījušies pēdējo 90 dienu laikā. Šim nolūkam nav nepieciešams satura stratēģis. Nepieciešams ieradums.

Mēs to ieviesām vienam klientam, lūdzot atbalsta vadītājam iezīmēt jebkuru biļeti, uz kuru varētu atbildēt vietne. Pēc pāris ceturkšņiem atbalsta vadītājs sāka mums sūtīt bieži uzdoto jautājumu sarakstu, pirms mēs to pat prasījām. FAQ kļuva par kopīgu projektu, un tas ir vienīgais veids, kā tas paliek aktuāls. Jebkurai aģentūrai, kas šādu darbu veic vairākos projektos, FAQ kā daļa no atkārtojamas SaaS vietņu sistēmas ir tas, kas uztur kvalitāti nemainīgu, nevis katru reizi izgudro procesu no jauna.

Pārskatīšana nav jāveic ilgāk par stundu. Piecpadsmit minūtes atbalsta biļetēm, piecpadsmit pārdošanas jautājumiem, piecpadsmit produkta izmaiņām un piecpadsmit lapas atjaunināšanai. Ja rēķināt par satura uzturēšanu, tas kļūst par atkārtotu ieņēmumu līniju. Ja nē, tas neļauj lapai novecot. Ir viena metrika, kuru vērts sekot, pat ja nevarat piesaistīt konkrētu skaitli: vai atbalsta komanda ziņo par mazāk tādiem pašiem jautājumiem. Kad atbalsta komanda pārstāj atbildēt uz jautājumu, kas tagad ir FAQ, tas ir ieguvums, un tas parasti ir redzams komandas tonī, pirms tas parādās jebkurā informācijas panelī. Kad atbalsta komanda sāk ieteikt jaunus FAQ ierakstus, jūs zināt, ka uzturēšanas process ir iesakņojies.

Nekas no tā neprasa pārveidi vai jaunu rīku. Tas prasa izmaiņas tajā, kā jūs ar klientu runājat par FAQ. Pārtrauciet to saukt par "FAQ" projektu plānos un sāciet saukt par "iebildumu lapu". Šī viena izmaiņa pārveidos visus turpmākos lēmumus, sākot ar apkopojamajiem jautājumiem un beidzot ar rakstāmajām atbildēm. Tā arī padarīs daudz vieglāku lapas uzturēšanas pamatojumu, jo neviens klients neapstrīd nepieciešamību turpināt novērst iebildumus.