SaaS FAQ страниците са конверсионният работен кон, който агенциите пренебрегват

Резюме

Повечето SaaS FAQ страници са изградени от тикети за поддръжка, което означава, че отговарят на въпроси от хора, които вече са купили — докато игнорират възраженията, които спират потенциалните клиенти да купят. Тази статия преобръща FAQ от мисъл след пускането в актив за продажби. Написана за агенции, които изграждат сайтове за множество клиенти, тя обхваща повтаряем процес: съберете възражения от търговския екип, групирайте въпросите по етап на покупка, напишете отговори, които са достатъчно пълни, за да прекратят търсенето, съчетайте всяко възражение със специфични социални доказателства и поддържайте страницата на тримесечен цикъл. Форматът мит срещу реалност показва какво наистина работи, с практически пример във всеки раздел. Резултатът е FAQ страница, която намалява натоварването на поддръжката и увеличава шанса потенциален клиент да се регистрира.

Повечето съвети за SaaS FAQ страници започват от грешното място. Те ги третират като почистване след пускането — място, където да паркирате отговори на тикети за поддръжка, така че екипът за поддръжка да спре да се повтаря. Тази рамка е причината FAQ страницата на клиента ви да не прави почти нищо за бизнеса. Какво наистина работи: FAQ страницата е една от малкото страници, които потенциален клиент посещава, след като вече е решил, че може да купи. Тя е страница на етапа на вземане на решение, а не документация. Тя трябва да бъде изградена, за да премахне възраженията, стоящи между посетителя и регистрацията, и заслужава същото стратегическо внимание като страницата с цени.

Ако сте в агенция, проблемът е още по-остър. Всеки клиент е различен: различен продукт, различен купувач, различна история на поддръжката. И все пак трябва да създадете нещо, което работи, без да започвате от нула всеки път. Изкушението е да копирате структурата на последния FAQ, който сте изградили. Това работи, докато не спре да работи, защото възраженията, които имат значение за клиент във финтех, не са същите като тези за клиент, работещ върху сътрудничество на екипи. Рамката трябва да е същата; съдържанието трябва да е различно. Развенчаването на митовете по-долу е тази рамка. Моделът отдолу е прост: очаквайте FAQ да продава, а не само да информира. Това променя как събирате въпроси, как ги групирате, колко дълъг е всеки отговор и какво поставяте до него.

Започнете с продажбата, не с тикета за поддръжка

Започнете, като попитате търговския екип на клиента си за последните пет сделки, които замлъкнали. Въпросите, които спрели тези сделки, са първите десет въпроса, на които вашата FAQ страница трябва да отговори. Повечето FAQ страници са изградени от тикети за поддръжка — въпроси от хора, които вече са купили. Въпросите, които всъщност блокират продажбите, идват от хора, които не са купили, и те обикновено са за миграция, сигурност, цени и какво се случва след края на пробния период.

Ето как изглежда това на практика. Клиент за автоматизация на работни процеси дойде при нас с FAQ, пълен с въпроси като „Как да нулирам паролата си?“ и „Кои браузъри се поддържат?“ Страницата беше технически полезна и комерсиално инертна. Затова попитахме търговския екип какво чуват в загубените сделки. Оказа се, че потенциалните клиенти питат дали инструментът може да замени тяхната текуща електронна таблица, дали миграцията ще изисква ИТ, и дали ценовата листа на продавача съвпада с това, което фактурирането всъщност ще таксува. Преизградихме FAQ около тези три възражения, всяко с кратък отговор и връзка към относима страница. Въпросите за нулиране на парола се преместиха в центъра за поддръжка. Страницата се превърна в инструмент за приключване на сделки вместо помощен център.

Когато провеждате това интервю, не се задоволявайте с „питат за цени“. Поискайте точната формулировка. „Цената на потребител или на работно пространство ли е?“ е действено. „Питат за цени“ не е. Също така попитайте какво прави конкурентът, което клиентът не може лесно да съответства — това обикновено изважда възраженията, които търговският екип е уморен да чува. Поставете ги на самия връх на страницата.

Това е място, където изграждането на SaaS уебсайт отвътре навън се отплаща: започвате от въпросите, които реалните купувачи задават, след което изграждате сайта около тях. Предупреждението е, че не можете напълно да пропуснете въпросите за поддръжка. Някои посетители са съществуващи клиенти. Но първокласното място на страницата трябва да отиде за въпроси, които се появяват преди покупката, а не след нея. Ако трябва да запазите някои въпроси за поддръжка на страницата, преместете ги на самото дъно под ясно обозначено заглавие „Съществуващи клиенти“. По този начин обслужвате и двете аудитории, без да позволите на въпросите за поддръжка да доминират. Полезен начин да проведете интервюто е да изпратите на търговския екип обикновена подкана: избройте всеки въпрос, който потенциален клиент е задал миналия месец и на който сте трябвало да отговорите ръчно. Ще получите два списъка. Въпросите, които изискват преценка, са материал за FAQ; тези, на които може да се отговори с връзка, принадлежат към документацията.

