Сбор ответов · 21 сентября 2026 г.

Опрос после онбординга нового клиента: что и когда спрашивать

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

Чем опрос после онбординга отличается от обычного «как вам покупка»

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

Когда отправлять: окно между шумом и забыванием

Тайминг — главная переменная, которую легко упустить. Отправленный в день регистрации опрос ловит первое впечатление от интерфейса: человек прошёл экран приветствия, увидел меню и ответил на вопрос об удобстве, хотя ещё ни разу не использовал продукт по назначению. Это шум, который выглядит как данные. Отправленный через два месяца опрос ловит уже сложившееся отношение, но теряет конкретику: клиент помнит общее чувство «было сложно» или «было легко», но не помнит, на каком именно шаге настройки застрял и что именно помогло его пройти. Рабочее окно — от трёх до десяти дней после первого полноценного использования продукта, а не после регистрации аккаунта: эти две даты для сложных B2B-продуктов часто расходятся на одну-две недели.

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

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

Пример: как этот опрос выглядит в живом B2B SaaS

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

Как выглядит хороший сигнал и как выглядит тревожный

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

Self-serve и онбординг с менеджером — разные анкеты

Форма онбординга меняет то, что стоит спрашивать. Если клиент настраивает продукт самостоятельно, без выделенного менеджера, вопросы стоит сфокусировать на документации и интерфейсе: было ли понятно, что делать дальше на каждом шаге, хватило ли подсказок в самом продукте, пришлось ли гуглить или писать в поддержку то, что должно было быть очевидно. Если онбординг идёт с участием менеджера или внедренца, добавляется вопрос про качество этого взаимодействия отдельно от продукта: клиент может быть недоволен процессом настройки, но хорошо отзываться о продукте, или наоборот, — и смешивать эти два измерения в одном вопросе значит терять, что именно нужно чинить. Для self-serve чаще важнее продуктовая аналитика в паре с опросом, для сопровождаемого онбординга — сам разговор с внедренцем важнее анкеты, а опрос играет вспомогательную, контрольную роль. Смешанный формат — когда часть шагов клиент проходит сам, а на сложных местах подключается внедренец, — встречается на практике чаще, чем чистые варианты, и для него разумно оставить общее ядро из трёх вопросов, а различающийся пятый вопрос менять в зависимости от того, был ли на этом конкретном аккаунте отдельный созвон с внедренцем.

Кто должен видеть ответы и что делать с низкой оценкой

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

Что делать с ответами, когда онбордингов десятки в месяц

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

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

Как посчитать долю успешных онбордингов по ответам

Из ответов на первый вопрос — «удалось ли получить результат» — считается простая метрика: доля клиентов, ответивших утвердительно в первое отправленное окно, без повторных напоминаний. Это грубый, но рабочий аналог метрики time-to-value, который не требует сложной продуктовой аналитики и событий в коде продукта. Если доля стабильно ниже семидесяти процентов, это повод разбирать не отдельные ответы, а сам процесс онбординга целиком: возможно, проблема не в клиентах, а в сценарии настройки, который системно занимает больше времени, чем закладывает команда продаж при подписании контракта. Метрику стоит считать помесячно и сравнивать по сегментам — новым клиентам с разным объёмом команды или разным тарифом, потому что у крупных внедрений порог «результата» обычно выше, а срок его достижения длиннее.

Типичные ошибки

• Отправлять опрос в день регистрации, а не после первого полноценного использования.
• Задавать вопрос про готовность рекомендовать на этом этапе — клиент ещё не успел получить устойчивую пользу.
• Делать анкету длиннее пяти вопросов — на онбординге терпения к анкетам меньше всего.
• Не назначать ответственного за реакцию на низкие оценки, из-за чего они просто накапливаются в таблице.
• Использовать одну и ту же анкету для self-serve и сопровождаемого онбординга без поправок на формат.
• Путать факт входа в аккаунт с фактом прохождения онбординга — вход в систему не значит достигнутый результат.

Ограничения метода

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

С чего начать

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

1. Определите момент «первого полноценного использования» для вашего продукта — это не всегда регистрация и не всегда первый вход.
2. Соберите четыре-пять вопросов, привязанных к конкретным шагам настройки, а не к общему впечатлению.
3. Назначьте ответственного, который реагирует на низкие и расплывчатые ответы в течение одного-двух дней.
4. Через месяц посчитайте долю клиентов, добравшихся до результата в плановый срок, — это станет базовой метрикой.
5. Решайте вопрос о раздельных анкетах для self-serve и сопровождаемого онбординга только после первых данных.