От обращения к проверяемой гипотезе продукта
- Зафиксируйте причину обращения, этап пути, контекст, ожидаемый результат и фактическое препятствие.
- Определите минимальный набор данных, доступы, срок хранения и применимые требования к согласию.
- Сгруппируйте похожие ситуации и отделите частный случай от повторяющегося паттерна.
- Сопоставьте сигнал с поведением, интервью или тестом понятности; не выводите причину из одного звонка.
- Проверьте одно обратимое улучшение и разберите на review качество, побочные эффекты и ограничения.
Ниже сохранён исходный материал. Поддержка не гарантирует причинность, согласие, удовлетворённость, удержание, продажи или улучшение продукта.
Подробности исходного материала
Однажды я сидел в переговорке у клиента — это был SaaS-продукт для малого бизнеса — и в углу комнаты стоял странный артефакт. Старый бабушкин телефон, без шуток, кнопочный, на подставке. Я спросил: «Это что, музей?». Гендиректор посмотрел на меня и говорит: «Это телефон поддержки. Я раз в неделю беру его домой и слушаю звонки. Просто слушаю. Иногда отвечаю». В тот момент я подумал: вот это правильный собственник. А потом я начал работать с компанией ближе и понял, что он уже три года знает, что у его продукта серьёзная проблема — и она ему слышна с этого самого телефона. А команда продукта про эту проблему не знает. Потому что между телефоном и команд есть пропасть. И эта пропасть — типичная история того, как улучшить продукт, оказывается невозможным даже для тех, кто очень хочет.
Тот конкретный звонок, который я услышал тогда, помню до сих пор. Женщина, около 50, владелица маленькой кофейни, говорит сотруднику поддержки: «Я не понимаю, как мне найти отчёт за прошлый месяц. Я уже три раза вам звоню. Мне сказали, что есть инструкция, я её читала. Но там написано не то, что я вижу». Голос усталый, не злой. Без скандала. Просто человек устал.
Сотрудник поддержки идеально вежливо проводит её по интерфейсу: «Кликните на иконку шестерёнки… выберите „Отчёты“… да-да, под фильтром „Период“…». Через десять минут она находит отчёт. Говорит: «Спасибо, девушка». Кладёт трубку. Тикет закрыт. Метрика «решено с первого обращения» вырастает на единицу. А продукт всё так же продолжает прятать самую востребованную функцию у пользователей за тремя кликами в неочевидном месте интерфейса. И женщина продолжает звонить через месяц. И ещё через один.
Как мы потеряли клиента, который остался
Этот сюжет — он повторяется в каждой второй компании, с которой я работал. Не в каждой третьей, а именно в каждой второй. Жалобы клиентов есть. Поддержка с ними справляется. Цифры выглядят хорошо: SLA выдерживается, удовлетворённость высокая, NPS приемлемый. Только вот клиенты тихо уходят, а в новых уходит втрое больше денег на привлечение, чем раньше.
Что произошло с той женщиной из кофейни? Она не ушла сразу. Она ещё полгода терпела. Потом перешла на конкурирующий сервис, у которого, между нами, и продукт хуже, и цены выше. Но там её научили один раз, и больше она не звонила.
Никто в компании не знал, что она ушла. Поддержка не считает оттёкших клиентов — это работа CRM. CRM показывает оттток в среднем по больнице, без причин. Продукт никогда не видел её обращений. А гендиректор знал, что что-то не так, но не знал, что именно. И вот это разрыв, о котором стоит поговорить.
Бывает так: вы строите продукт, потом строите вокруг него поддержку, потом стенку между ними. Сама стенка — невидимая. Ни один человек её не построил сознательно. Просто так сложилось, что отдел продукта и отдел поддержки сидят в разных Telegram-чатах, на разных встречах, с разными KPI. И жалобы клиентов остаются в зоне поддержки. А продукт делает то, что считает нужным, опираясь на гипотезы и роудмап.
Почему жалобы не доходят до продукта
Я несколько лет наблюдал, как именно жалобы теряются по дороге от клиента к продуктовой команде. Получилось три типичных барьера. Они независимы и накладываются друг на друга — в худших случаях работают все три одновременно.
Барьер первый: фильтр поддержки
Поддержка устроена так, чтобы решать проблемы быстро. Это её работа, и она с ней справляется. Но «решать быстро» — это не то же самое, что «понимать». Сотрудник поддержки в идеале закрывает тикет за 5–7 минут. Этого хватает, чтобы помочь клиенту. Но не хватает, чтобы зафиксировать причину, понять контекст, увидеть паттерн.
Хуже того, у поддержки часто есть KPI вроде «среднее время решения». Это значит, что чем быстрее сотрудник закроет тикет, тем лучше будет его метрика. И тогда длинные разговоры с клиентами, которые могли бы вскрыть продуктовую проблему, превращаются в проблему для самого сотрудника. Он начинает их избегать. Не сознательно — просто система так настроена.
В итоге мы получаем массу обращений, по каждому из которых клиент получил решение — но компания не получила знания. Тикет закрыт. Урок не извлечён.
Барьер второй: тон жалобы — и кто её слушает
Большинство жалоб клиентов написаны в тоне, который звучит, мягко говоря, неприятно. «Опять у вас всё сломалось», «как такое можно было допустить», «это уже третья ошибка за месяц». Если разработчик читает такую жалобу, у него срабатывает естественная защитная реакция: «Клиент не разобрался», «Он просто не умеет пользоваться», «Это не баг, это фича».
И в этом эмоциональном фоне теряется главное — содержание. Клиент пишет агрессивно, потому что устал. А устал он потому, что натыкается на одно и то же препятствие в пятый раз. Содержание жалобы важнее, чем её тон. Но тон отгоняет тех, кто мог бы это содержание услышать.
Поэтому в зрелых компаниях между клиентом и разработчиком есть фильтр — не цензурный, а переводческий. Кто-то берёт жалобу, очищает её от эмоций и переводит в формат, который продуктовая команда готова услышать: «Пользователь не находит отчёт за прошлый месяц. Зафиксировано 47 обращений за квартал на эту тему». В таком виде жалоба уже не раздражает, а стимулирует решение.
Барьер третий: разные приоритеты
У продукта свой роудмап. У поддержки свой беклог. У маркетинга своя кампания. И когда от клиента приходит жалоба, никому из этих трёх отделов она формально не относится — потому что не подпадает ни под чью текущую задачу.
В результате жалоба может валяться неделями, пока кто-нибудь не возьмёт её в работу. А чаще — никогда. Потому что для каждого отдела она «не своя». Мне попадалась компания, где жалобы клиентов хранились в Notion в отдельной таблице. Через год там было 1200 записей. Никто за это время не открывал эту таблицу.
Жалоба — это бесплатное исследование, которое мы игнорируем
Тут хочется сделать паузу и сказать главное. Жалоба клиента — это не сервисная задача. Это продуктовое исследование. Бесплатное, добровольное, в реальном времени. Клиент сам, своими словами, рассказывает вам, что в продукте сломано. Где упирается. Чего не хватает. И вы это получаете без бюджета на маркетинговое исследование, без фокус-групп, без брендового опросника на 47 пунктов.
Гарвардский Business Review много лет публиковал материалы про Voice of Customer — концепцию, в которой жалобы являются главным источником продуктовых решений. Bain & Company в своём анализе клиентского опыта приводит цифру: компании, которые систематически разбирают жалобы и превращают их в продуктовые задачи, удерживают клиентов в среднем на 30 процентов лучше, чем те, кто просто закрывает тикеты. Тридцать процентов — это огромная разница на горизонте года. Это, по сути, разница между ростом и стагнацией.
Что говорят данные: каждая жалоба — это десятки молчаливых
Тут есть ещё одна цифра, которую важно держать в голове. Исследования (в частности, материалы Nielsen и работы по customer satisfaction в журналах HBR) показывают: на каждого клиента, который пожаловался, приходится в среднем 25–27 клиентов, которые столкнулись с той же проблемой и просто промолчали. Из них часть терпит, часть уходит, часть рассказывает знакомым «там не работает». И ни о ком из них вы не узнаете.
То есть когда вам пришло 10 жалоб на одну и ту же проблему, у вас в реальности есть 250–270 пострадавших клиентов. Это уже не «единичный случай», это массовая история. Но мы видим только верхушку айсберга. И принимаем решения по верхушке.
Такая ассиметрия — главный аргумент за то, что повторяющиеся жалобы должны иметь приоритет, который соответствует не количеству обращений, а количеству реальных пострадавших. То есть в десятки раз выше, чем кажется.
Российская реальность: Wildberries, Авито, Додо Пицца
Есть российские компании, которые этот принцип применяют последовательно — и видно, как это меняет продукт. Wildberries несколько лет назад начал публиковать отзывы клиентов прямо на карточках товаров, и эти отзывы стали частью продуктового сигнала: ассортимент, поставщики, описания товаров — всё корректировалось под обратную связь. Не идеально, но видно, что обратная связь не лежит в забытой таблице, а влияет на решения.
Авито — другой пример. Их продуктовая команда регулярно публикует разборы пользовательских сценариев и того, как они меняли продукт под жалобы. Это не маркетинговый ход — это рабочая практика. Когда жалоба становится сигналом, продукт меняется. Когда жалоба остаётся в поддержке, продукт стоит.
Додо Пицца показывает похожий подход с другой стороны: Фёдор Овчинников ещё в начале пути ввёл публичную работу с жалобами. Не идеально приятную для компании, но честную. И это создало петлю: клиент пишет, команда разбирает, продукт меняется. И клиент видит, что его жалоба не уходит в пустоту. Что, кстати, само по себе резко снижает обиду — клиент готов простить почти любую проблему, если видит, что его услышали.
Метафора: жалоба — это геологический разрез
Если попробовать описать одной картинкой, чем именно жалоба отличается от обычной обратной связи, мне в голову приходит образ геологического разреза. Знаете, такие вертикальные срезы породы, на которых видны слои разных эпох? Один смотришь — и сразу понимаешь, что было сто лет назад, тысячу, миллион.
Жалоба клиента работает похожим образом. На поверхности — конкретный эпизод: «не нашла отчёт». Под поверхностью — слой пользовательского опыта: «я уже устала, потому что это третий раз». Ещё глубже — слой ожиданий: «я думала, что всё будет интуитивно, как в банковском приложении». На самом дне — слой жизненной ситуации: «у меня вообще-то кофейня, я не должна разбираться в IT каждый понедельник вечером».
Когда мы читаем жалобу как «инцидент в техподдержке», мы видим только верхний слой. Когда как геологический разрез — видим всю породу. И именно нижние слои дают ключи к продукту. Они говорят, кто на самом деле наш клиент, чего он на самом деле хочет, что у него в голове в момент использования.
Дальше всё просто. Жалоба, прочитанная как разрез, превращается в продуктовый инсайт. Жалоба, прочитанная как тикет, остаётся набором символов в системе. Разница не в самой жалобе — она в том, кто и как её читает. И вот этому, в общем, можно научиться. (Хотя не каждый разработчик готов читать жалобы как геолог. Но кто-то в команде должен это уметь — и в идеале это не один человек, а небольшая группа. Тогда даже неприятные жалобы перестают вызывать защитную реакцию и начинают работать как сырьё для решений.)
Метод трёх жалоб: как превратить тикеты в продуктовые задачи
Я разработал — точнее, собрал из практики десятка компаний — простой метод, который позволяет жалобам реально доходить до продукта. Назвал его «метод трёх жалоб», потому что он строится на одном простом правиле: если на одну и ту же проблему пришло три жалобы — это уже не случайность, это сигнал. И сигнал, на который продукт обязан ответить.
Шаг 1: фиксировать всё, не только то, что «решено»
В большинстве компаний фиксация жалоб привязана к статусу «не решено». Если поддержка справилась — тикет закрывается, жалоба пропадает. Это ошибка. Фиксировать нужно все жалобы, включая те, что были решены.
Потому что то, что для поддержки «решено» (ответили клиенту, объяснили, провели по интерфейсу), для продукта может означать «у нас тут хроническая дыра, мимо которой ходят все клиенты». Закрытие тикета — это не закрытие проблемы. Это закрытие одного эпизода проблемы.
На практике это значит: каждая жалоба должна попадать в общий пул, у каждой должна быть категория («интерфейс отчётов», «работа с подписками», «загрузка фото» и так далее), и пул этот должен быть открыт для продуктовой команды без посредников.
Шаг 2: классифицировать по продуктовым кускам, не по тонам
Когда жалобы поступают в общий пул, их нужно категоризировать. Здесь главная ловушка — категоризировать по эмоциональному тону или по тяжести инцидента. Это бесполезно для продукта.
Полезно категоризировать по продуктовому участку. Не «клиент злой» или «срочно», а «настройка уведомлений», «экспорт данных», «оплата картой». Тогда становится видно: 70% жалоб приходится на три участка, и эти участки — кандидаты на серьёзный пересмотр.
Шаг 3: возвращать в продукт через регулярный ритуал
Жалобы возвращаются в продукт через простую практику: раз в две недели — встреча, на которой продукт смотрит топ-10 жалоб по частоте за прошедший период. Не все, не все 200. Топ-10. Этого достаточно, чтобы увидеть закономерности и выбрать одну-две задачи в спринт.
Эта встреча должна быть короткой — максимум час. И на ней должен быть кто-то из поддержки, кто может прокомментировать конкретные тикеты. Не для отчёта, а для контекста.
Без такой встречи всё разваливается. Я видел десятки компаний, где жалобы фиксируются, классифицируются, лежат в красивой таблице — а решения по ним не принимаются, потому что нет ритуала, в котором эти решения принимаются. Просто документ. Просто список. Просто данные.
Антипаттерны: что мы делаем не так с жалобами
Прежде чем закончить, хочу пройтись по типичным ошибкам, которые я вижу почти в каждой компании. Если узнаете — это нормально, через это все проходят.
Защитная реакция вместо разбора
Первое и самое распространённое — это когда команда читает жалобу и сразу начинает защищаться. «Клиент не разобрался». «Это его проблема, что он не прочитал инструкцию». «Мы не виноваты, что он не понял». Это естественная человеческая реакция — никто не хочет признавать, что его работа неидеальна.
Но защитная реакция — это смерть для улучшения продукта. Если каждая жалоба воспринимается как обвинение, она перестаёт быть данными. Она превращается в эмоциональный конфликт между командой и пользователем. И в этом конфликте побеждает тот, у кого больше власти — то есть команда. А продукт остаётся таким, каким был.
Лекарство простое, но трудное: в команде должна быть культура, в которой жалоба читается как факт, а не как претензия. «Что произошло у клиента?» — это вопрос исследователя. «Кто виноват?» — это вопрос судьи. Нужны исследователи.
Усреднение вместо выбросов
Второй антипаттерн — смотреть на средние показатели вместо выбросов. NPS вырос на 2 пункта — отлично. Удовлетворённость держится на 85% — нормально. Только вот эти средние ничего не говорят про продукт. Они говорят, что в среднем по больнице температура нормальная.
А у вас 15% клиентов с критическими проблемами. И именно они — продуктовый сигнал. Не средние, не «удовлетворённые», а именно эти 15%. Они уйдут первыми. Они уже сейчас рассказывают знакомым, что у вас всё плохо. И они же — самый ценный источник информации, потому что им не лень писать.
Хорошие продуктовые команды смотрят на хвост распределения. Плохие — на медиану. Это очень простой различитель, и он работает почти всегда.
«Закрыли тикет — значит, решено»
Третий антипаттерн я уже упоминал, но он стоит отдельного абзаца. Когда метрика поддержки — это «время до закрытия» или «решено с первого обращения», у компании нет реального стимула разбирать продуктовые проблемы. Стимул — закрыть тикет. Точка.
Это исправляется одним простым действием: ввести вторую метрику — «количество повторных обращений по той же причине». Если эта метрика падает — продукт улучшается. Если стоит на месте — продукт стоит, и компания просто учится быстрее закрывать тикеты, не решая проблему.
Эта метрика не любима поддержкой, но она единственная честная. И продуктовая команда должна на неё смотреть еженедельно.
Кстати, в Тинькофф этот принцип реализован в очень жёсткой форме: если по одной и той же причине поступает определённое количество обращений, тикет автоматически эскалируется в продуктовую команду как продуктовая задача. Без обсуждения. Без согласований. Это не значит, что задача обязательно будет сделана — но она получает статус, которого не получит, если бы лежала в общей куче. И продукт обязан хотя бы посмотреть на неё. Этот механизм — инженерный по сути, но он лечит организационную дыру лучше, чем любые встречи и регламенты. Потому что не зависит от доброй воли отдельных людей.
Чек-лист и финал
Если коротко резюмировать всё это в чек-лист — вот пять вопросов, на которые стоит ответить, чтобы понять, как улучшить продукт через жалобы клиентов в вашей компании.
Первый: где у вас хранятся все жалобы? Если в нескольких местах (CRM, чат поддержки, телеграм-канал, личная почта руководителя) — ваши жалобы рассеяны и фактически потеряны. Они должны быть в одном месте, открытом для продуктовой команды. Второй: классифицированы ли жалобы по функциональным участкам продукта? Если категоризация по тяжести или эмоциям — пересмотрите. Третий: проводится ли регулярная встреча, на которой продукт смотрит топ-10 жалоб? Если нет — жалобы лежат, продукт не меняется. Четвёртый: какая метрика стоит на поддержке? Если только «время решения» — добавьте «количество повторов». Пятый: знает ли продуктовая команда хотя бы одну реальную историю клиента, который ушёл из-за конкретной проблемы? Если нет — поработайте с этим. Истории про реальных клиентов делают то, что цифры не делают.
Возвращаюсь к той самой женщине из кофейни, с которой я начал. Когда мы рассказали продуктовой команде её историю — без обобщений, конкретно её, с её фразами, — что-то изменилось. Они в течение недели переделали тот самый экран отчётов. Не потому что увидели цифры (цифры были и раньше). А потому что увидели человека.
В этом, наверное, главный смысл всего разговора. Жалоба — это не данные. Это история. И когда она рассказана как история, она работает. Когда она сведена к цифре в отчёте — она лежит. Поэтому рядом с любой системой фиксации жалоб должен быть канал, по которому реальные истории клиентов попадают в команду продукта. Не статистика. Истории.
Если у вас сейчас в компании есть поток жалоб, который никто не разбирает — начните с одного. С одного клиента. Прочитайте, что он написал. Поймите, что у него произошло. Расскажите эту историю на ближайшем совещании продукта. Этого хватит, чтобы запустить цепочку: «А давайте ещё одну посмотрим». Это и есть способ сдвинуть культуру. Не через регламент, не через KPI, а через одну услышанную историю.
Я бы добавил ещё один маленький, но важный совет. Когда будете слушать или читать жалобу — постарайтесь не искать виноватого. Ни клиента, ни себя, ни отдел разработки. Виноватых в большинстве случаев нет. Есть несовпадение того, что мы построили, и того, что человеку реально нужно. Это несовпадение можно увидеть только в одном случае: когда мы перестаём защищаться и начинаем слушать. И это самое сложное во всей истории — потому что наша работа лежит в продукте, и любая жалоба ощущается как удар по тому, что мы делали много месяцев. Но без этой готовности слушать никакие методы и регламенты не сработают.
Ну и последнее. В компании, у которой я начал этот рассказ, тот гендиректор и его бабушкин телефон — они через год перестали быть нужны. Не потому что жалоб стало меньше (их стало меньше, кстати, но не из-за этого). А потому что в команде завелась культура, в которой жалобы стали интересными. Их обсуждали в курилке, на стендапах, в личных переписках. Гендиректор перестал быть единственным человеком, который слышит клиентов. И продукт начал двигаться быстрее, чем когда-либо.
Вот это, пожалуй, главная цель всего того, о чём мы говорили. Не построить идеальную систему сбора жалоб. Не настроить лучший дашборд. А вырастить в команде интерес к голосу клиента. Когда этот интерес есть — всё остальное приходит само. Когда нет — никакая система не помогает. И вот это и есть тот самый бабушкин телефон в углу переговорки. Только теперь уже не нужно раз в неделю тащить его домой. Достаточно раз в две недели послушать одну запись с командой. И продукт начнёт меняться. Сначала медленно, потом неожиданно быстро.
Читайте по теме:
- Как улучшить продукт в компании, чтобы получать больше продаж
- Проблемное интервью: как закончить разговор
- Проблемное интервью: примеры вопросов
Предприниматель, бизнес-трекер, пишу о том, как развивать бизнес в условиях неопределенности
