Вашу документацию никто не читает — и ваш показатель активации это доказывает

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

Парадокс документации

У документации есть структурная проблема, которую не исправить никаким качеством текста. Её создают люди, которые понимают продукт полностью, для людей, которые не понимают его совсем, а читают её в другой вкладке браузера — не в продукте.

Каждый из этих трёх фактов приводит к своему сбою.

Пишут эксперты. Автор руководства знает, что «подключите рабочее пространство» означает: нажать на аватар, потом «Настройки», потом «Интеграции», потом третью карточку. Он пишет «подключите рабочее пространство», потому что для него это и есть инструкция. Пользователь читает её, смотрит на экран с сорока интерактивными элементами и не видит ничего с надписью «подключить рабочее пространство».

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

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

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

Где на самом деле утекает активация

Воронки онбординга обычно размечены не с той детализацией. Команды измеряют зарегистрировался → активирован, замечают провал и делают вывод, что продукт слишком сложный. Но провал — это не одно событие. Это три разных момента, и срываются они по разным причинам.

1. Первая настройка

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

Туры работают, когда ситуация пользователя совпадает с допущениями автора тура. И ломаются, как только пользователь нажимает куда-то не туда, приходит с уже импортированными данными или оказывается на тарифе, где четвёртый шаг недоступен.

2. Вторая задача

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

По второй задаче туров никто не делает. Она слишком вариативна, чтобы расписать её заранее, и слишком важна, чтобы её пропустить. Поэтому пользователя отправляют в документацию, и дальше в силу вступает описанный выше парадокс.

3. Функция, которую так и не находят

Самая дорогая утечка не похожа на утечку, потому что пользователь не задаёт ни одного вопроса. Он просто так и не открывает для себя возможность, которая сделала бы его продвинутым пользователем, и продлевает подписку на самом дешёвом тарифе — или не продлевает вовсе, потому что так и не зашёл достаточно далеко, чтобы понять, за что здесь стоит платить.

Со стороны это похоже на здоровое использование. Аккаунт заходит в систему, пользуется двумя функциями и уходит через одиннадцать месяцев — без тикетов в поддержку и без жалоб. Ничто на вашем дашборде так и не краснеет, потому что «пользователь так и не нашёл то, что удержало бы его» — не то событие, которое можно отследить.

Почему чат-виджет этого не исправил

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

Чат-бот отвечает в облачке. А работа происходит в интерфейсе.

Спросите хорошего бота по документации: «Как настроить SSO?» — и получите правильный, хорошо написанный ответ из шести шагов. Теперь пользователю предстоит сделать перевод, который бот пропустил:

1. Прочитать первый шаг и удержать его в памяти.

2. Поискать в интерфейсе что-то, что совпадает со словами из первого шага.

3. Угадать, какая из двух похожих кнопок имеется в виду.

4. Нажать и посмотреть, похож ли открывшийся экран на то, что описано во втором шаге.

5. Если не похож, решить, сам ли он неправильно прочитал ответ или ответ устарел.

6. Повторить это для каждого оставшегося шага, всякий раз теряя уверенность.

Это налог на перевод, и он взимается с каждого ответа чат-виджета. Бот перенёс в продукт документацию, но не перенёс туда работу.

Чат-бот объясняет в облачке. Менеджер по успеху клиентов доводит дело до конца — а смысл никогда не был ни в объяснении, ни в облачке.

— Что мы поняли, создавая Barkan

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

---

Что менеджер по успеху клиентов делает иначе

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

Никто никогда не утверждал, что эта модель не работает. Возражение всегда было в том, что она не масштабируется: нельзя закрепить живого менеджера по успеху клиентов за аккаунтом на $99 в месяц и выжить.

Так что вопрос не в том, работает ли модель менеджера по успеху клиентов. А в том, какие из его навыков можно перенести в софт. Их четыре.