Дължината не е изчерпателност

Принципът, който си струва да запазите, е релевантност чрез позиция. Посетител, който е три минути в безплатен пробен период, има различен въпрос от служител по доставки, оценяващ инструмента. Ако FAQ е един азбучен списък, служителят по доставки трябва да си проправи път през „Как да променя аватара си?“, за да намери „Как обработвате съхранението на данни?“ Повечето посетители няма да го направят. Те ще си тръгнат.

Един клиент, SaaS за управление на проекти, имаше FAQ, който беше подреден по азбучен ред и се простираше на няколко страници. Прегрупирахме го в четири категории: „Преди да започнете“ (какво прави, как се сравнява), „По време на пробния период“ (настройка, ограничения), „Покупка“ (цени, фактуриране, прегледи на сигурността) и „След покупка“ (промени в таксуването, поддръжка). Категорията „Покупка“ отиде първа, защото там се губеха парите. Броят на думите не се промени много, но страницата се превърна от списък в насочващ път.

Във всяка категория използвайте едно от двете правила за подреждане. Ако продуктът има ясен начин за покупка, подредете по тежест: въпросът, който спира сделката направо, е първи. Ако продуктът няма очевидна последователност, подредете по честота — но само в рамките на категорията, не на цялата страница. Важното е посетителят да може да намери въпроса, който го интересува, без да чете всичко. Използвайте котвени връзки в горната част на страницата, така че служител по доставки да може да скочи направо до „Покупка“, а потребител на пробния период — до „По време на пробния период“. На типичен SaaS сайт това са двете групи, които генерират най-много регистрации и най-много загубени сделки, затова те получават горната част на страницата.

За въпросите относно цените по-специално, същата логика, която бихте приложили към ценова страница, създадена за реализации, важи и вътре в FAQ: поставете детайлите, свързани с решението, първо, след това обосновката, после връзката. Не карайте посетителя да търси цената на плана, който иска. И в категорията „Покупка“ помислете отново за последователността. Поставете сигурността и съответствието преди методите на плащане, защото прегледът на сигурността често е вратар, който спира оценката, преди изобщо да възникне въпрос за плащане.

Мит	Реалност
FAQ съществува, за да отговаря на въпроси	FAQ съществува, за да премахва възраженията за покупка
По-дългият FAQ означава по-голяма изчерпателност	Сканируемият, групиран FAQ се представя по-добре от дълъг списък
Отговорите трябва да са кратки	Отговорите трябва да са достатъчно пълни, за да прекратят търсенето
Социалното доказателство принадлежи само на началната страница	Доказателство, поставено до възражение, преобразува по-добре
FAQ е резултат от пускането	FAQ е жив документ с цикъл на преглед

Цената на твърде краткия отговор

Ето примера преди-след, който използваме с клиенти, когато възразяват срещу „дългите“ отговори.

Преди: „Поддържате ли SSO? Да, поддържаме.“

След: „SSO е достъпен за плана Pro и нагоре. Можете да го активирате, щом сте собственик на работното пространство, от Настройки > Сигурност. Ето ръководство стъпка по стъпка. Ако екипът ви използва Okta или Azure AD, и двете се поддържат.“

Вторият отговор е по-дълъг, но също така е окончателен. Посетителят спира да търси, защото отговорът предвижда последващите въпроси. Писането така изглежда просто, но изисква да знаете какви са последващите въпроси в действителност. Най-лесният начин да ги намерите е да разгледате най-честите тикети за поддръжка за всяка функционална област и да включите отговорите в FAQ.

Структурата, която да използвате, е: директен отговор, едно изречение контекст, след това връзка. Удебелете директния отговор, така че четецът да го види веднага. Ако имате екранна снимка, поставете я след контекста, а не преди него. Не заравяйте отговора в параграф, който описва функцията. Това е същият принцип, който прави API документацията на компании като Stripe и Twilio да се откроява: можете да влезете, да получите отговора и да излезете. Навлизаме по-дълбоко в този стандарт в нашето ръководство за писмене на SaaS API документация, която разработчиците наистина използват. Предупреждението е, че „пълно“ не означава „дълго заради самото дълго“. Стена от текст си остава стена от текст.

Има и въпрос за тона. Твърде краткият отговор има тенденция да звучи рязко или дори грубо; твърде дългият отговор звучи защитно. Сладкото място е отговорът, който компетентен служител по поддръжката би дал в имейл: директен отговор, кратко обяснение и следваща стъпка. Ако екипът за поддръжка на клиента ви пише полезни имейли, поискайте няколко и ги използвайте като модел. Ако не го прави, можете сами да напишете модела и да оставите екипа за поддръжка да го коригира. Това също е добър начин да спечелите подкрепата на екипа за поддръжка, защото FAQ започва да прилича на най-добрите им имейли, а не на корпоративен документ.

