Метрика времени настройки: почему продуктовым командам стоит ее отслеживать

Почему время настройки важно

Нового пользователя в первый же день не волнует ваш роадмап. Его волнует только одно: сможет ли он запустить продукт без помощи?

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

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

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

Долгое время настройки обычно указывает не на медленных пользователей, а на пробелы в продукте. Чаще всего это значит, что продукт сам принимает недостаточно решений. Роли могут быть неясны, поэтому кто-то должен объяснять права доступа. Настройки по умолчанию могут быть слишком слабыми, поэтому каждый аккаунт требует отдельной доработки. А рабочий процесс может зависеть от знаний, которые есть только у поддержки или у продуктовой команды.

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

Представьте команду, которая продает софт небольшим клиникам. В этом месяце зарегистрировались десять клиник, и восемь из них начали работать. Звучит неплохо. Но если каждой клинике нужен менеджер по работе с клиентами, чтобы разложить роли сотрудников, очистить CSV-файлы и подправить настройки до первого входа, продукт по-прежнему не прост в освоении. Время настройки показывает это заранее.

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

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

Что должно входить во время настройки

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

Запускайте отсчет, когда реальный человек начинает настраивать свой аккаунт, рабочее пространство или командную среду. Не начинайте позже только потому, что продуктовая команда замечает пользователя уже после регистрации.

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

Где начинается и заканчивается таймер

Хороший сценарий регистрации все равно может скрывать долгий путь к ценности. Многие команды считают заполнение формы, подтверждение почты и первый вход завершением онбординга. Но пользователю эти шаги сами по себе не нужны. Ему важно что-то сделать.

Если команда регистрируется в инструменте для проектов в 9:00 утра, но не может создать первую рабочую доску до 14:30 из-за необходимости согласования у администратора, импорта данных и ответа поддержки, время настройки составляет 5,5 часа. И это не 3 минуты только потому, что форма регистрации была быстрой.

Что команды часто забывают считать

Учитывайте и простои, когда пользователь не может двигаться дальше. Ожидание согласований, импорта, проверки домена, ответа поддержки или ручной ревизии — все это часть числа. Это тоже часть опыта, даже если в этот промежуток никто из вашей команды не касался продукта.

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

Такие детали показывают, откуда на самом деле идет трение. Долгое время настройки часто связано не с одной медленной страницей, а со слабыми настройками по умолчанию, отсутствующей логикой прав доступа или скрытой работой за экраном.

Если вам нужен показатель, которому команда может доверять, измеряйте время настройки как прошедшее время до первого полезного результата, а затем помечайте задержки, которые на него повлияли. Так вы получите и простой показатель, и практическую карту того, что чинить в первую очередь.

На что обычно указывает долгое время настройки

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

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

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

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

Скрытая ручная работа тоже видна здесь

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

Именно поэтому время настройки нужно заканчивать на первом полезном результате, а не на создании аккаунта. Команда может радоваться быстрому signup, пока поддержка еще 40 минут что-то делает за кулисами. Эта метрика делает разрыв видимым.

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

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

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

Как измерять это шаг за шагом

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

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

1. Выберите один сценарий настройки и опишите его одним предложением. Сделайте его конкретным. Например: новый клиент регистрируется, команда создает аккаунт, импортирует первый файл, и клиент может начать пользоваться продуктом.
2. Определите одну точку начала и одну точку конца. Выбирайте моменты, которые можно увидеть, а не размытые этапы. Начинайте, когда у команды есть все необходимое, чтобы приступить. Заканчивайте, когда пользователь выполняет первую настоящую задачу.
3. Измерьте каждый шаг внутри сценария. Отдельно фиксируйте создание аккаунта, права доступа, импорт данных, проверки и передачи задач. Важно общее время, но время по шагам показывает, где именно работа замедляется.
4. Помечайте причину каждой паузы или задержки. Используйте короткий набор меток, например: согласование, отсутствуют данные, проблема импорта, неясное правило, ручное исправление.
5. Раз в неделю проверяйте небольшую выборку. На старте достаточно пяти-десяти настроек. Ищите повторяющиеся медленные шаги, а не один плохой день.

