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

Если коротко — это материал о том, почему «давайте поставим форму» почти никогда не приводит к улучшениям. И что с этим делать. Внутри только то, что мы видели на практике за 8 лет.

Главное из гайда:

🤩 Фидбэк не приносит ценности сам по себе. Ценность появляется, когда в компании выстроена система: сигнал → интерпретация → решение → изменение в продукте → влияние на метрики. Если хотя бы одно звено выпадает — инструмент превращается в накопитель данных.

🤩 Есть два типа запросов. «Нам нужен NPS» — это инструментный запрос: команда называет решение, не понимая проблему. «Мы теряем пользователей после онбординга и не понимаем почему» — это зрелый запрос. И разница здесь значительная, хотя внешне оба выглядят как работа с фидбэком.

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

🤩 Хороший пилот — это не «поставим форму и посмотрим». Это контролируемый эксперимент: конкретная зона, чёткая гипотеза и готовность действовать по результатам.

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

🤩 Забрать гайд можно у нас в Библиотеке

🧑‍💻 Вы знаете, что мы очень любим тему Customer Success и активно развиваем это направление в UX Feedback. Поэтому мы стараемся не пропускать профильные вебинары, конференцие и прочие мероприятия.

Мы часто бываем у Марины Востриковой в качестве гостей и спикеров, и очень скоро собираемся на ее новый эфир «Ленивый анализ аномалий в CS: как найти причину ухудшения метрики без data science». Он пройдет 9 июля в 17:00.

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

💗Все детали и ссылку на эфир можно забрать в чате мероприятия.
______

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

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

Коротко напомним, о чём мы там дискутировали:

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

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

🤩 Запись круглого стола — здесь

👩‍🔧 Привет, это Женя, CEO UX Feedback.

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

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

Обычно команды работают с тем, что лежит на поверхности:
🤩 обращения в поддержку
🤩 ответы на анкеты
🤩 сообщения из форм на сайте

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

❌ А теперь самое неприятное: большинство пользователей ничего не пишет. Они сталкиваются с проблемами, думают:
🤩 «тут неудобно»
🤩 «что-то странно работает»
🤩 «не хочу здесь ничего покупать»

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

Потому что именно там — основная ценность:
🤩 реальные причины оттока
🤩 скрытые барьеры
🤩 моменты, где продукт «ломается»

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

👩‍🔧 Свое решение для работы с фидбэком почти всегда начинается с ощущения простоты. Кажется, что задача очевидная: собрать форму, прикрутить бэкенд, начать получать ответы. И в каком-то смысле так и происходит — пользователи что-то пишут, данные копятся, команда чувствует, что «процесс запущен».

Но довольно быстро вы понимаете вот что: информации становится больше, а ясности — нет. Это происходит потому, что сбор фидбэка — это только первый шаг. Дальше нужна система, которой обычно нет.

В итоге фидбэк начинает расползаться:
💗 где-то лежат ответы
💗 где-то идут обсуждения
💗 где-то формируется бэклог
💗 но это не превращается в изменения продукта

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

И продукт постепенно уезжает в сторону. В этот момент своё решение начинает вредить:
💗 создаёт иллюзию, что вы «слушаете пользователей»
💗 забирает ресурсы на нерелевантные задачи
💗 закрепляет неправильные продуктовые решения

Самое опасное здесь — не отсутствие фидбэка, а ощущение, что с ним уже всё в порядке.

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

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

🤩 Подробнее — в нашей новой статье: «Своя разработка или готовый сервис: что выбрать для работы с обратной связью?»

👩‍🔧 Мы разобрали 83 286 жалоб пользователей онлайн-аптек. И вот что нас удивило.

Почти половина всех жалоб — про карточку товара. Не про доставку. Не про цены. Не про сайт.

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

А конкурент — буквально в одном клике. Другая аптека, агрегатор или маркетплейс.

Но это далеко не единственный вывод.

Например, из интервью с представителями рынка мы выяснили, что наличие препарата входит в число главных причин выбора онлайн-аптеки наряду с ценой (73%) и удобством покупки (24%). А в анализе пользовательских жалоб хорошо видно, почему даже при наличии нужного товара клиенты всё равно уходят без покупки.

👩‍⚕️ Именно такие закономерности мы собрали в нашем исследовании:

📍анализ 83 286 пользовательских жалоб;
📍9 ключевых тем, которые чаще всего влияют на опыт клиентов;
📍реальные цитаты пользователей;
📍выводы о том, какие проблемы сильнее всего влияют на конверсию и удержание.

✅ Если хотите получить отчет с данными, инсайтами и голосом самих пользователей рынка — оставьте "+" в комментариях, и мы отправим его вам в личные сообщения.

👩‍🔧 Идея сделать своё решение почти всегда продаётся через экономию. На старте это звучит логично: «зачем платить за сервис, если можно собрать свой инструмент». И на этом этапе обычно считают только одно — разработку MVP:

📍прикинули 2–3 месяца
📍сравнили со стоимостью сервиса
📍приняли решение «делаем сами»

Дальше реальность почти всегда идёт по другому сценарию. Сначала уезжают сроки — 2–3 месяца незаметно превращаются в 10–12, потому что сложность растёт быстрее, чем её успевают закладывать в план.

Потом подключаются ресурсы, о которых на старте почти никто не думает: тестирование, поддержка, DevOps, аналитика — каждый из них добавляет свою строчку в бюджет.

А затем начинается самое дорогое — постоянная доработка. Сценарии, которые казались законченными, приходится пересобирать заново.

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

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

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

➡️ Забрать материал в Библиотеке

💻 Цена — главный повод прийти в онлайн-аптеку. И один из самых серьезных поводов уйти.

35% жалоб на оплату в нашем отчёте по фарме про то, что цена на сайте и цена в чеке не совпадают. Ещё 17% — промокод применён, но цена не изменилась. 13% — бонусы списались, но не так, как ожидалось.

Все три — варианты одного и того же: пользователь планировал заплатить одну сумму, заплатил другую. По данным Baymard Institute, это причина №1 брошенных корзин в онлайн-магазинах — 39% покупателей уходят именно из-за этого.

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

👩‍⚕️ Если вы работаете в онлайн-фарме и хотите понять, где именно у вас теряются пользователи — напишите нам. Разберём ваш конкретный сценарий и покажем, как такие сигналы ловятся до того, как становится поздно.

🤩 Связаться с нами