Страницы FAQ для SaaS — конверсионная рабочая лошадка, которую агентства упускают из виду

Резюме

Большинство страниц FAQ для SaaS построены на основе тикетов поддержки, а значит, они отвечают на вопросы людей, которые уже купили продукт, — игнорируя возражения, которые мешают потенциальным клиентам совершить покупку. Эта статья превращает FAQ из запоздалой мысли после запуска в продающий актив. Написанная для агентств, которые создают сайты для множества клиентов, она описывает повторяемый процесс: собирайте возражения от отдела продаж, группируйте вопросы по этапам покупки, пишите ответы, достаточно полные, чтобы завершить поиск, сочетайте каждое возражение с конкретным социальным доказательством и поддерживайте страницу с ежеквартальной периодичностью. Формат «миф против реальности» показывает, что действительно работает, с практическим примером в каждом разделе. В результате страница FAQ снижает нагрузку на поддержку и увеличивает вероятность регистрации потенциального клиента.

Большинство советов о страницах FAQ для SaaS начинаются с неправильной точки. Они рассматривают их как уборку после запуска — место, куда можно сложить ответы на тикеты поддержки, чтобы команда поддержки перестала повторяться. Из-за такого подхода страница 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, выдающейся: вы можете прийти, получить ответ и уйти. Мы глубже рассматриваем этот стандарт в нашем руководстве по написанию документации API для SaaS, которой разработчики действительно пользуются. Предостережение: «полный» не означает «длинный ради длины». Стена текста остается стеной текста.

Есть также вопрос тона. Слишком короткий ответ обычно звучит отрывисто или даже грубо; слишком длинный — оборонительно. Идеальное место — ответ, который компетентный сотрудник поддержки дал бы в электронном письме: прямой ответ, краткое объяснение и следующий шаг. Если команда поддержки вашего клиента пишет полезные письма, попросите несколько и используйте их как образец. Если нет, вы можете написать образец сами и позволить команде поддержки его исправить. Это также хороший способ заручиться поддержкой команды поддержки, потому что FAQ начинает выглядеть как их лучшие письма, а не как корпоративный документ.

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

Возьмите каждое возражение на странице FAQ вашего клиента и задайте один вопрос: какой элемент социального доказательства мог бы его нейтрализовать? У клиента из сферы электронных подписей на главной странице был сильный раздел с отзывами. Но когда мы посмотрели на вопрос безопасности в FAQ — «Как вы обеспечиваете сохранность моих документов?» — ответом был сухой язык о соответствии требованиям. Отзыв на главной странице от юридической команды, которая говорила: «наша команда по комплаенсу одобрила их менее чем за день», был именно тем подтверждением, в котором нуждался этот ответ.

Мы начали сочетать каждое возражение с частью доказательства: вопрос о безопасности получил отзыв о комплаенсе, вопрос о цене — цитату клиента, который перешел от конкурента, вопрос о миграции — фразу о клиенте, который перевел всю свою компанию без простоев. FAQ перестал быть отдельной страницей и стал частью презентации.

Предостережение здесь — релевантность. Стена из логотипов рядом с FAQ дает мало; отзыв, непосредственно отвечающий на возражение, имеет вес, особенно если в нем указана роль человека, который его дает. Если у вашего клиента еще нет такого доказательства, начните собирать его из тех же звонков по продажам, которые дают возражения. Эти два актива происходят из одного источника. Когда у вас есть отзыв, извлеките одно предложение, которое соответствует вопросу FAQ. Вам не нужна полная цитата; достаточно одного конкретного предложения. Попросите отдел продаж отмечать, когда сделка закрывается, упоминал ли клиент конкретную проблему. Эта проблема — будущий вопрос FAQ, и собственные слова клиента — лучший ответ на него.

Существует и второй, менее очевидный вид доказательства: доказательство через продукт. Если потенциальный клиент спрашивает «Могу ли я экспортировать свои данные?», самый сильный ответ включает скриншот экрана экспорта, а не просто предложение «да». Если спрашивают «Сколько длится пробный период?», самый сильный ответ включает фразу о том, что произойдет, когда он закончится. Скриншоты и короткие GIF-файлы здесь работают, потому что они показывают, а не утверждают. Это также место, где FAQ связан с демонстрацией функций: вопрос вроде «Чем это отличается от электронной таблицы?» должен вести на раздел сайта, демонстрирующий разницу, а не на стену сравнительного текста.

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

Устойчивый принцип для агентства заключается в том, что страница FAQ — это процесс, а не страница. Продукт клиента меняется каждый месяц; новые возражения появляются с каждым изменением цен, каждым новым конкурентом, каждый квартал. Страница, запущенная в январе, к марту становится гаданием. Агентства, которые делают это повторяемым, встраивают в работу легкий ритм обслуживания.

После запуска установите ежеквартальный обзор, в рамках которого вы рассматриваете три источника: новые тикеты поддержки, вопросы с звонков по продажам и изменения продукта. Разделите обзор на два этапа. Сначала удалите вопросы, которые больше не важны. Затем добавьте вопросы, появившиеся за последние 90 дней. Для этого вам не нужен контент-стратег. Вам нужна привычка.

Мы внедрили это для одного клиента, попросив руководителя поддержки помечать любой тикет, на который мог бы ответить сайт. Через пару кварталов руководитель поддержки начал присылать нам список повторяющихся вопросов до того, как мы об этом просили. FAQ стал общим проектом — это единственный способ сохранить его актуальность. Для любого агентства, ведущего такую работу по нескольким проектам, рассмотрение FAQ как части повторяемой системы SaaS-сайта позволяет сохранять качество без изобретения процесса каждый раз.

Обзор не должен занимать больше часа. Пятнадцать минут на тикеты поддержки, пятнадцать на вопросы от продаж, пятнадцать на изменения продукта и пятнадцать на обновление страницы. Если вы выставляете счет за обслуживание контента, это становится регулярной статьей дохода. Если нет, это не дает странице устареть. Есть один показатель, за которым стоит следить, даже если вы не можете привязать к нему точное число: сообщает ли команда поддержки о меньшем количестве одинаковых вопросов. Когда команда поддержки перестает отвечать на вопрос, который теперь есть в FAQ, это победа, и она обычно видна по тону команды раньше, чем появится на каком-либо дашборде. Когда команда поддержки начинает предлагать новые записи для FAQ, вы знаете, что процесс обслуживания прижился.

Ничто из этого не требует редизайна или нового инструмента. Требуется лишь изменить то, как вы говорите о FAQ с клиентом. Перестаньте называть его «FAQ» в планах проекта и начните называть его «страницей возражений». Это одно изменение переформирует все последующие решения, от собираемых вопросов до написания ответов. Это также значительно упростит аргументацию в пользу обслуживания страницы, потому что ни один клиент не оспаривает необходимость продолжать парировать возражения.