Одного общего времени недостаточно. Настройка за 45 минут может казаться приемлемой, пока вы не увидите, что 20 минут ушло на ожидание согласования, а еще 10 — на исправление таблицы, которая не соответствовала ожидаемому формату.

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

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

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

Простой пример для команды

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

Задержка складывалась из мелких остановок. Менеджер по продажам мог сразу открыть аккаунт, а потом должен был ждать согласования по безопасности, прежде чем приглашать остальных членов команды. Одна эта пауза могла съесть большую часть дня.

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

К тому времени, когда клиент мог войти, увидеть данные и назначить работу команде, заявление про «пятиминутную настройку» выглядело смешно. Быстрой частью было создание аккаунта. Медленной — все вокруг него.

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

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

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

Ошибки, которые допускают команды

Команда может отслеживать время настройки и все равно не увидеть настоящую проблему. Обычно дело не в самой цифре. А в том, как команда определяет ее, отфильтровывает и объясняет неудобные случаи.

Одна из типичных ошибок — показывать только среднее значение. Из-за этого медленная настройка выглядит нормой. Если большинство пользователей завершает настройку за 12 минут, а одной группе нужно 2 часа, среднее скрывает боль. Именно эти более медленные случаи часто показывают недостающие правила, слабые настройки по умолчанию или лишние шаги, которые команда перестала замечать.

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

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

Поддержку за это часто обвиняют, и обычно это несправедливо. Если поддержка каждый день отвечает на один и тот же вопрос по настройке, значит, поток сломан. Звонок в поддержку может какое-то время скрывать трение онбординга, но он его не убирает. Лучше исправить экран, улучшить настройку по умолчанию или убрать шаг совсем.

Несколько привычек помогают сохранить метрику честной:

• сравнивайте типичное время настройки с самыми медленными пользователями, а не только со средним;
• учитывайте повторы, неудачные импорты, задержки согласования и обращения в поддержку;
• завершайте измерение на первом реальном результате, а не на создании аккаунта;
• проверяйте число после изменений в продукте, а не только на запуске.

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

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

Краткий обзор

Хорошая метрика времени настройки показывает, где продукт все еще зависит от людей. Если новый аккаунт работает только после звонков, передач задач и ручных исправлений, значит, настройка не завершена, когда заканчивается форма.

Когда вы смотрите на онбординг, задайте несколько прямых вопросов. Может ли новый пользователь сам получить один полезный результат? Подходят ли настройки по умолчанию большинству клиентов? Могут ли пользователи справиться с типичными ошибками без поддержки? Убирает ли каждый шаг согласования реальный риск? Есть ли один владелец времени настройки между продуктом, поддержкой, продажами и инженерией?

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

Этот разрыв становится очевидным, когда вы смотрите на реальный аккаунт. Команда может отчитываться, что настройка занимает 12 минут, потому что сценарий регистрации короткий. Но потом реальный клиент назначает звонок, чтобы выбрать параметры, ждет согласования, натыкается на ошибку импорта и просит поддержку почистить данные. Реальное время настройки ближе к часу.

А это важно. Такая задержка тормозит выручку, забивает очередь поддержки и приучает команду мириться с работой, которую должен делать продукт. Еще и прогнозы выглядят лучше, чем реальность.

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

Что делать дальше

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

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

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

Короткой проверки достаточно:

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

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

В B2B-продуктах такие проблемы часто проходят сразу через продукт, операции и инфраструктуру. Именно на таком типе работы через oleg.is фокусируется Oleg Sotnikov как fractional CTO и консультант для стартапов, особенно когда задержки в настройке вызваны и слабыми правилами продукта, и ручными исправлениями за кулисами.

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