Диалоги поддержки для поиска идей о продукте: простые шаги

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

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

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

Клиенты также описывают боль через симптомы. Они говорят, что экран непонятный, не хватает настройки или задача «не работает». Но за такой жалобой обычно стоит конкретная работа. Возможно, им нужно отправить счёт до закрытия дня в бухгалтерии, получить одобрение до выхода груза со склада или закончить настройку до начала встречи. Если вы фиксируете только поверхностную проблему, вы упускаете заблокированную задачу.

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

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

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

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

На что обращать внимание в реальных разговорах

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

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

Повторяющиеся вопросы тоже важны, даже если формулировки разные. Один человек спрашивает: «Где это настроить?» Другой: «Нужно ли создавать это до приглашения команды?» Третий: «Почему я не могу начать с этого экрана?» Это не три разные проблемы. Чаще всего это одна неясная идея в продукте.

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

Есть несколько паттернов, которые повторяются снова и снова:

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

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

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

Разделите каждый сигнал на четыре категории

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

Используйте четыре коротких тега:

• bug — что-то не работает, показывает неверный результат или ведёт себя не так, как задумано
• workaround — пользователь всё равно доводит дело до конца, но только через лишние шаги, копирование и вставку, таблицы или ручную помощь
• concept — пользователь не понимает модель продукта, ваши термины или то, для чего нужна функция
• delay — пользователь останавливается и ждёт, потому что не может решить, что выбрать, кто должен действовать или что будет дальше

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

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

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

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

Простой процесс разбора

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

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

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

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

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

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

Смотрите дальше ошибки — на заблокированную задачу

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

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

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

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

Простой разбор может опираться на четыре вопроса:

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

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

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

Пример: вопрос по онбордингу, который показал более крупный разрыв

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

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

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

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

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

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

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

После этого изменения меньше новых клиентов останавливались в том же месте. Поддержка тратила меньше времени на одно и то же объяснение.

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

Частые ошибки при разборе поддержки

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

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

Часто встречаются такие ошибки:

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

Третья ошибка особенно распространена. Support решает немедленную проблему, но урок остаётся спрятанным в разговоре. Запрос на возврат денег может на самом деле быть непониманием цены. Жалоба на вход в систему может начаться раньше — когда человек только создавал аккаунт и выбрал не тот путь.

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

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

Еженедельный чек-лист, который действительно работает

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

Для каждого разговора фиксируйте одни и те же пять пунктов:

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

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

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

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

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

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

Что делать с тем, что вы нашли

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

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

Прежде чем планировать крупную доработку, проверьте самое маленькое изменение, которое может убрать трение:

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

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

Поделитесь результатом в коротком отчёте, который support, product и руководство смогут прочитать меньше чем за две минуты. Пишите просто: что сказали пользователи, где они застряли, что, по вашему мнению, это вызвало, что вы изменили и что произошло после этого.

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

Некоторые команды видят паттерн, но всё равно буксуют, потому что никто не отвечает за следующий шаг. В такой ситуации может помочь внешняя помощь. На oleg.is Oleg Sotnikov предлагает поддержку в формате Fractional CTO и advisory для стартапов тем командам, которым нужно превратить запутанные сигналы поддержки в понятные продуктовые решения, владельцев задач и небольшие проверки.

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