Пробный период измеряют не круглыми числами, а одним рабочим циклом клиента: временем, за которое он успевает дойти до результата и оценить его. Для простого инструмента это 7–14 дней, для всего, что завязано на месячный ритм отчётности или закупок, — 30 дней. Функции при этом открывают полностью, а ограничивают объём: число пользователей, объектов, площадок или записей.
Ошибка обычно одна и та же: срок назначают наугад, половину возможностей прячут и оставляют человека наедине с интерфейсом. Он заходит пару раз, ничего не настраивает и пропадает. Работающая проба устроена как эксперимент с гипотезой — за отведённый срок клиент должен выполнить одно конкретное действие, ради которого продукт и покупают.
Как выбрать срок пробы: считайте по циклу клиента#
Срок — не маркетинговый параметр, а оценка времени, за которое клиент успевает получить результат и понять его ценность. Считайте от регистрации до первого осмысленного вывода: данные заведены, процесс прошёл целиком, результат можно показать руководителю. Если цикл занимает неделю, проба на 3 дня закончится отказом по причинам, к продукту отношения не имеющим.
Отсюда 3 ориентира. Инструмент, который настраивается за вечер и даёт эффект сразу, — 7 дней. Продукт, где нужно завести данные и обучить пару сотрудников, — 14 дней. Всё, что живёт месячным ритмом (отчётность, зарплата, закупки, начисление аренды), — 30 дней, иначе клиент не увидит ни одного полного круга.
Длинный срок не безобиден. Чем больше времени, тем спокойнее человек откладывает старт: 30 дней читаются как «займусь потом», и первая половина уходит впустую. Поэтому долгую пробу держат на внутренних точках — день запуска, день проверки, день решения, — а не на одной дате окончания. Сложное внедрение с переносом базы честнее продавать как платный пилот на узком контуре: одна точка, один отдел, один процесс.
Что открывать бесплатно, а что придержать#
Базовое правило: ограничивайте объём, а не возможности. Пусть в пробе доступны все функции, но на 2 пользователей, один объект и сотню записей. Тогда клиент проверяет продукт целиком и упирается в границу ровно там, где она начинает мешать работе, — это и есть естественный повод перейти на платный тариф.
Урезанный набор функций ломает саму проверку. Человек оценивает не продукт, а его обрезок, и делает вывод «не подходит» о том, чего не видел. Особенно вредно закрывать интеграции и выгрузку отчётов: как раз они отвечают на главный вопрос клиента — встроится ли инструмент в процессы, которые уже работают.
Придержать стоит то, что дорого обходится вам: ручной перенос базы, обучение группы, настройку силами вашего инженера, доработки под клиента. Это отдельные платные работы. Включив их в бесплатную пробу, вы раздаёте десятки часов людям, половина из которых не собиралась покупать.
Граница пробы должна совпадать с границей тарифов. Если в пробе 2 пользователя, а в младшем платном тарифе сразу 10, клиент увидит разрыв и заподозрит подвох, а разговор об оплате начнётся с оправданий; принципы сборки уровней разбираем отдельно — тарифная сетка.
Вход в пробу и первые 3 дня работы#
Требовать карту на входе или нет — вопрос того, чего не хватает: заявок или их качества. Без карты регистраций больше, но пустых среди них тоже больше; с картой приходят те, кто уже примеряет бюджет. Недорогой продукт на самообслуживании обычно открывают без карты, сложный — через короткую форму и звонок.
Дальше начинается главное. У пробы должно быть одно ключевое действие: не «осмотреться», а загрузить прайс, провести первую сделку, запустить рассылку. Экран после регистрации ведёт к нему за 3 шага, остальное на это время убирается с дороги. Порядок первых шагов разбираем в материале про онбординг пользователя.
Касания расписывают заранее: письмо в день старта с одним действием, проверка на 3-й день, напоминание за 3 дня до конца и письмо в последний день. У каждого письма один смысл и одна кнопка. Отвечать на вопросы во время пробы должен человек, а не форма с ответом через сутки.
Признак проблемы виден сразу: клиент заходит несколько раз, но ключевого действия не делает. Значит, он застрял на подготовке данных или не понял порядок шагов. Это повод позвонить в тот же день, а не ждать окончания срока и отправлять письмо со скидкой.
Что считать успехом и как закрывать пробу#
Регистрации сами по себе не говорят ничего. Смотрят на 3 числа: доля дошедших до ключевого действия, доля оплативших среди дошедших и срок от старта до первой оплаты. Если из 100 регистраций ключевое действие сделали 12, проблема не в отделе продаж, а в первых днях пробы, и скидка её не вылечит.
Разбирайте эти числа по источникам и сегментам. Часто оказывается, что один канал даёт много регистраций и почти нулевую долю дошедших: люди приходят не за тем, что вы продаёте. Такой канал дешевле выключить, чем достраивать под него отдельный сценарий пробы.
Окончание срока нельзя обставлять молчанием. Предупредите за 3 дня и в последний день, объясните, что произойдёт с данными, и оставьте доступ на чтение хотя бы на пару недель. Клиент, у которого внезапно пропала настроенная база, не возвращается никогда, даже если решение об оплате было почти принято.
Продление уместно один раз, по запросу и с названной причиной: не успели из-за отпуска, ждут данных от бухгалтерии. Автоматическое продление превращает пробу в бесплатный тариф. Если продления просит большинство, срок выбран неверно и его надо пересчитать по циклу, а не раздавать недели поштучно.
Вывод: проба — это управляемый эксперимент#
Пробный период работает, когда у него есть три заданных параметра: срок, равный одному рабочему циклу клиента, полный набор функций при ограниченном объёме и одно ключевое действие, к которому ведёт весь сценарий первых дней. Без этих трёх вещей проба превращается в бесплатную раздачу доступов с непредсказуемым результатом.
Перед запуском полезно письменно зафиксировать четыре решения: какое действие считаем ключевым, сколько дней даём, что ограничиваем и какие касания шлём. Дальше остаётся мерить долю дошедших и долю оплативших, а менять за раз что-то одно, иначе вы не поймёте, что именно сработало.
И проверяйте выводы по деньгам, а не по ощущениям. Проба, после которой клиенты платят месяц и уходят, хуже короткой и жёсткой: она приводит людей, которым продукт не нужен, и раздувает нагрузку на поддержку. Хорошая проба заканчивается не оплатой, а тем, что клиент уже перенёс в продукт кусок своей реальной работы.