Съчетайте възражението с неговото доказателство

Вземете всяко възражение във FAQ на клиента си и задайте един въпрос: кое социално доказателство би обезвредило това? Клиент за електронни подписи имаше силна секция с отзиви на началната страница. Но когато погледнахме въпроса за сигурността във FAQ — „Как пазите документите ми в безопасност?“ — отговорът беше сух език за съответствие. Отзивът на началната страница от правен екип, който казва „нашият екип за съответствие ги одобри за по-малко от ден“, беше точно уверението, от което се нуждаеше този отговор.

Започнахме да съчетаваме всяко възражение с доказателство: въпросът за сигурността получи отзив за съответствие, въпросът за цените получи цитат от клиент, който е преминал от конкурент, въпросът за миграцията получи ред за клиент, който е преместил цялата си компания без престой. FAQ престана да бъде отделна страница и се превърна в част от презентацията.

Предупреждението тук е релевантността. Стена от лога до FAQ добавя малко; отзив, който директно адресира възражението, носи тежест, особено когато посочва ролята на човека, който го дава. Ако клиентът ви все още няма такова доказателство, започнете да го събирате от същите търговски разговори, които генерират възраженията. Двата актива идват от един и същи източник. Когато имате отзив, извлечете една клауза, която съвпада с въпрос от FAQ. Не ви трябва целият цитат; едно конкретно изречение е достатъчно. Помолете търговския екип да отбележи, когато сделка приключи, дали клиентът е споменал конкретно притеснение. Това притеснение е бъдещ въпрос за FAQ, а собствените думи на клиента са най-добрият му отговор.

Има и втори, по-малко очевиден вид доказателство: продуктово доказателство. Ако потенциален клиент попита „Мога ли да експортирам данните си?“ най-силният отговор включва екранна снимка на екрана за експортиране, не само изречение, казващо „да“. Ако попитат „Колко дълго трае пробният период?“ най-силният отговор включва ред за това какво се случва, когато изтече. Екранните снимки и кратки GIF файлове работят тук, защото показват вместо да твърдят. Това е и където FAQ се свързва с демонстрацията на функции: въпрос като „С какво това се различава от електронна таблица?“ трябва да води към секцията от сайта, която демонстрира разликата, а не към стена от сравнителен текст.

FAQ е процес, а не резултат от пускането

Трайният принцип за агенцията е, че FAQ страницата е процес, а не страница. Продуктът на клиента се променя всеки месец; нови възражения се появяват с всяка промяна на цените, всеки нов конкурент, всяко тримесечие. Страницата, която стартирате през януари, е предположение до март. Агенциите, които правят това повтаряемо, вграждат лек цикъл на поддръжка в ангажимента.

След пускането задайте тримесечен преглед, в който разглеждате три входа: нови тикети за поддръжка, въпроси от търговски разговори и промени в продукта. Разделете прегледа на две стъпки. Първо, премахнете въпроси, които вече нямат значение. Второ, добавете въпроси, които са се появили през последните 90 дни. Не ви трябва стратег за съдържание за това. Трябва ви навик.

Въведохме това за един клиент, като помолихме ръководителя на поддръжката да маркира всеки тикет, на който уебсайтът би могъл да отговори. След няколко тримесечия ръководителят на поддръжката започна да ни изпраща списък с повтарящи се въпроси, преди да попитаме. FAQ се превърна в споделен проект, което е единственият начин да остане релевантен. За всяка агенция, която извършва този вид работа в множество ангажименти, третирането на FAQ като част от повтаряема система за SaaS уебсайтове е това, което поддържа качеството последователно, без да преоткрива процеса всеки път.

Прегледът не трябва да отнема повече от час. Петнадесет минути за тикети за поддръжка, петнадесет за въпроси от продажби, петнадесет за промени в продукта и петнадесет за актуализиране на страницата. Ако таксувате поддръжката на съдържанието, това се превръща в повтарящ се приход. Ако не го правите, това предпазва страницата от остаряване. Има един показател, който си струва да следите, дори и да не можете да прикачите твърдо число: дали екипът за поддръжка съобщава за по-малко от същите въпроси. Когато екипът за поддръжка спре да отговаря на въпрос, който вече е във FAQ, това е победа и обикновено се вижда в тона на екипа, преди да се появи в някое табло. Когато екипът за поддръжка започне да предлага нови записи във FAQ, знаете, че процесът на поддръжка се е вкоренил.

Нищо от това не изисква редизайн или нов инструмент. Това, което изисква, е промяна в начина, по който говорите за FAQ с клиента си. Престанете да го наричате „FAQ“ в плановете на проекта и започнете да го наричате „страницата на възраженията“. Тази единствена промяна ще преоформи всяко решение, което следва, от въпросите, които събирате, до отговорите, които пишете. Това също така ще улесни аргумента за поддържане на страницата, защото никой клиент не оспорва необходимостта да продължава да отблъсква възраженията.