Опыт настройки каналов сбора обратной связи (ОС) от пользователей
Меня зовут Владислава, я — исследователь в Контуре и работаю с несколькими продуктами в направлении недвижимости.
В моем направлении процесс получения обратной связи был непрозрачен, из-за чего мы ее практически не получали. Она как-то приходила через разных людей в продуктах — менеджеров по продажам, внедрения, активации и техподдержки. Часть заносилась в бэклог разработки в Trello, часть приходила в Slack, и еще часть доносилась голосом до члена команды разработки. Менеджеры сами решали, какие отзывы заносить, а какие нет. В итоге я не понимала, ни как устроен процесс обработки и получения ОС, ни что болит у пользователей.
В статье расскажу о том, какие каналы мы с командой попробовали, как это делали, с какими проблемами столкнулись и как обстоят дела сейчас.
Сразу скажу что я все еще нахожусь в процессе оценки эффективности каналов. Однако статья уже сейчас поможет тем, кто столкнулся с недостаточностью информации от пользователей и не получает желаемого результата от используемых в работе каналов. Вы можете прочитать и начать действовать не дожидаясь моих результатов, так как у каждого он будет свой.
Как начиналось
Я не сразу осознала, что мне чего-то не хватает. Но постепенно, набираясь исследовательского опыта в команде, поняла, что описанная выше ситуация не дает качественно решать мои задачи:
- оценивать текущую ситуацию, зная о проблемах с которыми сталкиваются пользователи
- учитывать эту информацию при редизайне сервиса
- получать быструю ОС после релиза, чтобы оперативно исправлять недостатки.
Осознав это, я составила план, который должен был помочь наладить ситуацию. Мне нужно было:
- Пообщаться со всеми, кому важно получение ОС.
- Пообщаться с теми, кто уже получает ОС от пользователей и в перспективе может получать.
- Организовать приток ОС из возможных каналов.
- Оценить ее качество и объем.
- Пожить с этим, чтобы понять, устраивает ли меня результат и что делать дальше.
Изначально в направлении ОС приходила только из техподдержки, от менеджеров внедрения и продаж. Сейчас ОС приходит из шести каналов:
- опросы в сервисе
- обращения в техподдержку
- отдел внедрения
- отдел активации
- отдел продаж
- отдел маркетинга.
Каждый канал приходилось настраивать по-своему, ниже расскажу, как выстраивался процесс по каждому из них.
Опрос в сервисе
Кажется, это самый очевидный способ сбора комментариев от пользователей и получения недостающей информации. С него мы и решили начать. На встрече с командой разработки обсудили, что хотим в целом получать ОС о работе с сервисом и посмотреть, какая она будет и какую пользу принесет.
Опыта составления опросов у меня и у команды было немного. Раньше мы два раза пробовали организовывали несколько опросов с помощью Typeform. Но ничего не вышло, ответов было совсем мало. А в процессе выявилось несколько проблем:
- У меня и команды не было четкого понимания, зачем это нужно.
- На разработку опросника нужно было потратить ресурс разработки. Но мы не понимали, обоснованные ли это траты.
- Было неясно, как быстро вставить опрос с помощью другого сервиса, чтобы стилистически он не выглядел инородно.
Тогда у меня вырос страх перед использованием этого метода исследования. Я поняла, что мне не хватает знаний, что разработка затратила свой ресурс, а результата не получила. Мне тяжело было признаться себе и команде в некомпетентности. Пришлось уделить много времени на изучение продукта и получение опыта, чтобы страх пропал и я смогла принять, что могу знать не все и нормально обратиться за помощью. После этого процесс сильно ускорился и я предприняла следующие шаги:
- Пообщалась со своей командой и уже сформировала понимание зачем нам нужны опросы, какую информацию хотим получать и почему, как можно встроить опрос.
- Изучила опыт других команд, чтобы узнать какие варианты опросов используют, какими сервисами пользуются и какая механика встраивания опросов в сервис существует.
После проделанного, я четко понимала для чего нам опросы и какие именно в сервисе нужны. Мы разделили их на 3 вида:
- Опрос на получение постоянной ОС, которая всегда встроена в сервис.
- Опрос, который встраивается в новый сценарий после релиза, чтобы команда смогла быстро реагировать на возникшие проблемы, а также получать положительный отклик от тех, для кого они старались.
- Опрос, который встраивается на определенный срок, чтобы собрать недостающую информацию по процессам работы и удовлетворенность пользователей. Он настраивается под необходимые параметры.
Опрос на получение постоянной ОС в сервисе
Изначально мы встроили опрос в виджет, который было видно на каждой странице сервиса. Пользователь мог оценить сервис и написать развернутый комментарий.
В итоге пользователь не стремился заполнять опрос, ответов было очень мало, из которых мы понимали только, то что в сервисе есть технические проблемы. С января 2021 года по май 2022 года пришло всего около 70 ответов. Получив такие результаты, я предположила, что если мы будем встраивать опрос в конкретный сценарий и просить оценить его, то ответов будет больше и ОС будет качественнее, так как пользователи будут сразу видеть анкету после прохождения конкретного сценария, и именно по нему будет оставлять конкретную, точную ОС.
Отказываться от этой ОС мы не хотели, но и не видели смысла показывать его в сервисе на всех страницах. Визуально он делал сервис грязным, поэтому мы его перенесли. Он до сих пор приносит ОС, в еще меньшем количестве и все также о технических проблемах. Пользы для улучшения продуктов от подобной ОС мы не получили.
Опросы после релизов для определенного сценария
Мы решили встраивать опросы в конкретные сценарии, по которым у нас есть сомнения, гипотезы или просто нет ничего, так как сценарий новый.
Здесь процесс был сложнее. Команда не приходила с запросом на ОС перед запуском фич/сценариев: мы не обсуждали метрики, вопросы и гипотезы. Поэтому на первых порах я стала самостоятельно организовывать встречи перед релизами. Когда задача переходила в разработку, я назначала встречу на проектировщика и аналитика. Так я узнавала, какие вопросы или сомнения есть, что хотелось бы узнать о сценарии или пользователе, а после принимала решение о необходимости исследования и методе.
Отсюда выросла задача встройки опроса в сам сценарий и необходимость получения более точечной ОС от пользователей. Также мы начали обсуждать установку метрик — это тоже победа и значительный рывок вперед, но о нем в другой раз.
Мы уже провели несколько опросов с помощью которых, узнали о недовольстве пользователей и очень быстро исправили замечания.
Опрос на определенный период с настройкой под необходимые параметры
Через какое-то время к нам пришли маркетологи с просьбой запустить в сервисе опрос NPS. Команде разработки оставалось его только встроить.
Плашку с опросом закрепили на первых страницах, ее видели все, кто заходил в сервис. Она была яркая, с понятным лаконичным вопросом и мгновенной возможностью оценить сервис от 1 до 10. Но это была обманка:при нажатии на варианты ответов, пользователя перекидывало на отдельную страницу с опросом. Но сам факт понятного и легкого входа помог пользователю зайти на опрос и ответить на несколько вопросов анкеты.
За 1,5 месяца получилось собрать 166 ответов. Это был рекорд для продукта, ведь у нас не так много активных пользователей. Этот опыт помог понять, что процесс установки опроса может замыкаться не только на мне: можно привлекать и другие отделы например, дизайнеров и копирайтеров. Тогда градус ответственности снижается, а задача делается быстрее и интереснее. Я также поняла, что важно формулировать короткий и понятный вопрос на входе. Мой страх к проведению исследования с помощью опросов на этом этапе пропал.
В итоге у команды получилось попробовать несколько вариантов сбора ОС. Это помогло:
- Оценить какой формат опросов приносит реальную пользу в развитии сервиса и что влияет на пользователей, чтобы заполнить анкеты.
- Замотивировать команду на обсуждение и размещение опросов в сервисе.
- Получить достаточное количество ОС, которая повлияла на скорость внесения корректировок в сервисе или понимания масштаба проблемы.
Обратите внимание, что в процессе обсуждения опросов не стоит экономить время на четкое формулирование и фиксирование условий: место размещения в сценарии, условия появления опроса и завершения, ЦА и тд. Иначе вы можете не получить желаемых результатов. Например, когда мы встраивали первый опрос, то не учли некоторые сценарные моменты и в итоге опрос увидело совсем мало пользователей, что повлияло на результат.
Обращения в техподдержку
Для меня это самый интересный и таинственный канал. Я понимала, что в техподдержку (ТП) поступает огромное количество ОС. Но как в ней разобраться, обработать, а главное понять, надо ли это делать, для меня было загадкой.
Я начала с того, что пообщалась с экспертом и настроила ежемесячное получение двух отчетов:
- Топ знаний с большим количеством обращений за месяц и общее их количество.
- Общую сводку по всем знаниям.
Несколько месяцев я наблюдала за динамикой цифр и не понимала, какие выводы, кроме изменения количества инцидентов за месяц и смены списка топ-знаний я могу делать. Понимала только, что мне нужны качественные данные, чтобы разобраться.
Я выгружала отчеты, анализировала их и рассказывала команде. На эту работу уходило много времени, иногда до двух недель. А результата я не замечала, и не видела большого отклика от команды. Однако понимала, что эта информация важна и ее нужно анализировать.
Через какое-то время я призвала на помощь аналитика. Мы поняли, что на эту работу не должно уходить много времени. Разработке важно понимать именно аномалии в конкретном месяце, а также отслеживать динамику знаний, которые попадают в топ-5 обращений.
В итоге у нас получилась полуавтоматическая таблица, в которую мне оставалось загружать данные и я сразу могла понять наличие аномалий в текущем месяце и уже их сопоставить с релизами, оценить взаимосвязь и, если надо, покопать дальше. Если аномалий не было, анализировать информацию отдельно не приходилось.
Из этой активности вырастали задачи на исследования. Помимо оценки аномалий я анализировала обращения, которые из месяца в месяц оставались в топе.
При анализе стало понятно, что комментарии менеджеров техподдержки очень расплывчатые и из них тяжело понять проблемы. Менеджеру было невыгодно заносить информацию более конкретно, так как на это у него уходило много времени. Однако с предложением к нам пришел сам эксперт техподдержки. Он предложил добавить динамичное поле «Описание проблемы», которое надо заполнять обязательно, чтобы завершить работу с клиентом. Это поле появилось всего в четырех знаниях, данные которых нас больше всего интересовали.
Сейчас эта активность находится в тестовом формате, в ближайшее время я займусь анализом полученных данных и смогу рассказать о выводах.
Обратная связь от отдела внедрения
Дальше расскажу о каналах внедрения и активации. Знаю, что не во всех компаниях они есть, поэтому хочется объяснить, чем они занимаются.
Внедрение помогает клиентам начать использовать продукт и настроить его под себя. Активация подключается, если клиент не использует сервис. Отдел выясняет причины отказа и помогают встроить продукт в рабочие процессы компании или приносят идеи в разработку по развитию.
Внедрение и раньше приносило ОС от пользователей. Они заносили ее частично в бэклог разработки, частично — в Slack. В Slack в основном попадали технические проблемы, которые решались сразу же.
В бэклог разработки поступали именно пожелания. Однако было несколько проблем с которыми мы сталкивались:
- Приходили задачи, а не проблемы.
- Критерии задачи были описаны некачественно. Непонятно, для чего пользователю это нужно: как часто он сталкивается с проблемой, как она мешает работе, что он делает, чтобы изменить ситуацию.
- Не было подсчета количества обращений.
- Менеджеры сами оценивали задачи. Основываясь на своем опыте они решали заносить ли ОС на доску для разработки. Поэтому много отзывов до нас не доходило.
Что мы сделали и что у нас получилось
Мы с командой решили попробовать несколько новых способов сбора ОС:
- Добавить опрос, который отправляется клиенту, который закончил обучение в сервисе.
- Иногда присутствовать на встречах, когда внедрение помогает пользователям со сделкой.
- Выборочно прослушивать звонки внедрения с клиентами.
Также мы обсуждали вариант заполнения анкеты или файла самими менеджерами по внедрению. Однако поняли, что это отнимает много ресурсов и это делать нежелательно.
Что в итоге получилось:
- Мы добавили анкету в рассылку по двум продуктам. Этот способ не принес результатов: за несколько месяцев мы не получили ни одного ответа.
- Совместное присутствие во время внедрения пользователя дало много инсайтов по сценарию. Получилось составить карту сценария и расписать проблемные места, с которыми сталкивались новые пользователи. Однако стало понятно, что этот способ отнимает много ресурсов: нужно всех состыковать по времени, бросать задачи и отменять назначенные встречи и подключаться к внедрению клиента. При этом одна сделка может длиться день или даже два. Поэтому без конкретной задачи такой способ также не подходит.
- На прослушку также надо выделять много времени, и без конкретной задачи или гипотезы она не имеет большого смысла. Этот метод хорош, когда новому исследователю в команде хочется понять пользователей, изучить сценарий и проблемы при его прохождении.
На данный момент мы поняли, что все выбранные варианты сбора ОС нам не подходят. Это очень тяжело осознавать, так как потрачено много сил.
Обратная связь от отдела активации
У активации дела обстоят немного иначе, чем у внедрения. Существует два типа пользователей с которыми работает отдел:
- Отказники, которые пользуются другим сервисом например, банковским, так как в нем есть возможности, которых у нас нет и не будет из-за специфики.
- Недовольные сервисом или те, кто купил сервис, но не пользуется.
Для меня, как для исследователя, была интересна именно вторая категория. ОС от них собиралась в отдельный файл. Но в отзывах также не было конкретики. Непонятно было даже, в чем именно заключается проблема, насколько она критична.
Также в CRM-системе компании использовалась анкета, которую заполняли менеджеры при работе с клиентом.
Что мы сделали и что у нас получилось
Мы с активацией решили немного доработать эту анкету под сбор ОС. Сейчас эта анкета тестируется на одном менеджере. После анализа мы планируем расширить ее на весь отдел активации.
Обратная связь от отдела продаж
В нашем направлении взаимодействие между отделом продаж и клиентами строится не совсем типично для остального Контура. У нас менеджер обычно закрепляется за клиентом на девять месяцев, поэтому клиенты часто связываются с ними и оставляют ОС.
Для отдела продаж у нас есть группа в корпоративной соцсети, где все менеджеры пишут пожелания от пользователей. От менеджеров приходили жалобы, что разработка не берет задачи, которые от них приходят. Были случаи, когда разработка узнавала о проблеме, о которой уже давно знали в отделе продаж.
Проблема была и с критериями сбора ОС и донесением ее до разработки. Эта проблема встречалась и у внедрения, и у активации. Я писала о ней выше.
При обсуждении с командой мы решили добавлять всю ОС в виде инцидента, который будет падать на эксперта техподдержки. А эксперт будет добавлять ОС в бэклог разработки или, если доработка нужна срочно, напрямую команде. После этого команда разработки будет разбирать поступившие запросы раз в две недели.
Мы описали критерии, которые обязательно нужно указать:
- данные клиента и его текущий чек за год
- описание задачи или проблемы
- как сейчас клиент справляется с проблемой
- как часто он с ней сталкивается
- потенциал клиента
- сколько у него юрлиц.
Какие-то критерии заносит именно менеджер по продажам, а что-то добавляет эксперт у которого есть информация по обращениям в техподдержку. Процесс должен работать и в обратную сторону: когда у эксперта или у менеджера по внедрению появляется пожелание, он отправляет его продажам, чтобы заполнить недостающие критерии.
Этот процесс уже имеет свои плоды. В бэклог стало поступать больше подробной ОС, у которой можно сразу оценить приоритет. При этом есть опыт, когда подобная ОС сразу ушла в задачу на разработку.
На данный момент канал получения ОС через отдел продаж является одним из самых эффективных.
Информация от отдела маркетинга
Я добавила и этот канал, хотя он не совсем вписывается в статью. Почему я это сделала?
После коммуникаций с маркетологами я поняла, что отдел в направлении проводит много исследований аудитории и владеет полезными данными, которыми можно пользоваться и во время разработки сервиса и при построении например, CJM.
Мы договорились обмениваться данными из исследований и приглашаем друг друга на встречи, где проходит презентация исследования.
Благодаря этой активности у нас появилась общая база с исследованиями. В моей работе это очень ценный инструмент, который помогает лучше узнать аудиторию и их сценарии, а также оценить необходимость доработки.
Итоги
Вот, что изменилось за почти два года моей работы:
- Увеличился объем ОС от пользователей.
- Я стала лучше понимать свою аудиторию и процессы.
- Могу оценить картину в целом по разным продуктам, понимаю какие проблемы для пользователя являются самыми болезненными и оценить их в динамике
- Команда разработки стала быстрее брать в работу задачи, которые поступают от продаж
- Сформировались четкие критерии сбора ОС для менеджеров разных ролей
- Выстроился процесс получения ОС после релизов новых сценариев и фич. Что помогает быстро оценить ситуацию и внести изменения.
- В целом улучшились коммуникации между членами команды
Не все прошло и проходит так гладко. В процессе работы мне пришлось встретиться с несколькими проблемами:
- Нежелание коллег менять процессы или встраивать новый процесс в работу.
- Расход большого количества времени и иногда невозможность быстро проанализировать тот или иной канал сбора ОС, чтобы внести изменения.
- Отсутствие отдачи от некоторых каналов по сбору ОС, маленький объем ОС.
Для себя лично отметила огромные плюсы от работы над этой задачей:
- Набралась опыта в коммуникации с разными отделами и постановки им задач.
- Попробовала разные подходы к одной и той же задаче.
- Попрощалась со страхами в использовании метода исследования.
- Изучила новые для себя процессы в компании.
- Получила огромный интерес к работе и желание помогать команде и развивать продукты.
- Почувствовала поддержку от команды, что очень ценно.
Что бы посоветовала
В статье я описала свой опыт, свои страхи и проблемы с которыми сталкивалась. Главное — не повторять мой опыт, а понять, что есть разные варианты решения задачи. Испытывать трудности и что-то не знать — нормально. Поэтому не бойтесь обращаться за помощью к членам команды и решать задачи совместно.
Как вы уже поняли из статьи, я сама где-то на середине пути и не могу посоветовать какой-то конкретный канал для сбора ОС. Пробуйте разное и подходящее для своего продукта.
Только небольшой совет — не беритесь за все разом. Лучше идите поэтапно, возможно так будет даже быстрее, но это не точно, потому что я выбрала другой путь.
