Контент самообслуживания, который отвечает раньше вопроса: как писать для туров и тултипов

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

Подсказки внутри продукта переворачивают последовательность. Тултип у поля, на котором люди замирают; шаг тура, объясняющий экран, открытый впервые; пункт чек-листа со ссылкой прямо на нужную настройку — всё это отвечает на вопрос до того, как человек осознанно его сформулировал. Загвоздка в том, что текст, написанный для базы знаний, внутри продукта почти никогда не работает: не та форма, не та длина, и организован он вокруг вашего списка функций, а не вокруг момента пользователя.

Этот гайд — о том, как писать контент самообслуживания, рассчитанный на показ, а не на поиск: статьи, строки тултипов и тексты туров, на которых держится онбординг с подсказками. Он для тех, кто отвечает за контент онбординга: продуктовых маркетологов, руководителей поддержки и основателей, совмещающих обе роли.

Найденный и показанный контент — разные жанры

Статья в базе знаний рассчитана на мотивированного читателя. Он пришёл с вопросом, стерпит три абзаца контекста и будет скроллить. Внутри продукта не верно ничего из этого. Пользователь в середине задачи. Тултипу достанется от силы двенадцать слов внимания. Шагу тура — двадцать пять, дальше взгляд уходит на кнопку «Далее». Карточке в пустом экране — заголовок и одно предложение.

Это ограничение меняет само определение «хорошего текста». В базе знаний выигрывает полнота. В продукте выигрывает момент: правильные двенадцать слов на правильном экране бьют идеальную статью на 800 слов, которую никто не открыл. Статья на 800 слов по-прежнему нужна — но как второй слой, в одном клике от момента, а не как парадный вход.

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

Начинайте с моментов, а не с функций

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

1. Откройте аналитику воронки или прохождения шагов и выпишите каждый экран, где новички тормозят или отваливаются.
2. Для каждой точки залипания сформулируйте вопрос, который пользователь задал бы вслух именно в этот момент, — его словами, а не вашими. Не «Об архитектуре загрузки данных», а «Почему мои данные до сих пор не появились?».
3. Отсортируйте по тому, сколько новых пользователей попадает в каждый момент за первую неделю.

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

Сначала вопрос, потом ответ — в первом же предложении

Каждый материал лестницы рождается как вопрос, сформулированный так, как его набрал бы пользователь. Оставьте вопрос заголовком статьи — буквально. «Где посмотреть свой первый отчёт?» работает лучше, чем «Обзор отчётности», и во внутреннем поиске продукта, и в сниппете поисковика, потому что совпадает с интентом слово в слово.

Дальше — ответ в первом предложении. Не после абзаца позиционирования, не после скриншота: первая же фраза закрывает вопрос, а всё остальное — уточняющие детали.

Где посмотреть свой первый отчёт? Первый отчёт появится в разделе «Отчёты → Еженедельные», как только источник данных завершит первую синхронизацию, — обычно в течение 15 минут после подключения.

Пользователь, прочитавший только эту строку, получил то, за чем пришёл. В этом и смысл. Приём «сначала ответ» кажется авторам расточительным («дальше же не дочитают!») и ровно поэтому правилен для читателя.

Один момент — одна мысль

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

Практичный бюджет длины, который держится в разных продуктах:

• Тултип или хотспот: одно предложение, 8–14 слов, глагол первым.
• Шаг тура: заголовок из 4–6 слов плюс одно предложение на 15–25 слов.
• Пункт чек-листа: действие — «Подключите первый источник данных» — плюс однострочная выгода: «и дашборд заполнится сам».
• Статья за моментом: 150–400 слов. Если нужно больше, вы описываете сразу два момента.

Пишите под состояние экрана

Один и тот же экран требует разных слов на первый день и на тридцатый. Пустой список проектов — момент для обучения («Проекты держат ваши сценарии в порядке — создайте первый»), а заполненному не нужно ничего. Тултипы первого запуска не должны срабатывать дважды: пользователь, которому трижды показали одно и то же «Добро пожаловать!», учится закрывать всё, что вы показываете, — включая ту единственную подсказку, которая спасла бы ему неделю.

Это скорее правило таргетинга, чем правило письма, но у него есть письменное следствие: помечайте каждый созданный материал состоянием, на которое он рассчитан. «Новое пространство, данные не подключены» читается совсем не так, как «данные подключены, отчёт не открыт». А когда контент и состояние расходятся — тултип объясняет кнопку, которой на тарифе пользователя нет, — доверие ко всем последующим подсказкам осыпается.

Списывайте то, что перестало работать

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

• Доля взаимодействия — сколько из увидевших кликнули, раскрыли или перешли по ссылке?
• Прирост прохождения шага — доходят ли увидевшие материал до конца шага чаще тех, кто его не видел?
• Доля мгновенных закрытий — закрытие в первую секунду означает, что на этом экране материал работает как шум.

Тултип с высоким закрытием и нулевым приростом прохождения не нейтрален — он приучает вас игнорировать. Уберите его. Шаг, который остаётся красным даже с подсказкой, обычно означает, что дорабатывать нужно сам сценарий: контент оказался неподходящим инструментом — и это тоже полезно знать.

Разбор на примере

Возьмите самую частую заминку в продуктах для работы с данными: источник подключён, дашборд всё ещё пуст, первая синхронизация идёт десять минут. Лестница для этого единственного момента:

• Карточка в пустом экране (заголовок и строка): «Данные уже в пути — первая синхронизация занимает около 10–15 минут. Мы подскажем, когда дашборд будет готов».
• Пункт чек-листа: «Подключить источник данных ✓ → Дождаться первого отчёта (автоматически)».
• Статья, ответ первым: «Если сразу после подключения источника дашборд пуст, дайте первой синхронизации 10–15 минут. Ниже — как проверить статус синхронизации, что значит «завис на шаге 2» и когда писать нам…».

Никто не ищет «сколько идёт первая синхронизация» в эти десять минут — люди просто молча решают, что продукт сломан. Показанная версия предотвращает этот вывод; найденная пришла бы слишком поздно.

Эффект накапливается

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